more information on this one :
doing packet capture I can see that TTL is not decreasing when I ping
from VM1 (192.168.1.2) to VM2 (10.10.1.2)
this means that VM2 is not doing any routing.
When I ping 10.10.1.2 I see that it is the MAC address from eth0
(192.168.1.2) who is responding.
At the end it is like the kernel is usurpating the IP address from the
other interface but not doing any routing process!
iptables FORWARD DROP & ip_forward=0 is not changing anything.
to double check I tried to not only access to the 10.10.1.2 IP Address
but another address connected (one more jump) and here I can see that
iptables & ip_forward is doing the right job.
Someone has seen this before? Is there a way to ajdust the kernel to not
act like this ? (any tips on iptables if there is no other choice?)
Many thanks :-)
On 07/01/2015 0:34, Ben wrote:
Thanks Ben,
I found this FAQ this morning and this is the reason I tried to tweak
my kernel but no effect :(
Even dropping policy on forward iptables is not doing anything, I can
still ping on all direction.
As I haven't been so clear this is what I discover :
I ----------------Server 1---------------- I=eth0=Direct Patch=eth0=I
----------------Server 2----------------- I
I--------------------VM1------------------I
I--------------------VM2-------------------I
I eth0 (192.168.1.1/24) I I eth0 (192.168.1.2/24) I
I eth1 (10.10.1.1) I I eth1 (10.10.1.2) I
on both Server 1 and Server 2
ovs-vsctl add-br vswitch-trust
ovs-vsctl add-port vswitch-trust eth0
ovs-vsctl add-port vswitch-trust tap50 tag=50
ovs-vsctl add-port vswitch-trust tap60 tag=60
eth0 on VM is linked to tap50
eth1 on VM is linked to tap60
from VM1 I can ping 192.168.1.2 & 10.10.1.2 as expected.
from VM2 I can ping 192.168.1.1 & 10.10.1.1 as expected.
If I removed eth1 on VM*1* and try to ping 192.168.1.2 from VM1 I can
as expected.
adding ip route add via 192.168.1.2 on VM1 I can ping 10.10.1.2
so VM2 is routing the trafic even if it is not on the same vlan, I
suspect because it is done on VM and vlan is done on server (not VM)
If you have any idea I would be very happy :)
belette
On 06/01/2015 22:21, Ben Pfaff wrote:
On Tue, Jan 06, 2015 at 07:56:53PM +0100, Ben wrote:
I just figured out a strange behaviour :
If I set two tap devices on 2 VM (tap50 & tap60) and set tap50
tag=50 and tap60 tag=60 on ovs I noticed that it is working well.
Each VM IP can ping each other on the same vlan, but if I erase one
IP address on one vm and add a default gw to route all the traffic
on the second tap interface I noticed that the other vm is still
responding to the ping even if I am requestiing an ip address into
the other vlan.
I check ip forwarding and ajust the rp_ & arp filter on my linux
kernel and iptables forward to deny everything but is keeps respond
to my ping.
I guess OVS is forwarding it properly to the VM but to the wrong tap
interface.
Maybe this FAQ is relevant. I can't tell for sure.
### 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.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
