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.
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
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
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.
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
