Mailing List Archive

Ran into the same bug.

$junos-preffered-source-address for an unnumbered for BNG functions does NOT return the "closest/must suitable address" based on the IP+Subnet that was given the subscriber... contrary to the BNG template doucmentation. It just defaults the actual loopback of the router. (the dynamic template that gets created against a demux0.xxxx subscriber says $preffered of "NONE")

This means that things like Subscriber "ARP liveliness detection" doesn't work/cant work. (since the subscriber won't arp-respond to an ARP requests where the source isn't in the local subnet)

I've had a JTAC case open on this for 8 months. Sent full configs, built a full lab for them (so they could trigger it remotely), self full PCAPs.

MX204 + JunOS 18.3Rxxxx + BNG (DHCP/IPoE naturally)

Also on MX80 w/same code - so it's the BNG code, not the platform doing it.

- Ck.




> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl <baldur@gigabit.dk> wrote:
>
> Hello
>
> I have a problem where some customer routers refuse to reply to arp from
> our juniper mx204. The arp will look like this:
>
> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
>
> The problem is that this should have been "tell 185.24.169.1" because the
> client is in the 185.24.169.0/24 subnet. The interface is
> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
> 185.24.169.1 among many others. A Linux box would select the nearest
> address but apparently junos does not know how to do this.
>
> Tried adding in "preferred-source-address $junos-preferred-source-address"
> but this just results in "preferred-source-address NONE" and does nothing.
> Also there is zero documentation on how junos will fill in that variable.
>
> Is there a solution to this? Is there a radius variable I can set with the
> preferred source address?
>
> Regards,
>
> Baldur
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Yes subscriber management has a lot of small but important things that are
not quite "done". Juniper should put on a task force to get all the bugs
sorted out. Could be a great system if they allow it to be.

For me the trouble with this is that without functioning ARP the customer
becomes "MAC locked". If he wants to upgrade his equipment, he has to call
us so we can clear his session. We have two routers and sometimes a user
somehow manages to register with different MAC addresses on the two.
Needless to say that creates a lot of trouble that will not sort itself
out. With functioning ARP I believe the wrong MAC address would be
corrected soon enough without intervention.

I wish I could just have a user defined radius variable and use that
instead of $junos-preferred-source-address. My script that generates that
radius configuration could easily calculate the correct source address and
program that in with the other radius variables for each user.

I am not creating a JTAC case on this before I have a fix for my other JTAC
cases (IPv6 is broken, dynamic VLAN with IP demux on top is broken, DHCP
combined with non-DHCP is likely also broken). So far I got IPv4 fixed
(access-internal routes ignored, work around use access routes), so they do
work on the problems I report.

Regards,

Baldur


Den man. 27. jan. 2020 kl. 04.53 skrev Chris Kawchuk <ckawchuk@gmail.com>:

> Ran into the same bug.
>
> $junos-preffered-source-address for an unnumbered for BNG functions does
> NOT return the "closest/must suitable address" based on the IP+Subnet that
> was given the subscriber... contrary to the BNG template doucmentation. It
> just defaults the actual loopback of the router. (the dynamic template that
> gets created against a demux0.xxxx subscriber says $preffered of "NONE")
>
> This means that things like Subscriber "ARP liveliness detection" doesn't
> work/cant work. (since the subscriber won't arp-respond to an ARP requests
> where the source isn't in the local subnet)
>
> I've had a JTAC case open on this for 8 months. Sent full configs, built a
> full lab for them (so they could trigger it remotely), self full PCAPs.
>
> MX204 + JunOS 18.3Rxxxx + BNG (DHCP/IPoE naturally)
>
> Also on MX80 w/same code - so it's the BNG code, not the platform doing it.
>
> - Ck.
>
>
>
>
> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl <baldur@gigabit.dk> wrote:
>
> Hello
>
> I have a problem where some customer routers refuse to reply to arp from
> our juniper mx204. The arp will look like this:
>
> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
>
> The problem is that this should have been "tell 185.24.169.1" because the
> client is in the 185.24.169.0/24 subnet. The interface is
> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
> 185.24.169.1 among many others. A Linux box would select the nearest
> address but apparently junos does not know how to do this.
>
> Tried adding in "preferred-source-address $junos-preferred-source-address"
> but this just results in "preferred-source-address NONE" and does nothing.
> Also there is zero documentation on how junos will fill in that variable.
>
> Is there a solution to this? Is there a radius variable I can set with the
> preferred source address?
>
> Regards,
>
> Baldur
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Interesting. I have observed a while ago that "preferred" doesn't work
for IPv6. Opened TAC case and eventually was told that "it doesn't work
for IPv6". Turns out that it's also broken for IPv4, but we do PPPoE, so
DHCP is running only for IPv6, so didn't get into IPv4 issue. The
workaround in my case was to use broadband loopback address as primary,
thanks that it's not so critical as IPv4 primary loopback.
As we are looking into possible IPoE implementation for some services,
thanks for heads up.

Kind regards,
Andrey Kostin

Baldur Norddahl ????? 2020-01-27 00:24:
> Yes subscriber management has a lot of small but important things that
> are
> not quite "done". Juniper should put on a task force to get all the
> bugs
> sorted out. Could be a great system if they allow it to be.
>
> For me the trouble with this is that without functioning ARP the
> customer
> becomes "MAC locked". If he wants to upgrade his equipment, he has to
> call
> us so we can clear his session. We have two routers and sometimes a
> user
> somehow manages to register with different MAC addresses on the two.
> Needless to say that creates a lot of trouble that will not sort itself
> out. With functioning ARP I believe the wrong MAC address would be
> corrected soon enough without intervention.
>
> I wish I could just have a user defined radius variable and use that
> instead of $junos-preferred-source-address. My script that generates
> that
> radius configuration could easily calculate the correct source address
> and
> program that in with the other radius variables for each user.
>
> I am not creating a JTAC case on this before I have a fix for my other
> JTAC
> cases (IPv6 is broken, dynamic VLAN with IP demux on top is broken,
> DHCP
> combined with non-DHCP is likely also broken). So far I got IPv4 fixed
> (access-internal routes ignored, work around use access routes), so
> they do
> work on the problems I report.
>
> Regards,
>
> Baldur
>
>
> Den man. 27. jan. 2020 kl. 04.53 skrev Chris Kawchuk
> <ckawchuk@gmail.com>:
>
>> Ran into the same bug.
>>
>> $junos-preffered-source-address for an unnumbered for BNG functions
>> does
>> NOT return the "closest/must suitable address" based on the IP+Subnet
>> that
>> was given the subscriber... contrary to the BNG template
>> doucmentation. It
>> just defaults the actual loopback of the router. (the dynamic template
>> that
>> gets created against a demux0.xxxx subscriber says $preffered of
>> "NONE")
>>
>> This means that things like Subscriber "ARP liveliness detection"
>> doesn't
>> work/cant work. (since the subscriber won't arp-respond to an ARP
>> requests
>> where the source isn't in the local subnet)
>>
>> I've had a JTAC case open on this for 8 months. Sent full configs,
>> built a
>> full lab for them (so they could trigger it remotely), self full
>> PCAPs.
>>
>> MX204 + JunOS 18.3Rxxxx + BNG (DHCP/IPoE naturally)
>>
>> Also on MX80 w/same code - so it's the BNG code, not the platform
>> doing it.
>>
>> - Ck.
>>
>>
>>
>>
>> On 25 Jan 2020, at 10:27 pm, Baldur Norddahl <baldur@gigabit.dk>
>> wrote:
>>
>> Hello
>>
>> I have a problem where some customer routers refuse to reply to arp
>> from
>> our juniper mx204. The arp will look like this:
>>
>> 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248
>>
>> The problem is that this should have been "tell 185.24.169.1" because
>> the
>> client is in the 185.24.169.0/24 subnet. The interface is
>> "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and
>> 185.24.169.1 among many others. A Linux box would select the nearest
>> address but apparently junos does not know how to do this.
>>
>> Tried adding in "preferred-source-address
>> $junos-preferred-source-address"
>> but this just results in "preferred-source-address NONE" and does
>> nothing.
>> Also there is zero documentation on how junos will fill in that
>> variable.
>>
>> Is there a solution to this? Is there a radius variable I can set with
>> the
>> preferred source address?
>>
>> Regards,
>>
>> Baldur
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp