Color-Based Mapping of VPN Services for SR-MPLS Segment Routing LSPs
Color-Based Mapping of VPN Services
You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) LSPs. This is called the color-IP protocol next hop resolution, where you are required to configure a resolution-map and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 and Layer 3 VPN services.
Junos OS supports colored SR-TE LSPs associated with a single color. The color-based mapping of VPN services feature is supported on static colored LSPs and BGP SR-TE LSPs.
- VPN Service Coloring
- Specifying VPN Service Mapping Mode
- Color-IP Protocol Next Hop Resolution
- Fallback to IP Protocol Next Hop Resolution
- BGP Labeled Unicast Color-based Mapping over SR-TE
- Supported and Unsupported Features for Color-Based Mapping of VPN Services
VPN Service Coloring
In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, or on an ingress router where the VPN NLRI is received and processed.
You can assign a color to the VPN services at different levels:
-
Per routing instance.
-
Per BGP group.
-
Per BGP neighbor.
-
Per prefix.
Once you assign a color, the color is attached to a VPN service in the form of BGP color extended community.
You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, the last color attached is considered as the color of the VPN service, and all other colors are ignored.
Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following order:
-
BGP export policy on the egress device.
-
BGP import policy on the ingress device.
-
VRF import policy on the ingress device.
The two modes of VPN service coloring are:
Egress Color Assignment
In this mode, the egress device (that is, the advertiser of the VPN NLRI) is
responsible for coloring the VPN service. To enable this mode, you can define a
routing policy, and apply it in the VPN service’s routing-instance
vrf-export, group export, or group neighbor export at the
[edit protocols bgp] hierarchy level. The VPN NLRI is advertised by
BGP with the specified color extended community.
For example:
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
Or
When you apply the routing policy as an export policy of a BGP group or BGP
neighbor, you must include the vpn-apply-export statement at the
BGP, BGP group, or BGP neighbor level in order for the policy to take an effect on
the VPN NLRI.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs on one or multiple ingress devices.
Ingress Color Assignment
In this mode, the ingress device (that is, the receiver of the VPN NLRI) is
responsible for coloring the VPN service. To enable this mode, you can define a
routing policy, and apply it to the VPN service’s routing-instance
vrf-import, group import, or group neighbor import at the
[edit protocols bgp] hierarchy level. All the VPN routes matching
the routing policy is attached with the specified color extended community.
For example:
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
Or
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
Specifying VPN Service Mapping Mode
To specify flexible VPN service mapping modes, you must define a policy using the
resolution-map statement, and refer the policy in a VPN service’s
routing-instance vrf-import, group import, or group neighbor import at
the [edit protocols bgp] hierarchy level. All the VPN routes matching the
routing policy are attached with the specified resolution-map.
For example:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
You can apply import policy to the VPN service’s routing-instance.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
You can also apply the import policy to a BGP group or BGP neighbor.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
Each VPN service mapping mode should have a unique name defined in the resolution-map.
Only a single entry of IP-color is supported in the resolution-map, where the VPN
route(s) are resolved using a colored-IP protocol next hop in the form of
ip-address:color.
Color-IP Protocol Next Hop Resolution
The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, builds a colored-IP protocol next hop in the form of IP-address:color, and resolves the protocol next hop in the inet6color.0 routing table.
You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver import policy.
For example:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
Fallback to IP Protocol Next Hop Resolution
If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next hop resolution.
The fallback is a simple process from colored SR-TE LSPs to LDP LSPs, by using a RIB group for LDP to install routes in inet{6}color.0 routing tables. A longest prefix match for a colored-IP protocol next hop ensures that if a colored SR-TE LSP route does not exist, an LDP route with a matching IP address should be returned.
BGP Labeled Unicast Color-based Mapping over SR-TE
BGP Labeled Unicast (BGP-LU) can resolve IPv4 or IPv6 routes over segment routing–traffic
engineering (SR-TE) for both IPv4 and IPv6 address families. BGP-LU supports mapping a BGP
community color and defining a resolution map for SR-TE. A colored
protocol next hop is constructed and it is resolved on a colored SR-TE tunnel in the
inetcolor.0 or inet6color.0 table. BGP uses
inet.3 and inet6.3 tables for non-color based mapping.
This enables you to advertise BGP-LU IPv6 and IPv4 prefixes with an IPv6 next-hop address
in IPv6-only networks where routers do not have any IPv4 addresses configured. With this
feature, Currently we support BGP IPv6 LU over SR-TE with IS-IS underlay.
BGP-LU supports the following scenarios:
-
BGP IPv4 LU over colored BGP IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.
-
BGP IPv4 LU over static colored and non-colored IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.
-
BGP IPv6 LU over colored BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
BGP IPv6 LU over static colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
IPv6 Layer 3 VPN services with IPv6 local address and IPv6 neighbor address.
-
IPv6 Layer 3 VPN services over BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
IPv6 Layer 3 VPN services over static-colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.
Supported and Unsupported Features for Color-Based Mapping of VPN Services
The following features and functionality are supported with color-based mapping of VPN services:
-
BGP Layer 2 VPN (Kompella Layer 2 VPN)
-
BGP EVPN
-
Resolution-map with a single IP-color option.
-
Colored IPv4 and IPv6 protocol next hop resolution.
-
Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.0 routing table.
-
Colored SR-TE LSP.
-
Virtual platforms.
-
64-bit Junos OS.
-
Logical systems.
-
BGP labeled unicast.
The following features and functionality are not supported with color-based mapping of VPN services:
-
Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static.
-
Layer 2 circuit
-
FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN.
-
VPLS
-
MVPN
-
IPv4 and IPv6 using resolution-map.