SR/LDP SRMS OSPF Inter-Area
Last updated
Last updated
Load sr.ldp.ms.ospf.init.cfg
R2 is an LDP-only node. All other routers are SR-only. Configure R1 as an SRMS so that routers such as R7 and R8 can form an LSP to R2.
Just like native prefix SIDs are propagated inter-area, prefix SID mappings are propagated inter-area in OSPF. Note that ISIS prefix SID mappings are not propagated between levels though.
First, R1 originates an Opaque-area (type 10) Ext Prefix LSA for 2.2.2.1/32:
This LSA uses an “Extended Prefix Range TLV” as opposed to the “Extended Prefix TLV” we see for native prefix SIDs. This TLV only has one flag, the Inter-Area flag, which is set to 0. When set to 1, this means that the LSA has been advertised to another area by an ABR. An ABR will ignore this TLV if the IA flag is set to 1 and the LSA comes from a non-backbone area. This is the same behavior that is used with Type 3 LSAs to ensure loopfreeness. Also note the AF (address-family) attribute which is 0, meaning IPv4. OSPFv2 doesn’t support IPv6 anyways, so this will always be 0.
The SID sub TLV is used within the “Extended Prefix Range TLV” to advertise the SID index. Just like ISIS, this sub TLV is reused, and certain flags are ignored when it is used in a mapping advertisement. Above, 0x60 means that the NP (No-PHP) and M (Mapping Server) flags are set. When the M flag is set, the NP and E (Explicit Null) flags are ignored, so the XR implementation should actually clear the NP flag. Receiving routers will know not to do PHP because this is a prefix SID mapping, not a natively advertised prefix SID. The NP flag is not used here to determine PHP, just like we saw with ISIS. Also note that the SID Index value is a starting value, since it applies to a “Extended Prefix Range TLV” and not a “Extended Prefix TLV.” When the range size is 1, then the index value is the actual index value of the single prefix.
R3 and R4, upon receiving this LSA, will propagate it into area 0 since the IA flag is set to 0. We can see this below:
Now the “Extended Prefix Range TLV” flags show a value of 0x80, which means the IA flag is set. Everything else is the same as in the LSA from area 1, except the advertising router becomes the ABR.
On R3 and R4, the prefix SID mapping in the active policy is known via each other, because they have a higher RID than R1. When each ABR propagates the mapping into another level, it looks as if that ABR itself is a mapping server.
R5 and R6 then propagate this further into area 2, because the IA flag is set but it is from area 0. (Just like with type 3 LSAs, you propagate Ext-Prefix Opaque-area LSAs in and out of area 0 only).
As before, the IA flag is set. For this reason, R5 and R6 do not propagate each other’s advertisements from area 2 back into area 0.
R7 and R8 will use the mapping from R6 as the active policy due to the higher RID.
We now have an end-to-end LSP between R7 and R2:
Let’s advertise a mapping from R3:
R3 will advertise this into both area 1 and area 0 with the IA flag cleared. R4 will propagate the area 1 advertisement into area 0. It will not propagate the area 0 advertisement redundantly into area 1.
So within area 1 we see a single LSA, and within area 0 we see two.
This is because of another rule that ABRs follow: In addition to ignoring LSAs from non-backbone areas with the IA flag set, an ABR does not propagate an LSA into an area as IA=1 if an existing LSA exists in that area with IA=0.
If you consider that the IA flag is the same effect as propagating a type 1 LSA as type 3, then it makes complete sense. A redundant ABR does not advertise a Type 3 LSA from area 0 back into the non-backbone area in which the prefix exists as a Type 1 LSA.
