• VRF interaction using EOS and Bash

 
 
Print Friendly, PDF & Email

Overview:

Virtual Routing and Forwarding, or VRF, is a construct within Arista’s Extensible Operating System, or EOS, that provides a network administrator with the ability to delineate network communications at the Network layer of the OSI 7-layer model.

When defining the attributes of a VRF, you can place your EOS CLI session into the context of the desired VRF. The technique of entering a VRF context has particular utility when you need to work more exclusively with a specific VRF. Doing so can help avoid redundant target VRF references with each pertaining command. Placing yourself into a VRF context can also be of value even when there are only 2 VRF’s created on a device.

 

In Practice:

In practice, both EOS and Bash offer the Network Administrator a powerful set of tools to assist with VRF management. In addition to the EOS-based VRF toolset, Arista includes access to Linux Bash where you can also administrate facets of a VRF. You have the ability with Arista devices to move between EOS CLI and Linux Bash and use either at will.

From Linux Bash, you have many of the same Linux tools that you will find on a typical Linux device. One of these tools is the IP NetNS command, which allows you to see VRF specific information.

In this article, we will show-case VRF instance interaction within EOS. Then we’ll delve into doing the same in Bash. This article will not include the process of creation or removal of VRF’s in either EOS or Bash.

 

EOS – VRF Interaction:

First, let’s start by viewing what VRF’s are currently defined.

Switch#show vrf

Maximum number of VRFs allowed: 4095
VRF Protocols State Interfaces
------------- --------------- ---------------- ----------------------------------------
Blue    IPv4 routing Vl20, Vl4002
Green   IPv4 routing Vl30, Vl130, Vl4003
MGMT    IPv4 routing Ma1
default IPv4 routing Et23, Et24, Lo0, Lo1, Vl10, Vl22, Vl100, Vl110, Vl4001

 

Entering a VRF Context:

The procedure to enter a VRF context is as follows (keep in mind tab-completion works for the VRF name):

Switch# cli vrf <vrf>

Deprecated usage: Switch# routing-context vrf <vrf>

Example:
Switch#cli vrf ?
WORD VRF name
default Default virtual routing and forwarding instance

Switch#cli vrf MGMT
Switch(vrf:MGMT)#

 

Working within a VRF Context:

Once within the desired VRF context, you can issue commands natively and only see tables that pertain to that specific VRF.

 

Example:
Switch(vrf:MGMT)#show ip route

VRF: MGMT
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route

Gateway of last resort:
S 0.0.0.0/0 [1/0] via 192.168.200.1, Management1
C 192.168.200.0/24 is directly connected, Management1

As a side note of caution, despite being in a specific VRF context, you still can affect global switch configuration changes for all VRF’s.

 

The VRF administration technique above is contrasted by the approach below of viewing aspects of a VRF from outside the VRF, without entering the VRF context:

 

Example:
Switch#show ip route vrf MGMT

VRF: MGMT
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route

Gateway of last resort:
S 0.0.0.0/0 [1/0] via 192.168.200.1, Management1
C 192.168.200.0/24 is directly connected, Management1

Switch#

 

Exiting a VRF Context:

To exit a VRF context within EOS you use the same command as you used to enter the context. Simply indicate the desired destination VRF context that you want to go back into.

Switch# cli vrf <vrf>

 

Example:
Switch(vrf:MGMT)#cli vrf default
Switch#

 

Bash – VRF Interaction:

As said, EOS provides you with the ability to jump between EOS CLI and Linux Bash at will. There are many reasons this would be a desired feature that is out of the scope of this document.

 

Linux VRF tools:

Included at the base for Arista’s EOS are Linux iproute2 project tools like ip netns. As a complement to EOS, the ip netns tool can be a valuable resource to assist with administrating VRF’s on a device. The terms “VRF” within EOS and “Namespace” within ip netns are in many ways an analogue to one another.

There are many ip netns command variables and most are outside the scope of this document. For more information on the ip netns command variables, please see its relevant man page. Certain command usages however are listed below:

 

Usage: <sudo> ip netns <sub-command> <vrf> <command>

Usage: ip netns identify

  • Used to identify what VRF you are currently in from within Bash.

Usage: ip netns list

  • Displays what VRF’s are defined on the device from the Bash prompt.

Usage: ip netns exec <vrf> <command>

  • Allows an administrator to execute Linux commands on a remote VRF.

 

To enter Bash from EOS, simply type bash and hit enter at the command prompt:

 

Example:
Switch#bash
Arista Networks EOS shell
bash-4.2#

 

Transitioning from EOS CLI:

It is worth noting that when you switch from EOS CLI to Bash (or vice versa), the VRF context you were in is maintained through this transition. The exception is if you change into a different VRF context while in Bash. When you exit Bash and return to EOS you are returned to the original VRF context when you entered Bash.

 

Example:
Switch#cli vrf MGMT
Switch(vrf:MGMT)#bash

bash-4.2# ip netns identify
ns-MGMT

 

Displaying defined VRF’s:

As with the “show vrf” command in EOS, you can also list the defined VRF’s from Bash. Please note that the naming convention of the VRF’s differs slightly between EOS and Bash. For example, the MGMT  VRF in EOS translates to the ns-MGMT  VRF in Bash.

 

Example:

bash-4.2# ip netns list
ns-BLAH
ns-Green
ns-Blue
ns-MGMT
default (id: 0)
bash-4.2#

 

Entering a VRF Context:

It is also possible to switch VRF contexts within Bash.

 

Example:
bash-4.2# ip netns identify
default
bash-4.2# ip netns exec ns-MGMT bash
bash-4.2#
bash-4.2# ip netns identify
ns-MGMT

 

Working within a VRF Context:

Once in a VRF context, you have device statistics and information specific to that VRF available to you. The following are a few examples.

 

View interfaces assigned to the VRF:
bash-4.2# ip netns identify
ns-MGMT

bash-4.2# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ma1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether fc:bd:67:0e:d7:70 brd ff:ff:ff:ff:ff:ff link-netnsid 0

 

Viewing the route table for the VRF:
bash-4.2# ip route
blackhole 0.0.0.0/8 proto gated scope nowhere
default via 192.168.200.1 dev ma1 proto gated
blackhole 127.0.0.0/8 proto gated scope nowhere
192.168.200.0/24 dev ma1 proto kernel scope link src 192.168.200.51

 

As discussed previously, you can also view information about other VRF’s from Bash without switching the VRF context:
Switch#bash
bash-4.2# ip route
blackhole 0.0.0.0/8 proto gated scope nowhere
blackhole 127.0.0.0/8 proto gated scope nowhere
127.0.0.0/8 dev ipfix proto kernel scope link src 127.0.0.1
127.254.254.1 dev fwd0 proto gated scope link metric 1024
172.22.22.0/24 dev vlan22 proto kernel scope link src 172.22.22.1
192.168.100.0/24 dev vlan100 proto kernel scope link src 192.168.100.2
192.168.110.0/24 dev vlan110 proto kernel scope link src 192.168.110.2
192.168.248.0/24 dev vlan10 proto kernel scope link src 192.168.248.1

bash-4.2# ip netns list
ns-BLAH (id: 0)
ns-Green
ns-Blue
ns-MGMT
default

bash-4.2# ip netns exec ns-MGMT ip route
blackhole 0.0.0.0/8 proto gated scope nowhere
default via 192.168.200.1 dev ma1 proto gated
blackhole 127.0.0.0/8 proto gated scope nowhere
192.168.200.0/24 dev ma1 proto kernel scope link src 192.168.200.51

 

Exiting a VRF Context:

The process to switch back to the original VRF within Bash is simple:

bash-4.2# ip netns exec ns-MGMT bash
bash-4.2# ip netns identify
ns-MGMT
bash-4.2# exit
exit
bash-4.2# ip netns identify
default

 

Exiting from Bash back to EOS CLI:

And finally, when you are ready to return to the EOS CLI, the process is just as simple:

bash-4.2# exit
logout
Switch#

 

Summary:

There are myriad additional tools and features to assist with VRF administration in both EOS and Bash. Simple awareness of VRF attribute management, whether within a VRF context or outside of it, combined with the accessibility that Arista offers via EOS and Bash has intrinsic value.

 

Resources:

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: