Mailing List Archive: arp bug workaround (mx204)

arp bug workaround (mx204)

Nov 4, 2020, 11:55 AM

Post #1 of 6 (1446 views)

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

Re: arp bug workaround (mx204) [ In reply to ]

krasi at smartcom

Nov 5, 2020, 3:47 AM

Post #2 of 6 (1446 views)

Permalink

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@test# show interfaces ps201 unit 60
demux-source inet;
vlan-tags outer 2301 inner 1711;
family inet {
unnumbered-address lo0.1;
}

krasi@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@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@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@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@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@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@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@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: arp bug workaround (mx204) [ In reply to ]

gert at greenie

Nov 9, 2020, 1:11 PM

Post #3 of 6 (1440 views)

Permalink

Hi,

On Wed, Nov 04, 2020 at 08:55:11PM +0100, Baldur Norddahl wrote:
> 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.

Why don't you just route the second (and further) IP to the primary IP
as gateway address? Can JunOS not resolve this indirect next-hop?

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Re: arp bug workaround (mx204) [ In reply to ]

baldur at gigabit

Nov 9, 2020, 2:16 PM

Post #4 of 6 (1440 views)

Permalink

Den man. 9. nov. 2020 kl. 22.11 skrev Gert Doering <gert@greenie.muc.de>:

> Hi,
>
> On Wed, Nov 04, 2020 at 08:55:11PM +0100, Baldur Norddahl wrote:
> > 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.
>
> Why don't you just route the second (and further) IP to the primary IP
> as gateway address? Can JunOS not resolve this indirect next-hop?
>
>
In a greenfield deployment I would do exactly that. I am also considering
telling future customers that is the only supported way. But a lot of
existing customers have a setup with a switch instead of a router, with
multiple routers or servers directly connected. A few customers even run
VRRP at their end.

I have high hopes for the solution outlined by Krasimir. I will report back
on that as soon as I can get time to test it.

Regards,

Baldur
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: arp bug workaround (mx204) [ In reply to ]

baldur at gigabit

Apr 14, 2021, 2:57 AM

Post #5 of 6 (1286 views)

Permalink

Hello

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

admin@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@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@test# show interfaces ps201 unit 60
> demux-source inet;
> vlan-tags outer 2301 inner 1711;
> family inet {
> unnumbered-address lo0.1;
> }
>
> krasi@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@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@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@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@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@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@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@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: arp bug workaround (mx204) [ In reply to ]

krasi at smartcom

Apr 15, 2021, 6:10 AM

Post #6 of 6 (1282 views)

Permalink

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@gigabit.dk> wrote:

> Hello
>
> I finally had time to implement this, but unfortunately I get this error
> at commit:
>
> admin@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@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@test# show interfaces ps201 unit 60
>> demux-source inet;
>> vlan-tags outer 2301 inner 1711;
>> family inet {
>> unnumbered-address lo0.1;
>> }
>>
>> krasi@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@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@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@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@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@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@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@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

Mailing List Archive

Mailing List Archive

Attached Files: