Hi,
VM101 has a leg into vn0799.
VM101 gets an IP address (192.168.30.2) from DHCP server (192.168.30.254) that sits behind a switch.
VM101 can ping forever 192.168.30.254, but when it tries to ping something beyond the next-hop (192.168.30.254) i.e. no in the same broadcast domain, either eno3 or eno4 sends the replies on behalf of the remote destination and with source address 0000.0000.0000.
Actually this just happens after the 2nd ICMP reply that comes from the remote IP, then the card generates ICMP replies with the NULL MAC address.
I captured on eno3 and eno4, on bond1, on vmbr1, up to the interface of the VM
I deactivated one enoX at time, to exclude a failure of the network card (though it would be really weird), always the same behaviour.
The issue is reproducible 100% of the times (at least in my environment)
I've been scratching my head the whole afternoon, I have never seen such a behaviour, should you have any hint to share with me, I'm completely puzzled.
By accident (I don't know if it is related to the issue above) I had a look at the switch of the zone and I saw the following:
There are more than 4000 entries for the two MAC addresses 1a:b0:11:ee:33:a5, 22:1b:20:67:99:67 that fill up (I guess the TCAM memory, the total number of entries is close 8190 that is very close to 8192, that might be the max number of entries, it's just a guess! I wouldn't know how to check)
See captures for eno3 (b8:2a:72:da:c3:d6) and eno4 (b8:2a:72:da:c3:d8), where ICMP requests left eno3 and ICMP replies entered eno4.
As I have already said, I shutdown on the switch one port at time, and this switch to 0000.0000.0000 happens with either port
You also have dump_eno04_02.pcap where you can find normal ICMP replies from 192.168.30.254 and weird (after the 2nd) for an IP address on the Internet.
Alex
Code:
+---z1ad0101----vn0101
eno3+ |
+--bond1---vmbr1----+---z1ad0102----vn0102
eno4+ |
+---z1ad0799----vn0799
VM101 has a leg into vn0799.
VM101 gets an IP address (192.168.30.2) from DHCP server (192.168.30.254) that sits behind a switch.
VM101 can ping forever 192.168.30.254, but when it tries to ping something beyond the next-hop (192.168.30.254) i.e. no in the same broadcast domain, either eno3 or eno4 sends the replies on behalf of the remote destination and with source address 0000.0000.0000.
Actually this just happens after the 2nd ICMP reply that comes from the remote IP, then the card generates ICMP replies with the NULL MAC address.
I captured on eno3 and eno4, on bond1, on vmbr1, up to the interface of the VM
I deactivated one enoX at time, to exclude a failure of the network card (though it would be really weird), always the same behaviour.
The issue is reproducible 100% of the times (at least in my environment)
I've been scratching my head the whole afternoon, I have never seen such a behaviour, should you have any hint to share with me, I'm completely puzzled.
By accident (I don't know if it is related to the issue above) I had a look at the switch of the zone and I saw the following:
Bash:
root@pve01:~# brctl showmacs z_z1ad0799 | wc -l
8191
root@pve01:~# brctl showmacs z_z1ad0799 | uniq
port no mac addr is local? ageing timer
2 1a:b0:11:ee:33:a5 yes 0.00
1 22:1b:20:67:99:67 yes 0.00
1 e8:ed:d6:eb:34:b2 no 109.52
root@pve01:~#
root@pve01:~#
root@pve01:~#
root@pve01:~# brctl showmacs z_z1ad0799 | grep 1a:b0:11:ee:33:a5 | wc -l
4095
root@pve01:~# brctl showmacs z_z1ad0799 | grep 22:1b:20:67:99:67 | wc -l
4094
There are more than 4000 entries for the two MAC addresses 1a:b0:11:ee:33:a5, 22:1b:20:67:99:67 that fill up (I guess the TCAM memory, the total number of entries is close 8190 that is very close to 8192, that might be the max number of entries, it's just a guess! I wouldn't know how to check)
See captures for eno3 (b8:2a:72:da:c3:d6) and eno4 (b8:2a:72:da:c3:d8), where ICMP requests left eno3 and ICMP replies entered eno4.
As I have already said, I shutdown on the switch one port at time, and this switch to 0000.0000.0000 happens with either port
You also have dump_eno04_02.pcap where you can find normal ICMP replies from 192.168.30.254 and weird (after the 2nd) for an IP address on the Internet.
Alex
Attachments
Last edited: