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
<ckawc...@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 <bal...@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
