Re: [vpp-dev] how to trace tcp4-output?
Sure, that’s a good option. But, the point is that the stack won’t try to figure out if the output interface is actually capable of honoring the “offload” flag. Still need to think if this could be handled better. Also, note that the stack handles segmentation itself, it does not offload rx/tx re-assembly/segmentation. Florin > On Apr 29, 2019, at 9:38 AM, Andreas Schultz > wrote: > > Am Mo., 29. Apr. 2019 um 18:21 Uhr schrieb Florin Coras > mailto: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 > <mailto: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 <http://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) >> mailto:dbar...@cisco.com>>: >> Try “pcap dispatch trace on max 1 buffer-trace >> 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 >> >> <https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html> >> >> >> HTH... Dave >> >> >> >> >> >> From: mailto:vpp-dev@lists.fd.io>> on behalf of >> Andreas Schultz > <mailto:andreas.schu...@travelping.com>> >> Date: Monday, April 29, 2019 at 9:31 AM >> To: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" > <mailto: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
Re: [vpp-dev] how to trace tcp4-output?
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 1 buffer-trace >> 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: * on behalf of Andreas Schultz < >> andreas.schu...@travelping.com> >> *Date: *Monday, April 29, 2019 at 9:31 AM >> *To: *"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 StendalReg 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...@trave
Re: [vpp-dev] how to trace tcp4-output?
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. Florin > On Apr 29, 2019, at 8:18 AM, Andreas Schultz > 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 <http://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) > mailto:dbar...@cisco.com>>: > Try “pcap dispatch trace on max 1 buffer-trace > 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 > > <https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/buildwireshark.html> > > > HTH... Dave > > > > > > From: mailto:vpp-dev@lists.fd.io>> on behalf of Andreas > Schultz <mailto:andreas.schu...@travelping.com>> > Date: Monday, April 29, 2019 at 9:31 AM > To: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" <mailto: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 > <mailto:i...@travelping.com> > GERMANY Web:http://www.travelping.com > <http://www.travelping.com/> > Company Registration: Amtsgericht StendalReg 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 > <mailto:i...@travelping.com> > GERMANY Web:http://www.travelping.com > <http://www.travelping.com/> > > Company Registration: Amtsgericht StendalReg No.: HRB 10578 &
Re: [vpp-dev] how to trace tcp4-output?
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 1 buffer-trace > 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: * on behalf of Andreas Schultz < > andreas.schu...@travelping.com> > *Date: *Monday, April 29, 2019 at 9:31 AM > *To: *"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 StendalReg 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 StendalReg 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/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] how to trace tcp4-output?
Hi Andreas,
The tracing should work but because we’re reusing the syn packet to build the
syn-ack, it might not show correctly. Could you breakpoint the tcp4-output and
try to see if the trace code is hit?
As for the checksum, tcp only tags the packet with a request to have it
offloaded. If the nic wrongly advertises that it can do it, the offload
infrastructure will comply with that.
If you’re using dpdk and you want to force sw checksum computation, change
startup conf and add "dpdk { enable-tcp-udp-checksum }”.
Hope this helps,
Florin
> On Apr 29, 2019, at 6:31 AM, Andreas Schultz
> wrote:
>
> 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
>
Re: [vpp-dev] how to trace tcp4-output?
Try “pcap dispatch trace on max 1 buffer-trace 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: on behalf of Andreas Schultz Date: Monday, April 29, 2019 at 9:31 AM To: "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<mailto:i...@travelping.com> GERMANY Web:http://www.travelping.com Company Registration: Amtsgericht StendalReg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 - -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12871): https://lists.fd.io/g/vpp-dev/message/12871 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] -=-=-=-=-=-=-=-=-=-=-=-
[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 StendalReg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann VAT ID No.: DE236673780 - -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12869): https://lists.fd.io/g/vpp-dev/message/12869 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] -=-=-=-=-=-=-=-=-=-=-=-
