Configuring SR Linux for P4Runtime
- Configure a TLS profile to secure communication with P4Runtime clients. See TLS profiles in the SR Linux Configuration Basics Guide for information about configuring TLS profiles.
- Configure interface identifiers. To allow P4Runtime clients to reference
specific interfaces in
PacketIn
andPacketOut
messages, you configure per-interface identifiers consisting of a port ID and device ID. See Identifying interfaces to P4Runtime. - Configure settings for the P4Runtime server, including idle timeout, session limits, and connection rate limiting. See Configuring P4Runtime server settings.
- Configure UNIX-socket specific settings for the P4Runtime server. See Configuring the P4Runtime server for UNIX sockets.
- Configure service authorization for the
p4rt
interface type. See Service authorization in the SR Linux Configuration Basics Guide.
Identifying interfaces to P4Runtime
PacketIn
and PacketOut
messages within the
P4Runtime StreamChannel
RPC require that the interface a packet is
received on or transmitted out of be uniquely identified. To do this, you configure a
unique per-interface identifier, which is a tuple consisting of the following:- A chassis-unique port identifier (known as the
interface_id
). This identifier can be manually configured, or if it is not, the systemifIndex
for the interface is used by default. - A chassis-unique device identifier that indicates the specific line card and
ASIC with which the port is associated (known as the
device_id
)
For example, to identify interface ethernet 1/1
to P4Runtime, you can
configure the interface_id
for the ethernet 1/1
port,
and configure a device_id
identifying the line card and ASIC associated
with the ethernet 1/1
port. The
device_id,interface_id
tuple uniquely identifies interface ethernet 1/1
.
The P4Runtime client uses a lookup table consisting of the
device_id,interface_id
tuple → interface-name (as specified by the
device) to translate where packets are to be sent to, or populate where a packet was
received.
Configuring a port identifier for P4Runtime
The interface_id
part of the device_id,interface_id
tuple uniquely identifies a port in the SR Linux chassis to a P4Runtime client. You
can configure the value for interface_id
. If you do not configure a
value for interface_id
, the port's ifIndex
value
is used by default.
--{ candidate shared default }--[ ]--
# info interface ethernet-1/1 p4rt
interface ethernet-1/1 {
p4rt {
id 2002
}
}
Configuring a device identifier for P4RT
The device_id
identifies a specific line card and ASIC in the
chassis. P4Runtime uses the combination of the device_id
and
interface_id
to identify the specific interface that a packet
was received on (in PacketIn
messages). Note that for identifying
the interface that a packet is to be sent via (in PacketOut
messages), only the interface_id
is used.
There is no default device_id
for a line card / ASIC; you must
configure the device_id
value to be used by P4Runtime.
--{ candidate shared default }--[ ]--
# info platform linecard 1 forwarding-complex 0
platform {
linecard 1 {
forwarding-complex 0 {
p4rt {
id 10001
}
}
}
}
Configuring P4Runtime server settings
- Whether to administratively enable the P4Runtime server
- Limit the number of connection attempts per minute by P4Runtime clients
- Limit the number of P4Runtime RPC connections that can be active at one time
- Idle-timeout in seconds for P4Runtime clients
- The network instance on which to administratively enable the P4Runtime server
- The gRPC service to enable; in this case, p4rt
- The port the P4Runtime server listens to for the network-instance. By default, this is TCP port 57400.
- IP addresses the P4Runtime server listens on within the network-instance
- TLS profile to secure communication between P4 Runtime clients and SR Linux for the network-instance
- Whether username/password authentication is used for each P4Runtime RPC request
- gRPC trace options ([common | grpc | request | response])
- The YANG models to use when the origin field is not present in requests (default: native)
--{ candidate shared default }--[ ]--
# info system grpc-server mgmt-test
system {
grpc-server mgmt-test {
admin-state enable
timeout 14400
rate-limit 120
session-limit 40
metadata-authentication true
tls-profile tls-profile-1
network-instance mgmt
port 9559
services [
p4rt
]
source-address [
192.168.0.1
]
}
}
Configuring the P4Runtime server for UNIX sockets
You can configure the following settings for the P4Runtime server that apply to UNIX sockets:
- Whether to administratively enable the P4Runtime server for UNIX sockets
The following example configures settings for the P4Runtime server for UNIX sockets:
--{ candidate shared default }--[ ]--
# info system grpc-server mgmt-test
system {
grpc-server mgmt-test {
admin-state enable
metadata-authentication true
tls-profile test-tls
unix-socket {
admin-state enable
}
}
}
Configuring a chassis ID for the SR Linux device
P4Runtime controllers sometimes model the chassis as a set of IDs, with the chassis having an ID, and each forwarding class having its own ID.
If necessary, you can assign a chassis ID to the SR Linux device. The chassis ID is not used by SR Linux for any purpose; it is intended for use by other controllers that may require a chassis ID on the device.
The following example configures a chassis ID for the SR Linux device:
--{ candidate shared default }--[ ]--
# info platform chassis id
platform {
chassis {
id 2403019611
}
}
Disconnecting P4Runtime clients
You can use a tools command to manually disconnect P4Runtime clients from the server.
To do this, get the identifier for the P4Runtime client from the info from state system grpc-server <name> command, then enter the following command to disconnect the client:
-{ running }--[ ]--
# tools system grpc-server mgmt-test client 4053 disconnect