OVS bridge port MAC addressing (why a bridge port has 2 MAC addresses)
devstack Queens single machine installation: (=OVS 2.8.1)
I am tracing via tcpdump, traffic to a VM attached to br-int The VM eth0 MAC address is (ip a, when logged into VM) :
2: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether fa:16:3e:a0:98:ed brd ff:ff:ff:ff:ff:ff
listing ports on br-int:
sudo ovs-vsctl list-ports br-int
int-br-ex
int-br-mgmt0
patch-tun
qg-ac123978-b4
qg-b87b2643-51
qr-0e9bd56d-da
qr-3653dac3-4c
qr-c9189f92-7a
qvof2c4214a-ab
tap3a9b2922-25
tap5fbaf2c6-19
tap68439ee4-28
tapfb20c21a-64
now to find which port my VM is attached I search for my MAC in following output
sudo ovs-vsctl list interface > ovs-interfaces
and find my MAC in following section of the file:
_uuid : a9ed016e-75fe-4af4-94e4-1110a95797e4
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status : []
cfm_flap_count : []
cfm_health : []
cfm_mpid : []
cfm_remote_mpids : []
cfm_remote_opstate : []
duplex : full
error : []
external_ids : {**attached-mac="fa:16:3e:a0:98:ed**", iface-id="f2c4214a-abfe-4259-a276-eb963e511a14", iface- status=active, vm-uuid="b99242d9-0543-4de6-9606-3431627d3187"}
ifindex : 101
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current : []
link_resets : 0
link_speed : 10000000000
link_state : up
lldp : {}
mac : []
**mac_in_use : "02:31:3d:c6:d6:8e"**
mtu : 1500
mtu_request : []
name : "qvof2c4214a-ab"
ofport : 31
ofport_request : []
options : {}
So I can see that my VM vif is attached to port qvof2c4214a-ab
BUT why the 2 MACs attached-mac and mac_in_use ? if I tcpdump traffic on qvof2c4214a-ab I will only see that attached-mac address (which is expected)
sudo tcpdump icmp -e -i qvof2c4214a-ab
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on qvof2c4214a-ab, link-type EN10MB (Ethernet), capture size 262144 bytes
09:02:04.300080 fa:16:3e:35:3b:b1 (oui Unknown) > fa:16:3e:a0:98:ed (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.122.1 > 192.168.120.12: ICMP echo request, id 8688, seq 1, length 64
09:02:04.300446 fa:16:3e:a0:98:ed (oui Unknown) > fa:16:3e:35:3b:b1 (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.120.12 > 192.168.122.1: ICMP echo reply, id 8688, seq 1, length 64
If I check port numbers on br-int used by Openflow:
sudo ovs-ofctl dump-ports-desc br-int
OFPST_PORT_DESC reply (xid=0x2):
1(int-br-mgmt0): addr:3e:7e:42:a7:fc:85
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
2(int-br-ex): addr:2e:06:99:9d:80:88
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
.... skipping
.....
12(qr-0e9bd56d-da): addr:fe:7f:00:00:76:28
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
31(qvof2c4214a-ab): addr:02:31:3d:c6:d6:8e
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
LOCAL(br-int): addr:ee:b8:b5:65:06:44
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
Here, however, we see the qvof2c4214a-ab port is labelled with the 'mac_in_use' MAC .
For people like me, who trace through neutron rarely, it makes searching more difficult. (made me triple check if I had correct port)
I assumed bridges were basic L2 forwarding tables (SMAC, port) , obviously openflow tables in OVS add a lot ...