[j-nsp] arp bug workaround (mx204)
Krasimir Avramski
krasi at smartcom.bg
Thu Apr 15 09:10:06 EDT 2021
Hi,
I have tested with 18.2.
With 19.4R3 I have the same commit error.
18.4 is also affected with static configuration, but once a demux is
managed by subscriber-management, the underlying ps is allowed:
show interfaces demux0.3221225477 extensive
Logical interface demux0.3221225477 (Index 536870952) (SNMP ifIndex
200000040)
(Generation 10)
Flags: Up Encapsulation: ENET2
Interface set: test
Demux:
*Underlying interface: ps0.3221225476* (Index 536870950)
I suggest downgrading to a working version with your setup and then open a
case with jtac. Seems the limit is introduced in 18.3 or 18.4
Best Regards,
Krasi
On Wed, 14 Apr 2021 at 12:57, Baldur Norddahl <baldur at gigabit.dk> wrote:
> 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
>>>
>>
More information about the juniper-nsp
mailing list