Is there a way we can set switches interfaces an IP ?

[edgar-costa]

There is no specific reason why I want to do this, apart from learning. When making the P4 switches act as a L3 "router", to make the scenario more realistic I assigned IPs to the switches interfaces.

The problem is that now it seems that the switch is not getting any packet, I guess that when you configure an IP for the interface the traffic is captured by the kernel first.

Is there a way to bypass this ? Does it even make sense ?

EDIT 1: while writing this I had the idea of enabling ip_forward=1. Magically, packets seem to arrive to the switch. I was actually not expecting this, since forward should only work when the forwarding rules are installed in the linux routing tables, right ?

EDIT 2:

Actually (and now it makes more sense to me), the ip_forward=1 thing did not solve the issue at all. It just made me think that connectivity was restored, but packets would jump directly from one host to the other without passing through the switches. This because all switches are placed to the root namespace (mininet default) and thus the main host is able to route from one interface to another directly (since it knows to which subnet each switch interface is connected and thus it adds that to the routing table.

Can simple_switch bypass this layer of the linux kernel ? As fas as I remember ovs did not have this issue.

[antoninbas]

This is out-of-scope of bmv2. You need to disable IP forwarding and ideally not assign IP addresses to the interfaces assigned to bmv2, in order to ensure that packet forwarding is not done by Linux.

All the functionality should be contained in your P4 programmed, which means that if your router interfaces need an IP address and MAC addresses, you should probably insert that information into a table at runtime. This is probably a simplistic view of a real-world router but you can have a port table in your P4 program to match on the ingress port and write the appropriate IP address and MAC address for the interface to metadata, so that they are available to the rest of the pipeline. Again probably a simplistic view: 1) if MAC address in packet doesn't match iface MAC, do L2 switching; 2) if MAC address matches and IP matches, send packet to CPU; 3) if MAC address matches and IP doesn't match, do IP forwarding.

[antoninbas]

One take-away is that (unlike OVS?) bmv2 doesn't integrate with linux networking tools such as ip. This wouldn't really be possible anyway because of the protocol-independent nature of P4, unless the architecture itself assumes a fixed-function routing block.

[edgar-costa]

Thanks for the answer ( I agree it might be out of scope),

I know I could use tables to assign macs and IPs to ports and do some filtering there. I just (naively) wanted to set IPs to the switch interfaces so our students learning p4 would not ask all the time why the "l3 switch" interfaces do not have IP. I know there are some ways to bypass the linux kernel so all the IP stuff is not handled by linux. However, its fine, probably doing what you say its enough, and students should be able to "believe" a little bit more.