[ovs-discuss] I can't manage to use more than one port on the vswitch

O A oalabeatrix at gmail.com
Fri Sep 29 13:59:42 UTC 2017


>> On Sep 28, 2017, at 10:30 AM, O Alabeatrix <oalabeatrix at gmail.com>> 
>> wrote:
>>
>>
>>>> On Sep 28, 2017, at 8:50 AM, O Alabeatrix <oalabeatrix at gmail.com>>> 
>>>> 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



More information about the discuss mailing list