ip-prefix-routes
Syntax
ip-prefix-routes {
advertise (direct-nexthop | gateway-address);
donot-advertise-community;
encapsulation (mpls | srv6 | vxlan);
export routing-policy-name;
gateway-interface interface-name;
import routing-policy-name;
reject-asymmetric-vni;
route-attributes {
as-path {
export-action (allow | skip);
import-action (allow | skip);
}
community {
export-action (allow | skip);
import-action (allow | skip);
}
preference {
export-action (allow | skip);
import-action (allow | skip);
}
}
source-packet-routing {
srv6 {
locator loc-name {
(end-dt4-sid | end-dt46-sid | end-dt6-sid | micro-dt4-sid | micro-dt46-sid | micro-dt6-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 |
| donot-advertise-community | Starting with Junos release 19.4R1, for when a Type 5 route 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 |
| 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. |
| 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 |
| import routing-policy-name | (Optional) Specify the name of the routing policy configured at the |
| 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. See Blocking Asymmetric EVPN Type 5 Routes for more
information. Note: ACX7100
routers running Junos OS Evolved Release 24.4R1 and earlier do not
support asymmetric EVPN Type 5 routes. When you configure EVPN Type 5
routes on an ACX7100 router running Junos OS Evolved Release 24.4R1 and
earlier, you must also configure the
reject-asymmetric-vni option at the [edit
routing-instances routing-instance-name protocols
evpn ip-prefix-routes] hierarchy level in the same routing
instance. |
| 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. |
The remaining statements are explained separately. See CLI Explorer.
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.