Loved the lab and the setup, wanted to say this first! If I could offer some suggestions that could help with studying this. Is there a way to have links that go back and forth between what is being asked and the solution? I know probably stupid, however this is long and scrolling to the areas can become tedious.
For my edification on the route summarization section could you not make a prefix list and route map redistribute static and do a null route for the 172.16.x.x subnets on R5? It seems there are many ways to skin that cat. Also, on the area 3 do you need neighbor commands on R9 and R10? When I did mine I did and it worked once removed neighborship dropped. I am using CML if that matters at all.
Thank you, and again great lab. This certainly showed me areas I am weak on and need to get more practice in. What I like to see is seeing how things are implemented at this level.
First of all we are very pleased that the lab was helpful in your learning journey. Your suggestions are always welcome, and we’ll take a look to see if they can be used to improve the lab.
That’s a nice suggestion. I’ll pass it on to @ReneMolenaar to see if something can be done about that.
Indeed, there are several ways to achieve this particular goal, and the approach you suggest is technically valid and functionally equivalent, but there are some important differences in behavior.
The summary-address command requires the component routes to actually exist in the routing table to generate the aggregate. If all three /24 routes fail (i.e., R6 goes down), IOS automatically withdraws the 172.16.8.0/21 summary from OSPF. This is the desired behavior for conditional advertisements.
The null-route alternative has a subtle difference: The manual ip route 172.16.8.0 255.255.248.0 Null0 static route persists regardless of whether R6 is reachable. This means even if R6 becomes unreachable and all three /24 static routes are removed from the table (even if configured with tracked objects or next-hop reachability, which they should be), the null route remains, and the aggregate continues to be advertised into OSPF, creating a black hole for that traffic.
So you see, each approach has distinct characteristics that affect behavior, elegance, and consistency with how OSPF summarization is designed to work. The lab’s official approach (summary-address) is the preferred best practice, but the alternative approach works and is a legitimate engineer’s tool.
In this particular case, we have a point-to-multipoint non-broadcast network type. The neighbor commands are indeed needed. But note this detail: The neighbor command is mandatory only on R3. R9 and R10 don’t need that command (although it is good practice to put it in). This is simply how point-to-multipoint non-broadcast networks work. The router that needs to initiate contact (the hub/ABR, which is the one that knows about the others) configures the neighbors. The spokes learn R3’s address when they receive the unicast Hello sent by R3, and they can then respond. When you removed a neighbor command, did you remove it from R3? If so, then the dropped neighborship is expected behavior.
I removed the neighbor command from R9 and R10 and the adjacency dropped almost immediately. However, maybe I did not wait long enough for the change to take place for everything to clear out and allow neighbors to come back. So it could have been user error. Thank you and good point on the summary route.
Thanks for your response. This seemed like strange behavior to me, so I thought I’d investigate and lab it up.
I created a P2P NB neighbor between two routers, R1, and R2, and used the same config as in the lab. I put the neighbor command only on R1. The adjacency came up. I then put in the neighbor command on R2, and nothing changed. Once I removed the neighbor command from R2, the adjacency did indeed drop. However, as you suspected, after several seconds the adjacency came back up! But note that, from R1’s perspective, the adjacency never dropped. It only appears to drop on the router from which the neighbor command was removed.
It seems that the adjacency does not wait for the full dead interval (80 s) to expire before dropping. It drops essentially immediately because the router proactively removes the neighbor relationship locally when the neighbor statement is deleted from the configuration. This is unlike an interface failure or link-down event, where the dead timer would need to expire.
But it eventually receives a hello packet from the other router, reestablishing the neighbor adjacency. Make sense? That’s an interesting little nuance in its behavior.
Indeed, this does make sense to me. I think I will be running the BGP Pro lab next. I love these things probably far more than I should ha! Its one thing to learn the concepts its another to see it all together running. I like the designs and how it forces me to learn these topics so thank you for the help as always!
