[ACP-DC Training #15] EVPN (Ethernet VPN)

Layer 3 fabric has become a standard topology commonly used in large-scale data centers because it provides low-latency communication within three hops between any hosts.

Ethernet VPN (EVPN) enables both L2 and L3 communication by combining protocols such as VXLAN and MP-BGP to create dynamic EVPN tunnels between switches. In this process, BGP-extended communities exchange routing and control information between VTEPs, allowing switches to automatically discover remote VTEPs belonging to the same VNI and dynamically create tunnels between them without requiring administrators to manually specify tunnels one by one.

VXLAN-based Ethernet VPN Overview

EVPN is a standard-based BGP control plane that advertises MAC addresses, MAC and IP bindings (mapping information), IP prefixes (network ranges), etc., through routing protocols.

The initial EVPN standard (RFC 7432) defined the BGP EVPN control plane and specified the MPLS data plane (data transmission plane).
Subsequently, this control plane, which included the MPLS data plane, RFC 8365As described in detail, it has been extended to accommodate additional data plane encapsulation models, including VXLAN, NVGRE, and MPLS over GRE. Today, we will focus on EVPN, which works with the VXLAN data plane for building overlay networks.

Existing static VXLAN learns the MAC address of a remote host Flood and Learn (or Ingress replication) It uses a method that learns by broadcasting packets when the destination MAC address is unknown, which entails the inconvenience of having to manually configure remote VTEPs one by one in the flood list. On the other hand MP-BGP EVPNIf you use it as a control plane, switches on the VXLAN overlay can automatically discover remote VTEPs and advertise in advance via BGP that “there is a host with a certain MAC and IP under me,” thereby completely eliminating the flood-and-run method that causes unnecessary traffic.

To this end, MP-BGP supports new EVPN Network Layer Reachability Information (NLRI) transmitted within BGP through a multiprotocol BGP extension that uses the newly defined Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI).

• Route Distinguisher (RD): It is a unique number (a type of unique identification number) prepended to addresses advertised within VRF, which ensures that even if different tenants (customers or departments) use the same IP or MAC address (overlapping), they can be perfectly distinguished and supported as distinct, unique routes within the BGP table.
• Route Target (RT): It is a BGP-extended community advertised alongside EVPN routes, acting as a kind of ‘access card’ that allows for policy-based control over which routes to selectively import and export between various VLANs and VRFs.

Auto-discovery via EVPN

VTEPs use BGP EVPN routes to automatically discover neighboring VTEPs, establish VXLAN tunnels, and assign the tunnels to each VXLAN.

• IMET route: VTEPs advertise their VXLAN IDs (VNIs) to the network via the IMET path. If two VTEPs have the same VXLAN ID, the two devices recognize each other, automatically establish a VXLAN tunnel, and assign the tunnel to the corresponding VXLAN. Using this method, replication lists for forwarding broadcast, unknown unicast, and multicast (BUM) traffic can be automatically created without manual configuration.
• MAC/IP advertisement route and IP prefix advertisement route In an EVPN deployment environment, VTEPs advertise MAC/IP ad paths or IP prefix ad paths containing export targets. When a remote VTEP receives this path, it compares the export targets in the path with its local import targets to determine whether to accept it.

Layered transport network

EVPN transport networks generally use a layered structure such as a spine-leaf. In the transport network Leaf nodeIt connects to the server and performs the role of VTEP that provides VXLAN services, and, Spine nodeIt performs the role of rapidly forwarding VXLAN traffic based solely on the Outer IP header without looking inside the VXLAN.

If all VTEPs and transport network equipment in an EVPN network belong to the same Autonomous System (AS — iBGP environment), instead of establishing complex 1:1 full-mesh BGP connections between leaf switches Spine nodes are Route Reflectors (RR) It can perform the role of reflecting (relaying) only the routing paths between VTEPs.

As can be seen in the figure above, the spine node acts only as a relay in the control plane, receiving BGP EVPN routes and re-advertising them to other leaves, and does not directly perform VXLAN encapsulation and decapsulation.

MP-BGP extension for EVPN

The major EVPN route types defined by BGP to carry not only existing IP ranges but also Ethernet (L2) information are as follows:

• Ethernet auto-discovery route – Route Type 1): A single server advertises Ethernet Segment (ES) information at a multihomed site connected to two or more switches.
• MAC/IP advertisement route – Route Type 2): Advertises the MAC reachability information of a specific host and host path information (host's ARP or IPv6 ND mapping information).
• Inclusive multicast Ethernet tag (IMET) route – Route Type 3): To automate VTEP discovery, VXLAN tunnel establishment, and VXLAN tunnel assignment, it advertises mapping information on which VTEP has which VXLAN (VNI).
• Ethernet segment route – Route Type 4): Advertises mapping information between ES (Ethernet Segment) and VTEP in a multihoming environment.
• IP prefix advertisement route – Route Type 5): Advertises BGP IPv4 or IPv6 unicast routes, such as external networks or subnet ranges, in the form of IP prefixes.

As such, MP-BGP distinguishes BGP EVPN routes of different L2 domains or tenants to prevent overlap. Route Distinguisher (RD) It uses fields and supports the following two types of route targets (RTs) to control which BGP EVPN routes to advertise and accept:

• Export route target: Before advertising the BGP EVPN routes learned at the local site to remote VTEPs, the VTEP appends an Export targets value to the route indicating which group the route belongs to.
• Import route target: The VTEP checks the export targets of BGP EVPN routes received from remote VTEPs. The VTEP imports the BGP EVPN route into its routing/forwarding table only when the export targets of the received route match its local import targets.

Layer 2 forwarding

MAC learning

VTEP learns MAC addresses using the following two methods and has a hybrid structure where local addresses are learned via the data plane like a standard switch, and remote addresses are learned via the EVPN control plane:

• Local MAC learning: VTEP automatically learns the source MAC address of a frame transmitted from a local site (such as a directly connected server) using the existing switch method. The outgoing interfaces of the local MAC address entry are the site-facing interfaces, and this is the location where the MAC address is learned.
• Remote MAC learning: VTEP uses MP-BGP (EVPN Route Type 2) to advertise local MAC reachability information to remote sites and, conversely, learn MAC reachability information from remote sites. The output interface of the MAC address entry advertised and learned from the remote site is not a physical port VXLAN tunnel interfaceIt is recorded as.

Intra-site unicast (local unicast)

This topology shows a situation where Host A sends a frame to Host D.

The two hosts belong to the same VLAN and are connected under the same VTEP.
In this case, VTEP-1 immediately bridges (L2 switching) the packet to local interface 2 without passing through the VXLAN tunnel at all.
In other words, VTEP performs standard local Layer 2 forwarding for known unicast traffic occurring within the local site.

Inter-site unicast (remote destination unicast)

As shown in the figure above, this time Host C가 Host ISends a frame.

Host ISince it is connected to another remote VTEP, VTEP-1 first queries its own MAC table.
On the table Host ISince it is stated that to reach it, one must go through ‘tunnel interface 1’ (as previously learned via MP-BGP), VTEP-1 encapsulates the packet into VXLAN and sends it to VTEP-2.

VTEP-2, upon receiving the packet, deencapsulates (re-encapsulates) and queries its MAC table, Host IAfter confirming that it is connected through local interface 3, it bridges packets to interface 3.

BUM Traffic Handling (Broadcast, Unknown-unicast, and Multicast)

When VTEP receives a BUM (Broadcast, Unknown Unicast, Multicast) frame, it floods it to all local site-facing interfaces except the interface from which the packet entered. Simultaneously, the source VTEP replicates this flood frame and sends a single copy to the destination IP address of each VXLAN tunnel belonging to the corresponding VXLAN (Head-end Replication).

Each destination VTEP that receives the packet floods the deencapsulated inner Ethernet frame to all local site-direction interfaces belonging to the VXLAN.
At this time To prevent network loops, destination VTEPs never flood frames received through a tunnel back into another VXLAN tunnel (Split Horizon principle).

MAC mobility

MAC mobility refers to the movement of a virtual machine (VM) from one VTEP to another due to real-time migration of virtual machines (e.g., VMware vMotion).

The source VTEP originally connected does not immediately know of the MAC movement event indicating that the terminal has left.
Therefore, moved The destination VTEP advertises a new MAC/IP ad route (Route Type 2) for the corresponding MAC address to notify other VTEPs of this change.do.

After receiving this new route, the source VTEP withdraws the old route of the corresponding MAC address it previously had.
At this time, the MAC/IP ad path includes a sequence number that increases by 1 each time the MAC address moves.
Even if the MAC address changes multiple times in a short period, switches compare these sequence numbers to accurately identify the most recent mobile tunnel interface with the highest number.

Layer 3 forwarding

L3 routing is required for communication between different VXLANs (subnets), and depending on where the gateway is placed, it is classified into centralized and distributed types.

L3 centralized gateway

A specific VTEP unit (or pair) serves as a dedicated gateway for VXLAN internal hosts.
This central VTEP terminates VXLAN tunnels while handling all Layer 3 routing forwarding for hosts.

Networks use the following processes to forward Layer 3 traffic from a host to a destination:

• The host sends an ARP request to obtain the MAC address of the VSI (Virtual Switch Interface, SVI) acting as the gateway, and sends Layer 3 traffic to the centralized EVPN gateway with the obtained MAC address as the destination.
• The local VTEP looks up the matching MAC address table and, instead of routing directly, first forwards the traffic to the centralized EVPN gateway through the VXLAN tunnel.
• The centralized EVPN gateway removes VXLAN encapsulation and performs Layer 3 routing forwarding. If the final destination host is located behind another remote VTEP, the central gateway re-encapsulates the packet with VXLAN to the destination VNI and forwards it to the destination VTEP (this can cause hairpinning/trombinning, where traffic passes through the central gateway and returns).
• All return traffic also undergoes the same procedure described above.

L3 distributed Anycast gateway

This method was introduced to solve the inefficient bypass paths (hairpinning) of a centralized system.

As the name suggests, connected to hosts or servers belonging to the same subnet Set the exact same gateway IP and MAC address for all leaf VTEPs (for the corresponding subnet).As a result, it essentially operates in an Anycast manner. This (Anycast) gateway IP and MAC address are configured on the SVI interface (Interface VLAN) facing the server and tenant.

Thanks to this, any server can immediately handle L3 routing on the local leaf switch directly above it, and uninterrupted communication is possible without the need to refresh the ARP cache because the IP and MAC of the default gateway are the same even when a VM moves to another rack (vMotion).

Under the SVI interface active-gateway You can configure the Anycast Gateway using commands as follows:

switch(config)# interface vlan 10 switch(config-if-vlan)# active-gateway ip 10.1.1.1 mac 00:00:02:02:02:02

Active Gateway Configuration Recommendations

• The Virtual IP configuration of the Active Gateway is the same as the Physical IP configuration of the interface. It must never be the same. In an EVPN environment, the Active Gateway virtual IP and physical IP cannot be set to be the same; doing so may lead to a failure where data traffic floods infinitely. Additionally, the physical IP addresses configured on the SVI interfaces of the VSX-Primary and VSX-Secondary devices must be different from each other (however, active-gatewayThe virtual IP and virtual MAC for grouping are set identically across all VTEPs).
• The same rule applies even when configuring an active gateway for each VTEP to implement an asymmetric IRB through a distributed gateway.
• For anycast gateway configuration, the active gateway MAC address set in the tenant SVI must be the same for both IPv6 and IPv4. The active gateway IPv6 address is a link-local address., fe80::It must be an address starting with ) and must be configured identically on both VSX peer devices.

Distributed routing – Asymmetric and Symmetric IRB integration and bridging

When using EVPN with distributed routing, there are two approaches to how each leaf switch (VTEP) routes and forwards server packets from different subnets:

• Asymmetric IRB: A method where the processing of the outbound and inbound journeys is asymmetrical (Bridge → Route → Bridge)
• Symmetric IRB: A method in which routing is performed symmetrically on both the entrance and exit switches (Bridge → Route → Route → Bridge)

1. Asymmetric IRB

First, let's look at the asymmetric IRB.

In a distributed routing and asymmetric IRB environment, packets Immediate routing at the Ingress VTEPBecome, and finally Encapsulate with destination VNIIt is then transmitted to the exit VTEP (Egress VTEP).
Then, the exit VTEP simply performs bridging (L2 switching) to the destination port without routing.

In the topology of the figure above, the processing example of a packet leaving Host-1 in VNI A (10) and destined for Host-2 in VNI B (20) is as follows:

1. Host-1This switch is the entry VTEP. SW1Sends a packet to.
2. switch SW1The packet Immediate routing from VNI 10 to VNI 20do.
3. switch SW1The packet is the destination Encapsulated with VNI 20So, the switch SW2Delivered as.
4. Switch with exit VTEP SW2It de-encapsulates (de-encapsulates) the packet.
5. switch SW2Since the packet has already been passed to VNI 20, it bridges (L2 forwards) the packet to the destination interface connected to Host-2 without routing.

Features and Constraints:

For an asymmetric IRB to operate, the entry VTEP must know not only the source VNI but also the destination VNI information, so, Configure both source and destination VNIs (and their corresponding VLANs/SVIs) for Layer 2 and Layer 3 forwarding on the incoming VTEP.It must be done. In other words, both routing and bridging are used at the entry VTEP, while only bridging is used at the exit VTEP.

As a result, since all identical VLANs and VNIs within the data center must be configured individually on every VTEP, asymmetric IRBs require more ARP and MAC table entry space (memory resources) on VTEP equipment, leading to poor scalability in large-scale environments.

2. Symmetric IRB

The most critical difference between asymmetric and symmetric IRBs is that in a symmetric IRB, Both switches (entry VTEP and exit VTEP) route every packetFurthermore, to achieve this, a separate dedicated transport VNI (Transport VNI, or L3 VNI) is used to connect the VTEPs (thanks to this, each switch only needs to have the VLAN/VNI of the server actually connected to it, making it highly scalable).

In the same topology as above, the symmetric IRB processing for a packet departing from Host-1 in VNI 10 and destined for Host-2 in VNI 20 is as follows:

1. Host-1This switch is the entry VTEP. SW1Sends a packet to.
2. switch SW1It routes packets from VNI 10 to the tenant public routing path, Transport L3 VNI 1020.
3. switch SW1The packet Encapsulated with L3 VNI 1020So, the switch SW2Delivered as.
4. Switch with exit VTEP SW2It receives the packet, deencapsulates it, and at L3 VNI 1020, the final destination VNI is Routing one more time to VNI 20do.
5. switch SW2It forwards (bridges) packets to the destination interface connected to Host-2.

eBGP EVPN supported topologies

When deploying EVPN, both iBGP and eBGP are valid options. When using eBGP, the following two topologies are supported:

• Dual AS (Dual-AS): It is a structure where all spine switches share one common AS number (e.g., AS 65000) and all leaf switches share another common AS number (e.g., AS 65001).
• Multi-AS: All spine switches share a single common AS number, and all leaf switches each have a different unique AS number (e.g., AS 65001, 65002, 65003…).

EVPN Tunnel Endpoints (VTEPs) communicate with each other via next-hop addresses within advertised routing routes. However, Due to the fundamental operating principle of eBGP, whenever a routing path crosses a router (spine), the next-hop IP address changes to the IP of that router (spine).It works. However, if the spine changes the next hop to its own IP, the remote leaf switch will not be able to know the tunnel IP of the source VTEP that originally sent the route, and thus will not be able to establish a VXLAN tunnel.

Therefore, in order to maintain the next hop (i.e., the initial tunnel endpoint information) as is, Additional settings to prevent changing the next hop associated with the EVPN path on the spine switch (next-hop-unchanged) is absolutely necessarydo.

switch(config-bgp-l2vpn-evpn)# neighbor 1.1.1.1 next-hop-unchanged

also Dual-AS topologyIn this case, since all leaf switches use the same AS number, when a peer VTEP (leaf switch) receives a route from another leaf switch through the spine, it sees that the same AS number is recorded in the route record (AS-Path) and rejects (drops) that route due to the BGP loop prevention mechanism.

To prevent this and ensure that the route with my AS number is also accepted normally, at the leaf switch allowas-in You must use the command.

switch(config-bgp-l2vpn-evpn)# neighbor 1.1.1.1 allowas-in 65001

Since two switches bundled as a VSX pair must logically operate as a single VTEP, regardless of whether it is a dual AS deployment or a multi-AS deployment Must always belong to the same ASPlease keep this in mind.

EVPN configuration

MP-BGP configuration

Enabling extended BGP community EVPN sends additional control information, such as Route Targets (RTs) or MAC movement sequence numbers, to the BGP extension community, so it must be enabled.

neighbor { | } send-community [standard | extended]

Spine MP-BGP Sample Configuration (Based on iBGP Route Reflector)

switch(config)# router bgp 100 switch(config-bgp)# neighbor 20.0.0.1 remote-as 100 switch(config-bgp)# neighbor 30.0.0.1 remote-as 100 switch(config-bgp)# address-family l2vpn evpn switch(config-bgp-l2vpn-evpn)# neighbor 20.0.0.1 activate switch(config-bgp-l2vpn-evpn)# neighbor 20.0.0.1 route-reflector-client switch(config-bgp-l2vpn-evpn)# neighbor 20.0.0.1 send-community extended switch(config-bgp-l2vpn-evpn)# neighbor 30.0.0.1 activate switch(config-bgp-l2vpn-evpn)# neighbor 30.0.0.1 route-reflector-client switch(config-bgp-l2vpn-evpn)# neighbor 30.0.0.1 send-community extended

In the original text route-reflector-ServerAlthough it is indicated as such, in the actual AOS-CX CLI, Spine designates leaf neighbors as clients to become an RR server. route-reflector-client Use the command.

The network uses MP-BGP EVPN to automatically discover remote VTEPs and advertise MAC addresses and MAC/IP bindings on VXLAN overlays, thereby eliminating manual flood and learn.

MP-BGP is a multiprotocol BGP extension that uses the newly defined Address Family Identifier (AFI) and subsequent Address Family Identifier (SAFI) (of the above configuration address-family l2vpn evpn), supports the new EVPN Network Layer Reachability Information (NLRI) transmitted within BGP. The Route Distinguisher (RD) is a unique number added to the beginning of addresses advertised within a VRF, ensuring full support even if IP and MAC addresses are duplicated between different tenants.

Additionally, you can selectively import and export routes between multiple VRFs using BGP extension communities called Route Targets (RTs), which are advertised along with EVPN routes. To allow BGP routers to transmit these community values required by EVPN, transmit extension communities between BGP EVPN peers (send-community extendedYou must set ).

Leaf BGP Sample Configuration:

router bgp 100 neighbor 20.0.0.2 remote-as 100 address-family l2vpn evpn neighbor 20.0.0.2 activate neighbor 20.0.0.2 send-community extended exit-address-family

EVPN Enabling (Enabling EVPN)

To enable EVPN on the switch, you must perform the following three steps:

• Enter EVPN context (configuration mode).
• Define an RD (Route Distinguisher) for each VLAN.
• Set the Route Target (RT).

1. Enable EVPN

switch(config)# evpn switch(config-evpn)#

2. RD Definition

switch(config-evpn)# vlan 10 switch(config-evpn-vlan-10)# rd 6800:1

3. Set Route Target (RT)

switch(config-evpn)# vlan 10 switch(config-evpn-vlan-10)# route-target export 1:1 switch(config-evpn-vlan-10)# route-target import 1:1

AOS-CX does not support manually setting static VTEPs simultaneously when EVPN is enabled to dynamically learn VTEPs.

Route Distinguisher (RD)

The path separator (RD) specifies a unique number that precedes the address advertised within the VRF.
This allows you to support duplication even if IP addresses and MAC addresses overlap between different tenants.

The default value is empty.NULL)since, The administrator must set up RD manually.Must do.

To configure RD, use the following command: rd {auto | | }

• RD Parameters:
  • autoAutomatically generates and assigns a unique RD value by combining the switch's BGP router ID (loopback IP) and VLAN ID, etc.
  • <AS-NUMBER:ID>: Specifies an AS number (2 bytes or 4 bytes) and an arbitrary ID combination. Since the total RD size is fixed at 6 bytes, if the AS number is a 2-byte value, the subsequent administrator designated number (ID) becomes a 4-byte value, and if the AS number is a 4-byte value, the subsequent administrator designated number (ID) becomes a 2-byte value.
  • <IP-ADDRESS:ID>: Specifies a combination of IP address and ID. Since the IP address occupies 4 bytes, the ID that follows becomes 2 bytes.

Route Target (RT)

Route Targets (RTs) control the import and export of VPN routes only to systems within the network that actually need those routes.

The default value is NULLsince, Administrator manually sets up RTMust do.

To configure RT, you must use the following command: route-target {import | export | both} {auto | | }

• RT Parameters:
  • import: Sets the route target to bring the EVPN route received from the remote into my table.
  • exportSets the route target to append when exporting my local EVPN route remotely.
  • both: Sets the Import and Export path targets to the same value at once.
  • autoAutomatically calculates and assigns RT values based on the AS number and VNI (or VLAN) values.
  • <AS-NUMBER:ID>: Specifies the AS number (2 bytes or 4 bytes) and ID. If the AS number is 2 bytes, the subsequent administrator number becomes a 4-byte value, and if the AS number is 4 bytes, the subsequent administrator number becomes a 2-byte value.
  • <IP-ADDRESS:ID>: Specifies a combination of a 4-byte IP address and a 2-byte ID.

EVPN Verification and Confirmation (Verifying EVPN)

1. Checking EVPN configuration

switch# show running-config evpn evpn vlan 10 rd 2:2 route-target both auto vlan 20 rd 3:3 route-target both 3000:1

The first step to take when monitoring and troubleshooting EVPN is show running-config evpn It is to check the EVPN settings by entering a command.
The key point to focus on here is Whether the target VLANs have been included without omission, and whether the RD (Route Identifier) and RT (Route Target) are configured to match as intended between both VTEPs It is to confirm.

2. Checking EVPN instances summary

switch# show bgp l2vpn evpn summary VRF : default BGP Summary ----------- Local AS : 100 BGP Router Identifier : 10.1.17.1 Peers : 2 Log Neighbor Changes : No Cfg. Hold Time: 180 Cfg. Keep Alive : 60 Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus 10.1.7.1 100 1291 1300 18h:31m:50s Established Up 10.1.7.3 100 1294 1294 18h:31m:57s Established Up

switch# show interface vxlan1 vteps Source Destination Origin Status VNI VLAN ----------- ----------- ------ ----------- ------ ---- 10.1.17.1 10.1.17.2 evpn operational 100110 10 10.1.17.1 10.1.17.2 evpn operational 100111 11 10.1.17.1 10.1.17.3 evpn operational 100110 10 10.1.17.1 10.1.17.3 evpn operational 100111 11

Next, show bgp l2vpn evpn summary Use the command.

This command displays summary information for all BGP EVPN instances, and in particular, the status of BGP sessions with peers (State)go EstablishedYou can check if it has been properly established.

Another useful command is show interface vxlan1 vtepsno see.

This command is dynamically generated via EVPN and BGP without manual configuration (Origin: evpn) List of remote VTEP tunnels and activation status(Status: operationalShows ).

3. Checking EVPN instances detail

switch# show bgp l2vpn evpn Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, e external S Stale, R Removed, a additional-paths Origin codes: i - IGP, e - EGP, ? - incomplete EVPN Route-Type 2 prefix: [2]:[ESI]:[EthTag]:[MAC]:[OrigIP] EVPN Route-Type 3 prefix: [3]:[EthTag]:[OrigIP] EVPN Route-Type 5 prefix: [5]:[ESI]:[EthTag]:[IPAddrLen]:[IPAddr] VRF : default Local Router-ID 10.1.17.10 Network Nexthop Metric LocPrf Weight Path -------------------------------------------------------------------- Route Distinguisher: 10.1.17.10:10 (L2VNI 100010) *> [3]:[0]:[10.1.17.10] 10.1.17.10 0 100 0 ? Route Distinguisher: 10.1.17.11:10 (L2VNI 100010) *>i [3]:[0]:[10.1.17.11] 10.1.17.11 0 100 0 ? * i [3]:[0]:[10.1.17.11] 10.1.17.11 0 100 0 ?

In the output result above [3]:[0]:[10.1.17.11]As shown, the number at the beginning of the square brackets indicates the EVPN Route-Type. The major EVPN Route-Types are as follows:

• Ethernet auto-discovery route (Route 1): Multihoming sites advertise Ethernet Segment (ES) information.
• MAC/IP advertisement route (MAC/IP advertisement route – Route 2): Advertises the locally learned host MAC address and MAC/IP (v6) binding (ARP/ND neighbor entry and host path mapping information).
• Inclusive Multicast Ethernet Tag Route (IMET route – Route 3): Advertises VTEP and VXLAN mapping information to automate VTEP discovery, VXLAN tunnel establishment, and VXLAN tunnel assignment (these are the Type 3 paths shown in the output example above).
• Ethernet Segment Route (Ethernet Segment route – Route 4): Advertises the mapping between ES and VTEP.
• IP Prefix Advertisement Route (IP Prefix advertisement route – Route 5): BGP advertises IPv4 or IPv6 unicast routes in the form of IP prefixes.

Support Scope: The current AOS-CX release is Supports only MAC and MAC/IP advertising (Route Type 2), Universal Multicast Ethernet Tag (IMET) routes (Route Type 3), and IP Prefix Route Advertising (Route Type 5).do.
This is because AOS-CX uses its own technology for multihoming instead of the standard EVPN ES methods Type 1 and 4. VSX Logical VTEP This is because it is processed much more concisely in this way.

4. Checking EVPN MAC address table

switch# show mac-address-table MAC age-time : 300 seconds Number of MAC addresses : 7 MAC Address VLAN Type Port ----------------------------------- 54:80:28:fd:dc:00 10 evpn vxlan1(10.1.17.3) 00:50:56:a5:b5:42 10 evpn vxlan1(10.1.17.2) 00:24:a8:cc:a0:3d 10 evpn vxlan1(10.1.17.2) 00:24:a8:cc:a0:3f 10 dynamic 1/1/13 54:80:28:fd:dc:00 11 evpn vxlan1(10.1.17.3) 90:20:c2:ba:43:00 1101 dynamic 1/1/25 90:20:c2:ba:92:00 1102 dynamic 1/1/26

show mac-address-table Local physical port (1/1/13 Learned directly from (etc.) dynamic MAC addresses of the type, and remote VTEP through the MP-BGP EVPN control plane (vxlan1(10.1.17.3) Learned by receiving advertisements from etc. evpn MAC address of typeYou can distinguish and check them at a glance.

---

In this module, we automate tunnel and MAC/IP learning by combining a control plane called MP-BGP with static VXLAN. The core principles of EVPN와 Distributed Anycast Gateway (IRB) We have looked at the design together. Now, you can overcome the limitations of manual configuration and broadcast flooding to build your own intelligent data center fabric that flexibly accommodates virtual machine movement and communicates via optimal paths, even in large-scale multi-tenant environments.

In the next session, we will look one by one at the EVPN Additional Features that suppress unnecessary ARP/ND traffic on this EVPN fabric and implement multicast routing (IGMP snooping and PIM-SM) as well as IPv6 overlay networks based on IPv4 underlays.