Here’s some tips on setting up a management VRF in Arista gear, including management VRF routing which may or may not be available to you depending on equipment.  Keep in mind that I’m doing this so that I can have management protocols on a management VLAN without having to use the built-in management ethernet port.  I can’t remember if the management ethernet is already isolated, or if these same steps apply to using it as your management interface.  In my case I don’t care because I want management going out the already configured 10gig port channel with the rest of the switch’s north/south traffic.

So, first things first, if you would like your management VRF to support routing, make sure VRF’s are even possible before wasting your time trying commands that may not work.  Use the feature matrix to find this:

https://www.arista.com/en/support/product-documentation/supported-features

Set it to the model you have, select layer 3 features, then search.  It should show you on that page if VRF’s are supported.

Okay, moving on, first thing to do is define your VRF.  I simply call my management VRF “MGMT”.  Don’t just paste the following code though, read the explanation that follows it as it may not be correct for your environment:

vrf definition MGMT
 description Management Traffic vlan 192
 rd 100:100
!

Okay, in the above, the things you may need to change are:

• The VRF name; mine is “MGMT” but perhaps you already have one named that.  You should run “show vrf” first to make sure you don’t.
• My description is just a reminder, but includes the vlan ID I used for this VRF, so you can remove/edit as needed, or eliminate description entirely.
• The route distinguisher is required if you need your management VRF to support routed traffic, including even just having a default gateway static route.  So if you’re going to be sending syslog, sflow, NTP queries, code upgrade scp’s, etc. to a remote network beyond the one your management interface appears on, you’re going to need a route distinguisher.  If you do NOT use MPLS in your network, then the number you choose is irrelevant; I just use 100:100 as I don’t use MPLS.  If you do use MPLS, you should ensure this does not create any conflicts if you plan to also use MPLS on the management interface(s).So just remember, no route distinguisher, no routing, even static.  If your management network is flat, or you’ll be doing just NAT’d inbound connections to the device, then you do not need the route distinguisher.

Next up, you need to put one or more interfaces into the management VRF named MGMT (in my case) before traffic can be passed for the management side of the switch.  We will also later isolate all management protocols to just this VRF.  In my case, VLAN 192 is for management traffic, so I’m going to add an interface on that VLAN for management use, put it in the MGMT VRF, and give it an IP address:

interface Vlan192
 vrf forwarding MGMT
 ip address 192.0.2.6/24
!

Okay, now we have our management VRF, a virtual interface in it, and an IP assigned.  My switch uplinks off of a port channel, so I’m going to add that vlan to the trunk:

interface Port10
switchport trunk allowed vlan add 192

Now, in addition to the other VLANs already permitted to go in and out that trunk, 192 is in the list so my management traffic can make it into the switch and to my management VLAN 192 interface.  Finally, if your management network is not flat, you’ll need to add a route specific to the management VRF:

ip route vrf MGMT 0.0.0.0/0 192.0.2.1

Now my switch, at 192.0.2.6, can access whatever the next hop router 192.0.2.1 permits it to; it is successfully connected with routing.  You can use the “show vrf” command to confirm this:

arista-7010t#show vrf
Maximum number of vrfs allowed: 15
    Vrf          RD         Protocols           State        Interfaces
---------- ------------- --------------- ------------------- ----------
    MGMT       100:100      ipv4,ipv6        v4:routing,      Vlan192
                                             v6:no routing

If you had not added the rd 100:100 to the VRF config, in the above table you’d see “v4:incomplete” instead of v4:routing, and while traffic to the management IP from the same network would work, off-network would not, and “show ip route vrf MGMT” would show default gateway unreachable.

Okay, so next up, many things that you may turn on, or default to on, will be available on any interface with an IP address assigned.  That’s bad, don’t do that.  That’s why we have management VRF’s; put those services in the VRF and isolate them.  Here’s the ones I know of that both should be locked down, and support being put in a VRF:

• NTP – you can put the Arista NTP client in your VRF via:

  ntp source vrf MGMT Vlan192
  ntp server vrf MGMT 192.0.2.1

• SNMP – turn the server off in the default VRF; you have to explicitly do that or you’ll find it listening on interfaces you probably don’t want:

  no snmp-server vrf default
  snmp-server vrf MGMT

• Routing – if you’re only going to use static routes in your management VRF, turn off routing for it (static still works):

  no ip routing vrf MGMT

• SSH – here’s the one that annoys me.  On Arista, SSH in the management VRF has to be explicitly not shut down, but SSH on the default VRF must be explicitly shut down; i.e. it’s on by default in the default VRF, but it’s off by default in any other VRF.  So, off on default, on in VRF:

  management ssh
      idle-timeout 15
      shutdown
      !
      vrf MGMT
         no shutdown

• Telnet – turn off for both, and it’s backwards from SSH, off by default, but explicitly off in VRF’s:

  management telnet
     vrf MGMT
     shutdown

• XMPP – off by default, but define the VRF anyway and tell it to shut down, even though you won’t see the shutdown tag in the running config.

  management xmpp
     vrf MGMT