What is an EVPN Type 5 Route for (EVPN/VXLAN)

May 24, 2025 Leave a comment

For EVPN/VXLAN, Type 5 routes are used for two purposes: Internally and Externally

Internally it’s used to communicate which VTEPs have a given subnet instantiated on it.

Here’s an example of the output of the command show ip bgp route-type ip-prefix ipv4 on an Arista cEOS spine running EVPN/VXLAN.

It’s showing you that 10.1.10.0/24 (VLAN 10/VNI 10010) is only available on leaf1 and leaf2 (10.1.255.1-2) and 10.1.20.0/24 (VLAN 20/VNI 10020) is only available on leaf3 and leaf4 (10.1.255.3-4). It’s eBGP so each leaf has its own ASN (you see in the path field). The next hop shows the VTEP IP (10.1.254.1-4). I checked on the spine as the spine receives all the EVPN routes from the leafs and propagates them as a route server. The spines don’t install any of these routes, they just propagates them.

       Network                Next Hop              Metric  LocPref Weight  Path

 * >      RD: 10.1.255.1:10000 ip-prefix 10.1.10.0/24
                                 10.1.254.1            -       100     0       65101 i
 * >      RD: 10.1.255.2:10000 ip-prefix 10.1.10.0/24
                                 10.1.254.2            -       100     0       65102 i
 * >      RD: 10.1.255.3:10000 ip-prefix 10.1.20.0/24
                                 10.1.254.3            -       100     0       65103 i
 * >      RD: 10.1.255.4:10000 ip-prefix 10.1.20.0/24
                                 10.1.254.4            -       100     0       65104 i

This is important for to know when trying to find a host who’s MAC or MAC-IP isn’t known. Let’s say you’re on leaf1 on VLAN 10, and there’s a host you’re trying to ping on VLAN 50. In Arista cEOS with symmetric IRB, the internal Type 5 routes are generated under the tenant VRF with “redistribute connected”.

   vrf Blue
      rd 10.1.255.2:10000
      route-target import evpn 10000:10000
      route-target export evpn 10000:10000
      redistribute connected

On leaf3 and 4, I’m going to remove that redistribute connected command, then see what the spines see.

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 10.1.255.1:10000 ip-prefix 10.1.10.0/24
                                 10.1.254.1            -       100     0       65101 i
 * >      RD: 10.1.255.2:10000 ip-prefix 10.1.10.0/24
                                 10.1.254.2            -       100     0       65102 i


So for 10.1.20.0/24, we have no prefix information. Any VLAN 20 to VLAN 20 communication will work, any you can communicate with a host in VLAN 20 from outside of VLAN only if the host has talked and a Type 2 route was generated. But if there’s no reachability information, the fabric doesn’t have a way to find it without the Type 5 route information. So if they talk, the fabric will discover them. If the host is silent, the Type 5 route is needed.

Right now there’s a host at 10.1.20.201 on VLAN 20. From a host on 10.1.10.0/24, I’ll try to ping 10.1.20.201.

host1#ping 10.1.20.201
PING 10.1.20.201 (10.1.20.201) 72(100) bytes of data.
From 10.1.10.1 icmp_seq=1 Destination Net Unreachable

I’ll turn the Type 5 routes back on.

host1#ping 10.1.20.201
PING 10.1.20.201 (10.1.20.201) 72(100) bytes of data.
80 bytes from 10.1.20.201: icmp_seq=1 ttl=62 time=11.8 ms
80 bytes from 10.1.20.201: icmp_seq=2 ttl=62 time=3.34 ms
80 bytes from 10.1.20.201: icmp_seq=3 ttl=62 time=2.18 ms
80 bytes from 10.1.20.201: icmp_seq=4 ttl=62 time=2.04 ms
80 bytes from 10.1.20.201: icmp_seq=5 ttl=62 time=1.95 ms

The fabric had enough information now to find the hosts because the Type 5 routes were there.

So that’s internally. What about externally?

On leaf3 I configured an external router, R1, for BGP on the tenant VRF.

leaf3#show ip bgp summary vrf Blue 
BGP summary information for VRF Blue
Router identifier 10.1.20.1, local AS number 65103
Neighbor Status Codes: m - Under maintenance
  Neighbor V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.1.5.0 4 1                 25        37    0    0 00:16:20 Estab   1      1
From this BGP session, leaf3 has learned the route 172.16.0.0/12. 
B E      172.16.0.0/12 [200/0]
           via 10.1.5.0, Ethernet12


But that route is only learned on leaf3, how do we get it to the other leafs? Type 5. Again the result of show bgp evpn route-type ip-prefix ipv4:

          Network                Next Hop              Metric  LocPref Weight  Path
(A bunch of other routes)
* >      RD: 10.1.255.3:10000 ip-prefix 172.16.0.0/12
                                 10.1.254.3            -       100     0       65103 1 i

This tells the fabric that the network 172.16.0.0.12 is available on leaf3 (65103). If a host anywhere else on the fabric needs to send a packet to that network, encap the VXLAN packet and send it to leaf3.

Now a host connected to leaf1 can ping 172.16.0.1, which is outside of the EVPN/VXLAN fabric.

host1#ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 72(100) bytes of data.
80 bytes from 172.16.0.1: icmp_seq=1 ttl=62 time=2.98 ms
80 bytes from 172.16.0.1: icmp_seq=2 ttl=62 time=1.57 ms
80 bytes from 172.16.0.1: icmp_seq=3 ttl=62 time=1.64 ms
80 bytes from 172.16.0.1: icmp_seq=4 ttl=62 time=1.62 ms
80 bytes from 172.16.0.1: icmp_seq=5 ttl=62 time=1.80 ms

Filed under Uncategorized Tagged with , , ,

Running CVP on Proxmox

April 7, 2024 Leave a comment

With VMware jacking up the prices and killing off the free version of ESXi, people are looking to alternatives for a virtualization platform. One of the more popular alternatives is Proxmox, which so far I’m really liking.

If you’re looking to run CVP on Proxmox, here is how I get it installed. I’m not sure if Proxmox counts as officially supported for production CVP (it is KVM, however), but it does work fine in lab. Contact Arista TAC if you’re wondering about Proxmox suitability.

Getting the Image to Proxmox

Oddly enough, what you’ll want to do is get a copy of the CVP OVA, not the KVM image. I’m using the most recent release (at the time of writing, always check Arista.com) of cvp-2024.1.0.ova.

Get it onto your Proxmox box (or one of them if you’re doing a cluster). Place it somewhere where there’s enough space to unpack it. In my case, I have a volume called volume2, which is located at /mnt/pve/volume2.

I made a directory called tmp and copied the file to that directory via SCP (using FileZilla, though there’s several ways to get files onto Proxmox, it’s just a Linux box). I then untared the OVA with tar -xvf (I know, right? I had no idea it was just a tgz ball).

root@proxmox:/mnt/pve/volume2/tmp# tar -xvf cvp-2024.1.0.ova
cvp.ovf
cvp.mf
cvp-disk1.vmdk
cvp-disk2.vmdk

In my case, this gave me four files, two of which are vmdk disk files.

Importing the OVA to Proxmox Inventory

The next step is to import the disks and the VM into system inventory. You’ll need to pick a volume to place it in, as well as a unused VMID. In my case, I’m using volume2 and the VMID of 109, which was available in my environment. 

root@proxmox:/mnt/pve/volume2/tmp# qm importovf 109 cvp.ovf volume2 --format qcow2
...
transferred 0.0 B of 1.0 TiB (0.00%)
transferred 11.0 GiB of 1.0 TiB (1.07%)
transferred 21.8 GiB of 1.0 TiB (2.13%)
transferred 32.8 GiB of 1.0 TiB (3.20%)
transferred 43.7 GiB of 1.0 TiB (4.27%)
...

This process will take a few minutes at least. You’ll see it refer to 1 TiB, but don’t worry, it’s thin provisioned so it’s not actually going to take up 1 TB (at least not initially).

You should now see the VM in your Proxmox Inventory. I would change the name, as well as up the RAM to something higher (it starts with 28 GB, I put it at around 36 GB of RAM). You’ll need to add a NIC as well. Put it on a virtual switch (bridge) and select VirtIO for the NIC model.

From there you can follow the install CVP instructions. Remember you’ll need both forward and reverse DNS records, as well as access to an NTP server to complete the install.

Filed under Uncategorized Tagged with , , , , , , ,