[j-nsp] arp bug workaround (mx204)

Wed Apr 14 05:57:46 EDT 2021

Hello

I finally had time to implement this, but unfortunately I get this error at
commit:

admin at interxion-edge1# commit
error: Underlying interface for vlan/ip demux can't be ps
error: configuration check-out failed

This is on mx204 version 21.1R1.11.

Was something changed to disallow ip demux on top of VPLS ps interfaces? Is
there an alternative to the ps interface? Krasimir appears to have a
successful test, what is the difference?

If you need the full config that I am trying to commit, please send a
direct mail. It contains user IP addresses so I am not happy about having
that on the mailing list.

Thanks,

Baldur

Den tor. 5. nov. 2020 kl. 12.48 skrev Krasimir Avramski <krasi at smartcom.bg>:

> Hi Baldur,
>
> Indeed, you are persistent in asking for that issue ;-). The idea is to
> use the RFC1925 6a) - "It is always possible to add another level of
> indirection."
>
> krasi at test# show interfaces ps201 unit 60
> demux-source inet;
> vlan-tags outer 2301 inner 1711;
> family inet {
>     unnumbered-address lo0.1;
> }
>
> krasi at test# show interfaces demux0
> unit 60 {
>     demux-options {
>         underlying-interface ps201.60;
>     }
>     family inet {
>         demux-source {
>             185.24.168.2/32;
>         }
>         unnumbered-address lo0.1 preferred-source-address 185.24.168.1;
>     }
> }
> unit 61 {
>     demux-options {
>         underlying-interface ps201.60;
>     }
>     family inet {
>         demux-source {
>             212.237.105.194/32;
>         }
>         unnumbered-address lo0.1 preferred-source-address 212.237.105.1;
>     }
> }
>
> krasi at test# show routing-instances internet routing-options
> static {
>     route 185.24.168.2/32 {
>         qualified-next-hop demux0.60;
>     }
>     route 212.237.105.194/32 {
>         qualified-next-hop demux0.61;
>     }
> }
>
> krasi at test# run show interfaces demux0.60 |match "Pref|Under"
>       Underlying interface: ps201.60 (Index 528)
>       Family Inet Source prefixes, total 1
>           Prefix: 185.24.168.2/32
>       Preferred source address: 185.24.168.1
>
>
> krasi at test# run show interfaces demux0.61 |match "Pref|Under"
>       Underlying interface: ps201.60 (Index 528)
>       Family Inet Source prefixes, total 1
>           Prefix: 212.237.105.194/32
>       Preferred source address: 212.237.105.1
>
> krasi at test# run monitor traffic interface demux0.60 no-resolve
> ....
> 13:29:05.274236 Out arp who-has 185.24.168.2 tell 185.24.168.1
> 13:29:18.976788 Out arp who-has 185.24.168.2 tell 185.24.168.1
>
> krasi at test# run monitor traffic interface demux0.61 no-resolve
> .................
> 13:30:01.788921 Out arp who-has 212.237.105.194 tell 212.237.105.1
> 13:30:15.788642 Out arp who-has 212.237.105.194 tell 212.237.105.1
>
> Btw, you can use only one demux ifl for the extra ip address and set
> appropriate preferred-source-address on ps201.60 and demux0.60
>
> HTH,
> Krasi
>
> On Wed, 4 Nov 2020 at 22:02, Baldur Norddahl <baldur at gigabit.dk> wrote:
>
>> Hello
>>
>> I am trying to work around an arp bug in Junos. The issue is as follows:
>>
>> set interfaces ps201 unit 60 vlan-tags outer 2301
>> set interfaces ps201 unit 60 vlan-tags inner 1711
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> set routing-instances internet routing-options static route
>> 185.24.168.2/32
>> qualified-next-hop <http://185.24.168.2/32qualified-next-hop> ps201.60
>> mac-address b4:75:0e:15:38:9e
>> set routing-instances internet routing-options static route
>> 212.237.105.194/32 qualified-next-hop ps201.60 mac-address
>> d8:07:b6:46:7a:31
>> set routing-instances internet interface ps201.60
>> set protocols router-advertisement interface ps201.60
>>
>> The above works but hardcodes the MAC address of the customer. This is
>> necessary because there is no way to make Junos choose the correct source
>> address for ARP requests for both 185.24.168.2/32 and 212.237.105.194/32
>> at
>> the same time. You could do either of the following but not both:
>>
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> preferred-source-address 185.24.168.1
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> preferred-source-address 212.237.105.1
>>
>> With 185.24.168.1/24 and 212.237.105.1/24 both being configured on lo0.1.
>>
>> There exists an algorithm, unfortunately only mandatory for IPv6, that
>> automatically chooses the closest available address from the list of
>> possible candidate addresses. But Junos does not implement this for IPv4
>> (unknown if it does for IPv6). Instead it will always use the primary
>> address from lo0.1 if specified, otherwise a random address.
>>
>> The CPE will ignore ARP requests from the juniper router that have the
>> wrong source address. Our only solution has been to use the mac-address
>> parameter to hardcode the address, which sidesteps the issue by not using
>> ARP.
>>
>> This is also a problem with subscriber management.
>>
>> We use the above configuration for customers that paid for an extra IP
>> address. Often the extra address is from a different series than his
>> original address, because all addresses have been assigned. We can not
>> retroactively fix that as we have an existing customer base and customers
>> do not like to be told to change their static configuration, DNS names
>> etc.
>>
>> So I am searching for work arounds. For example if I could make an ACL
>> that
>> rewrites the vlans matching an IP address, such that the two IPs were on
>> two different VLANs, I could solve this by having two interfaces for the
>> customer. Alas that does not seem to be possible.
>>
>> Anyone have an idea how to create some sort of work around that does not
>> force the MAC address to be hardcoded?
>>
>> Thanks,
>>
>> Baldur
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>