[P4-dev] INT demo issue - Bad UDP checksum for packets headed to monitor

Avinash Herle avinash.herle at barefootnetworks.com
Wed May 10 12:54:54 EDT 2017


Couple of quick question Rakesh.
1) Did you install the VXLAN_GPE driver and the other dependencies
mentioned in this readme?
2) Once you run the mininet scripts you should see a few log files
(prefixed with tmp_) generated in the path <p4factory>/mininet. Do they
report any error?

Please try the following

1) Run the mininet script
2) Start a long running iperf session say, h1 perf -c 10.2.1.4 -t 100
3) Open another window and console into
     a) switch leaf1 (since it is connected to the source h1).
Collect tcpdump on the interface leaf1-eth1 (interface connected to h1).
The host h1 is supposed to add the INT shim header. Verify if the INT
header is added.
     b) switch leaf1. Collect tcpdump on the interface leaf1-eth3
or leaf1-eth4 depending upon which interface the packets go out of. leaf1
should have appended INT metadata.
     c) switch leaf2 (since it is connected to the destination h4).
Collect tcpdump on the interface leaf2-eth2 (interface connected to h4).
4) Do refer the INT spec when verifying the tcpdump.
5) If every hop is appending it's metadata information, then proceed with
checking the monitor.
6) Make sure you have all the dependencies for the monitor installed. Refer
readme.

Let me know if you have any more questions.

Also, do not reload/refresh the web client when the application is running.
You might have to re-run the application in this case. The Readme mentions
a few known monitor issues and troubleshooting tips.

PS: You need to build switch with switchlink.

Thanks,
Avinash

On Wed, May 10, 2017 at 12:01 AM, Yongfeng Sun <sunnogo at gmail.com> wrote:

> I encountered this issue, too. But it's a bit different.
>
> I find that vm-eth22 got the packet after preprocessor.py which strips the
> INT body from vxlan-gpe body. However, web client doesn't show the flow.
>
> Use tshark to capture the packet:
>
>  sunyongfeng  ~  workshop  p4factory  mininet  sudo tshark -i vm-eth22
> [sudo] password for sunyongfeng:
> Running as user "root" and group "root". This could be dangerous.
> tshark: Lua: Error during loading:
>  [string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled
> due to running Wireshark as superuser. See https://wiki.wireshark.org/
> CaptureSetup/CapturePrivileges for help in running Wireshark as an
> unprivileged user.
> Capturing on 'vm-eth22'
>   1 0.000000000 192.168.1.44 -> 192.168.1.100 UDP 62 47895 → 54321  Len=20
> ...
> 118 packets captured
>  sunyongfeng  ~  workshop  p4factory  mininet  sudo tshark -i
> vm-eth22 -Vc 1
> Running as user "root" and group "root". This could be dangerous.
> tshark: Lua: Error during loading:
>  [string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled
> due to running Wireshark as superuser. See https://wiki.wireshark.org/
> CaptureSetup/CapturePrivileges for help in running Wireshark as an
> unprivileged user.
> Capturing on 'vm-eth22'
> Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on
> interface 0
>     Interface id: 0 (vm-eth22)
>     Encapsulation type: Ethernet (1)
>     Arrival Time: May 10, 2017 14:55:59.203745483 CST
>     [Time shift for this packet: 0.000000000 seconds]
>     Epoch Time: 1494399359.203745483 seconds
>     [Time delta from previous captured frame: 0.000000000 seconds]
>     [Time delta from previous displayed frame: 0.000000000 seconds]
>     [Time since reference or first frame: 0.000000000 seconds]
>     Frame Number: 1
>     Frame Length: 62 bytes (496 bits)
>     Capture Length: 62 bytes (496 bits)
>     [Frame is marked: False]
>     [Frame is ignored: False]
>     [Protocols in frame: eth:ethertype:ip:udp:data]
> Ethernet II, Src: 52:c7:b0:b9:09:a0 (52:c7:b0:b9:09:a0), Dst:
> 66:64:01:1c:df:8a (66:64:01:1c:df:8a)
>     Destination: 66:64:01:1c:df:8a (66:64:01:1c:df:8a)
>         Address: 66:64:01:1c:df:8a (66:64:01:1c:df:8a)
>         .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
>         .... ...0 .... .... .... .... = IG bit: Individual address
> (unicast)
>     Source: 52:c7:b0:b9:09:a0 (52:c7:b0:b9:09:a0)
>         Address: 52:c7:b0:b9:09:a0 (52:c7:b0:b9:09:a0)
>         .... ..1. .... .... .... .... = LG bit: Locally administered
> address (this is NOT the factory default)
>         .... ...0 .... .... .... .... = IG bit: Individual address
> (unicast)
>     Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.1.44, Dst: 192.168.1.100
>     0100 .... = Version: 4
>     .... 0101 = Header Length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
>         0000 00.. = Differentiated Services Codepoint: Default (0)
>         .... ..00 = Explicit Congestion Notification: Not ECN-Capable
> Transport (0)
>     Total Length: 48
>     Identification: 0x0b77 (2935)
>     Flags: 0x02 (Don't Fragment)
>         0... .... = Reserved bit: Not set
>         .1.. .... = Don't fragment: Set
>         ..0. .... = More fragments: Not set
>     Fragment offset: 0
>     Time to live: 64
>     Protocol: UDP (17)
>     Header checksum: 0xab65 [validation disabled]
>         [Good: False]
>         [Bad: False]
>     Source: 192.168.1.44
>     Destination: 192.168.1.100
>     [Source GeoIP: Unknown]
>     [Destination GeoIP: Unknown]
> User Datagram Protocol, Src Port: 47895 (47895), Dst Port: 54321 (54321)
>     Source Port: 47895
>     Destination Port: 54321
>     Length: 28
>     Checksum: 0x840e [validation disabled]
>         [Good Checksum: False]
>         [Bad Checksum: False]
>     [Stream index: 0]
> Data (20 bytes)
>
> 0000  0a 02 01 04 0a 02 01 03 08 00 78 bc 00 00 0a 01   ..........x.....
> 0010  00 03 20 00                                       .. .
>     Data: 0a0201040a020103080078bc00000a0100032000
>     [Length: 20]
>
> 1 packet captured
>
>
> Rakesh Kumar <kumar19 at illinois.edu>于2017年5月10日周三 上午10:14写道:
>
>> Hey All,
>>
>> I was trying to recreate the INT demo on a Ubuntu 14.04 LTS VM and
>> followed the instructions here: https://github.com/
>> p4lang/p4factory/tree/master/apps/int
>>
>> The network comes up, the hosts are able to connect to each other (i.e.
>> pings and iperfs between them work), but the web application does not see
>> any counter updates (i.e. the time series all sit at 0).
>>
>> So, I tried debugging it. Ultimately, I used tcpdump on each host and
>> verified that there are UDP packets being sent to the monitor at
>> 192.168.1.100 (IP address for the interface on the native host). These
>> packets never make it to the destination interface and have a bad UDP
>> checksum. This explains why the counters are zero, because of course there
>> are no updates reaching the monitor. But I don't have many ideas about how
>> to fix this?
>>
>> Any ideas on what might be causing this? Is it normal/expected behavior
>> due to some header modifications?
>>
>>
>> Thanks and Regards,
>>
>>
>> -
>> rakesh
>>
>> P.S: Is there a slack where devs hangout if I needed more interactive
>> help about anything?
>> _______________________________________________
>> P4-dev mailing list
>> P4-dev at lists.p4.org
>> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at lists.p4.org
> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20170510/f160742c/attachment-0002.html>


More information about the P4-dev mailing list