In the last post we have seen as SR and TI-LFA works fine by default with NSSA ospf areas.
Anyhow, the game broke as soon as we added the no-summaries setting. As a result, our ABR was no longer able to compute the TI-LFA path.
Here, we are going to explore some workarounds.
The first one allows us to stick with our NSSA no-summaries area but does not provide a very fast failover in case of failure.
The idea is to manually define a static SR lsp that follows our intended TI-LFA path:
set protocols source-packet-routing preference 15
set protocols source-packet-routing segment-list r1-bkp-sl inherit-label-nexthops
set protocols source-packet-routing segment-list r1-bkp-sl auto-translate
set protocols source-packet-routing segment-list r1-bkp-sl r2 ip-address 192.168.23.0
set protocols source-packet-routing segment-list r1-bkp-sl r4 ip-address 192.168.24.1
set protocols source-packet-routing segment-list r1-bkp-sl r1 ip-address 192.168.14.0
set protocols source-packet-routing preserve-nexthop-hierarchy
set protocols source-packet-routing source-routing-path r1-bkp to 1.1.1.1
set protocols source-packet-routing source-routing-path r1-bkp binding-sid 1000111
set protocols source-packet-routing source-routing-path r1-bkp primary r1-bkp-slBasically, we define a colorless lsp (installed into inet.3 directly) that follows the path R3-R2-R4-R1. Ip addresses are given so that Junos automatically translates them into adjacency SIDs.
We also set preference 15 so that L-OSPF route stays primary by default.
This is the result:
root@r3# run show route 1.1.1.1 table inet.3
inet.3: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[L-OSPF/10/5] 00:06:03, metric 1
> to 192.168.13.0 via ge-0/0/0.0
[SPRING-TE/15] 00:00:08, metric 1, metric2 1
> to 192.168.23.0 via ge-0/0/1.0, Push 77, Push 23(top)
[edit]
root@r3# run show route 1.1.1.1 table inet.3 active-path
inet.3: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[L-OSPF/10/5] 00:06:09, metric 1
> to 192.168.13.0 via ge-0/0/0.0We have a backup path!
However, this solution is not perfect for at least two reasons:
- we “hard-coded” the backup path. True, it follows the TI-LFA path that was computed before but what if R3-R2 failed along with the protected link (R3-R1)? In that case, our backup lsp would go down. To say it in other words, we get a backup path but we lost the dynamicity of the IGP and TI-LFA. Yet, we have to say that if both links fail simultaneously we would be in a double fault scenario and we might accept traffic to be lost (that’s up to how many failures we want to accept and cover)
- the backup route is just another route towards that endpoint but it is not a real backup route. It is not pre-installed into FIB with a higher weight. This route becomes active when the L-OSPF one goes down but this is not instantaneous like a backup route.
Moreover, if some seamless mpls must be provided, we might need to make the binding SID (1000111) available and known to other nodes
root@r3# run show route label 1000111
mpls.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1000111 *[SPRING-TE/15] 00:05:34, metric 1, metric2 0
> to 192.168.23.0 via ge-0/0/1.0, Swap 77, Push 23(top)For this reason, this solution might work but I would not recommend it in a real environment.
Do we have an alternative? Yes we do.
The real issue here is the NSSA itself. NSSA was designed many years ago when networks very different and, more importantly, devices were less powerful. NSSA brought some resource saving along with some limitations (not related to SR) like the one we have seen here.
Nowadays, we can safely migrate from NSSA and its limitations and opt for regular areas. Migrating to regular areas might lead someone to shout “yes but…what about all the routes my lsdb will get? No-summaries was designed to reduce the size of the lsdb”. That’s what I think about this. As just said, NSSA came into the game in another “era”. Thinking about the size of the db and ways to limit flooding was relevant when devices scalability was a concern. Today, we can safely say we simply have “more space”. As a result, thinking about saving space this way might seem a bit anachronistic, “out of time”. It is not that saving resources is bad; you can still do it but is it really necessary? Especially, considering the limitations we bump into with things like NSSA.
Moreover, available features to configure ospf progressed as well and today we are able to use standard areas but, at the same time, to perform filtering and control on flooding.
This is the key concept behind this second solution, the recommended one.
First we transform area 1 from every router into a standard one:
delete protocols ospf area 0.0.0.1 nssaOn R1 (non ABR area 1 router) we check our db:
root@r1# run show ospf database | match Summ | count
Count: 34 lines
root@r1# run show ospf database | match Summ
Summary 3.3.3.3 3.3.3.3 0x80000001 114 0x22 0xa480 28
Summary 3.3.3.3 4.4.4.4 0x80000001 103 0x22 0x9a84 28
Summary 4.4.4.4 3.3.3.3 0x80000001 114 0x22 0x625a 28
Summary 4.4.4.4 4.4.4.4 0x80000001 103 0x22 0x58c4 28
Summary 5.5.5.5 3.3.3.3 0x80000001 114 0x22 0x52c9 28
Summary 5.5.5.5 4.4.4.4 0x80000001 103 0x22 0x34e3 28
Summary 6.6.6.6 3.3.3.3 0x80000001 114 0x22 0x24f3 28
Summary 6.6.6.6 4.4.4.4 0x80000001 103 0x22 0x60e 28
Summary 7.7.7.7 3.3.3.3 0x80000001 114 0x22 0xff13 28
Summary 7.7.7.7 4.4.4.4 0x80000001 103 0x22 0xe12d 28
Summary 8.8.8.8 3.3.3.3 0x80000001 114 0x22 0xd13d 28
Summary 8.8.8.8 4.4.4.4 0x80000001 103 0x22 0xb357 28
Summary 192.168.34.0 3.3.3.3 0x80000001 114 0x22 0xeb56 28
Summary 192.168.34.0 4.4.4.4 0x80000001 103 0x22 0xcd70 28
Summary 192.168.35.0 3.3.3.3 0x80000001 114 0x22 0xfea5 28
Summary 192.168.35.0 4.4.4.4 0x80000001 103 0x22 0xeab4 28
Summary 192.168.36.0 3.3.3.3 0x80000001 114 0x22 0xf3af 28
Summary 192.168.36.0 4.4.4.4 0x80000001 103 0x22 0xdfbe 28
Summary 192.168.45.0 3.3.3.3 0x80000001 114 0x22 0x7cb9 28
Summary 192.168.45.0 4.4.4.4 0x80000001 103 0x22 0x7224 28
Summary 192.168.46.0 3.3.3.3 0x80000001 114 0x22 0x71c3 28
Summary 192.168.46.0 4.4.4.4 0x80000001 103 0x22 0x672e 28
Summary 192.168.56.0 3.3.3.3 0x80000001 114 0x22 0x216d 28
Summary 192.168.56.0 4.4.4.4 0x80000001 103 0x22 0x387 28
Summary 192.168.57.0 3.3.3.3 0x80000001 114 0x22 0x1677 28
Summary 192.168.57.0 4.4.4.4 0x80000001 103 0x22 0xf791 28
Summary 192.168.58.0 3.3.3.3 0x80000001 114 0x22 0xb81 28
Summary 192.168.58.0 4.4.4.4 0x80000001 103 0x22 0xec9b 28
Summary 192.168.67.0 3.3.3.3 0x80000001 114 0x22 0xa7db 28
Summary 192.168.67.0 4.4.4.4 0x80000001 103 0x22 0x89f5 28
Summary 192.168.68.0 3.3.3.3 0x80000001 114 0x22 0x9ce5 28
Summary 192.168.68.0 4.4.4.4 0x80000001 103 0x22 0x7eff 28
Summary 192.168.78.0 3.3.3.3 0x80000001 114 0x22 0x1af9 28
Summary 192.168.78.0 4.4.4.4 0x80000001 103 0x22 0xfb14 28We have 34 Summary LSAs. They are router loopbacks and p2p links. Right now, everything is flooded.
Next, on ABRs we add this:
set policy-options policy-statement lsa-filtering term ok from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement lsa-filtering term ok then accept
set policy-options policy-statement lsa-filtering then reject
set protocols ospf area 0.0.0.1 network-summary-export lsa-filteringWe use a feature called network-summary-export. Through a policy, we tell the ABR to only advertise certain Summary LSAs to other routers within area 1. Specifically, only /32 addresses (routers loopbacks) are accepted.
As a result, on R1:
root@r1# run show ospf database | match Summ | count
Count: 12 lines
[edit]
root@r1# run show ospf database | match Summ
Summary 3.3.3.3 3.3.3.3 0x80000001 229 0x22 0xa480 28
Summary 3.3.3.3 4.4.4.4 0x80000001 218 0x22 0x9a84 28
Summary 4.4.4.4 3.3.3.3 0x80000001 229 0x22 0x625a 28
Summary 4.4.4.4 4.4.4.4 0x80000001 218 0x22 0x58c4 28
Summary 5.5.5.5 3.3.3.3 0x80000001 229 0x22 0x52c9 28
Summary 5.5.5.5 4.4.4.4 0x80000001 218 0x22 0x34e3 28
Summary 6.6.6.6 3.3.3.3 0x80000001 229 0x22 0x24f3 28
Summary 6.6.6.6 4.4.4.4 0x80000001 218 0x22 0x60e 28
Summary 7.7.7.7 3.3.3.3 0x80000001 229 0x22 0xff13 28
Summary 7.7.7.7 4.4.4.4 0x80000001 218 0x22 0xe12d 28
Summary 8.8.8.8 3.3.3.3 0x80000001 229 0x22 0xd13d 28
Summary 8.8.8.8 4.4.4.4 0x80000001 218 0x22 0xb357 28We reduced the db size but kept Summary LSAs for routers loopback.
This is fundamental because, unlike NSSA with no-summaries, R1 now has lsps to other routers (not just R2):
root@r1# run show route table inet.3
inet.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2.2.2.2/32 *[L-OSPF/10/5] 00:04:19, metric 2
> to 192.168.13.1 via ge-0/0/1.0, Push 1002
to 192.168.14.1 via ge-0/0/2.0, Push 1002
3.3.3.3/32 *[L-OSPF/10/5] 00:04:26, metric 1
> to 192.168.13.1 via ge-0/0/1.0
4.4.4.4/32 *[L-OSPF/10/5] 00:04:19, metric 1
> to 192.168.14.1 via ge-0/0/2.0
5.5.5.5/32 *[L-OSPF/10/5] 00:04:19, metric 2
> to 192.168.13.1 via ge-0/0/1.0, Push 1005
to 192.168.14.1 via ge-0/0/2.0, Push 1005
6.6.6.6/32 *[L-OSPF/10/5] 00:04:19, metric 2
> to 192.168.13.1 via ge-0/0/1.0, Push 1006
to 192.168.14.1 via ge-0/0/2.0, Push 1006
7.7.7.7/32 *[L-OSPF/10/5] 00:04:19, metric 3
> to 192.168.13.1 via ge-0/0/1.0, Push 1007
to 192.168.14.1 via ge-0/0/2.0, Push 1007As a consequence, magically, R3 is now able to compute the TI-LFA path (without the need of the static SPRING route):
root@r3# run show route 1.1.1.1 table inet.3
inet.3: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[L-OSPF/10/5] 00:05:55, metric 1
> to 192.168.13.0 via ge-0/0/0.0
to 192.168.23.0 via ge-0/0/1.0, Push 1001, Push 1004(top)
[SPRING-TE/15] 00:05:37, metric 1, metric2 1
> to 192.168.23.0 via ge-0/0/1.0, Push 79, Push 27(top)
[edit]
root@r3# deactivate protocols source-packet-routing
[edit]
root@r3# commit
commit complete
[edit]
root@r3# run show route 1.1.1.1 table inet.3
inet.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[L-OSPF/10/5] 00:06:08, metric 1
> to 192.168.13.0 via ge-0/0/0.0
to 192.168.23.0 via ge-0/0/1.0, Push 1001, Push 1004(top)
[edit]
root@r3# run show route 1.1.1.1 table inet.3 extensive | match weigh
Next hop: 192.168.13.0 via ge-0/0/0.0 weight 0x1, selected
Next hop: 192.168.23.0 via ge-0/0/1.0 weight 0xf000Here it is! Working TI-LFA and no more NSSA (but with the ability to control flooding).
Maybe it is time to move away from NSSA 🙂
Ciao
IoSonoUmberto
IoSonoUnRouter 