Hi Chris inline > On 22 Apr 2015, at 13:24, Christiaan Schade > <[email protected]> wrote: > > 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?
transparent_mode does not have major performance improvements on recent kernels, that’s why we decided to remove it. > - Is it now always transparent mode 0? (Looking at the diff this seems to be > the case) Yes > - Is there an impact on performance? Same 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 ;) Sorry about that :-) > > Thanks, > > Chris Regards Alfredo > > 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]> >>> <mailto:[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]> >>>> <mailto:[email protected] >>>> <mailto:[email protected]>> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> <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]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> <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
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
