ip-prefix-routes
Syntax
ip-prefix-routes {
advertise (direct-nexthop | gateway-address);
encapsulation (mpls | srv6 | vxlan);
reject-asymmetric-vni;
donot-advertise-community;
<export routing-policy-name>;
gateway-interface interface-name;
source-packet-routing {
srv6 {
locator loc-name {
(end-dt4/6/46-sid | micro-dt4/6/46-sid);
}
}
}
vni number;
}
Hierarchy Level
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols evpn], [edit routing-instances routing-instance-name protocols evpn]
Description
In an Ethernet VPN (EVPN) environment, enable the device to advertise the IP prefix associated with a specified customer domain as a Type 5 route to remote data centers. You might also enable IP prefix routes in a metro transport network. You use this feature when the Layer 2 domain does not exist at the remote data centers or metro network peering points.
We support two models for implementing Type 5 routes:
-
Pure Type 5 route without overlay next hop and Type 2 route
-
Type 5 route with gateway IRB interface as overlay next hop and Type 2 route
A pure Type 5 route advertises the summary IP prefix and includes a BGP extended community called a router MAC. The router MAC carries the MAC address of the sending switch and provides next-hop reachability information for the prefix. In contrast, a standard Type 5 route requires a gateway IP address as a next-hop overlay and a supporting Type 2 route to provide recursive route resolution.
QFX5110 and QFX10000 switches currently support only fully resolved next-hop—that is, EVPN pure Type 5—routes. QFX10000 switches support only EVPN Virtual Extensible LAN (VXLAN) with Type 5 routes (not MPLS encapsulation).
On QFX5110, QFX5120,
EX4650,
EX4400, and EX4100
switches,
when you configure pure Type 5 routing in an overlay EVPN-VXLAN network, you must
also configure the overlay-ecmp statement at the [edit forwarding-options
vxlan-routing] hierarchy level.
Configuring
the overlay-ecmp statement causes the Packet Forwarding Engine to
restart, which interrupts all forwarding operations. As a result, we strongly
recommend you put that configuration in place before the EVPN-VXLAN network becomes
operational.
EX9200 switches support both Type 5 routes but only pure Type 5 routes with MPLS encapsulation. EX9200 switches support both MPLS and VXLAN encapsulation with the standard Type 5 route that includes a gateway IP address as the next-hop overlay.
We introduced pure Type 5 routing for EVPN-VXLAN in Junos OS Release 15.1X53-D30
for QFX10002 switches only. In that release, this statement is
ip-prefix-support forwarding-mode symmetric.
Starting with Junos OS Release 15.1X53-D60, the statement is
ip-prefix-routes advertise direct-nexthop.
When you upgrade to Junos OS Release 15.1X53-D60 or later, the upgrade process
automatically updates any configuration with the original
ip-prefix-support statement to the new
ip-prefix-routes statement.
Starting in Junos OS Release 15.1X53-D60, QFX10000 switches support pure Type 5 routing.
By default, Juniper Networks devices that support pure EVPN Type 5 routes don't advertise IP prefixes with a mask length of /32 as pure Type 5 routes. To advertise /32 prefixes, you must set up a term in an export policy that explicitly accepts these prefixes into the routing table. The following are excerpts from a sample configuration:
user@qfx10002# show policy-options policy-statement slash32
term 1 {
from {
protocol bgp;
route-filter 10.44.44.44/31 orlonger;
}
then accept;
}
user@qfx10002# show routing-instances EVPN-A protocols evpn
ip-prefix-routes {
advertise direct-nexthop;
encapsulation vxlan;
vni 5000;
export slash32;
...
Options
The advertise, encapsulation and vni number options are required. The export routing–policy-name option
is optional.
| advertise direct-nexthop |
Enable the switch to send IP prefix information using an EVPN pure Type 5 route, which includes a router MAC extended community used to send the MAC address of the switch. This router MAC extended community provides next-hop reachability without requiring an overlay next-hop or supporting Type 2 route. Note:
For pure route Type 5, QFX5110 and QFX10000 switches support only VXLAN encapsulation, and EX9200 switches support only MPLS encapsulation. |
| advertise gateway-address (EX9200 switches only) |
Enable the switch to advertise a gateway address in exported IP prefix routes. This gateway address provides overlay next-hop reachability. Note:
You must also specify a gateway address by including the
|
| encapsulation (mpls | srv6 | vxlan) |
Specify the encapsulation for IP prefixes: MPLS, SRv6, or VXLAN. Note:
The same type of encapsulation must be used end to end. Only VXLAN encapsulation is supported on the QFX10000 line of switches and QFX5110 switches. |
| reject-asymmetric-vni | Enables the local Junos device to block asymmetric EVPN type 5 traffic. The
device examines the incoming EVPN Type 5 route packets and rejects the route
when the VNI in the ingress route is different from the locally configured
VNI. Note:
This option is required when you configure EVPN Type 5 routing on ACX7100 routers, which don't support Type 5 route advertisement with asymmetric VNIs. |
| donot-advertise-community |
Starting with Junos release 19.4R1, for when a Type 5 routes is created
from the Type 2 MAC and IP advertisement that was learned from a remote
PE device, the default behavior is to include the community information
from the Type 2 route (if any) in the Type 5 route. You can prevent
behavior this by enabling the |
| export routing-policy-name |
(Optional) Specify the name of the routing policy configured at the
|
| gateway-interface interface-name |
Specify the gateway interface to use as a next-hop overlay for a standard
Type 5 route. You must use this option in conjunction with the
|
| source-packet-routing |
Enable SRv6 source packet routing, identify the SRv6 locator defined at
Possible SRv6 SIDs:
|
| vni number |
Specify the identifier associated with a customer domain. Each customer domain must have a unique identifier. |
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 15.1X53-D60 and Junos OS Release 17.2R1.
Support for logical systems on MX Series routers added in Junos OS Release 17.4R1.
reject-asymmetric-vni option introduced in Junos OS Release 22.2R1
and Junos OS Evolved Release 22.1R1
Support for SRX and vSRX Virtual Firewall Series firewalls added in Junos OS Release 22.4R1.
source-packet-routing option introduced in Junos OS Release 23.4R1 and Junos OS Evolved Release 23.4R1.