* Updated the utils/run_exercise.py to allow exercises to customize host configuration from the topology.json file. Now hosts and `ping` each other in the basic exercise. Other Linux utilities should work as well (e.g. iperf). ``` mininet> h1 ping h2 PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data. 64 bytes from 10.0.2.2: icmp_seq=1 ttl=62 time=3.11 ms 64 bytes from 10.0.2.2: icmp_seq=2 ttl=62 time=2.34 ms 64 bytes from 10.0.2.2: icmp_seq=3 ttl=62 time=2.15 ms ^C --- 10.0.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 2.153/2.540/3.118/0.416 ms mininet> pingall *** Ping: testing ping reachability h1 -> h2 h3 h2 -> h1 h3 h3 -> h1 h2 *** Results: 0% dropped (6/6 received) ``` Only updated basic exercise, still need to update other exercises. Also, updated the root-bootstrap.sh because I was running into issues with latest version of vagrant. * Accidentially added the solution to the basic exercise in the previous commit. Undoing that here ... * Updated the topology.json file and table entries for the basic_tunnel exercise. * Updated P4Runtime exercise with new topology and table entries. * Fixed MAC addresses in P4Runtime exercise. It is working now. * Fixed MAC addresses in P4Runtime exercise starter code * Updated ECN exercise to use new topology.json file. Updated the table entries / MAC addresses as well. * Updated the topology.json file and table entries for the MRI exercise. * Updated source_routing exercise with new topology file and verified correct functionality. * Updated load_balance exercise with new topology. * Moved basic exercise triangle topology into a separate folder * Added new topology for the basic exercise: a single pod of a fat-tree. * Updated Makefiles and run_exercise.py to allow exercises to configure each switch with a different P4 program. This is mainly for the firewall exercise. * Updated Makefiles of project to work with new utils/Makefile * Updated load_balance and p4runtime exercise Makefiles * Initial commit of the firewall exercise, which is a simple stateful firewall that uses a bloom filter. Need to update README files * Initial commit of the path_monitor exercise. It is working but still need to update the README and figure out what we want the tutorial attendees to implement. * Updated README file in firewall exercise. Also removed the bits from the starter code that we want the tutorial attendees to implement * Renamed path_monitor exercise to link_monitor * Updated the README in the link_monitor exercise and removed the bits from the starter code that we want the tutorial attendees to implement. * Updated README for the firewall exercise * Adding pod-topo.png image to basic exercise * Added firewall-topo.png image to firewall exercise * Added link-monitor-topo.png to link_monitor exercise * Updated README files to point to topology images * Updated top-level README to point to new exercises. * Fixed link for VM dependencies script in README * Updated bmv2/pi/p4c commits * Updated README files for exercises to fix some typos and added a note about the V1Model architecture. * Added a note about food for thought in the link_monitor README * Updated the firewall.p4 program to use two register arrays rather than a single one. This is to make the design more portable to high line rate devices which can only support a single access to each register array. * Minor fix to firewall exercise to get rid of compiler warning. * Updated comment in firewall exercise. * Minor (typo) fixes in the firewall ReadMe * More info in firewall exercise ReadMe step 2 * Updated firewall.p4 to reuse direction variable * More testing steps, small fixes in firewall exercise Readme * Added food for thought to firewall Readme * Cosmetic fixes to firewall ReadMe * Made a few updates to the basic exercise README and added more details to the link_monitor exercise README. Also added a command to install grip when provisioning the VM. This could be useful for rendering the markdown README files offline. * Updated top level README so it can be merged into the master branch. * Moved cmd to install grip from root-bootstrap to user-bootstrap
Implementing Source Routing
Introduction
The objective of this exercise is to implement source routing. With source routing, the source host guides each switch in the network to send the packet to a specific port. The host puts a stack of output ports in the packet. In this example, we just put the stack after Ethernet header and select a special etherType to indicate that. Each switch pops an item from the stack and forwards the packet according to the specified port number.
Your switch must parse the source routing stack. Each item has a bos
(bottom of stack) bit and a port number. The bos bit is 1 only for the
last entry of stack. Then at ingress, it should pop an entry from the
stack and set the egress port accordingly. The last hop may also
revert back the etherType to TYPE_IPV4
.
Spoiler alert: There is a reference solution in the
solution
sub-directory. Feel free to compare your implementation to the reference.
Step 1: Run the (incomplete) starter code
The directory with this README also contains a skeleton P4 program,
source_routing.p4
, which initially drops all packets. Your job (in
the next step) will be to extend it to properly to route packets.
Before that, let's compile the incomplete source_routing.p4
and
bring up a network in Mininet to test its behavior.
-
In your shell, run:
make
This will:
- compile
source_routing.p4
, and - start a Mininet instance with three switches (
s1
,s2
,s3
) configured in a triangle, each connected to one host (h1
,h2
,h3
). Check the network topology using thenet
command in mininet. You can also change the topology in topology.json - The hosts are assigned IPs of
10.0.1.1
,10.0.2.2
, etc (10.0.<Switchid>.<hostID>
).
- compile
-
You should now see a Mininet command prompt. Open two terminals for
h1
andh2
, respectively:mininet> xterm h1 h2
-
Each host includes a small Python-based messaging client and server. In
h2
's xterm, start the server:./receive.py
-
In
h1
's xterm, send a message from the client:./send.py 10.0.2.2
-
Type a list of port numbers. say
2 3 2 2 1
. This should send the packet throughh1
,s1
,s2
,s3
,s1
,s2
, andh2
. However,h2
will not receive the message. -
Type
q
to exit send.py and typeexit
to leave each xterm and the Mininet command line.
The message was not received because each switch is programmed with
source_routing.p4
, which drops all packets on arrival. You can
verify this by looking at /tmp/p4s.s1.log
. Your job is to extend
the P4 code so packets are delivered to their destination.
Step 2: Implement source routing
The source_routing.p4
file contains a skeleton P4 program with key
pieces of logic replaced by TODO
comments. These should guide your
implementation---replace each TODO
with logic implementing the
missing piece.
A complete source_routing.p4
will contain the following components:
- Header type definitions for Ethernet (
ethernet_t
) and IPv4 (ipv4_t
) and Source Route (srcRoute_t
). - TODO: Parsers for Ethernet and Source Route that populate
ethernet
andsrcRoutes
fields. - An action to drop a packet, using
mark_to_drop()
. - TODO: An action (called
srcRoute_nhop
), which will:- Set the egress port for the next hop.
- remove the first entry of srcRoutes
- A control with an
apply
block that:- checks the existence of source routes.
- TODO: if statement to change etherent.etherType if it is the last hop
- TODO: call srcRoute_nhop action
- A deparser that selects the order in which fields inserted into the outgoing packet.
- A
package
instantiation supplied with the parser, control, and deparser.In general, a package also requires instances of checksum verification and recomputation controls. These are not necessary for this tutorial and are replaced with instantiations of empty controls.
Step 3: Run your solution
Follow the instructions from Step 1. This time, your message from h1
should be delivered to h2
.
Check the ttl
of the IP header. Each hop decrements ttl
. The port
sequence 2 3 2 2 1
, forces the packet to have a loop, so the ttl
should be 59 at h2
. Can you find the port sequence for the shortest
path?
Food for thought
- Can we change the program to handle both IPv4 forwarding and source routing at the same time?
- How would you enhance your program to let the first switch add the path, so that source routing would be transparent to end-hosts?
Troubleshooting
There are several ways that problems might manifest:
source_routing.p4
fails to compile. In this case,make
will report the error emitted from the compiler and stop.source_routing.p4
compiles but switches or mininet do not start. Do you have another instance of mininet running? Did the previous run of mininet crash? if yes, check "Cleaning up Mininet" bellow.source_routing.p4
compiles but the switch does not process packets in the desired way. The/tmp/p4s.<switch-name>.log
files contain trace messages describing how each switch processes each packet. The output is detailed and can help pinpoint logic errors in your implementation. The<switch-name>-<interface-name>_<direction>.pcap
files contain pcap captures of all packets sent and received on each interface. Usetcpdump -r <filename> -xxx
to print the hexdump of the packets.
Cleaning up Mininet
In the cases above, make
may leave a Mininet instance running in
the background. Use the following command to clean up these
instances:
mn -c
Next Steps
Congratulations, your implementation works! Move on to Load Balance.