On Sep 28, 2017, at 10:30 AM, O Alabeatrix <[email protected]>> wrote:


On Sep 28, 2017, at 8:50 AM, O Alabeatrix <[email protected]>>> wrote:

Hi

I’m a network admin starting to learn Open vSwitch. I don’t manage to make it functionning.
I’m using Debian 9 with three physical interfaces:
. enp0s3: management interfaces
. enp0s8: physical interface on vswitch0
. enp0s9: physical interface on vswitch1

vswitch0 (LOCALE) IP: 192.168.1.200

Theorically, as there is an IP on vswitch0, it shouldn’t matter wether it’s enp0s8 or enp0s9 that is plugged into the 192.168.1.0/24 network. Alas, it’s only when enp0s9 is used that the ping to the outter physical IP succeed.
An both in default L2 and OpenFlow3 mode.

Here are the config and status files:

Debian9 config:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install openvswitch-switch openvswitch-common
sudo ovs-vsctl add-br vswitch0
sudo ip link set vswitch0 up
sudo ip addr flush dev enp0s8
sudo ip addr flush dev enp0s9
sudo ovs-vsctl add-port vswitch0 enp0s8
sudo ovs-vsctl add-port vswitch0 enp0s9
sudo ip link set enp0s8 up
sudo ip link set enp0s9 up
sudo ip addr add 192.168.1.200/24 dev vswitch0

Normal default L2 Test:

ping -c 3 192.168.1.1 --->>> Fails, unless I swap the interfaces used

Status:

sudo ovs-vsctl show
bf88303a-48cb-48b6-bd07-af1b8eaaca89
    Bridge "vswitch0"
        Port "enp0s9"
            Interface "enp0s9"
        Port "vswitch0"
            Interface "vswitch0"
                type: internal
        Port "enp0s8"
            Interface "enp0s8"
    ovs_version: "2.6.2"

--
sudo ovs-ofctl show vswitch0
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000080027c5c636
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(enp0s8): addr:08:00:27:f4:a5:b9
     config:     0
     state:      0
     current:    1GB-FD COPPER AUTO_NEG
advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
     speed: 1000 Mbps now, 1000 Mbps max
2(enp0s9): addr:08:00:27:c5:c6:36
     config:     0
     state:      0
     current:    1GB-FD COPPER AUTO_NEG
advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
     speed: 1000 Mbps now, 1000 Mbps max
LOCAL(vswitch0): addr:08:00:27:c5:c6:36
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
--
sudo ovs-ofctl dump-flows vswitch0
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=686.922s, table=0, n_packets=224, n_bytes=28746, idle_age=1, priority=0 actions=NORMAL
----

OpenFlow3 mode and tests:

sudo ovs-vsctl set bridge vswitch0 protocols=OpenFlow13
sudo ovs-ofctl -O Openflow13 dump-flows vswitch0

OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=1334.814s, table=0, n_packets=398, n_bytes=66282, priority=0 actions=NORMAL

ping 192.168.1.1 –>>> Fail ( functions if I swap the interfaces cables)

I just can’t figure out what is going wrong here, even after compairing the status files ( ip link show, ip addr show).
thanks for any help <wlEmoticon-smile[1].png>


>In this instance, I think it's appropriate to ask about the upstream >switch configuration. I don't see anything immediately odd about your > >configuration, so we'll need to determine how OVS is interacting with >the upstream physical switch (things like VLANs, tagging, etc.).

>Also, since you have 2 NICs added to the OVS bridge and don't appear to >be connected to an OpenFlow controller, you'll need to address bridging > >loops and Spanning Tree. Specifically, you'll want to either a) place >the physical interfaces in different broadcast domains, or b) use some >form >of link aggregation.
>
>--
>Scott

Only 1 NIC is plugged int the 192.168.1.0/24 L2 domain at a time, so there is no STP/bridging loop involved.
The other cable is always plugged in another L2 domain:

Actually, the Debian 9 Open vSwitch is a VirtualBox VM.
enp0S8 is bridged on the physical network
enp0s9 is on another plane (inet)

I’ll investigate your suggestion pointing to a weird interaction between Open vSwitch and VirtualBox networking. But if one cable is plugged into ‘nowhere land’ (inet), that shouldn’t prevent the Open vSwitch from trying to use the other port, sending ARP request, ... I’ll add that I’m very skilled with Virtualized networking so .. hum .. this is intriguing ... Thanks for having checked my config files and giving me an input. It’s my first steps with Open vSwitch, I’m a real rookie over this subject
I go back wiresharking all this <wlEmoticon-smile[1].png>


Are you able to share details on the VirtualBox networking configuration? Also, what is the > 192.168.1.1/24 target you're trying to ping? Finally, you may need to put the virtual interfaces into > promiscuous mode; that's often the case when running OVS in a VM.

--
Scott

After some investigations and wiresharking, the problem seems to come from VirtualBox networking. Wiresharking show that vswitch0 sends the ARP request, 192.168.1.1 gets the ARP request and sends the ARP reply, but no vswitch0 interface gets the ARP reply. Furthermore, carefull analysis shows that VirtualBox lets the ARP reply get in by the interface that has the same MAC as the vSwitch, and drops it on the other one.
Fiddling around with VirtualBox settings doesn't seem to solve the problem.
Strangely, I work with VirtualBox bridged interfaces all year long, and never encontered any such problem ( Only VirtualBox networking stack getting frozen and needing a reboot). There must be a strange eerie bad interaction between VirtualBox bridged interfaces and open vSwitch.

I'm running my setup on a real hardware mini-ITX x86 board with three NICS and it's functionning OK. So problem half-solved.
I'll check with VMWare and HyperV to compare what happens :-)

Thanks for your help !


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to