geant-dataplaneprogramming / int-platforms Goto Github PK

Hello, first of all thank you for the very good work done on this implementation.

Here is my issue, I have tried to adapt this code base in order to be able to use it with TCP packets but unfortunately I have not succeeded yet. My testbed is as follow, I have two hosts (h1 and h2) separated by two switches (s1 and s2) and INT is configured to only put INT headers for packets going from h1 -> h2. I have tried to run iperf3 between the two hosts but my packets are dropped at the receiving end (h2), after the INT headers are removed by the sink switch, due to a bad checksum (I assume). Furthermore, the switch S2 which is just before h2 is the int sink switch.

Netstat output on h2:

Here is the code that i have added in parser.p4 (in the apply block of the function computeChecksum) to compute the tcp checksums:

update_checksum_with_payload(
            hdr.tcp.isValid(),
            {   hdr.ipv4.srcAddr,
                hdr.ipv4.dstAddr,
                8w0,
                hdr.ipv4.protocol,
                meta.tcpLen,
                hdr.tcp.srcPort,
                hdr.tcp.dstPort,
                hdr.tcp.seqNum,
                hdr.tcp.ackNum,
                hdr.tcp.dataOffset,
                hdr.tcp.reserved,
                hdr.tcp.flags,
                hdr.tcp.winSize,
                hdr.tcp.urgPoint
            },
            hdr.tcp.csum, HashAlgorithm.csum16);

        update_checksum_with_payload(
            hdr.tcp.isValid() && hdr.int_header.isValid(),
            {   hdr.ipv4.srcAddr,
                hdr.ipv4.dstAddr,
                8w0,
                hdr.ipv4.protocol,
                meta.tcpLen,
                hdr.tcp.srcPort,
                hdr.tcp.dstPort,
                hdr.tcp.seqNum,
                hdr.tcp.ackNum,
                hdr.tcp.dataOffset,
                hdr.tcp.reserved,
                hdr.tcp.flags,
                hdr.tcp.winSize,
                16w0,
                hdr.tcp.urgPoint,
                hdr.int_shim,
                hdr.int_header,
                hdr.int_switch_id,
                hdr.int_port_ids,
                hdr.int_q_occupancy,
                hdr.int_level2_port_ids,
                hdr.int_ingress_tstamp,
                hdr.int_egress_tstamp,
                hdr.int_egress_port_tx_util,
                hdr.int_hop_latency
            },
            hdr.tcp.csum, HashAlgorithm.csum16);

Where meta.tcpLen is simply if(hdr.tcp.isValid()) meta.tcpLen = hdr.ipv4.totalLen - (bit<16>)(hdr.ipv4.ihl)*4; computed in the Egress pipeline (last instruction).

It should be noted that the checksums are correct while the INT headers are still valid

I have also provided the pcap files of the switches. pcap.zip

So my question is the following, do you have any clue of what should I do more to be able to use INT with TCP ?

Best regards,
Champagne Loïc

Hi Team,

We installed this stack using Docker, following the instructions from README. But we are not seeing any INT data/logs being collected! Is this repository still working? I Can provide more information if needed. Please let me know. Thanks for your time and consideration.

Best regards,
Arka Mallick
Next Reply

Hello,

I would like firstly thank you for this awesome opensource. I'm implementing an INT collector using C-pure. I found some differences in your implementation wrt. what's specified in the INT specification document V1.0. What is the reason of these differences?

The first difference is about the ingress/egress timestamps as being mentioned in README:

Note: All INT implementation use 64-bit ingress and egress timestamps (instead of 32-bit timestamps defined in INT specification documents).

Another difference is about the level 2 in/egress ports:

• the implementation uses 16 bits for each value:

header int_level2_port_ids_t {
    bit<16> ingress_port_id;
    bit<16> egress_port_id;
}

• meanwhile the specification document proposes to use 32 bits for each value:

  • In "4.7 INT Hop-by-Hop Metadata Header Format", page 15:

  bit6: Level 2 Ingress Port ID + Egress Port ID (4 bytes each)

  • In the proposed P4 code, page 22:

header int_level2_port_ids_t { 
    bit<32> ingress_port_id;
    bit<32> egress_port_id;
}

This code checks the checksum of the packet in both ingress as well as egress parser, but doesn't store result of the checksum verification into a value in user-defined metadata (out metadata meta parameter of both parsers). As a result of this mistake, both ingress and egress control have no idea, that they should change the value of drop_ctl parameter which indicates when packet should be dropped.

Possible solution:
structure (out metadata meta) should have parameter something like bool checksum_error which ingress and egress control can analyze and set the proper value of the ingress deparser metadata parameter drop_ctl so then deparser can drop the packet based on the value of this parameter drop_ctl.

Also code of both ingress and egress deparsers is not checking this parameter drop_ctl and is not droping packets when this parameter indicates, that packet should be dropped.

There is a problem with instruction mask in mininet configuration which cause that no metadata are added by transit node for cesnet traffic . I belive that it is caused by typo in following file:
https://github.com/GEANT-DataPlaneProgramming/int-platforms/blob/master/platforms/bmv2-mininet/int.p4app/commands/commands1.txt#L3
where instead of mask 0xCC should be 0xCC00

When I repeat the experiment with INT (int-platform) I encountered some confusion, mainly that I could not verify the connection between hosts (ping failed, host1 with ip addr 10.0.0.1/8, host2 with ip addr 10.0.0.2/8) below (attached) are two screenshots recording the experiment. switch1 connecting to host1 connects to switch2 through eth2. You can view the table and ports of switch1 that uses port3 to process the packets that should be forwarded to switch2/host2. So I think this faulty handler is the main cause of ping failure.
What I would like to know is that when I run 'bash start_int1.0.sh' I get the initial configurations mentioned above, what do I do if I want to change these initial configurations? Is the error accidental or repo's fault?
Thank you in advance.

Hi, excellent work. I have two main questions about the repo. The first one is related to the name of the issue I'm creating and is about the implementation of this code on a Virtualbox VM. As far as I know, this solutions works on Ubuntu 18.04 with Linux kernel 4.15. I tried to use it on a VirtualBox VM with this specifications and I got everything working fine (I asummed that because I was able to produce packets between h1 and h2 as the testbed says)

but checking the first issue I noticed that when running the application my SO lacks of some virtual interfaces (mainly the one named "int_collection" and the "int_collector"). Here is a pic of the interfaces that ifconfig command showed me.

Do I need to use Ubuntu as a host SO or it is normal this behaviour. The second question is about the pcap file generated on the /tmp/int4app directory. When running the application, I only get two files int_collector.log (which is empty) and the p4s.s1.log (which contains the interfaces configured)

Am I doing something wrong? Kinds regards.