P4 Support

[kthare10]

Enabling P4 Switch on FABRIC

Standard slice request

User's Slice Request

The user requests a slice with the following specifications:

• VM1: Located at Site1, connected via a Shared NIC.
• VM2: Located at Site2, connected via a Shared NIC.
• P4 Switch: Located at either Site1, Site2, or Site3.

Connections:

• VM1 to P4 Switch Port 1 via an L2PTP link.
• VM2 to P4 Switch Port 1 via an L2PTP link.
• Submit the Slice.

Expected Result:

Upon deploying P4 code on the P4 switch, VM1 should successfully transmit traffic to VM2.

Slice Request

A sample slice request using fablib can be found below:

simple_p4_slice_request

Switch Provisioning for Users

The AM Handler performs the following steps to provision a P4 switch:

• Boots a Debian-based golden image, specifically a RARE freeRtr derivative:

  echo rare | sudo -S efibootmgr --bootnext 0004
  echo rare | sudo -S reboot
  

• Installs the user's SSH key into the root account:

  echo {{ sshkey }} >> ~/.ssh/authorized_keys
  

• Assigns a floating IP address (more details below).

Switch Deprovisioning

The AM Handler undertakes the following actions to deprovision a P4 switch:

• Removes the user's SSH key.
• Releases the floating IP address (details below).

Outstanding Items

Connectivity of P4 Switch

• Accessible solely via the head node.
• Proposed method (Mert): Utilize a Floating IP Address for the P4 switch, allowing allocation and deallocation, potentially using Ironic.

Switch Environment

• Ensures inclusion of licensed SDE within the image.
• Facilitates all compilation and build processes directly on the switch.
• RENCI holds an Intel Level 2 license permitting these actions.
• SC labs utilize P416, aligning with our preferred configuration.
• SC labs demonstrate procedures such as connecting VSCode (including terminal windows) to the switch via SSH.
• Provides a login shell/SSH on the switch (root access), maintaining licensed software integrity on the switch (compiler). Notebooks are configured accordingly.

Queries

• Methods to prevent users from downloading the SDE tar file hosted on the switch?
  • Could this be achieved using Security Group rules?

[ibaldin]

Couple of questions/thoughts

1. Transmitting traffic between VM1 and VM2 is conditional on appropriate P4 program loaded into the switch - are you planning to provide a default that makes it act like e.g. a learning switch? I'm guessing freeRtr does that out of the box. Seems like a good idea - a user gets a working-by-default environment.
2. Deprovisioning user keys - is it needed if the switch is reimaged every time? In my original thinking we were going to wipe the switch clean after every user/use. That seems like a good security feature. Otherwise users will leave all kinds of artifacts behind I think.

[kthare10]

1. As you mentioned intent is to give user a default working environment. freeRtr gives that too. In addition, we are working on for default example P4 code which can be deployed, that just passes traffic.
2. You are right - removing SSH keys is not required as the next provisioning, we flash with the image again.

[kthare10]

Recommendations:

• Special Project permission for using P4 requiring Project Lead to sign a pledge for not sharing the SDE. Something similar to https://wiki.geant.org/display/RARE/P4+targets
• Connectivity to switch via the VM
• Require Switch to be associated with a VM if needed - TBD

[kthare10]

Implemented in 1.8. Workflow described below:

• User has to request Switch.P4 Permission to request P4 switches in slices.
• Typical Slice:
  • Request a slice with a P4 switch on SIte2 and 2 VMs on Site1
  • Each VM is connected to one Port of the P4 Switch over L2STS
  • Configure IPs, 192.168.0.1 and 192.168.0.2 respectively on each VM interface
• CF Workflow
  • Orchestrator checks the Required Permissions, validates requested policy and forwards the request to Broker
  • Broker does the allocation and approves the reservations if P4 switch is available
  • Approved Reservations are redeemed at AM
  • AM does the following
    • Installs rare image via ONIE
    • Installs docker, kernel modules and other packages
    • Creates a fabric user
    • Pulls Docker Image for P4 container which has SDE installed in it
    • Launches the container on the Switch
    • User's public key is pushed in fabric user's authorized keys enabling the user to SSH into the switch via bastion node

Once the slice is up, user can ssh to Switch via bastion node using their slice key and access the SDE inside the p4_container running on the Switch.