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
