[j-nsp] arp bug workaround (mx204)

[Baldur Norddahl]

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