[j-nsp] arp from correct IP address

[Baldur Norddahl]

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 at 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 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>