A very common approach for networks is to have the management interface of the network node (switch, router, load balancer, etc.) in a separate VRF [Virtual Routing and Forwarding] instance. This has many security benefits, especially in the case of internet facing devices.
Main ones from my perspective are:
- Separate routing table to the rest of the device
- Isolation of management services
- Independent virtual/physical interfaces, with tightened ACLs
Arista EOS for quite some time has supported VRFs, but something that you need to keep in mind when using them is that the VRF has it’s own routing table. So when you create a VRF e.g. MGMT-VRF all your addresses and routes for the management network are no longer in the default routing instance.
switch(config)# vrf definition MGMT-VRF
switch(config-vrf-MGMT-VRF)# rd 123:12
switch(config)# interface et1
switch(config-if-et1)# vrf forwarding MGMT-VRF
Some commands are VRF aware e.g. ping. For example you can run the following command:
ping vrf MGMT-vrf 10.10.10.1
Unfortunately not all commands are VRF aware yet – an obvious one is the copy command. The solution to this is to switch to the routing-context that you are trying to copy to/from and then run the copy command (this applies to all non-VRF-aware commands).
switch# routing-context vrf MGMT-VRF
switch# show routing-context vrf
Current VRF routing-context is MGMT-VRF
switch# copy ...
Then afterwards switch back to the default
switch# routing-context vrf default
