This document will provide a summary over an Arista EOS switch and how an administrator can use Virtual Routing and Forwarding (VRFs) to achieve a desired solution. The number of VRFs varies per switch due to the amount of RAM and CPU on a switch.  As of this writing, VRF scale are the following per model. Configuration of a VRF is fairly straightforward and all VRFs have their own separate forwarding tables.  As with everything in EOS, all VRFs meet at SysDB. As these numbers may change in the future (as new features are added), please refer to the Release Notes and TOI documentation, These can be found on the Software Downloads page here.

Number of VRFs = user-defined + default VRF

  • 7050 , 7010 – up to 16 VRFs
  • 7050X, 7250X, 7300X – up to 32 VRFs
  • 7150 – up to 15 VRFs
  • 7500E – up to 32 VRFs
  • 7280E – up to 8 VRFs
  • 7260CX – up to 16 VRFs
  • 7060CX/7060QX – up to 16 VRFs
  • 7500R/7280R – up to 32 VRFs

Note: Since the scaling limit can vary depending on software release, and exact platform in question (amount of RAM ordered, etc.) as of 4.15.4F, the show vrf command includes the max number of user-defined VRFs.

Arista >show vrf
Maximum number of vrfs allowed: 15
   Vrf       RD       Protocols       State    Interfaces
--------- -------- --------------- ----------- ----------

 VRF_SysDB  CONFIGURATION EXAMPLE A user defined VRF is created with the vrf definition command in config mode. Furthermore, a route distinguishes must be applied to the VRF in order to activate it. In the example below 65001 is the Autonomous System number, and 15 is the local number. For a thorough explanation of VRF configuration, please view the latest Arista Config Guide found under Product Documentation.

Arista(config)#vrf definition MGMT
 Arista(config)#rd 65001:15

Now we can start adding interfaces and SVIs to this VRF. Please note that IP information will be removed when adding an interface to a VRF. To do this, under the interface config mode, issue the vrf forwarding <name> command.

Arista(config)#interface ethernet10
Arista(config)#vrf forwarding MGMT

We can now verify this configuration using several show command. You can also show the

Arista(config)#show vrf
   Vrf         RD             Protocols       State         Interfaces
----------- -------------- --------------- ---------------- ----------------
   MGMT        65001:16       ipv4            routing       Ethernet10

  ROUTING AND VRFs We can also mix L3 with our VRFs. At the bottom of this document lists several use cases one can use with VRFs. Once again, for a thorough explanation of VRF configuration, please view the latest Arista Config Guide found under Product Documentation. OSPF for example, can be configured per VRF. When issuing the router ospf command, specify the VRF to be used. You could even use the #show ip ospf neighbor command and notice we have listed a VRF column to make it easier for troubleshooting.

Arista(config)#router ospf 100 vrf MGMT
Arista#show ip ospf neighbor
Neighbor ID     VRF    Pri   State            Dead Time   Address         Interface         RED        1   FULL/DR          00:00:37      Vlan200

You can also add in static routes per VRF with — you guessed it — specifying the vrf

Arista(config)#ip route vrf MGMT ethernet 1

Or even static ARPs (granted not routing, but still cool nonetheless!)

Arista(config)#arp vrf MGMT 0011.22.33.4455 arpa

Remember to use the ? mark when issuing commands, if there is a vrf keyword you can add it into a VRF. For example, to view the routing table of a participial VRF issue the #show ip route vrf MGMT command. No network engineer is complete without use of ping! To ping FROM a certain VRF, issue the command

ping vrf MGMT

Finally, we have a way to copy to/from VRFs as well! Some customers like to keep an out-of-band (OOB) network for management traffic and allow only certain subnets to reach it. You may run into some issues where your default VRF can not access some internal management resources like a file share server. I ran into one case where I needed t copy over a Splunk extension (.swix file) from a file share but the regular copy commands were not working. Issue was that the switch was operating under the default vrf. In order for the switch to copy FROM a VRF, we will need to change the routing context of the switch. In order to do this, under EXEC mode change the mode of the switch via

Arista#routing-context vrf [VRF_ID]

Once I switched to the MGMT VRF I was able to ping my file share and able to copy over my extension. To switch back to the default routing table, simply type in #routing-context default You can verify which routing-context (VRF) you are currently under via the #show routing-context vrf command. To list the VRFs configured on the switch, type in #show vrf There are multiple uses for this as well, not just for copying files to and from. Several uses case include

  • Placing the eAPI service under a certain VRF (out of band management for example)
  • Placing the XMPP service under a certain VRF
  • Placing the LLDP service under a certain VRF
  • Enable SNMP on a VRF. Note that SNMP can only be active on one VRF per switch.
  • Placing interfaces or SVIs in a VRF to isolate it from the default routing context (useful for MPLS). Note however that by assigning an interface to a VRF you’ll loose IP addresses associated with the port.
  • Sub-interfaces in a VRF are supported!
  • VXLAN Routing with Overlay VRFs supported!
  • Ability to route traffic between two VRFs on the same physical switch (via external cable).
  • Source interface for Arista .swix extensions like Splunk Forwarder. You can choose which VRF will reach the Splunk indexer.

Lastly, a nice script could be run off the CLI (no need to drop into bash). By creating an alias with variables to catch user input, you can avoid having to change the router’s context!

switchA#sho run section copyvrf
alias copyvrf
   10 routing-context vrf %1
   20 copy %2 %3
   30 routing-context vrf default
switchA#copyvrf MGMT scp://edmund@ flash:
tor1-config                                   100%  681     0.7KB/s   00:00
Copy completed successfully.


This post was originally wrote for EOS Central at – republished here. Please see the original link here.

William Zambrano

William Zambrano

NYC networkers is run by William Zambrano, a passionate network engineer who has been in the IT industry for eight years who posts up blog articles, YouTube videos, and holds events in the NYC area. He lives in Queens, New York and has consulted in various different companies in the NY area. Previously William worked as a Cisco Certified Systems Instructor (CCSI) but now currently works for Arista Networks serving as a Systems Engineer. William can be reached by email at

More Posts - Website

Follow Me: