The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This section illustrates how, with the Packet I/O functionality, you can use Linux applications to manage communication with the IOS XR interfaces. It describes how the OS environment must be set up to establish packet I/O communication with hosted applications.
Interfaces configured on IOS XR are programmed into the Linux kernel. These interfaces allow Linux applications to run as if they were running on a regular Linux system. This packet I/O capability ensures that off-the-shelf Linux applications can be run alongside IOS XR, allowing operators to use their existing tools and automate deployments with IOS XR.
The IP address on the Linux interfaces, MTU settings, MAC address are inherited from the corresponding settings of the IOS XR interface. Accessing the global VRF network namespace ensures that when you issue the bash command, the default or the global VRF in IOS XR is reflected in the kernel. This ensures default reachability based on the routing capabilities of IOS XR and the packet I/O infrastructure.
You can run bash commands at the IOS XR router prompt to view the interfaces and IP addresses stored in global VRF. When you access the Cisco IOS XR Linux shell, you directly enter the global VRF.
|
Step 1 |
From your Linux box, access the IOS XR console through SSH, and log in. Example: |
||
|
Step 2 |
View the ethernet interfaces on IOS XR. Example:This outsput displays the ip-address and the status of the active NCS 1004 interfaces.
|
||
|
Step 3 |
Check the IP and MAC addresses of the interface that is in Example:MgmtEth0/RP0/CPU0/0 as it is in UP state.This output shows the configuration details of the |
||
|
Step 4 |
Verify that the bash command runs in global VRF to view the network interfaces. Example:This output shows the active network interfaces in Linux. The |
||
|
Step 5 |
Access the Linux shell. Example: |
||
|
Step 6 |
(Optional) View the IP routes used by the Example: |
The basic routes required to allow applications to send or receive traffic can be programmed into the kernel. The Linux network stack that is part of the kernel is used by normal Linux applications to send/receive packets. In an IOS XR stack, IOS XR acts as the network stack for the system. Therefore to allow the Linux network stack to connect into and use the IOS XR network stack, basic routes must be programmed into the Linux Kernel.
|
Step 1 |
View the routes from the bash shell. |
|
Step 2 |
Programme the routes in the kernel. Two types of routes can be programmed in the kernel:
|
The Linux system contains a number of individual network namespaces. Each namespace contains a set of interfaces that map to a single interface in the XR control plane. These interfaces represent the exposed XR interfaces (eXI). By default, all interfaces in IOS XR are managed through the IOS XR configuration (CLI or YANG models), and the attributes of the interface (IP address, MTU, and state) are inherited from the corresponding configuration and the state of the interface in XR.
With the new Packet I/O functionality, it is possible to have an IOS XR interface completely managed by Linux. This also means that one or more of the interfaces can be configured to be managed by Linux, and standard automation tools can be used on Linux servers can be used to manage interfaces in IOS XR.
This section shows how to configure an interface to be Linux-managed.
|
Step 1 |
Check the available exposed-interfaces in the system. Example: |
|
Step 2 |
Configure the interface to be managed by Linux. Example: |
|
Step 3 |
View the interface details and the VRF. Example: |
|
Step 4 |
Verify the configuration in XR. Example: |
|
Step 5 |
Verify the configuration from Linux. Example: |
This section shows how to bring up the interface and configure a custom MTU in a Linux-managed interface.
|
Step 1 |
Configure the MTU setting. Example: |
|
Step 2 |
Verify that the MTU setting has been updated in Linux. Example: |
|
Step 3 |
Check the effect on the IOS XR configuration with the change in MTU setting on this interface. The output indicates that the interface acts as a regular Linux interface, and IOS XR configuration receives inputs from Linux. |
This example shows how the bundle-ether interface packet statistics are synchronized between IOS XR and Linux. The packet and byte counters maintained by Linux for IOS XR interfaces display only the traffic sourced in Linux. You can configure to periodically synchronize these counters with the IOS XR statistics for the interfaces.
|
Step 1 |
Configure the statistics synchronization including the direction and synchronization interval. Example:Example:where —
|
|
Step 2 |
Verify that the statistics synchronization is applied successfully on IOS XR. Example:For troubleshooting purposes, use the show tech-support linux networking command to display debugging information. |
The NCS 1004 allows you to synchronoze routes between the IOS XR and linux interfaces. You can achieve route synchronization in three methods.
Sending traffic from Linux via a connected network.
Sending traffic from Linux via a network requiring a route, where the route is present in XR.
Sending traffic from Linux via a network requiring a route (no route present).
For each of the three scenarios, we will use the following back-to-back topology for illustration. All interfaces are assumed to be configured with their IP addresses and up.
All the three methods consider the R1 node has the same configuration.
RP/0/RP0/CPU0:ios#bash
[ios:~]$ ifconfig
Lo0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 20.2.2.2 netmask 255.255.255.255 broadcast 0.0.0.0
ether 9a:91:5d:6d:ad:c8 txqueuelen 2000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Mg0_RP0_CPU0_0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 72.163.4.154 netmask 255.0.0.0 broadcast 72.255.255.255
ether 74:88:bb:ff:fe:c8 txqueuelen 2000 (Ethernet)
RX packets 69764 bytes 7270201 (6.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 1400
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
to_xr: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1300
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 2000 (UNSPEC)
RX packets 8 bytes 768 (768.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 348 (348.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0In this method, we are sending traffic to 12.0.0.2 or 100.0.0.2 from Linux on R1. No extra configuration is required in Linux. XLNC syncs all of the relevant IP addresses and the kernel populates the routes.
|
Step 1 |
View the IP routes used by the to_xr interfaces. Example: |
|
Step 2 |
Verify connectivity with R2 node. Example: |
This example shows how to the use the to_xr Linux interface. This interface uses Rx-inject to inject a packet as though it had just been received by the router. This leads to the packet being routed as per routes installed in the RIB.
The key piece of information required here is the source address which should be chosen. Linux has no way of determining this without a route, but in typical deployments the XR features that rely on Linux Networking (Model Driven Telemetry, and IOS-XR Install) need connectivity. To allow these to work, XR uses the IP of the lowest-numbered Loopback (e.g. Loopback0) interface and sets it as the source hint for the default route.
If connectivity is instead needed to a destination that cannot route to the lowest-numbered loopback, the user must manually add a new route to Linux. (In future releases it will be possible to configure XR routes to be added to Linux automatically, but manual intervention is needed in the first release.)
|
Step 1 |
Check the route details for the NCS 1004 node R1. Example: |
|
Step 2 |
View the IP routes used by the to_xr interfaces. Example: |
|
Step 3 |
Add a rotue sync configuration in XR. Example: |
|
Step 4 |
Verify the linux configuration in XR. Example: |
|
Step 5 |
Add a route with source IP address in Linux Example: |
|
Step 6 |
Verify connectivity with R2 node. Example: |
This method uses only the Linux networking stack to accomplish the same as scenario 2. Here the required configuration is to set the route in Linux. You can omit the source IP, as this will be resolved via Linux.
|
Step 1 |
Check the route details for the NCS 1004 node R1. Example: |
|
Step 2 |
View the IP routes used by the to_xr interfaces. Example: |
|
Step 3 |
Set the route in Linux. Example: |
|
Step 4 |
Verify connectivity with R2 node. Example: |
Feedback