[ovs-discuss] Fwd: Rhel 6.1 - openvswitch 1.2.2 - network commutation between physical and virtual - doesn't work

Benoit ML ben42ml at gmail.com
Fri Sep 30 15:41:21 UTC 2011


---------- Forwarded message ----------
From: Benoit ML <ben42ml at gmail.com>
Date: 2011/9/30
Subject: Re: [ovs-discuss] Rhel 6.1 - openvswitch 1.2.2 - network
commutation between physical and virtual - doesn't work
To: Leland Vandervort <leland at dev.discpro.org>


This is my last test on openvswitch :

Well I have :
- A vswitch with a physical port on eth4
- An internal interface vi1 with tag = 3702

- A physical server with an interface eth0.3702
- H3C configured to "permit" traffic trhoug

Conclusion :
  OpenVswitch send the packet trough eth4 with a  tag 3702.  (ARP Request)
  The pysical receive the packet  and respond (ARP Reply)
  The packet arrive to the eth4 interface of openvswitch (so the H3C do the
job no ?)  BUT without vlan tag (no tag view  by tcpdump ... vlan offload ?
other ?)





================================================================
tcpdump -i eth4 vlan 3702
tcpdump: WARNING: eth4: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes
17:18:32.656862 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28


17:18:33.656836 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:35.657891 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:36.657857 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:37.657873 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:39.658863 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:40.658834 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
================================================================

================================================================
tcpdump -i eth4 | grep 192.168.37
tcpdump: WARNING: eth4: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes
17:18:45.659854 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:45.660128 ARP, Reply 192.168.37.6 is-at 00:10:18:75:71:ee (oui
Unknown), length 46
17:18:47.660887 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:47.661111 ARP, Reply 192.168.37.6 is-at 00:10:18:75:71:ee (oui
Unknown), length 46
17:18:48.660792 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:48.661048 ARP, Reply 192.168.37.6 is-at 00:10:18:75:71:ee (oui
Unknown), length 46
17:18:49.660876 ARP, Request who-has 192.168.37.6 tell 192.168.37.2, length
28
17:18:49.661127 ARP, Reply 192.168.37.6 is-at 00:10:18:75:71:ee (oui Unknown
================================================================




2011/9/30 Benoit ML <ben42ml at gmail.com>

> The switch is a H3C 7506.
> The port, i think, is configured to have a pvid=99 and permit tagged vlan
> 2, 101 and 3702.
>
> But strange fact :  tcpdump didnt see any tag when the packet comme from
> the H3C ...  If tcpdump doesnt see tag, can I assume that openvswitch doesn
> t see the tag ?
>
> Another strange fact :  Two serveur with a vlan inside the OS (bond0.3702),
> the switch configured to autorise the traffic, well with tcpdump -i bond0 i
> didn't see a thing ...  any idea ?
>
>
>
> Well This is possible ... I will have a closer look .
> Thanks for the time.
>
> Regards,
>
>
>
> 2011/9/30 Leland Vandervort <leland at dev.discpro.org>
>
>>  Benoit,
>>
>> I presume that the physical interface in question is connected to a
>> physical switch with dot1q tagging in operation on the physical port?  If
>> so, is it a Cisco switch by chance?  And if yes, is the port configured to
>> use vlan2 as the native vlan?  We had a similar issue with the bridge in Xen
>> where the Xen Bridge tagged the ARP request when sending it to the physical
>> switch, but since the VLAN in question was the native vlan for the trunk,
>> the response was not tagged.  Xen Bridge had no idea what to do with the
>> packet because it wasn’t tagged, and there was no support in the Xen bridge
>> for a “native” vlan definition.
>>
>> As a work-around, we set the physical switchport to tag ALL vlans by
>> setting the native vlan to 1 (which is not being used anyway).
>>
>> The other potential reason could be that although the switchport is
>> configured as a trunk, it also has an access vlan configuration ... or
>> finally, simply that the physical switch port isn’t configured as a dot1q
>> trunk, so doesn’t tag any frames.
>>
>> Things to check and confirm.
>>
>> Regards,
>>
>> Leland
>>
>>
>>
>> Le 30/09/2011 13:49, « Benoit ML » <ben42ml at gmail.com> a écrit :
>>
>> Hi,
>>
>> Some more information :
>> When I use TCPDUMp on the physcal interface user by openvswitch :
>> - I see the vlan ID  when the packet leave openvswitch (ARP request)
>> - I didn't see the vlan ID when the packet arrive (ARP respond)
>>
>> It's like the  vlan was not transmit to openvswitch  (I clearly see that
>> the ARP answer is dropped by ovs)
>>
>> Regard,
>>
>> 2011/9/30 Benoit ML <ben42ml at gmail.com>
>>
>> Hello,
>>
>> We suffering a problème about network switching between a physical world
>> and a virtual world :
>>
>> We have a x86 server, with 10Gb cards.  On the vswitch we have  add some
>> cards to do the switching :
>> ovs-vsctl  add-bond brCentral ovsbond0 eth4 eth5 bond_mode=active-backup
>> bond_updelay=10 bond_downdelay=10 lacp=off trunk=[0,2,3702]
>>
>> But appears a broblème :  the switching works very good for untagged
>> frames but doesn't work fort tagged vlan 2 frames ... So the VM never see
>> the response for a simple arp request :(
>>
>>
>> I've see the "ovs-vlan-bug-workaround eth4 on"  but :
>> ovs-vlan-bug-workaround: operation failed (kernel does not support the
>> VLAN bug workaround)
>>
>> We have tested with "Emeluex oneConnect 10Gbps", module be2net and with
>> braodcom bnx2x ...
>>
>>
>> Any idea plz ?
>>
>>
>> Software version
>> RHEL6.1
>> kmod-openvswitch-2.6.32-131.12.1.el6-1.2.2-1.el6.x86_64
>> openvswitch-1.2.2-1.el6.x86_64
>> kernel-2.6.32-131.12.1.el6.x86_64
>> modinfo be2net
>> filename:
>> /lib/modules/2.6.32-131.12.1.el6.x86_64/kernel/drivers/net/benet/be2net.ko
>> license:        GPL
>> author:         ServerEngines Corporation
>> description:    ServerEngines BladeEngine 10Gbps NIC Driver 2.103.298r
>> version:        2.103.298r
>> srcversion:     538F174333FC55CF8B6A4BD
>> alias:          pci:v000010DFd0000E220sv*sd*bc*sc*i*
>> alias:          pci:v000019A2d00000710sv*sd*bc*sc*i*
>> alias:          pci:v000019A2d00000700sv*sd*bc*sc*i*
>> alias:          pci:v000019A2d00000221sv*sd*bc*sc*i*
>> alias:          pci:v000019A2d00000211sv*sd*bc*sc*i*
>> depends:
>> vermagic:       2.6.32-131.12.1.el6.x86_64 SMP mod_unload modversions
>> parm:           rx_frag_size:Size of a fragment that holds rcvd data.
>> (ushort)
>> parm:           num_vfs:Number of PCI VFs to initialize (uint)
>> parm:           multi_rxq:Multi Rx Queue support. Enabled by default
>> (bool)
>>
>>
>>
>>
>>
>>
>
>
> --
> --
> Benoit
>
>


-- 
--
Benoit




-- 
--
Benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20110930/772512a5/attachment.html>


More information about the discuss mailing list