You're the man! Your previous solution worked! Thanks! On 10 July 2015 at 15:54, Kevin Benton <[email protected]> wrote:
> You should be able to confirm this is the issue by running brctl showmacs > <bridgename>. If the mac addresses is learned in that table on the physical > interface, any traffic to that mac wouldn't be flooded to your VM. > On Jul 10, 2015 12:16 PM, "Kevin Benton" <[email protected]> wrote: > >> Am I correct in understanding that the traffic you are expecting to see >> is mirrored traffic not actually destined to the VM? >> >> If so, linuxbridge is probably going to learn that the port all observed >> macs belong to is the physical one so nothing will be flooded on the bridge. >> >> Try disabling mac learning on that bridge with the follow command so >> everything is flooded: brctl setageing <bridgename> 0 >> >> On Jul 10, 2015 1:01 AM, "Martinx - ジェームズ" <[email protected]> >> wrote: >> >>> Thank you James! >>> >>> Listen, trying to resume my topology for you, my Instance have two >>> interfaces. >>> >>> 1- eth0 - its default gateway - vxlan with dhcp (okay); >>> 2- eth1 - vlan provider network (the one that doesn't work) (eth3 if >>> instance have 4 vNIC). >>> >>> I can access the Instance via ssh through its namespace router normally >>> (or VNC Console). >>> >>> For "eth1", the physical switch port sends a mirrored tagged vlan >>> traffic to it. My instance just (wants to) consumes that traffic >>> (untagged)... My instance is a kind of NFV (in "offline" mode)... >>> >>> Do you still think that makes sense to capture the traffic >>> simultaneously? >>> >>> You're right, "eth1" have no IP, it is just UP, reading packets... >>> >>> Thanks! >>> Thiago >>> >>> On 10 July 2015 at 00:12, James Denton <[email protected]> >>> wrote: >>> >>>> Thanks, Thiago. >>>> >>>> >>>> Do you mind running a capture across the 3 interfaces (eth, bridge, >>>> tap) simultaneously? In particular, traffic generated outside of the >>>> node that demonstrates connection attempts to your instance. It will be >>>> helpful to see if there are continuous ARP requests without replies, or a >>>> reply and continuous TCP SYN packets and whatnot. On the tap interface you >>>> should only expect to see broadcast, multicast, and unicast traffic to the >>>> MAC address of the instance. Because the MAC addresses are masqueraded in >>>> those captures, and they're not related, it's hard to tell what you're >>>> seeing. Do you mind not masking them this time around? >>>> >>>> >>>> Also, what is the IP address of the instance? Seeing that this is an >>>> all-in-one, I'm guessing you didn't having issues with DHCP? >>>> >>>> >>>> Thanks, >>>> >>>> James >>>> >>>> >>>> ------------------------------ >>>> *From:* Martinx - ジェームズ <[email protected]> >>>> *Sent:* Thursday, July 9, 2015 8:51 PM >>>> *To:* James Denton >>>> *Cc:* [email protected] >>>> *Subject:* Re: [Openstack] 99.5% of packets are disappearing somewhere >>>> between the Linux Bridge (brqxxxxzzzz-yy) and the tap (tapxxxxzzzz-yy). >>>> >>>> Hello James! >>>> >>>> On 9 July 2015 at 11:17, James Denton <[email protected]> >>>> wrote: >>>> >>>>> Hi Thiago, >>>>> >>>>> * I can see the untagged packets arriving at "brq50b13311-fa", by >>>>> using "tcpdump -eni brq50b13311-fa"; >>>>> >>>>> >>>>> Do you mind posting the packet capture from eth3 and the bridge on >>>>> pastebin? >>>>> >>>> >>>> >>>> I don't mind, I'll just replace the public IPs before posting (and >>>> possibly MAC)... >>>> >>>> >>>> * Actual traffic hitting physical "eth3" with VLAN tag (OK): >>>> >>>> http://paste.openstack.org/show/360214/ >>>> >>>> >>>> * Actual traffic hitting "brq50b13311-fa" without tag (OK): >>>> >>>> http://paste.openstack.org/show/360249/ >>>> >>>> >>>> * Actual traffic hitting "tap9a546be0-d6" without tag (BUGGED - >>>> missing packets): >>>> >>>> http://paste.openstack.org/show/360274/ >>>> >>>> >>>> * Actual traffic hitting vNIC "eth3" without tag (BUGGED - missing >>>> packets): >>>> >>>> http://paste.openstack.org/show/360275/ >>>> >>>> >>>> *** Only PVST, OSPF and ICMP are appearing inside the Instance (and >>>> its tap, of course) *** >>>> >>>> >>>> >>>>> >>>>> For example, I can not see the string "Cisco" while running >>>>> "tcpdump -eni brq50b13311-fa | grep -i cisco", so, where those packets >>>>> come >>>>> from (that I'm seeing on tap9a546be0-d6 and within its instance - pastebin >>>>> above) ??? >>>>> >>>>> >>>>> Those are multicast packets for PVST and OSPF from the switch and >>>>> router, respectively. You might try filtering by MAC on the bridge instead >>>>> of using grep to isolate those packets: >>>>> >>>>> tcpdump -eni brq50b13311-fa ether dst 01:00:0c:cc:cc:cd >>>>> >>>>> I would expect to see those packets on eth3 as well. >>>>> >>>> >>>> You're absolutely right! >>>> >>>> The PVST, OSPF (and very rare ICMP) are appearing @ eth3 too (with >>>> "vlan XXXX" tagged), my bad (that grep, "ether dst" is much better, tks). >>>> >>>> Look, inside the Instance - vNIC eth3: >>>> >>>> tcpdump -eni eth3 >>>> >>>> http://paste.openstack.org/show/360127/ >>>> >>>> >>>> Only the PVST, OSPF and ICMP packets are hitting the tapxxxxzzzz-yy >>>> interface! As expected, I can see those packets inside of the Instance as >>>> well (Pastebin above). >>>> >>>> Why TCP/UDP isn't passing? >>>> >>>> >>>>> * I CAN NOT see the untagged packets arriving at "tap9a546be0-d6", >>>>> by using "tcpdump -eni tap9a546be0-d6"! >>>>> >>>>> >>>>> What do your security group rules look like? >>>>> >>>> >>>> I have no Security Groups, no Firewall, no ipset... >>>> >>>> >>>> ML2 configuration contains: >>>> >>>> http://paste.openstack.org/show/356860/ >>>> >>>> >>>> >>>>> >>>>> What is driving me crazy is that, on top of this very same setup >>>>> (including e1000 driver), but with different vlan tag, it works! >>>>> >>>>> >>>>> Is it the same eth3 interface? You may want to avoid vlan 666, >>>>> anyway. Never known those numbers to be lucky. >>>>> >>>> >>>> Yes, very same eth3. >>>> >>>> LOL... I just posted this number here, to not publish private data, >>>> actual VLAN ID is different. :-P >>>> >>>> Why it works for "VLAN X", but not for "VLAN Y", is a mystery for me. >>>> >>>> Thank you so much for your help! >>>> >>>> I'm seeing some debugging progress here... >>>> >>>> Hopping to get this fixed! It is very important for the project that >>>> I'm working on. >>>> >>>> >>>>> >>>>> James >>>>> >>>> >>>> Thiago >>>> >>> >>> >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : [email protected] >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >>>
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
