Linux Host Networking Through SSR
The SSR software is a set of daemons (processes) that run within a Linux operating system. There are many standard Linux components leveraged by SSR (e.g., NTP, sshd, dnf, etc.) that require network access. These components (hereafter referred to as host components) will send traffic via Linux's routing table unless instructed otherwise. This document describes the best practice for routing that traffic from the underlying Linux host operating system into the SSR routing domain, for subsequent traffic forwarding using the SSR paradigm.
When running on the host platform, the SSR has its own routing table in addition to the one that is running within Linux.
This document applies specifically to SSR routers. The SSR conductor does not require any special configuration to affect Linux host networking, since it does not forward packets using any technique other than Linux host networking to begin with.
Basic Configuration
To forward traffic between Linux and SSR, we will use an interface type known as a Kernel Network Interface, or KNI. This is used to connect userspace applications with kernel networking.
By default, the SSR creates a KNI interface ("kni254") that is used to route packets to Linux as part of its host-service configuration. (A host-service is configured on a network-interface, and is used to forward various traffic types such as SSH and HTTP/HTTPS to Linux applications.) This kni254 interface is, by default, only used for inbound traffic (from Linux to the SSR) for host-services. By following the steps below, we can leverage the kni254 interface to send outbound traffic to the SSR.
Create services (or modify existing services) for network access, adding an access-policy that permits the tenant _internal_.
The _internal_ tenant is associated with all inbound requests arriving from Linux to SSR via kni254.
service internet
name internet
description "internet reachability"
scope private
security internal
address 0.0.0.0/0
access-policy guest
source guest
permission allow
exit
access-policy trusted
source trusted
permission allow
exit
access-policy _internal_
source _internal_
permission allow
exit
share-service-routes false
exit
Traffic originating from Linux and traveling through a KNI interface will have a source address of 169.254.127.127, which is a link-local address. You must ensure that source-nat is enabled on the egress interface used to carry this traffic out of the SSR platform.
Advanced Configuration
If you want to selectively forward via SSR, you can edit /etc/sysconfig/network-scripts/route-kni254 from its default route of 0.0.0.0/0 with any address/prefix you wish. Additionally, you can edit the route-kni254 file to contain as many individual route statements as you like; it is important to only edit this file while the SSR is stopped, however, since it will cache the contents of the file when it starts, and restore the copy it cached when software is stopped.
- Stop the SSR software on the router. There are many ways to accomplish this, one of which is to type
sudo systemctl stop 128Tfrom the Linux shell prompt.
You must ensure you are in a position to access the Linux subsystem on an SSR router even when the SSR software is not running.
- Add a route to the internet in a route file associated with
kni254(the following should all be typed on one line):
sudo echo 0.0.0.0/0 via 169.254.127.126 dev kni254 metric 200 > /etc/sysconfig/network-scripts/route-kni254
- Start the SSR software:
sudo systemctl start 128T
The loopback-static-route plugin can be installed and enabled on the SSR router to dynamically manage Linux routes.
KNI VLAN
A host device-interface can be configured with a vlan-enabled network interface. Doing so creates a unique linux interface that is managed for each network-interface, but only one underlying KNI will be created on the system. If there is no non-vlan network-interface on the device-interface, an implicit underlying “base” interface is instantiated for the KNI, and linux VLAN interfaces are stacked on it.
Output reflecting KNI interfaces with a VLAN of 200 configured:
admin@t124-dut1.Fabric128# show device-interface
Sat 2019-02-16 18:45:18 UTC
========================================
t124-dut1:dev12
========================================
Type: host
Forwarding: true
Mode: host
MAC Address: b2:9c:1f:9a:d9:7a
Admin Status: up
Operational Status: up
Redundancy Status: non-redundant
Speed: 1000
in-octets: 2816
in-unicast-pkts: 38
in-errors: 0
out-octets: 0
out-unicast-pkts: 0
out-errors: 0
network-interfaces:
dev12:
base state: good
dev12.200:
vlan state: good
Completed in 0.24 seconds
admin@t124-dut1.Fabric128# show platform device-interfaces
Sat 2019-02-16 18:45:56 UTC
===============================================================
t124-dut1
===============================================================
----------------------------
Device Interface Information
----------------------------
Name: dev12
Manufacturer:
Description:
Driver:
Driver Version: unavailable
Speed:
PCI Address:
MAC Address: be:0c:c2:1e:79:be
Firmware Version: unavailable
Statistics Supported: unavailable
Test Info Supported: unavailable
EEPROM Access Supported: unavailable
Register Dump Supported: unavailable
network-interfaces:
dev12:
base info: good
dev12.200:
vlan info: good
Completed in 1.29 seconds