A networking-focused entity recognized solely as humblegrumble despatched me the next query after studying my When OSPF Turns into a Distance Vector Protocol article:
How do A1 and A2 know to not promote a Kind-3 abstract LSA generated from space 1 prefixes again into space 1?
He’s proper. There isn’t any “originating space” info within the type-3 LSA, so how does an ABR know to not reinsert the type-3 LSA generated by one other ABR again into the world?
TL&DR: The OSPF route choice course of takes care of that.
Wish to know the gory particulars? Let’s study them utilizing this pattern community:
- A1 and A2 are ABRs. The hyperlink between them is in space 0 (black).
- S1 and S2 are in space 1, as are their hyperlinks with the ABRs (inexperienced).
- R2 is in space 2 (blue), and R3 is in space 3 (crimson).
- Every ABR is thus in three areas: the spine space, space 1, and space 2 or 3.
- All point-to-point hyperlinks are unnumbered. The one prefixes we must always see within the OSPF knowledge and the IP routing desk are the loopback prefixes.
After beginning the lab, you need to see the next abstract LSAs on A2 (the printout on A1 is comparable, however has the abstract LSA info for space 2):
Abstract LSAs on A2 (edited to take away router hyperlink states)
a2# present ip ospf database
OSPF Router with ID (10.0.0.4)
Abstract Hyperlink States (Space 0.0.0.0)
Hyperlink ID ADV Router Age Seq# CkSum Route
10.0.0.5 10.0.0.3 265 0x80000001 0xae88 10.0.0.5/32
10.0.0.6 10.0.0.4 264 0x80000001 0x9e96 10.0.0.6/32
192.168.0.1 10.0.0.3 265 0x80000001 0xa734 192.168.0.1/32
192.168.0.1 10.0.0.4 264 0x80000001 0x06ca 192.168.0.1/32
192.168.0.2 10.0.0.3 265 0x80000001 0x02ce 192.168.0.2/32
192.168.0.2 10.0.0.4 264 0x80000001 0x9742 192.168.0.2/32
Abstract Hyperlink States (Space 0.0.0.1)
Hyperlink ID ADV Router Age Seq# CkSum Route
10.0.0.3 10.0.0.3 281 0x80000001 0x5ee4 10.0.0.3/32
10.0.0.3 10.0.0.4 274 0x80000001 0xbc7b 10.0.0.3/32
10.0.0.4 10.0.0.3 276 0x80000001 0xb87f 10.0.0.4/32
10.0.0.4 10.0.0.4 279 0x80000001 0x4ef2 10.0.0.4/32
10.0.0.5 10.0.0.3 267 0x80000001 0xae88 10.0.0.5/32
10.0.0.5 10.0.0.4 264 0x80000001 0x0d1f 10.0.0.5/32
10.0.0.6 10.0.0.3 267 0x80000001 0x0923 10.0.0.6/32
10.0.0.6 10.0.0.4 264 0x80000001 0x9e96 10.0.0.6/32
Abstract Hyperlink States (Space 0.0.0.3)
Hyperlink ID ADV Router Age Seq# CkSum Route
10.0.0.3 10.0.0.4 274 0x80000001 0xbc7b 10.0.0.3/32
10.0.0.4 10.0.0.4 279 0x80000001 0x4ef2 10.0.0.4/32
10.0.0.5 10.0.0.4 264 0x80000001 0x0d1f 10.0.0.5/32
192.168.0.1 10.0.0.4 264 0x80000001 0x06ca 192.168.0.1/32
192.168.0.2 10.0.0.4 264 0x80000001 0x9742 192.168.0.2/32
Certainly, the abstract LSA for 192.168.0.1/32 is inserted into space 3, however not again into space 1.
As we all know, OSPF would by no means take into account a path that isn’t one of the best path to a vacation spot. The subsequent step on our journey ought to thus be the OSPF routes (the outcomes of the SPF calculation):
OSPF routes on A2
a2# present ip ospf route
============ OSPF community routing desk ============
N 10.0.0.3/32 [10] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.4/32 [0] space: 0.0.0.0
straight hooked up to lo
N IA 10.0.0.5/32 [20] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.6/32 [10] space: 0.0.0.3
by way of 10.0.0.6, eth3
N 192.168.0.1/32 [20] space: 0.0.0.1
by way of 192.168.0.2, eth2
N 192.168.0.2/32 [10] space: 0.0.0.1
by way of 192.168.0.2, eth2
============ OSPF router routing desk =============
R 10.0.0.3 [30] space: 0.0.0.1, ABR
by way of 192.168.0.2, eth2
[10] space: 0.0.0.0, ABR
by way of 10.0.0.3, eth1
A2 prefers the trail A2-S2-S1, which is certainly the lowest-cost path to S1. Nevertheless, all hyperlinks in our community have equal OSPF value (10). If we alter the price of the S2-A2 hyperlink to 50, we would pressure A2 to take the trail by way of A1, proper?
Nope. Though the fee to succeed in 192.168.0.1/32 has elevated to 60, A2 nonetheless doesn’t need to take into account the higher path by way of space 0.
OSPF routes on A2 after altering the A2-S2 value to 50
a2# present ip ospf route
============ OSPF community routing desk ============
N 10.0.0.3/32 [10] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.4/32 [0] space: 0.0.0.0
straight hooked up to lo
N IA 10.0.0.5/32 [20] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.6/32 [10] space: 0.0.0.3
by way of 10.0.0.6, eth3
N 192.168.0.1/32 [60] space: 0.0.0.1
by way of 192.168.0.2, eth2
N 192.168.0.2/32 [50] space: 0.0.0.1
by way of 192.168.0.2, eth2
============ OSPF router routing desk =============
R 10.0.0.3 [70] space: 0.0.0.1, ABR
by way of 192.168.0.2, eth2
[10] space: 0.0.0.0, ABR
by way of 10.0.0.3, eth1
The foundation reason behind that conduct is the bullet (6) in part 16.2 of the OSPFv2 RFC that describes methods to cope with inter-area routes (abstract LSAs):
Else, if the paths current within the desk are intra-area paths, do nothing with the LSA (intra-area paths are all the time most well-liked).
As I wrote in 2008:
Intra-area routes are most well-liked over inter-area or exterior routes no matter their value.
To date, so good, however how does that impression the era of abstract LSAs? The abstract LSAs are generated from the OSPF routing desk (the outcomes of the SPF calculation) (RFC 2328, part 12.4.3):
Abstract-LSAs are originated by space border routers. The exact abstract routes to promote into an space are decided by inspecting the routing desk construction (see Part 11) in accordance with the algorithm described under. Notice that solely intra-area routes are marketed into the spine, whereas each intra-area and inter-area routes are marketed into the opposite areas.
The spine abstract LSA for 192.168.0.1/32 is just not within the OSPF routing desk on A2 (it prefers the costlier intra-area route) and thus by no means will get inserted again into space 1. Likewise, the abstract LSA inserted into space 3 has a better value than it will have had have been A2 contemplating the spine abstract LSA:
Abstract LSA noticed by R3 (in space 3)
r3# present ip ospf database abstract 192.168.0.1
OSPF Router with ID (10.0.0.6)
Abstract Hyperlink States (Space 0.0.0.3)
LS age: 970
Choices: 0x2 : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Kind: summary-LSA
Hyperlink State ID: 192.168.0.1 (abstract Community Quantity)
Promoting Router: 10.0.0.4
LS Seq Quantity: 80000002
Checksum: 0x9512
Size: 28
Community Masks: /32
TOS: 0 Metric: 60
Double-Checking Our Conclusions
Let’s double-check our conclusions. If the intra-area route is the one impediment stopping A2 from inserting a abstract LSA into space 1, then partitioning the world (disconnecting the hyperlink between S1 and S2) ought to take away that impediment, and we must always see a spine abstract LSA generated from space 1 reinserted into the opposite a part of space 1.
OSPF LSAs carry no space info. Thus, it’s completely authorized, albeit not sensible, to have a number of disjoint community areas with the identical space quantity.
That’s precisely what occurs. The router LSA describing S1 stays within the OSPF database of A2, nevertheless it’s not related to some other LSA in the identical space, and is thus ignored within the SPF calculation.
Space 1 router LSAs within the OSPF database on A2
a2# present ip ospf database
OSPF Router with ID (10.0.0.4)
...
Router Hyperlink States (Space 0.0.0.1)
Hyperlink ID ADV Router Age Seq# CkSum Hyperlink depend
10.0.0.3 10.0.0.3 369 0x80000006 0xbcca 1
10.0.0.4 10.0.0.4 1395 0x80000006 0xc196 1
192.168.0.1 192.168.0.1 358 0x8000000a 0xd01b 3
192.168.0.2 192.168.0.2 38 0x8000000c 0xfea2 2
The perfect OSPF route for 192.168.0.1/32 is thus the abstract LSA originated within the spine space by A1:
Finest OSPF routes on A2
a2# present ip ospf route
============ OSPF community routing desk ============
N 10.0.0.3/32 [10] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.4/32 [0] space: 0.0.0.0
straight hooked up to lo
N IA 10.0.0.5/32 [20] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 10.0.0.6/32 [10] space: 0.0.0.3
by way of 10.0.0.6, eth3
N IA 192.168.0.1/32 [20] space: 0.0.0.0
by way of 10.0.0.3, eth1
N 192.168.0.2/32 [50] space: 0.0.0.1
by way of 192.168.0.2, eth2
A2 thus inserts the abstract LSA for 192.168.0.1/32 into (a distinct) space 1:
Space 1 abstract LSAs within the OSPF database on A2
a2# present ip ospf database
OSPF Router with ID (10.0.0.4)
...
Abstract Hyperlink States (Space 0.0.0.1)
Hyperlink ID ADV Router Age Seq# CkSum Route
10.0.0.3 10.0.0.3 653 0x80000002 0x5ce5 10.0.0.3/32
10.0.0.3 10.0.0.4 650 0x80000002 0xba7c 10.0.0.3/32
10.0.0.4 10.0.0.3 683 0x80000002 0xb680 10.0.0.4/32
10.0.0.4 10.0.0.4 660 0x80000002 0x4cf3 10.0.0.4/32
10.0.0.5 10.0.0.3 623 0x80000002 0xac89 10.0.0.5/32
10.0.0.5 10.0.0.4 670 0x80000002 0x0b20 10.0.0.5/32
10.0.0.6 10.0.0.3 663 0x80000002 0x0724 10.0.0.6/32
10.0.0.6 10.0.0.4 620 0x80000002 0x9c97 10.0.0.6/32
192.168.0.1 10.0.0.4 341 0x80000001 0x06ca 192.168.0.1/32
The OSPF database on A2 nonetheless comprises the abstract LSAs created by A1 earlier than the world partitioning. These LSAs are not used as a result of there’s no technique to attain A1 by way of space 1. They are going to disappear solely after their age exceeds the MaxAge (1 hour, specified within the RFC, not negotiable).
There isn’t any technique to flush these LSAs from the OSPF database. Resetting the OSPF course of on A2 will take away them, however they’ll reappear as quickly because the A2-S2 adjacency is reestablished and S2 tells A2 it has a couple of fascinating LSAs to share (extra scary particulars).
Reproducing the Outcomes
I used the following netlab topology when penning this weblog submit. You can begin it (instantly and free-of-charge) in a GitHub Codespace container – change the listing throughout the Codespace container to OSPF/area-range and execute netlab up. Have enjoyable.
module: [ ospf ]supplier: clabdefaults.machine: frraddressing.p2p.ipv4: Truenodes:s1:ospf.space: 1loopback.ipv4: 192.168.0.1/32s2:ospf.space: 1loopback.ipv4: 192.168.0.2/32a1:ospf.space: 0a2:ospf.space: 0r2:ospf.space: 2r3:ospf.space: 3hyperlinks:- group: spineospf.space: 0members: [ a1-a2 ]- group: area_1ospf.space: 1members: [ s1-a1, s2-a2, s1-s2 ]- group: area_2ospf.space: 2members: [ r2-a1 ]- group: area_3ospf.space: 3members: [ r3-a2 ]
Notes:
- I set the loopback addresses on S1 and S2 to fastened values to make them stand out within the routing tables (strains 9 and 12)
- The OSPF space of a node’s loopback interface must be specified within the node knowledge (strains 8, 11, 14, 16, 18, and 20). The default OSPF space is zero (spine), however I nonetheless specified it on A1 and A2 to make it extra evident.
- If the hooked up nodes have totally different OSPF areas, the hyperlink’s OSPF space might need to be specified (strains 27, 30, and 33).
- I used hyperlink teams to set the identical ospf.space on a number of hyperlinks. The group names additionally properly describe what the hyperlinks do.
