Re: [j-nsp] arp from correct IP address
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 : 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. 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.3R + 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 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
Re: [j-nsp] arp from correct IP address
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 : > 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. 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.3R + 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 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
Re: [j-nsp] arp from correct IP address
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. 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.3R + 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 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
