Please don't drop the list.
Thanks for the updated information, this helps to clarify a little.
A few stream-of-consciousness notes:
- You still shouldn't need spanning tree, so something has already gone
wrong - are you sure you don't have some inter-bridge forwarding turned on
for your KVM hypervisor?
- In your second attachment, you can see request as well as replies - I
would expect to see only requests (with replies leaving through the other
interface) if routing was set up correctly on that VM
- It should be pretty easy to debug this
- Run the command below while you can see these unexpected packets.
This would tell you the source
- ovs-dpctl dump flows int
- The only possible sources for a packet with an action sending to
ifInt2 would be
- ifint1 - likely, sent from other VM due to misconfiguration
- nothing - the packet is coming through another bridge, or OVS bug
- int - unlikely, coming from HV ip stack or OVS bug
- ifInt2 - really unlikely, specific egress-port action or OVS bug
- All of the above 'or OVS bug's would be very surprising
Let me know if you find out anything more, good luck.
-Reid
On Fri, Jul 12, 2013 at 6:00 PM, Eduard Serra <[email protected]> wrote:
> Hi Reid,
>
> Thanks for your early answer. Thing is: the topology actually works, but
> it seems there are some weird traffic issues in the middle.
>
> We have recreated the case several times and the inter-vlan traffic
> "out-of-nowhere" still persists. I'll add all relevant information of
> configuration as well as provide screenshots or captures taken during this
> traffic behaviour.
>
> Please, do take into account that we do assume it is our fault until it is
> found out otherwise.
>
> Further details:
> - Vlan are tagged with 802.1q. All vlans are tagged on the bridge, though
> we also tried to set them on trunk and make every VM tag them through the
> vconfig/8021q module on linux. Results were the same.
>
> -In topology (see atachement topology.png) i have updated the image to
> show layer 3 information properly. It should now show IP's set for every
> entry point in the networks.
>
> Configuration for the ovs is as follows:
>
> 1e01a4b8-b0c1-4ed0-b068-e422e3467895
> Bridge int
> Port "ifInt2"
> tag: 150
> Interface "ifInt2"
> Port int
> Interface int
> type: internal
> Port "ifInt1"
> tag: 150
> Interface "ifInt1"
> Bridge "br0"
> Port "mgmt1"
> tag: 100
> Interface "mgmt1"
> Port "eth0"
> trunks: [100]
> Interface "eth0"
> Port "br0"
> tag: 100
> Interface "br0"
> type: internal
> Port "mgmt2"
> tag: 100
> Interface "mgmt2"
> ovs_version: "1.11.90"
>
> - br0 and int are set with "stp_enable = true".
>
> All entry points to every subnetwork are tagged. We have left port
> int@intuntouched since we had no need for it (we only wanted communication
> among
> the VM's with this subnetwork).
>
> - All Layer 3 configuration is configured by standard console
> configuration in linux debian 7.0 kernel 3.8 precompiled openvswitch module
> with the kernel.
>
> Once all configuration is up, all pings are do properly reach their
> targets and they are answered back properly. Problem is, in the internal VM
> network registers some traffic for unkown reasons:
>
> - screen1-wire: shows capturing traffic at ifInt2 (internal VM network)
> receiving ping packets from VLAN 100 which should be unreachable.
>
> - screen2-tcpdump: shows tcpdump (-i eth2) receiving traffic at VM's iface
> eth2 which should not be reaching at all.
>
> We even tried to shutdown ("ifconfig iface down")the VMs' interfaces and
> we could see traffic from VLAN 100
> on int1@int or int2@int. We don't have screenshot but we can recreate it
> if necessary.
>
> Hope this clears our situation a bit more. Thanks for your help in advance.
>
>
>
>
> El 12/07/2013 19:18, Reid Price escribió:
>
> Hi Edu Serra,
>
> The environment you describe seems straightforward and is known to work.
> Does the attached image really reflect your topology? There seems to be
> an issue somewhere in these statements:
>
> - The very first moment a machine had 2 interfaces up, some traffic
> would happen to be replicated
> - Also, between switches there is no patch, nor anything, and there
> is no forwarding on the VM machines of any type.
> - We turned off completly interfaces ifInt1 and ifInt2 from the VM's
> (what does 'turn off' mean? mention actual commands)
>
> You are missing useful information for bug reports. (e.g.:
> https://github.com/enukane/ovs/blob/master/REPORTING-BUGS). Is the VLAN
> tagged on the VM or on the bridge?
>
> I would check your VM configuration and make sure you understand how the
> IP stack responds to incoming packets.
>
> -Reid
>
>
> On Fri, Jul 12, 2013 at 7:39 AM, Edu Serra <[email protected]> wrote:
>
>> Hi everyone,
>>
>> We have one topology we needed to recreate and we chose to try
>> openvswitch for it. After reading a lot and several days through
>> trial-and-error tests ,we decided we would post our case.
>>
>> Topology to be recreated is as the image (attachement) shows.
>>
>> First off, vlan100 shall be used for management purposes and should be
>> seen througout the whole network (outside from the very same host), and
>> vlan150 should be an internal, virtualized lan that would be only used for
>> traffic shapping tests.
>>
>> The very first moment a machine had 2 interfaces up, some traffic would
>> happen to be replicated and the VM's and even the host would eventually die
>> due to cpu overload. We found that to avoid this, we had to at least have
>> STP to avoid loops in our topology. We also tweaked several ARP options in
>> unix kernel to avoid certain ARP announcements and responses be made
>> through unproper interfaces.
>>
>> When we finally got to have the topology and all connectivity seemed
>> fine, we started our traffic shaping tests, and we found that the traffic
>> going through the Internal Vlan was kinda weird. We checked (through
>> tcpdump/wireshark) the traffic recieved on the Int switch's interfaces and
>> we found out that most of the traffic from VLAN 100 was getting "somehow"
>> to the other switch.
>>
>> To further test this, we repliacted the same case, but this time we
>> turned off completly interfaces ifInt1 and ifInt2 from the VM's, which
>> would lead to see only the traffic generated by the Switch Int (only STP?)
>> , but to our surprise, in this situation the traffic from the other switch
>> was getting through this switch and its interfaces as well.
>>
>> There is no controller attached to neither of them (should them be
>> working as learning switches). Also, between switches there is no patch,
>> nor anything, and there is no forwarding on the VM machines of any type.
>>
>> Any help would be greatfully appreciated-
>>
>> _______________________________________________
>> discuss mailing list
>> [email protected]
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>>
>
>
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
