Hi Alfredo, Thanks! I can confirm that the fix is working.
P.S. could you give me some more information on the rationale behind removing transparent mode? - Why is it removed? - Is it now always transparent mode 0? (Looking at the diff this seems to be the case) - Is there an impact on performance? We were already running in transparent mode 0 all the time, so I'm just wondering if anything has changed that I should be aware of. The commit message / documentation is a little scarce on these things ;) Thanks, Chris On 04/18/2015 05:53 PM, Alfredo Cardigliano wrote: > Hi Christiaan > there is a patch in SVN for this, please update and let us know, > in essence kernel is stripping out the first VLAN tag, now pf_ring is pushing > it back. > > Alfredo > >> On 15 Apr 2015, at 15:50, Christiaan Schade >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> I did forget some other important information: >> Driver: >> igb-5.2.5-zc >> >> $ethtool -k eth4 >> Offload parameters for eth4: >> rx-checksumming: on >> tx-checksumming: on >> scatter-gather: on >> tcp-segmentation-offload: on >> udp-fragmentation-offload: off >> generic-segmentation-offload: on >> generic-receive-offload: on >> large-receive-offload: off >> rx-vlan-offload: off >> tx-vlan-offload: off >> ntuple-filters: off >> receive-hashing: on >> >> I also tried >> rx-vlan-offload: on >> tx-vlan-offload: on >> >> with no difference >> >> On 04/15/2015 03:23 PM, Christiaan Schade wrote: >>> >>> Hi all, >>> >>> I think this issue might be related to r8710 (fix for hw vlan strip in case >>> of multiple sockets on the same device). >>> I've attached two PCAP files: ip_two_vlan.pcap and pfdump.pcap where >>> pfdump.pcap is the result of 'pfsend -f ip_two_vlan.pcap' and 'pfdump -w >>> pfdump.pcap' between two servers. >>> >>> The result is that the first (out of two) VLAN tag is stripped out in >>> pfdump.pcap. >>> >>> == Additional info == >>> - Using PF_RING 6.0.2, both VLAN tags are stripped out (i.e. there are no >>> more VLAN tags in pfdump.pcap). My guess is that r8710 attempts to fix this >>> issue (I have not verified if the problem exists >>> in r8709). >>> - Using r9212, only the first VLAN tag is stripped out >>> - Using r9212, packets with 1 VLAN tag are processed correctly (if I >>> pfsend the pfdump.pcap it still has 1 VLAN tag after receiving it. Also >>> verified with other PCAPs with only 1 VLAN tag) >>> >>> Other tests performed: >>> | Source | Destination | Result | >>> ----------------------------------------- >>> | pfsend | pfdump | 1 VLAN tag | >>> | tcpreplay | pfdump | 1 VLAN tag | >>> | tcpreplay | tcpdump | 2 VLAN tags | >>> | pfsend | tcpdump | 2 VLAN tags | >>> >>> PF_RING at destination (where pfdump runs): >>> >>> $ cat /proc/net/pf_ring/info >>> PF_RING Version : 6.0.3 ($Revision: 9212$) >>> Total rings : 0 >>> >>> Standard (non DNA/ZC) Options >>> Ring slots : 4096 >>> Slot version : 16 >>> Capture TX : Yes [RX+TX] >>> IP Defragment : No >>> Socket Mode : Standard >>> Total plugins : 0 >>> Cluster Fragment Queue : 0 >>> Cluster Fragment Discard : 0 >>> >>> uname -a at destination (where pfdump runs): >>> $ uname -a >>> Linux sm-advantech-01 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 >>> 03:51:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>> >>> [Side note] I see that transparent_mode is now deprecated, does this mean >>> that from 6.0.3 on PF_RING is always in transparent mode 0? >>> >>> If I'm missing any important information please let me know, I'd be happy >>> to run any further tests to assist you in understanding the problem >>> >>> Thanks in advance, >>> >>> Christiaan Schade >>> >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] <mailto:[email protected]> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >> >> -- >> ------------------------------------------------------------------------ >> ATTENTION: >> The information in this email message is confidential and may be legally >> privileged. It is intended solely for the addressee. >> >> Should you receive this message by mistake, you are hereby notified that >> any disclosure, reproduction, distribution or use of this >> message is prohibited and may be unlawful. >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > -- ------------------------------------------------------------------------ ATTENTION: The information in this email message is confidential and may be legally privileged. It is intended solely for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is prohibited and may be unlawful. _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
