- play_arrow EVPN-VXLAN
- play_arrow Overview
- Understanding EVPN with VXLAN Data Plane Encapsulation
- EVPN-over-VXLAN Supported Functionality
- Understanding VXLANs
- VXLAN Constraints on EX Series, QFX Series, PTX Series, and ACX Series Devices
- EVPN Over VXLAN Encapsulation Configuration Overview for QFX Series and EX4600 Switches
- Implementing EVPN-VXLAN for Data Centers
- PIM NSR and Unified ISSU Support for VXLAN Overview
- Routing IPv6 Data Traffic through an EVPN-VXLAN Network with an IPv4 Underlay
- Understanding How to Configure VXLANs and Layer 3 Logical Interfaces to Interoperate
- Understanding GBP Profiles
- play_arrow Configuring EVPN-VXLAN Interfaces
- Understanding Flexible Ethernet Services Support With EVPN-VXLAN
- EVPN-VXLAN Lightweight Leaf to Server Loop Detection
- Overlapping VLAN Support Using VLAN Translation in EVPN-VXLAN Networks
- Overlapping VLAN Support Using Multiple Forwarding Instances or VLAN Normalization
- Layer 2 Protocol Tunneling over VXLAN Tunnels in EVPN-VXLAN Bridged Overlay Networks
- MAC Filtering, Storm Control, and Port Mirroring Support in an EVPN-VXLAN Environment
- Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN
- DHCP Smart Relay in EVPN-VXLAN
- play_arrow Configuring VLAN-Aware Bundle Services, VLAN-Based Services, and Virtual Switch Support
- play_arrow Load Balancing with EVPN-VXLAN Multihoming
- play_arrow Setting Up a Layer 3 VXLAN Gateway
- play_arrow Configuring an EVPN-VXLAN Centrally-Routed Bridged Overlay
- play_arrow Configuring an EVPN-VXLAN Edge-Routed Bridging Overlay
- play_arrow IPv6 Underlay for VXLAN Overlays
- play_arrow Multicast Features with EVPN-VXLAN
- Multicast Support in EVPN-VXLAN Overlay Networks
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Example: Preserving Bandwidth with IGMP Snooping in an EVPN-VXLAN Environment
- Overview of Selective Multicast Forwarding
- Configuring the number of SMET Nexthops
- Assisted Replication Multicast Optimization in EVPN Networks
- Optimized Intersubnet Multicast in EVPN Networks
- play_arrow Configuring the Tunneling of Q-in-Q Traffic
- play_arrow Tunnel Traffic Inspection on SRX Series Devices
- play_arrow Fault Detection and Isolation in EVPN-VXLAN Fabrics
-
- play_arrow EVPN-MPLS
- play_arrow Overview
- play_arrow Convergence in an EVPN MPLS Network
- play_arrow Pseudowire Termination at an EVPN
- play_arrow Configuring the Distribution of Routes
- Configuring an IGP on the PE and P Routers on EX9200 Switches
- Configuring IBGP Sessions Between PE Routers in VPNs on EX9200 Switches
- Configuring a Signaling Protocol and LSPs for VPNs on EX9200 Switches
- Configuring Entropy Labels
- Configuring Control Word for EVPN-MPLS
- Understanding P2MPs LSP for the EVPN Inclusive Provider Tunnel
- Configuring Bud Node Support
- play_arrow Configuring VLAN Services and Virtual Switch Support
- play_arrow Configuring Integrated Bridging and Routing
- EVPN with IRB Solution Overview
- An EVPN with IRB Solution on EX9200 Switches Overview
- Anycast Gateways
- Configuring EVPN with IRB Solution
- Configuring an EVPN with IRB Solution on EX9200 Switches
- Example: Configuring EVPN with IRB Solution
- Example: Configuring an EVPN with IRB Solution on EX9200 Switches
- play_arrow Configuring IGMP or MLD Snooping with EVPN-MPLS
-
- play_arrow EVPN E-LAN Services
- play_arrow EVPN-VPWS
- play_arrow Configuring VPWS Service with EVPN Mechanisms
- Overview of VPWS with EVPN Signaling Mechanisms
- Control word for EVPN-VPWS
- Overview of Flexible Cross-Connect Support on VPWS with EVPN
- Overview of Headend Termination for EVPN VPWS for Business Services
- Configuring VPWS with EVPN Signaling Mechanisms
- Example: Configuring VPWS with EVPN Signaling Mechanisms
- FAT Flow Labels in EVPN-VPWS Routing Instances
- Configuring EVPN-VPWS over SRv6
- Configuring Micro-SIDs in EVPN-VPWS
-
- play_arrow EVPN-ETREE
- play_arrow Overview
- play_arrow Configuring EVPN-ETREE
-
- play_arrow Using EVPN for Interconnection
- play_arrow Interconnecting VXLAN Data Centers With EVPN
- play_arrow Interconnecting EVPN-VXLAN Data Centers Through an EVPN-MPLS WAN
- play_arrow Extending a Junos Fusion Enterprise Using EVPN-MPLS
-
- play_arrow PBB-EVPN
- play_arrow Configuring PBB-EVPN Integration
- play_arrow Configuring MAC Pinning for PBB-EVPNs
-
- play_arrow EVPN Standards
- play_arrow Supported EVPN Standards
-
- play_arrow VXLAN-Only Features
- play_arrow Flexible VXLAN Tunnels
- play_arrow Static VXLAN
-
- play_arrow Configuration Statements and Operational Commands
EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN
Learn how a device in an EVPN-VXLAN fabric gives preference to either an EVPN Type 2 route or an EVPN Type 5 route when the device learns and advertises both types of routes.
A device in an EVPN-VXLAN edge-routed bridging fabric imports and advertises EVPN Type 2 MAC+IP routes by default. You can also configure the device to import and to advertise EVPN Type 5 IP prefix routes. The device treats either type of route as a unique route, even when it corresponds to the same destination host. Each unique IP host route uses a dedicated next hop in the Packet Forwarding Engine (PFE). As a result, having both types of routes enabled together puts a strain on the PFE's next-hop resources. Also, traffic generally flows more efficiently if the device uses one type of route over the other in certain cases.
Starting in Junos OS Release 21.2R1, when the device has both types of routes together in a routing instance for the same destination, it uses a preference algorithm to choose the preferred route to store.
Benefits
Supports higher scaling in edge-routed bridging fabrics because the preference algorithm reduces next-hop resource requirements in the PFE.
Improves bridging performance by choosing the more efficient path for locally learned (Type 2) host IP routes in an Ethernet segment.
Supports higher scaling with EVPN Type 5 routes while enabling ARP suppression and proxy ARP in the fabric using Type 2 routes. The Type 2 routes carry the customer edge (CE) device MAC address information required for proxy ARP to work.
EVPN Type 2 and Type 5 Coexistence Preference Algorithm
In an EVPN-VXLAN fabric, devices use Type 2 routes by default. You must explicitly enable
the device to also import and advertise EVPN Type 5 routes in a virtual routing and
forwarding (VRF) instance. To enable Type 5 routes and the coexistence preference algorithm,
configure the ip-prefix-routes statement at the [edit
routing-instances name protocols evpn] hierarchy level.
With Type 5 routes enabled, the device might learn an IP host address from a Type 2 MAC + IP route for which it also has a Type 5 route for the same prefix. In that case, the device uses the coexistence preference algorithm to choose only one of the two routes to store as the preferred route.
The preference algorithm works as follows:
For any destinations for which the device has no Type 5 route, the device uses Type 2 routes.
If the device has a Type 5 route with a matching prefix for a local ESI Type 2 route, it installs the Type 2 route.
Otherwise the device prefers the Type 5 route for all other destinations.
With this algorithm, EVPN-VXLAN devices generally prefer Type 5 routes for traffic in or between data centers and in or between VLANs (bridge domains). Type 5 routes are ideal for the purpose of VXLAN overlay routing. However, a device can forward packets more efficiently using Type 2 routes in some cases. One example is when the device learns Type 2 MAC+IP routes for destinations that it only needs to bridge locally. The preference algorithm accounts for that case.
The device does not use make before break (MBB) actions to adjust preferred routes due to configuration updates. When making a route preference change in this case, the device first deletes the non-preferred route, then adds the new preferred route. Examples of configuration changes that can cause preference changes include:
- If you didn't enable Type 5 routes, and then you enable Type 5 routes.
- When you configure an ESI locally, in which case the device prefers the MAC+IP Type 2 route.
Type 5 Route Options and Policy Options
In your EVPN-VXLAN configuration, use one of these advertising mode options with the
ip-prefix-routes statement when you enable Type 5 routes:
advertise direct-nexthop—With this option, the device advertises all non-host routes for a VRF as Type 5 advertisements.advertise gateway-address—With this option, the device only advertises prefixes for the IRB interfaces for the extended EVPN instances and bridge domains.
You can also include policy options in your EVPN-VXLAN Type 5 route configuration to refine the routes the device actually imports or advertises.
For example, you can define:
A policy to export all local routes and EVPN routes, such as the following:
content_copy zoom_out_mapset policy-options policy-statement type5_export_policy term 1 from protocol local set policy-options policy-statement type5_export_policy term 1 then accept set policy-options policy-statement type5_export_policy term 2 from protocol evpn set policy-options policy-statement type5_export_policy term 2 from route-filter 0.0.0.0/0 prefix-length-range /32-/32 set policy-options policy-statement type5_export_policy term 2 then accept set policy-options policy-statement type5_export_policy term 3 from protocol evpn set policy-options policy-statement type5_export_policy term 3 from route-filter 00:00:00:00:00:00:00:00/0 prefix-length-range /128-/128 set policy-options policy-statement type5_export_policy term 3 then accept
A policy that only advertises routes for specific host addresses or prefixes, such as the following:
content_copy zoom_out_mapset policy-options policy-statement type5_policy term 1 from protocol local set policy-options policy-statement type5_policy term 1 from route-filter 10.0.2.0/24 orlonger set policy-options policy-statement type5_policy term 1 then accept set policy-options policy-statement type5_policy term 2 from protocol local set policy-options policy-statement type5_policy term 2 from route-filter 2001::192:101:1:100/48 orlonger set policy-options policy-statement type5_policy term 2 then accept
A policy that filters and doesn't import routes for specific host addresses or prefixes, such as the following:
content_copy zoom_out_mapset policy-options policy-statement type5_import_policy term 1 from protocol bgp set policy-options policy-statement type5_import_policy term 1 from route-filter 10.0.2.0/24 orlonger set policy-options policy-statement type5_import_policy term 1 then reject set policy-options policy-statement type5_import_policy term 2 from protocol bgp set policy-options policy-statement type5_import_policy term 2 from route-filter 2001::192:101:1:100/48 orlonger set policy-options policy-statement type5_import_policy term 2 then reject
Include the desired policy options in your ip-prefix-routes configuration.
For example:
set routing-instances vrf1 protocols evpn ip-prefix-routes advertise direct-nexthop set routing-instances vrf1 protocols evpn ip-prefix-routes encapsulation vxlan set routing-instances vrf1 protocols evpn ip-prefix-routes vni 100 set routing-instances vrf1 protocols evpn ip-prefix-routes import type5_import_policy set routing-instances vrf1 protocols evpn ip-prefix-routes export type5_export_policy set routing-instances vrf1 instance-type vrf set routing-instances vrf1 interface irb.1 set routing-instances vrf1 interface irb.2 set routing-instances vrf1 route-distinguisher 192.168.0.1:100 set routing-instances vrf1 vrf-target target:100:200
CLI Commands to Verify Preferred Route Type
You can use the CLI commands in this section to see the preferred route type.
show ethernet-switching mac-ip-table
The show ethernet-switching mac-ip-table CLI
command displays the value RTS in the MAC IP flags column when the
switch "skips" adding a learned Type 2 route. This value means the device prefers a Type 5
route with a matching prefix. The command displays the definition Dest Route
Skipped for the value RTS at the top of the output.
The command displays results for all VLANs (bridge domains) by default. You can also specify a particular VLAN (bridge domain). By default, the command displays information for the default-switch instance. You can also use other command line options to display results for a specific routing instance if the device has multiple routing instances.
The following sample output shows MAC+IP table information for the default-switch instance where the device preferred Type 5 routes for some destinations:
user@device> show ethernet-switching mac-ip-table
MAC IP flags (S - Static, D - Dynamic, L - Local , R - Remote, Lp - Local Proxy,
Rp - Remote Proxy, K - Kernel, RT - Dest Route, (N)AD - (Not) Advt to remote,
RE - Re-ARP/ND, RO - Router, OV - Override, Ur - Unresolved,
RTS - Dest Route Skipped, RGw - Remote Gateway)
Routing instance : default-switch
Bridging domain : v1
IP MAC Flags Logical Active
address address Interface source
10.1.1.254 10:10:10:00:00:01 S,K irb.1
2001:db8::a:1:1:fffe 20:20:20:00:00:01 S,K,RTS irb.1
10.1.1.2 c8:e7:f0:4b:d1:00 DR,K,RTS vtep.32769 192.168.22.22
2001:db8::a:1:1:2 c8:e7:f0:4b:d1:00 DR,K,RTS vtep.32769 192.168.22.22
fe80::cae7:f000:14b:d100 c8:e7:f0:4b:d1:00 DR,K,RT vtep.32769 192.168.22.22
10.1.1.1 dc:38:e1:e0:30:c0 S,K irb.1
2001:db8::a:1:1:1 dc:38:e1:e0:30:c0 S,K irb.1
fe80::de38:e100:1e0:30c0 dc:38:e1:e0:30:c0 S,K irb.1
MAC IP flags (S - Static, D - Dynamic, L - Local , R - Remote, Lp - Local Proxy,
Rp - Remote Proxy, K - Kernel, RT - Dest Route, (N)AD - (Not) Advt to remote,
RE - Re-ARP/ND, RO - Router, OV - Override, Ur - Unresolved,
RTS - Dest Route Skipped, RGw - Remote Gateway)
Routing instance : default-switch
Bridging domain : v2
IP MAC Flags Logical Active
address address Interface source
10.1.2.254 10:10:10:00:00:02 S,K,RTS irb.2
2001:db8::a:1:2:fffe 20:20:20:00:00:02 S,K,RTS irb.2
10.1.2.2 c8:e7:f0:4b:d1:00 DR,K,RTS vtep.32769 192.168.22.22
2001:db8::a:1:2:2 c8:e7:f0:4b:d1:00 DR,K,RTS vtep.32769 192.168.22.22
fe80::cae7:f000:24b:d100 c8:e7:f0:4b:d1:00 DR,K,RT vtep.32769 192.168.22.22
10.1.2.1 dc:38:e1:e0:30:c0 S,K irb.2
2001:db8::a:1:2:1 dc:38:e1:e0:30:c0 S,K irb.2
fe80::de38:e100:2e0:30c0 dc:38:e1:e0:30:c0 S,K irb.2
With the extensive option, the show ethernet-switching
mac-ip-table command includes the value dest_route_skipped in
the MAC IP flags row. The following command shows the MAC+IP table
information for MAC address c8:e7:f0:4b:d1:00:
user@device> show ethernet-switching mac-ip-table extensive c8:e7:f0:4b:d1:00
IP address: 10.1.1.2
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v1
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000081
MAC-IP flags: remote,kernel,dest_route_skipped
IP address: 2001:db8::a:1:1:2
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v1
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000101
MAC-IP flags: remote,kernel,dest_route_skipped
IP address: fe80::cae7:f000:14b:d100
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v1
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000101
MAC-IP flags: remote,kernel,dest_route
IP address: 10.1.2.2
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v2
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000081
MAC-IP flags: remote,kernel,dest_route_skipped
IP address: 2001:db8::a:1:2:2
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v2
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000101
MAC-IP flags: remote,kernel,dest_route_skipped
IP address: fe80::cae7:f000:24b:d100
MAC address: c8:e7:f0:4b:d1:00
Routing instance: default-switch
Bridging domain: v2
Logical interface: vtep.32769
IP MAC Flags Logical Active
address address Interface source
192.168.22.22
MAC-IP local mask: 0x0000000000000000
MAC-IP remote mask: 0x0000000000000000
MAC-IP remote-proxy mask: 0x0000000000000000
MAC-IP RPD flags: 0x08000101
MAC-IP flags: remote,kernel,dest_route
show route forwarding-table
The show route forwarding-table CLI command shows
when the device uses a local Type 5 route over a learned Type 2 route for a destination. In
this case, when you include the extensive option, the output includes the
keywords VxLAN Local in the Flags field. This flag means
the route is a Type 5 route.
For example:
user@device> show route forwarding-table destination 10.1.1.2 table vrf1 extensive
Routing table: vrf1.inet [Index 8]
Internet:
Destination: 10.1.1.2/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, prefix load balance , VxLAN Local
Nexthop:
Next-hop type: composite Index: 1799 Reference: 3
Next-hop type: indirect Index: 524291 Reference: 2
Nexthop: 10.0.0.2
Next-hop type: unicast Index: 1796 Reference: 3
Next-hop interface: xe-0/0/11.0
show route table
The show route table CLI command with the
extensive option includes the keyword VxlanLocalRT in the
State output field for a Type 5 route.
Here's an example using the syntax show route
destination-prefix table table-name
extensive. This command shows that the device installed a Type 5 route for the
destination IP prefix 10.1.1.2 in the routing table for routing instance vrf1:
user@device> show route 10.1.1.2 table vrf1.inet.0 extensive
vrf1.inet.0: 14 destinations, 18 routes (14 active, 0 holddown, 0 hidden)
10.1.1.2/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.1.1.2/32 -> {composite(1799)}
*EVPN Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x6d06abc
Next-hop reference count: 6
Next hop type: Router, Next hop index: 1796
Next hop: 10.0.0.2 via xe-0/0/11.0, selected
Label element ptr: 0x83f82d8
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
Protocol next hop: 192.168.22.22
Composite next hop: 0x66fc1b0 1799 INH Session ID: 0x0
VXLAN tunnel rewrite:
MTU: 0, Flags: 0x0
Encap table ID: 0, Decap table ID: 8
Encap VNI: 100, Decap VNI: 100
Source VTEP: 192.168.11.11, Destination VTEP: 192.168.22.22
SMAC: dc:38:e1:e0:30:c0, DMAC: c8:e7:f0:4b:d1:00
Indirect next hop: 0x6df0e84 524291 INH Session ID: 0x0
State: <Active Int Ext VxlanLocalRT>
Age: 5:10:00 Metric2: 1
Validation State: unverified
Task: vrf1-EVPN-L3-context
Announcement bits (1): 2-KRT
AS path: I
Communities: target:100:200 encapsulation:vxlan(0x8) router-mac:c8:e7:f0:4b:d1:00
Thread: junos-main
Composite next hops: 1
Protocol next hop: 192.168.22.22 Metric: 1
Composite next hop: 0x66fc1b0 1799 INH Session ID: 0x0
VXLAN tunnel rewrite:
MTU: 0, Flags: 0x0
Encap table ID: 0, Decap table ID: 8
Encap VNI: 100, Decap VNI: 100
Source VTEP: 192.168.11.11, Destination VTEP: 192.168.22.22
SMAC: dc:38:e1:e0:30:c0, DMAC: c8:e7:f0:4b:d1:00
Indirect next hop: 0x6df0e84 524291 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.0.0.2 via xe-0/0/11.0
Session Id: 0x0
192.168.22.22/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Next hop type: Router
Next hop: 10.0.0.2 via xe-0/0/11.0
Session Id: 0x0
