[j-nsp] arp bug workaround (mx204)

[Krasimir Avramski]

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
>