Arista EOS VRF Configuration and Route Leaking

VRF instances on Arista EOS keep tenant or function traffic separate while sharing the same physical fabric or uplink. The configuration has three moving parts that must all be present — the VRF instance, a per-VRF routing table enabled with ip routing vrf, and interfaces or BGP neighbours bound to that VRF — and leaving out the second one produces a VRF that exists but forwards nothing. This guide covers the build, the BGP route-target model, and the two ways to leak routes between VRFs.

Create the VRF instances

vrf instance MGMT
vrf instance PROD
vrf instance DEV
!
ip routing
ip routing vrf MGMT
ip routing vrf PROD
ip routing vrf DEV

An optional per-VRF route distinguisher is useful when the VRF participates in MPLS or EVPN:

vrf instance PROD
   rd 65001:100

Assign interfaces and build a per-VRF static route

interface Ethernet1
   description to-core-uplink-prod
   no switchport
   vrf PROD
   ip address 10.100.0.2/30
!
interface Ethernet2
   description to-dev-lab
   no switchport
   vrf DEV
   ip address 10.200.0.2/30
!
interface Ethernet3
   description oob-management
   no switchport
   vrf MGMT
   ip address 10.250.0.2/24
!
ip route vrf PROD 0.0.0.0/0 10.100.0.1
ip route vrf DEV 10.20.0.0/16 10.200.0.1

Verify the VRF is complete

show vrf
show ip route vrf PROD
show ip interface vrf PROD brief
show interfaces Ethernet1
show vrf PROD detail

If the VRF appears in show vrf but routes never appear, check that ip routing vrf PROD is present. In show ip route vrf PROD an empty table with configured interfaces is the signature of a missing routing enable statement.

BGP inside a VRF and route targets

router bgp 65001
   router-id 10.0.0.1
   !
   vrf PROD
      rd 65001:100
      route-target import evpn 65001:100
      route-target export evpn 65001:100
      neighbor 10.100.0.1 remote-as 65002
      neighbor 10.100.0.1 maximum-routes 12000
      !
      address-family ipv4
         neighbor 10.100.0.1 activate
         redistribute connected
         redistribute static
      !
   vrf DEV
      rd 65001:200
      route-target import evpn 65001:200
      route-target export evpn 65001:200

Route targets are how the VRF's routes are classified on export and selected on import. Peering, MPLS L3VPN and EVPN all reuse the same import/export logic, which is why a route-target mismatch is the first thing to check when a VPN route is learned but not installed.

Inter-VRF route leaking

There are two supported approaches. The route-target method reuses the existing BGP VRF context:

router bgp 65001
   vrf DEV
      rd 65001:200
      route-target import vpn-ipv4 65001:100    ! pull PROD routes in
      route-target export vpn-ipv4 65001:200

The route-map method gives finer control and does not require an MPLS or EVPN control plane between the VRFs:

ip prefix-list PL-SHARED seq 10 permit 10.20.0.0/16 le 24
!
route-map RM-PROD-TO-DEV permit 10
   match ip address prefix-list PL-SHARED
!
router general
   vrf DEV
      leak routes source-vrf PROD subscribe-policy RM-PROD-TO-DEV
      exit
   exit
!
service routing protocols model multi-agent

The leak is one-way unless configured in both directions, and it is applied per destination VRF — vrf DEV subscribes to routes from PROD. Use a prefix list so a new subnet in the source VRF does not silently become visible everywhere.

Verification and troubleshooting

show ip route vrf DEV
# leaked prefixes are tagged with the "L" code and name their source VRF
show ip bgp vrf DEV 10.20.0.0/16
show ip bgp vrf DEV
show route vrf DEV
show running-config vrf

In show ip route vrf DEV, leaked entries appear as B L ... (source VRF PROD). If the prefix is present in show ip bgp vrf PROD but absent from the DEV table: confirm the policy name matches exactly, confirm the leak statement sits inside router general > vrf <target>, and remember that route leaking requires the multi-agent routing model.

Deployment notes

• Keep one VRF for out-of-band management on every device. Mixing management and production traffic in a single table makes the day the production table breaks much worse.
• Name VRFs consistently across the estate (PROD/DEV/MGMT), because automation and monitoring will filter on those names.
• Document each leak explicitly with its purpose and the prefixes involved — undocumented leaking is how segmentation quietly disappears.

Related reading: Arista EOS VLAN, trunk, SVI and port-channel runbook, Arista EOS EVPN-VXLAN symmetric IRB, and Cisco IOS to Arista EOS command mapping.

原文链接：https://www.arista.com/en/um-eos/eos-evpn-and-vcs-commands