Hi Ben, Appreciate the response. I agree that this explains what we are seeing. Thanks, John
On Thu, Oct 11, 2018 at 10:25 PM Ben Pfaff <[email protected]> wrote: > > I think that you're encountering a consequence of the Linux "weak ES" > model. It's not specific to Open vSwitch. The FAQ talks about this: > > 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 > $ ip addr add 192.168.0.5/24 dev br0 > $ ip link set br0 up > $ ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal > $ ip addr add 192.168.0.9/24 dev vlan9 > $ ip link set vlan0 up > > 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" > <https://tools.ietf.org/html/rfc1122>`__ 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 Wed, Oct 03, 2018 at 05:23:16PM +0100, John Hurley wrote: > > Hi, > > > > I've observed a bit of an anomaly when decapsulating VXLAN traffic > > that is inside a VLAN (using Open vSwitch version 2.10.90). > > > > I create a VXLAN port on a bridge and added a rule to match this > > tunnel and egress to a different port: > > > > ovs-vsctl add-port br0 vx2 -- set interface vx2 type=vxlan > > option:remote_ip=10.0.0.2 option:key=123 option:csum=true > > ofport_request=100 > > ovs-ofctl add-flow -OOpenFlow13 br0 in_port=100,tcp,actions=1 > > > > I configure a VLAN port on the host and assign it the IP end point > > address of the tunnel. e.g. > > > > ip link add link eth1 name eth1.20 type vlan id 20 > > ip address add 10.0.0.1 dev eth1.20 > > > > The following scenarios occur when sending in traffic: > > > > 1. vxlan traffic over vlan id 20 - matches and decapsulated > > 2. vxlan traffic with no outer vlan - matches and decapsulated > > 3. vxlan traffic over vlan id 21 - does not match > > > > However, if I add and up another vlan port with id 21 (while making no > > other changes to IP addresses etc.) I see (3) now matching and > > decapsulating. > > > > Is this behaviour intended? > > It seems like there should be tighter coupling between the incoming > > port/VLAN and the tunnel endpoint IP? > > If this behaviour is not harmful, it might be sufficient to just document > > it. > > > > For reference, this is the kernel rule installed in all tests (note: > > includes no reference to outer VLAN): > > > > recirc_id(0),tunnel(tun_id=0x7b,src=10.0.0.2,dst=10.0.0.1,flags(-df-csum+key)),in_port(3),eth(),eth_type(0x0800),ipv4(proto=6,frag=no),packets:60, > > bytes:7546, used:0.000s, flags:SFPR., actions:2 > > > > Thanks, > > John > > _______________________________________________ > > discuss mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
