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 <bal...@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