MRI example on Fabric-Testbed Configuration help.

[Nagmat Nazarov]

Dear Community,

I am trying to implement MRI(Multi-Hop Route Inspection –  https://github.com/p4lang/tutorials/tree/master/exercises/mri ) on Fabric Testbed but facing some difficulties.

The Jupyter Hub file for this example is : mri.ipynb .

Tables for S1,s2,s3 are sX_commands.txt.

After deployment of the codes I am sniffing packets on ports1(ens8) on switch1 and it forwards it to port2(ens9) as shown in the picture.

As we discussed with Paul Ruth in office hours their checksum changed while transferring from port1 to port2.

It was “0x43bc” on port1 and became “0x61b8” on port2. As I am using Basic_Nics, maybe the packets are being discarded because of the wrong checksum values. May the wrong checksums trigger the packet drop? If yes, will using dedicated Nics change the result?

The main issue is I am not able to sniff packets on port1 on Switch2.

Kind regards,

Nagmat

 

[Nagmat Nazarov]

Update regarding the MRI experiment.

@Paul recommended me capture the packet in the bmv2 switch and send the same captured packet before installing P4 docker containers. I tried it and as Paul expected the packets didn’t go through as shown in the attached picture. As shown in the picture when we send normal packets, it is going through the switch, but when I resend the old packet it doesn’t go through.

 

[Nagmat Nazarov]

Apart from resending the packets captured on the P4 switch,

Paul recommended me to use Dedicated Nics. (Slice-id : 8aff3c57-7a84-41c6-8e9c-dae4d4087111 , Slice_name : “mri_ded” )

Before installing P4 dockers I could receive packets on other ethernet ports of the switches easily.

But I got the same results as with Basic_Nics. The packets were reaching the switches but not exchanging with other switches.

What may be the issue?

Kind regards,

Nagmat

[Ilya Baldin]

All FABRIC network services are provided at Ethernet layer and above, which does require that experiments generate valid Ethernet frames. If your experiment generates invalid Ethernet frames, then our switches (that inteconnect the servers together) will silently drop them.

[Nagmat Nazarov]

Dear Ilya Baldin,

Thanks for the response.

Question 1: If a program is working smoothly on the Mininet environment, does it mean that it will work on the Fabric_testbed environment?

The program I am compiling and deploying on FT is : https://github.com/nagmat1/p4_tutorials/blob/main/pl_basic/basic.p4

Slice_id : 22680d2f-e6e2-48f3-a538-94911dc0e7b2

Slice name : basic_nagm01

I deployed the same program on mininet environment and it was working fine. After deploying it on Fabric_testbed and configuring the tables and ports on the control plane I can see the packet coming to port1 and being forwarded to port2 as shown in the picture(ens9 is port1 and ens8 is port2 going to switch2). I can analyze the same situation on switch 2 and switch 3. The packets are being forwarded inside p4 switch but not exchanged among the switches. What may be the issue? How can I overcome it?

Kind regards,

Nagmat

 

 

[Ilya Baldin]

No it does not. Mininet doesn’t necessarily generates valid Ethernet frames. The most likely issue is that our (FABRIC) dataplane switch that interconnects the ports is dropping the frames because they are not valid.

[Nagmat Nazarov]

The same packets are not dropped in real p4 switches. I am calculating new checksum for all modified packets. Do you mean invalid checksum by “not valid”? Is there any way around it?

 

[Ilya Baldin]

The real P4 switches may be more tolerant since they are built around the idea of modifying frame formats. I do not know the details of what you are trying to do, but invalid Ethernet frames will not pass through our dataplane switches.

There’s a simple experiment you can try – try to pass the frames unmodified – if they go through, but your modified frames do not, your frames are not considered valid by our switches and are being dropped.

[Nagmat Nazarov]

Ilya Baldin wrote:

The real P4 switches may be more tolerant since they are built around the idea of modifying frame formats. I do not know the details of what you are trying to do, but invalid Ethernet frames will not pass through our dataplane switches.

There’s a simple experiment you can try – try to pass the frames unmodified – if they go through, but your modified frames do not, your frames are not considered valid by our switches and are being dropped.

I tried sending unmodified packets before deploying p4 code and it was passing smoothly. If any modified packets won’t go through (FABRIC) data plane switch that interconnects the ports, does it mean that any p4 program where the header is modified can’t experiment on a fabric testbed?

[Ilya Baldin]

Any header that is not valid will not pass. Without knowing more about what and how you are modifying I cannot answer. Valid packets should pass through without problems. You can use wireshark or similar to look at your packet traces to see if it flags anything between unmodified and modified frames.

[Author]

Posts