You might be running into a Linux kernel networking detail discussed in the FAQ.
### Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this: ovs-vsctl add-br br0 ovs-vsctl add-port br0 eth0 ifconfig br0 192.168.0.5 ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal ifconfig vlan9 192.168.0.9 but other hosts that are only on VLAN 0 can reach the IP address configured on VLAN 9. What's going on? A: RFC 1122 section 3.3.4.2 "Multihoming Requirements" describes two approaches to IP address handling in Internet hosts: - In the "Strong ES Model", where an ES is a host ("End System"), an IP address is primarily associated with a particular interface. The host discards packets that arrive on interface A if they are destined for an IP address that is configured on interface B. The host never sends packets from interface A using a source address configured on interface B. - In the "Weak ES Model", an IP address is primarily associated with a host. The host accepts packets that arrive on any interface if they are destined for any of the host's IP addresses, even if the address is configured on some interface other than the one on which it arrived. The host does not restrict itself to sending packets from an IP address associated with the originating interface. Linux uses the weak ES model. That means that when packets destined to the VLAN 9 IP address arrive on eth0 and are bridged to br0, the kernel IP stack accepts them there for the VLAN 9 IP address, even though they were not received on vlan9, the network device for vlan9. To simulate the strong ES model on Linux, one may add iptables rule to filter packets based on source and destination address and adjust ARP configuration with sysctls. BSD uses the strong ES model. On Fri, Jul 15, 2016 at 04:30:37PM +0000, Chen, Weiwen wrote: > Hi Ben, > > I think I am closer to the issue. The problem is the somehow VM gets plugged > to the vswitch internal interface, not really vnet0 port, so it can hear all > mac addresses. Not sure a bug in virsh or OVS. On another setup I have 2 > vswitches: cs-eno1 and cs-eno2 with internal interfaces on port 4 and port 1 > respectively. I am surprised to see vswitch cs-eno1 has the FDB entries on > cs-eno2/port 1. Seems a bug for OVS? > > # ovs-appctl fdb/show cs-eno1 > port VLAN MAC Age > 1 1304 00:50:56:88:e3:e7 134 > 1 0 00:50:56:88:5f:c9 128 > 1 0 be:c8:a0:e0:03:77 116 > 1 0 00:50:56:88:22:42 116 > 1 0 be:c8:a0:e0:03:85 115 > > # ovs-dpctl show > system@ovs-system: > lookups: hit:694659076 missed:99684211 lost:1003 > flows: 196 > masks: hit:4482180901 total:18 hit/pkt:5.64 > port 0: ovs-system (internal) > port 1: cs-eno2 (internal) > port 2: eno2 > port 3: vnet0 > port 4: cs-eno1 (internal) > port 5: eno1 > > > > -----Original Message----- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Wednesday, July 13, 2016 4:32 PM > To: Chen, Weiwen <wei-wen.c...@hpe.com> > Cc: discuss@openvswitch.org > Subject: Re: [ovs-discuss] OVS learned duplicated FDB entries on two > different Virtual Machine interfaces > > Before, you said "I thought VM interface should be access port." If they are > actually trunk ports, then I do not understand your environment. > > OVS only learns MACs that it actually receives from a port, within the VLANs > associated with the packets. If you see the same MAC learned on multiple > VLANs, then it is because that MAC was observed within multiple VLANs. > > On Wed, Jul 13, 2016 at 09:47:29PM +0000, Chen, Weiwen wrote: > > Hi Ben, > > > > Unfortunately I need to configure the port as trunk mode as I need to bring > > up VLAN subinterfaces inside the VM. However, I do not expect OVS will > > learn the MAC of VM2 on port of VM1, right? > > > > In addition, I double checked there is no real duplicated MAC existing in > > my env. > > > > Thanks & Regards > > -weiwen > > > > -----Original Message----- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Wednesday, July 13, 2016 3:21 PM > > To: Chen, Weiwen <wei-wen.c...@hpe.com> > > Cc: discuss@openvswitch.org > > Subject: Re: [ovs-discuss] OVS learned duplicated FDB entries on two > > different Virtual Machine interfaces > > > > On Tue, Jul 12, 2016 at 04:03:33AM +0000, Chen, Weiwen wrote: > > > I have RHEL KVM host with both OVS 2.50/2.31 (on different systems) > > > but experienced the VM interface has a large forward entries. I > > > thought VM interface should be access port and with single VM MAC in > > > FDB. Is this a bug in OVS? If not, please let me what is configured > > > wrong. > > > > > > Thanks a lot! > > > > > > Here are my configuration: > > > > > > # ovs-vsctl show > > > Bridge "cs-eno1" > > > Port "vnet5" > > > Interface "vnet5" > > > Port "cs-eno1" > > > Interface "cs-eno1" > > > type: internal > > > Port "vnet3" > > > Interface "vnet3" > > > Port "vnet8" > > > Interface "vnet8" > > > Port "vnet4" > > > Interface "vnet4" > > > Port conf > > > Interface conf > > > type: internal > > > Port "eno1" > > > Interface "eno1" > > > Port "vnet1" > > > Interface "vnet1" > > > Port "vnet2" > > > Interface "vnet2" > > > Port "vnet0" > > > Interface "vnet0" > > > ovs_version: "2.5.0" > > > > OVS certainly supports access ports, but all of the above are configured as > > trunks. To configure an OVS port as an access port, one must set the "tag" > > column to a VLAN ID (and this would show up in "ovs-vsctl show" > > output), either at the time of adding the port or later. > > > > The ovs-vsctl manpage explains how to set an access VLAN at the time of > > adding a port: > > > > [--may-exist] add-port bridge port [column[:key]=value]... > > Creates on bridge a new port named port from the network > > device > > of the same name. > > > > Optional arguments set values of column in the Port record > > cre‐ > > ated by the command. For example, tag=9 would make the port > > an > > access port for VLAN 9. The syntax is the same as that for > > the > > set command (see Database Commands below). > > > > Without --may-exist, attempting to create a port that exists > > is > > an error. With --may-exist, this command does nothing if > > port > > already exists on bridge and is not a bonded port. > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss