In this article, I’ll walk you through a classic MPLS RSVP use case between Juniper and DATACOM 2 with some manipulation in the affinity bits, also known as link coloring, in order to influence the potential paths that will be chosen by the CSPF (constrained shortest path first) . So, let’s assume a service provider has this design requirement:
A ISP needs to setup a VPWS (l2-circuit) between 2 PEs, Juniper
SW4_DM4001(Figure 1), however, this LSP should never use a specific link, which for the sake of this example, let’s assume it is a high latency link. Plus, the service provider does not want to change OSPF costs because this traffic engineering should only influence this particular VPWS.
To address this design requirement, RSVP with affinity fits like a glove. Essentially, you can color MPLS RSVP links and include or exclude them from the CSPF algorithm. In this case, we’ll color this undesired high-latency link as
yellow and when setting the RSVP LSPs between these two PEs we’ll exclude the yellow color. In this particular example, since we’re not using explicit-path to enforce a strict path and just excluding a certain link, ultimately the CSPF will end up following the IGP shortest path, however, it won’t use this latency link.
When interoperating RSVP with affinity in a multi-vendor network you have to keep in mind that, on wire, the affinity bits field is 32-bit long. However, when setting this attribute on the cli, some vendors have different approaches. For example, on
Junos you set an integer, which represents the bit position ranging from 0 to 31. On DATACOM DM4000 Switches, on other hand, you also set an integer, but this represents a decimal absolute value that you’ll have on wire. So, let’s say this
yellow link is supposed to be
0x10 (decimal 16) on wire:
On Junos 1, you should set this attribute as 4 (i.e.,
2^4=16). By the way, Juniper uses the
admin-groupcontainer to set the affinity bits:1set protocols mpls admin-groups yellow 4
On DATACOM DM4000, you have to set the affinity attribute as 16:1rsvp signalling link attributes 16
Figure 1 shows the topology used in this use case. The undesired high latency link is the one between
SW4_DM4001 on VLAN 3004, which has the topology text label
affinity 0x10 | yellow. In this topology, the RSVP LSPs will be setup between
SW4_DM4001. As you can see in Figure 1, considering the perspective from
SW4_DM4001 (working as both egress PE and ingress PE), there are three MPLS RSVP links available,
VLAN 4004 (affinity 0), 4000 (affinity 0) and 3004 (affinity 0x10):
For the sake of readability, I’ll show only the essential part of the configuration of both
Junos vMX and
SW4_DM4001. According to the configuration bellow, there are two RSVP LSPs,
SW4_TO_VMX. They both exclude
affinity 0x10. These two LSPs are used by this VPWS
vc-id 1600, which xconnects customers A’s site#1 and site#2 (Figure 1).
When configuring the affinity attribute, since this is meant to be a link-state attribute, usually the entire link is expected to have the same affinity attribute on each end of the link. Make sure you set the same affinity on both switches connecting this link.
Now we’ll verify how these LSPs will reconverge as we shut network links down. Specifically, we’ll focus on all links connected to
SW4_DM4001, since both LSPs will have to go over them, they’re strategic to analyze the reconvergence of this topology:
Initially, all links are UP. As shown in Figure 2, both RSVP LSPs are following the shortest path, going through
SW3_DM4001 (which is the PHP LSR switch for both LSPs). As expected, they both avoided the
yellow link - the shortest path will change though, as I start to shut some links down:
As you can see in Figure 3, both LSPs don’t go through
SW3_DM4001 anymore. Now, they have shifted to the top paths in this topology going through
SW2_DM4004. As expected, again, they both avoided the
yellow link, even though the yellow link has the same metric as the current shortest path:
After shutting VLAN 4004 - Port-channel 24 down, the only remaining MPLS/RSVP-enabled link is the VLAN 3004, which has the
yellow affinity color - Figure 4. Even though we have back-to-back L3 reachability (see the ping test down bellow) between
SW4_DM4001, both LSPs won’t consider this link as an eligible path. As a result, they will be operational down and the VPWS circuit that uses these underlying LSPs won’t be set-up, as we initially intended:
RSVP is extremely flexible when it comes to LSP traffic engineering, meaning you can include or exclude certain criteria, in this case we leveraged the affinity bits to avoid an undesired high latency link when the CSPF is being computed. Plus, an advantage of RSVP is the fact that you can traffic engineer paths without messing up with the IGP forwarding table. If you are using affinity in a multi-vendor network watch out how your vendor set these bits, the math should be straight forward, make sure you get it right, otherwise the LSP won’t be computed correctly by the CSPF.