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