Multi-Area/Level Segment Routing
Segment Routing can be used with multi-area OSPF or multi-level ISIS, and it can even be used with redistribution between OSPF and ISIS. However, the catch is that adjacency SIDs cannot be advertised when running SR in topologies such as this. Adjacency SIDs only make sense if all routers synchronize their database and have a shared understanding of the topology. With multi-area/level IGP, the inter-area routes are essentially just distance-vector. Topology information is lost for the purpose of scalability. We can still advertise prefix-SIDs across IGP area/level/process boundaries and obtain end-to-end LSPs though. We will just lose the ability to do FRR, TE, etc.
We’ll re-use our topology from the Introduction series:
ISIS Multi-Level Prefix-SID Distribution
The lab is still configured with ISIS and it is a flat level 2 topology. We will configure R1 and Gi1 of R2 as level 1, and leave everything else as level 2 in area 0001.
By default all L2 routers will know 1.1.1.1/32 with prefix-SID index 1, but R1 will only know R2’s prefix SID.
R2’s level 2 LSP shows 1.1.1.1/32 as a L1 route that was re-advertised. (You can tell this by the R flag being set). The prefix SID is automatically included. But all adjacency information is lost.
R1 is missing routes because, by default, ISIS propagates L1 routes into the L2, but filters all L2 routes from L1. L1 routers must rely on the attached bit from an L1/L2 router to route outside their area. But to faciliate LSPs between R1 and other routers in level 2, we need to specifically know the /32s and their associated prefix SIDs. Let’s leak /32 routes from L2 into L1 on R2.
R2 now leaks /32s into level 1, and automatically includes the prefix SIDs.
Redistribution between OSPF and ISIS
Let’s swap the ISIS L1 for OSPF area 0 and preform redistribution of /32s between the routing protocols.
R1 learns the prefix SIDs for the /32s of the routers in the ISIS topology via Opaque Type 11 LSAs. These are AS flooded LSAs instead of the Opaque Type 10 LSAs which are only area flooded. The reason for this is that the /32s prefixes are known via Type 5 LSAs that R2 injected, so the Opaque LSAs flood throughout the AS to match the behaviour of the Type 5 LSAs.
If we look at one of the Type 11 LSAs, we can see that functionally it looks very similar to the Type 10 LSA.
One big difference in the Type 11 LSA is that the N-bit is not set under the Flags. The N-bit signifies that the prefix-SID is the Node SID that represents the advertising router. Additionally the NP-bit is set, which means No PHP. R1 should not pop the label, as R2 is not the owner of 3.3.3.3/32.
Compare this to the Type 10 LSA that 2.2.2.2 originates for its own loopback. The N-bit is set, and the NP-bit is not set.
Similarly, R2 sets the P bit on the external 1.1.1.1/32 that it redistributes into ISIS. This means “PHP off.” Note that this was also true for the previous section with multi-level ISIS. Inter-area /32s were advertised with the PHP off bit set. R2 needs to advertise 1.1.1.1/32 into the ISIS domain but ensure that other routers dont pop the label when sending traffic towards R2, as if R2 actually owned this prefix.
OSPF Multi-Area
We’ll now change the ISIS level 2 to OSPF Area 1. Area 0 and Area 1 should learn inter-area routes to the /32 loopbacks via Type 3 LSAs.
By default, intra-area routes are advertised to other areas at ABRs via Type 3 LSAs. The ABR in this topology is R2. R1 knowns the prefix SIDs of all routers in the topology:
This is because R2 advertises all /32s as Type 3 LSAs, and then advertises a corresponding Type 10 Opaque LSA for these prefixes:
On each Opaque LSA that R2 injects, it must set the NP bit so that R1 does not preform PHP. We saw this in the previous section when ISIS was redistributed into OSPF. The difference between the LSA below and the Type 11 LSA was that the N-bit was not set in the Type 11 LSA. I believe this is because when the route was redistributed into ISIS, the fact that it represents a node is lost. However, with OSPF inter-area routing, the fact that 3.3.3.3 represents node R3 is kept in-tact.
Because R2’s loopback is part of area 0, when R2 advertises it into area 1 it does not set the NP bit, even though it is an inter-area prefix. In this case it does want its neighbors to preform PHP. Here you can see both the N-bit (meaning this is a Node SID) and the A-bit, which means that this node is attached to another area, and is an ABR.
Conclusion
Multi-area/level segment routing is not as complicated as you might of thought. You lose all adjacency SID information, and prefix SID information is propagated along with the /32 inter-area route to allow for end-to-end LSPs. In all cases, the prefix SID follows the automatic inter-area routes or redistributed routes. You don’t have to do anything specific to include the prefix SID with the advertised route.
In OSPF, a corresponding Opaque LSA is advertised with the inter-area/external prefix. If the prefix SID is injected as a Type 5 LSA, then the Opaque LSA is Type 11 in order to flood domain-wide. If the prefix SID is advertised as a Type 3 LSA, the the Opaque LSA is Type 10 (area-wide flooding).
In ISIS, there is not the same concept of external vs. inter-area routes. A router injects the route into the other level by setting the re-advertise bit, meaning this was re-advertised from another level. In addition, when a level 2 route is advertised into level 1, the down bit is set so that the route cannot loop back to level 2 from level 1 again. This is normal ISIS inter-area routing.
In both OSPF and ISIS, the PHP behaviour needs to be signaled. OSPF sets the NP bit, instructing its neighbors not to preform PHP for the prefix. ISIS sets the P-bit on the prefix meaning “PHP off.”
Last updated