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
