Introduction
As we saw in the SPF and TE Single Protocol Solutions blog, when deploying differentiated services it becomes necessary on the ingress router to forward some services, those requiring specific paths constraints, using only the Traffic-Engineered(TE) LSPs or even very specific TE LSPs while other service may be ‘allowed’ to use the SPF LSPs. In this blog we will explore several options for service mapping ranging from implicit techniques to very specific policy driven techniques. We will also explore how attributes associated with a Border Gateway Protocol (BGP) based service destination may be used as match criteria for service mapping policy. Lastly, while services may take many forms, general Internet reachability, L3VPN or L2VPN services, Voice and Video services, etc. and each may have different network requirements, this blog will focus generally on mapping a Layer-3 (L3) packet to a next-hop LSP.
Load-balancing between different protocols
Let’s start off by looking back at where we left off in the last blog. The default behavior for route selection is to use the protocol preference of the contributing route for next-hop resolution. As such, next-hop resolution always selects the TE LSPs (RSVP-TE, SR-TE) over the SPF LSPs (LDP, L-ISIS). Thus if there is an SPF LSP and a TE LSP to the same protocol next-hop in the inet.3 RIB then the TE LSP will always be preferred and all traffic will be forwarded using the TE-LSP.
We saw how a multi-path policy can be used to, essentially, make an SPF LSP and a TE-LSP equal so that ingress load-balancing becomes an option. See below for a quick look at the previous example
Figure 1: Load-balancing between L-ISIS & SR-TE paths
R1 Example Configuration
routing-options {
rib {
inet.3 {
policy-multipath policy spf-te-lb;
policy-options {
policy-statement spf-te-lb {
term 1 {
from {
protocol [ spring-te l-isis ];
route-filter 1.1.1.6/32 exact;
}
then accept;
Verification of the multipath policy
admin@R1> show route 11.0.0.102 table inet.3
inet.3: 5 destinations, 9 routes (5 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
1.1.1.6/32 *[Multipath/8] 00:00:37, metric 1, metric2 0
> to 11.101.202.2 via ge-0/0/2.0, Push 106
> to 11.101.201.2 via ge-0/0/1.0, Push 19, Push 17, Push 16(top)
Implicit mapping
Multiple Loopbacks
Since the crux of the problem is that both SPF and TE LSPs have the same destination as the protocol next-hop for a service, one simple way to address the challenge is to use different protocol next-hops and create TE LSPs to only specific ones. By configuring multiple loopback addresses on the destination routers, an operator can indirectly control LSP selection. In the example below, we will look at how to create and use a shortest-path LDP LSP, the red LSP using the red next-hop (1.1.1.16), and a traffic-engineered RSVP-TE LSP using the blue next-hop (1.1.1.6).
Figure 2: Separate protocol next-hops
Example R1 configuration
protocols {
ldp {
interface all;
...
protocols {
mpls {
label-switched-path te-lsp-to-r6 {
to 1.1.1.6;
primary {
explicit-path-to-r6;
...
path {
explicit-path-to-r6 {
192.0.13.2 strict;
192.0.34.2 strict;
192.0.45.2 strict;
192.0.56.2 strict;
Verification of the path specified next-hops
regress@R1> show route 1.1.1.16 table inet.3
inet.3: 8 destinations, 20 routes (8 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
1.1.1.16/32 *[LDP/9] 00:00:22, metric 1
> to 10.1.12.2 via ge-0/0/1.0, Push 90
regress@R1> show route 1.1.1.6 table inet.3
inet.3: 8 destinations, 20 routes (8 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
1.1.1.6/32 *[RSVP/7/1] 5d 01:02:08, metric 30
> to 10.1.13.2 via ge-0/0/2.0, label-switched-path to-r6
COS-Based Forwarding Policies
Class-of-service (CoS)-based forwarding (CBF) enables you to control next-hop LSP selection based on a packet’s class of service and, in particular, the value of the IP packet’s precedence bits (though other classification fields are available) used to classify a packet. In the example below, we can specify that certain classes are forwarded using the SPF LSPs while other classes are forwarded only using the explicit-paths. In other words, CBF allows path selection based on class. Figure 3, below, shows a simple example of CBF where packets are classified on ingress to R1, associated with forwarding-classes, 3 output queues and 2 next-hop LSP mappings.
Figure 3: COS Based Forwarding
Example R1 configuration
class-of-service {
forwarding-policy {
next-hop-map spf-te-service-map {
forwarding-class spf-Services {
non-lsp-next-hop;
}
forwarding-class te-Services {
lsp-next-hop rsvp-te-lsp-to-*;
...
...
routing-options {
forwarding-table {
export spf-te-service-map;
Like the previous examples, CBF has its pro’s and con’s. On one hand, it’s very easy to envision classes of LSPs and then assign service destinations to those classes. While class association can be based on many attributes of the service (destination prefix, IP precedence values, etc.), CBF has a behavior that is very much data-plane driven because there is a tight coupling between forwarding-classes and output queues. This coupled with other per hop behavior (PHB) forwarding requirements may complicate using CBF solely for the purpose of service-mapping.
Explicit mapping
Using multiple loopback addresses certainly has it’s advantages in that it’s quite simple to understand, easy to manage and intuitive when verifying the routing tables. However, if there is a need to differentiate between more than a couple of services and/or business policy dictates more complex service mapping policies, e.g. fall-back scenarios, then the added loopback addresses may become less desirable or ineffective entirely.
Static routes
There is nothing romantic about using static routes but they can be effective and provide the necessary granularity if used correctly. A nuance associated with using static routes for service mapping is that the next-hop LSP MUST be named. In other words, an L-ISIS route is not named as a next-hop LSP for a static route. The configuration example below uses the same base diagrams of figure 1 and 2 and maps a specific service destination, 123.0.0.0/24, to a blue TE RSVP-TE LSP and another service destination, 145.0.0.0/24, to the red TE SR-TE LSP.
Example configuration on R1
routing-options {
static {
route 123.0.0.0/24 {
lsp-next-hop rsvp-te-lsp-to-r6;
Verification of the static service mapping
admin@R1# run show route 123.0.0.0
inet.0: 58 destinations, 62 routes (58 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
123.0.0.0/24 *[Static/5] 00:00:07
> to 11.101.202.2 via ge-0/0/2.0, label-switched-path rsvp-te-lsp-to-r6
There are a few noteworthy things to take away from this example:
- Static routes are added on the ingress router (this will become more relevant after the next section)
- If the service destination that is being mapped is known via normal routing procedures, such as via BGP, and the lsp-next-hop that is referenced by the static route becomes unavailable the service destination may become reachable via another LSP. This can be controlled by using additional discard static routes.
- Resiliency can be controlled by defining multiple static routes. For example, 123.0.0.0/24 can be mapped to multiple LSPs and metrics can be assigned to control preference during forwarding selection.
The BGP link … Abstraction!
Thus far we have looked at a few methods, some explicit, and some implicit, for mapping service destinations to next-hop LSPs. However, they all are quite specific and do not rely on any indirection between the service destination and the ingress next-hop LSP selection. Over the years, most, if not all, service reachability has migrated to BGP based applications. Whether it’s basic Internet content reachability, BGP based L3VPN or L2VPNs for Data-center centric services using EVPNs, they all have one thing in common … the service destination is known via a BGP NLRI. The following two sections will look at how to attach BGP attributes to service destinations and associate those attributes with next-hop LSPs.
BGP Communities
A BGP community is a group of destinations that share a common property. Community information is included as a path attribute in BGP update messages. This information identifies community members and enables you to perform actions on a group of service destinations without having to elaborate upon each specific destination. You can use community and extended communities attributes to trigger routing decisions, such as acceptance, rejection, preference, or redistribution and in this case … next-hop LSP selection.
In the following example, R6 is announcing two service routes, as in the previous examples, via BGP. Service-route 123.0.0.0/24 is being announced with the ‘red’ community = 100:100, while service-route 145.0.0.0/24 is being announced with the ‘blue’ community = 200:200. R1 is configured with a policy that dictates that blue communities are mapped to blue LSPs and red communities mapped to red LSPs.
Figure 4: BGP community based service mapping
R1 configuration example for service mapping
routing-options {
forwarding-table {
export service-map;
}
}
policy-options {
policy-statement service-map {
term RED-SPF-services {
from community RED-services;
then {
install-nexthop strict lsp-regex red-lsp-to-*;
}
}
term BLUE-TE-services {
from community BLUE-services;
then {
install-nexthop strict lsp-regex blue-lsp-to-*;
}
}
}
community RED-services members 100:100;
community BLUE-services members 200:200;
Verification of the Community based policy mapping
Before policies applied
regress@R1# run show route 123.0.0.0
inet.0: 34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
123.0.0.0/24 *[BGP/170] 5d 01:53:27, localpref 100, from 1.1.1.6
AS path: I, validation-state: unverified
to 10.1.13.2 via ge-0/0/2.0, label-switched-path blue-lsp-to-r6
> to 10.1.12.2 via ge-0/0/1.0, label-switched-path red-lsp-to-r6
After service-map policy is applied
regress@R1# run show route 123.0.0.0
inet.0: 34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
123.0.0.0/24 *[BGP/170] 00:00:11, localpref 100, from 1.1.1.6
AS path: I, validation-state: unverified
to 10.1.12.2 via ge-0/0/1.0, label-switched-path red-lsp-to-r6
regress@R1# run show route 145.0.0.0
inet.0: 34 destinations, 34 routes (33 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
145.0.0.0/24 *[BGP/170] 00:00:02, localpref 100, from 1.1.1.6
AS path: I, validation-state: unverified
to 10.1.13.2 via ge-0/0/2.0, label-switched-path blue-lsp-to-r6
Notice the use of the regular expressions and the strict keywords in the policy definition. What this enables is the matching of any available Blue or Red LSP that can reach the service route. This is useful when services are dual homed to the network. The strict keyword ensures that if no red or blue LSP is available, that the next-hop LSP selection does not fall-back to another LSP type. In some cases, it may be desirable to create a fall-back policy definition by creating adding another term and/or dropping the strict keyword from the policy.
BGP SR TE Communities
BGP SR-TE offers a way of representing SR Policies (and candidate paths) via the BGP UPDATE message. Thus it enables BGP to propagate a segment routing policy for traffic engineering to ingress routers, similarly to the previous example to steer labeled or IP traffic into an ingress SR-TE LSP. BGP installs the candidate routes of the segment routing policy into routing tables bgp.inetcolor.0 (or bgp.inet6color.0). BGP route and next-hop LSP selection is in turn done via the new inetcolor tables vs. the inet3 table in the previous example.
Figure 5: BGP SR TE based service mapping
Like the RSVP-TE service-mapping example, where we first created the multipath route, we need to do a little upfront work for SR-TE based service-mapping by enabling the segment-routing-te BGP address-family and adding the extended-nexthop-color knob for unicast prefixes.
R1 configuration example for enabling SR-TE AF
protocols {
bgp {
group ibgp_inet/srte/l3vpn {
family inet {
unicast {
extended-nexthop-color;
}
segment-routing-te;
...
R1 configuration example for enabling SR color and a binding SID
protocols {
source-packet-routing {
source-routing-path sr-te-lsp-to-r7 {
to 1.1.1.7;
color 200;
binding-sid 1000;
primary {
red-path-to-r7;
}
}
segment-list sr-to-r7 {
hop1 label 19;
hop2 label 16;
hop3 label 17;
hop4 label 19;
...
isis {
source-packet-routing {
srgb start-label 500 index-range 100;
node-segment {
ipv4-index 1;
}
}
interface all;
...
Verification of the SR-TE based policy
Uncolored route to R7 in inet.3
regress@R1> show route 1.1.1.7 table inet.3
inet.3: 6 destinations, 8 routes (6 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
1.1.1.7/32 *[L-ISIS/14] 06:49:09, metric 30
> to 10.1.12.2 via ge-0/0/1.0, Push 107
Colored SR-TE route to R7 in inetcolor.0 table
regress@R1# run show route table inetcolor.0
inetcolor.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.7-200<c>/64
*[SPRING-TE/8] 01:08:47, metric 1, metric2 0
> to 10.1.13.2 via ge-0/0/2.0, Push 19, Push 17, Push 16(top)
Service-destinations associated with colored and uncolored routes
regress@R1> show route 189.0.0.0
inet.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
189.0.0.0/24 *[BGP/170] 00:00:35, localpref 100, from 1.1.1.7
AS path: I, validation-state: unverified
> to 10.1.13.2 via ge-0/0/2.0, Push 19, Push 17, Push 16(top)
regress@R1> show route 167.0.0.0
inet.0: 31 destinations, 31 routes (30 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
167.0.0.0/24 *[BGP/170] 00:00:33, localpref 100, from 1.1.1.7
AS path: I, validation-state: unverified
> to 10.1.12.2 via ge-0/0/1.0, Push 107
Notice the subtle difference between the RSVP-TE and SR-TE service-mapping examples:
- In the RSVP-TE example, both service-destinations (123/24 and 145/24) are announced with community tags and explicitly matched by policy on the ingress router.
- In the SR-TE case, we only announce the Blue service-destinations (189/24) with the color Blue, for explicit routing, and allow the Red service-destinations, those requiring shortest-path LSPs, to resolve normally via inet.3 over the L-ISIS routes.
- Both examples show very strict service-mapping and there will be no fall-back.
Conclusion
As we’ve seen, there are a number of ways to address service mapping when we have deployed a single protocol for both shortest-path and traffic-engineered services. Each method has it’s pro’s and con’s in terms of the amount of complexity of configuration and thus the amount potential work required to implement such solutions. It’s clear that the abstraction provided by BGP communities and/or BGP SR TE SAFI offer a great deal of flexibility at the expense of describing service-mapping with routing policy.
Acknowledgements
A special thanks to Harish Sitaraman <hsitaraman@juniper.net> for his contributions and thorough reviews.
References
MPLS LSP Install
https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-adding-lsp-related-routes-to-the-inet-3-routing-table.html
MPLS LSP no-install-to-address
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/no-install-to-address-edit-protocols-mpls.html
MPLS COS Based Forwarding
https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-based-forwarding-overview-cos-config-guide.html
BGP Communities
https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-bgp-communities-extended-communities-match-conditions-overview.html
Mapping traffic onto LSPs
https://www.juniper.net/documentation/en_US/junos/topics/example/policy-lsp-forwarding-next-hop-assigned-to-different-destination-prefixes.html
BGP SR Traffic Engineering
https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-sr-te.html