>-----Original Message----- >From: Michael Beavington [mailto:mbeav...@pt.com] >Sent: Tuesday, November 13, 2012 6:02 AM >To: e1000-devel@lists.sourceforge.net >Subject: Re: [E1000-devel] Q. Default VLAN erroneous behaviour? > >We're using Fedora 3.4.2-1.fc16.x86_64 > >Clarification on our interface (not using eth0). > >p19p1 Link encap:Ethernet HWaddr 00:80:50:05:23:64 > inet addr:192.168.240.2 Bcast:192.168.240.255 >Mask:255.255.255.0 > inet6 addr: fe80::280:50ff:fe05:2364/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:6452445 errors:0 dropped:2518 overruns:0 frame:0 > TX packets:5863768 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:491128699 (468.3 MiB) TX bytes:553181059 (527.5 MiB) > >p19p1.3 Link encap:Ethernet HWaddr 00:80:50:05:23:64 > inet addr:10.91.0.230 Bcast:10.91.1.255 Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:848556 errors:0 dropped:0 overruns:0 frame:0 > TX packets:488415 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:75929558 (72.4 MiB) TX bytes:181253808 (172.8 MiB) > >]# ethtool -i p19p1 >driver: ixgbe >version: 3.11.33 >firmware-version: 0x8000035b >bus-info: 0000:01:00.1 >supports-statistics: yes >supports-test: yes >supports-eeprom-access: yes >supports-register-dump: yes > >]# ethtool -i p19p1.3 >driver: 802.1Q VLAN Support >version: 1.8 >firmware-version: N/A >bus-info: >supports-statistics: no >supports-test: no >supports-eeprom-access: no >supports-register-dump: no > >We've created interface p19p1 as our main ethernet connection. This is >supposed to be our default vlan: vlan 1. We have then also created other >vlans such as p19p1.3 for some management messages.
p19p1 is the interface attached to the physical device (as seen by ethtool -i it is controlled by the ixgbe driver not the 8021q driver). As such you will see all the traffic on that device. >When I monitor vlan 3 traffic on p19p1.3 using tcpdump, I see the correct >messaging with the (tag stripped) vlan 3 traffic. That's good. > >When I monitor p19p1 using tcpdump (non promisc), I see the untagged >traffic as expected, but I also see the vlan traffic destined to p19p1.3 That is correct. It is my understanding that this is by design. Perhaps you should ask your question on the Linux netdev mailing list. I'm not an expert on the subject. >with the 802.1q ethernet tag. When we test leaking TIPC packets into vlan >3, we get error messages that suggest that these vlan 3 destined packets >are actually be processed by our TIPC processes bound to p19p1. The >problem is not restricted to TIPC, but any packets that are vlan tagged. > >My question to the group was, how can I tell that these vlan tagged >packets are not being delivered to the processes bound to the p19p1 >interface? I'm hoping that I've configured the tcpdump wrong, but when If you open a raw socket yes, but that would require root access. >looking at the driver code, it's not clear to me where the traffic for the >default vlan is being handled. We also have an older platform, not using >this driver, that behaves as I expect i.e. no vlan traffic on eth0. The driver does not strip the packets as you expect. It may strip the vlan tags from the packet. Which driver/HW behaves differently? Every driver I had seen works as you describe in this email. Thanks, Emil >Reading how other O/S use the interface (e.g. Cisco), it seems that they >are able to specifically define the PVID/native/default VLAN. In Fedora we >assume that our main ethernet connection p19p1. It seems to be correct >when I look at other examples on the web or in the 802.1q standard. It's >just a little fuzzy since there is no specific way of defining the native >vlan. > >Mike Beavington >Performance Technologies >+1-613-287-5364 >mbeav...@pt.com >40 Hines Rd, Suite 500, >Ottawa, ON K2K 2M5 > > > > > > >From: "Tantilov, Emil S" <emil.s.tanti...@intel.com> >To: Michael Beavington <mbeav...@pt.com>, >"e1000-devel@lists.sourceforge.net" <e1000-devel@lists.sourceforge.net> >Date: 11/12/2012 09:26 PM >Subject: RE: [E1000-devel] Q. Default VLAN erroneous behaviour? > > > >>-----Original Message----- >>From: Michael Beavington [mailto:mbeav...@pt.com] >>Sent: Sunday, November 11, 2012 8:56 AM >>To: e1000-devel@lists.sourceforge.net >>Subject: [E1000-devel] Q. Default VLAN erroneous behaviour? >> >>I've done a tcpdump -p (non promisc) and was looking at the packets >coming >>in on the main interface (eth0). What I was seeing was all the packets, >>including the vlan tagged packets for vlans 4, 5. This didn't seem >right. >>When I tcpdumped, the vlan interfaces, I received the correct stripped >>packets. > >I'm not sure I understand what the nature of the problem is. Are you >saying that >the interface is receiving vlan packets meant for other interfaces, or >that the >vlan tags are not being stripped. > >It would help if you can provide more information about your setup. >Where (on which interface) are vlans 4 and 5 (from your example above) >configured? > >Thanks, >Emil > >>I was wondering if I should see those packets on eth0 for the other vlans >>when I execute tcpdump in the non-promiscuous mode? I was looking at the >>code to see where the packets are being stripped out, but it's not clear >>where that's happening. We're worried that packets leaking out of a >>different system might be impacting our own system even though the >default >>interface should not be processing tagged packets. >> >>ixgbe 3.11.33 (we also saw this on 3.8) >> >>Mike Beavington >>Performance Technologies >>+1-613-287-5364 >>mbeav...@pt.com >>40 Hines Rd, Suite 500, >>Ottawa, ON K2K 2M5 >> > ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired