would this bug also affect Vyatta 6.7 ? (not Vyos)
I’m getting similar trouble in 1.1.6. So, this patch not included to official releases then?
Confirmed this appears to be the continued behaviour in 1.1.6.
The example configuration below contains different subnets on upper and lower interfaces. When communicating with hosts in 172.16.200.0/24 the arp request egresses the upper interface (eth2v24) and the arp reply is ingressed by the lower interface (eth2), causing communication failure.
set interfaces ethernet eth2 address 172.16.227.25/29
set interfaces ethernet eth2 duplex auto
set interfaces ethernet eth2 smp_affinity auto
set interfaces ethernet eth2 speed auto
set interfaces ethernet eth2 vrrp vrrp-group 24
set interfaces ethernet eth2 vrrp vrrp-group 24 virtual-address 172.16.200.9/24
set interfaces ethernet eth2 vrrp vrrp-group 24 hello-source-address ‘172.16.227.25’
set interfaces ethernet eth2 vrrp vrrp-group 24 advertise-interval 1
set interfaces ethernet eth2 vrrp vrrp-group 24 preempt true
set interfaces ethernet eth2 vrrp vrrp-group 24 priority 150
set interfaces ethernet eth2 vrrp vrrp-group 24 sync-group total
set interfaces ethernet eth2 vrrp vrrp-group 24 rfc3768-compatibility
In situations where the lower and upper interfaces have an address in the same subnet, traffic is successfully passed to the VRRP address. However, NATed traffic will be hidden behind the lowest numbered address in the subnet, irrespective of the named interface in the NAT rule. For example, the configuration below allows network communication, but traffic that should be NAT behind eth0v8 (address 5.5.5.8) will actually be processed behind eth0 (5.5.5.5).
set interfaces ethernet eth0 description INTERNET
set interfaces ethernet eth0 address 172.16.227.9/29
set interfaces ethernet eth0 vrrp vrrp-group 8 virtual-address 5.5.5.5/28
set interfaces ethernet eth0 duplex auto
set interfaces ethernet eth0 firewall in name INTERNET-IN
set interfaces ethernet eth0 firewall local name INTERNET-LOCAL
set interfaces ethernet eth0 smp_affinity auto
set interfaces ethernet eth0 speed auto
set interfaces ethernet eth0 vrrp vrrp-group 8
set interfaces ethernet eth0 vrrp vrrp-group 8 virtual-address 5.5.5.8/28
set interfaces ethernet eth0 vrrp vrrp-group 8 hello-source-address ‘172.16.227.9’
set interfaces ethernet eth0 vrrp vrrp-group 8 advertise-interval 1
set interfaces ethernet eth0 vrrp vrrp-group 8 preempt true
set interfaces ethernet eth0 vrrp vrrp-group 8 priority 150
set interfaces ethernet eth0 vrrp vrrp-group 8 sync-group total
set interfaces ethernet eth0 vrrp vrrp-group 8 rfc3768-compatibility
set interfaces ethernet eth2 description OFFICE
set interfaces ethernet eth2 address 172.16.227.25/29
set interfaces ethernet eth2 address 172.16.200.2/24
set interfaces ethernet eth2 duplex auto
set interfaces ethernet eth2 smp_affinity auto
set interfaces ethernet eth2 speed auto
set interfaces ethernet eth2 vrrp vrrp-group 24
set interfaces ethernet eth2 vrrp vrrp-group 24 virtual-address 172.16.200.9/24
set interfaces ethernet eth2 vrrp vrrp-group 24 hello-source-address ‘172.16.227.25’
set interfaces ethernet eth2 vrrp vrrp-group 24 advertise-interval 1
set interfaces ethernet eth2 vrrp vrrp-group 24 preempt true
set interfaces ethernet eth2 vrrp vrrp-group 24 priority 150
set interfaces ethernet eth2 vrrp vrrp-group 24 sync-group total
set interfaces ethernet eth2 vrrp vrrp-group 24 rfc3768-compatibility
set nat source rule 200 description “Office -> Internet”
set nat source rule 200 outbound-interface eth0v8
I would like to see the behaviour that when rfc3768-compatibility was enabled, that ARP traffic received on the lower interface was redirected to the upper interface. Also, that the NAT engine respected the interface and address configured.
Is there an existing bug tracking issue for this?
Apologies in advance for any repetition.
Thanks for the confirmation of the arp traffic interface problem.