Am Mo., 29. Apr. 2019 um 18:21 Uhr schrieb Florin Coras < fcoras.li...@gmail.com>:
> Unfortunately, as things stand, the tunnel should compute the checksum > before encapsulating the traffic. Otherwise the output node won’t be able > to find the right headers. > > Will look into simplifying this. > I have look into it a bit more. If I had used a midchain-adjacency instead it should would. The midchain rewrite processing seems be handling the check sums and also segmentation. Andreas > Florin > > On Apr 29, 2019, at 8:18 AM, Andreas Schultz < > andreas.schu...@travelping.com> wrote: > > Thanks, that helped a lot. I found that traffic is not passing through the > node as I expected it. > > The actual graph is > > tcp4-output -> ip4-lookup -> ip4-rewrite -> upf-if-input > > Note: upf-if-input is the node function of an interface. It is found > through a fib entry that look like this: > > 10.106.14.227/32 > unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:38 buckets:1 uRPF:43 to:[0:0]] > [0] [@5]: ipv4 via 0.0.0.0 upf_session1: mtu:9000 > > What I was expecting that between ip4-rewrite and upf-if-input > the vnet_interface_output_node function of the software interface would be > invoked. > > As far as I can see that is the only logical place that would calculate > check sums and do segmentation on for software interfaces. > For routed traffic that is normally not needed, but locally generated > traffic (like a local TCP endpoint) needs it. > > It feels like I'm missing a important piece of the picture here. > What function or node should fill in the checksum for locally generate > traffic before it is encapsulated into a tunnel and what might be wrong > that it does not work in my setup? > > Many Thanks, > Andreas > > Am Mo., 29. Apr. 2019 um 16:59 Uhr schrieb Dave Barach (dbarach) < > dbar...@cisco.com>: > >> Try “pcap dispatch trace on max 10000 buffer-trace >> <rx-interface-input-node> 1000”, cause a transaction, “pcap dispatch trace >> off”; then look at the resulting trace w/ a vpp-dispatch-trace enabled >> wireshark. See >> https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html >> >> >> >> HTH... Dave >> >> >> >> >> >> *From: *<vpp-dev@lists.fd.io> on behalf of Andreas Schultz < >> andreas.schu...@travelping.com> >> *Date: *Monday, April 29, 2019 at 9:31 AM >> *To: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> >> *Subject: *[vpp-dev] how to trace tcp4-output? >> >> >> >> Hi, >> >> >> >> I'm trying to debug a problem and need to trace tcp4-output with vpp >> 19.04. >> >> >> >> So far I have tried it with "trace add tcp4-output 100 verbose", but that >> is not producing the expected result. The trace buffer is always empty. >> >> >> >> I was expecting that "trace add af-packet-input 100" would also trace the >> replies. But I can only see the incoming TCP-SYN, the generated SYN+ACK and >> the tcp4-output nodes are not showing up in the trace. >> >> I do know that the SYN+ACK gets generate, because I can see it in tcpdump >> after it has gone through an encapsulation. >> >> >> >> The problem I'm trying to figure out is why the TCP SYN+ACK packet when >> it hits a tunnel encapsulation node has invalid (or even no) check sums. I >> suspect there is something going on with the csum offload. But without the >> trace, finding that problem is a nightmare. >> >> >> >> Many thanks, >> >> Andreas >> >> >> >> >> >> -- >> >> -- >> Dipl.-Inform. Andreas Schultz >> >> ----------------------- enabling your networks ---------------------- >> Travelping GmbH Phone: +49-391-81 90 99 0 >> Roentgenstr. 13 Fax: +49-391-81 90 99 299 >> 39108 Magdeburg Email: i...@travelping.com >> GERMANY Web: http://www.travelping.com >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> >> Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 >> --------------------------------------------------------------------- >> > > > -- > -- > Dipl.-Inform. Andreas Schultz > > ----------------------- enabling your networks ---------------------- > Travelping GmbH Phone: +49-391-81 90 99 0 > Roentgenstr. 13 Fax: +49-391-81 90 99 299 > 39108 Magdeburg Email: i...@travelping.com > GERMANY Web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 > --------------------------------------------------------------------- > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12873): https://lists.fd.io/g/vpp-dev/message/12873 > Mute This Topic: https://lists.fd.io/mt/31383412/675152 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > > > -- -- Dipl.-Inform. Andreas Schultz ----------------------- enabling your networks ---------------------- Travelping GmbH Phone: +49-391-81 90 99 0 Roentgenstr. 13 Fax: +49-391-81 90 99 299 39108 Magdeburg Email: i...@travelping.com GERMANY Web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 ---------------------------------------------------------------------
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12875): https://lists.fd.io/g/vpp-dev/message/12875 Mute This Topic: https://lists.fd.io/mt/31383412/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
