EVPN Type-5 Routes: IP Prefix Advertisement
The EVPN type 2 routes can be used to advertise IP prefixes by making use of the optional IP address and IP address length fields in the route, however they are explicitly linked to the MAC address advertised within the route. The EVPN type-5 route defined within the draft https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-04, provides the ability to decouple the advertisement of an IP prefix from any specific MAC address, providing the ability to support floating IP address, optimize the mechanism for advertising external IP prefixes, and reduce the churn when withdrawing IP prefixes.
The figure below displays the format of the new type-5 IP-prefix route.
- Advertising of IP prefixes behind an appliance, when the appliance is not running a routing protocol and only supporting static routes. This could be the typical use case for a Virtual Firewall with a number of local subnets directly attached, but the firewall is only supporting static routes into the associated EVI.
- Support for active-standby deployment of appliances using a shared floating IP model. This is an extension of the previous case where there is now a virtual IP (or VIP) for clustering the appliances, rather than a dedicated physical IP address on the appliance.
- Support for Layer 2 appliances, acting as a “bump in the wire” with no physical IP addresses configured, where instead of the appliances having an IP next-hop there is only a MAC next-hop.
- IP-VRF to IP-VRF model, which is similar to inter-subnet forwarding for host routes (detailed in the symmetric/asymmetric section), except only Type-5 routes and IP prefixes are advertised, allowing announcement of IP prefixes into a tenant’s EVI domain for external connectivity outside the domain.
In interface-less mode, the IP prefixes within the type-5 route, whether they are local or learned from a connected router are advertised to remote peers via the shared IP-VRF, as illustrated in the figure below.The IP-VRF to IP-VRF model, is further divided in the draft into three distinct use cases.
As illustrated above, the IP prefix (subnet-A) residing behind the router (Rtr-1) is learned via an IGP in EVI-1 on VTEP-1. The prefix is announced and learned by the remote VTEPs residing in the same EVI, via the type-5 route announcement. The type-5 route, is advertised along with the prefix, with a route-target (2000:2000) and a VNI label (2000) equal to the IP-VRF which interconnects the VTEPs in the EVI, the router-mac extended community of the route is used to define the inner DMAC (equal to system MAC of VTEP-1) for any VXLAN frame destined to advertised IP prefix.
From a forwarding perspective, host residing on subnet-B communicating with a host on subnet-A, will send traffic to their default gateway which is the IRB interface on VTEP-2 in VLAN 11/VNI 1011. VTEP-2 performs a route lookup for the destination subnet-A), which has been learned in the IP-VRF with a next-hop of VTEP-1 and VNI label of 2000. The packet is thus VXLAN encapsulated with VNI label of 2000 an inner DMAC of A (VTEP-1 system/router MAC), and routed to VTEP-1, which is the next-hop for the prefix. Receiving the frame, VTEP-1 de-encapsulates the packet, with an inner DMAC of the VTEPs router MAC, it performs a local route lookup for the destination subnet-A), which has been learned with a next-hop of rtr-1. The frame is forwarded directly to rtr-1, which subsequently routes the packet to the local host on subnet-A. The format of the type-5 route in interface-less mode is illustrated in figure below.
In this model, the VTEPs forming the EVI are interconnected via an IP-VRF, meaning there is no IRB interface (MAC and IP) created for the interconnection on each of the VTEPs, hence the term “interface-less”. With no IRB interface the gateway IP address within the type-5 route is set to 0, traffic is routed to the prefix based on the next-hop of the route (VTEP IP) as well as MAC address conveyed within the Router MAC extended community, which represents the inner destination MAC of the VXLAN encapsulated frame.