Topology_OSPF_Stubs

After coming back from a weekend of being sick, I’m going to perform what has already been covered in previous posts so I may not go crazy with output from configs, however I do want to document any road blocks I struggle with or unexpected network behaviors. I did some reading of my original notes over the weekend while sick, which was cool to study from my own materials, and am going to set up the following at the very least:

  • Add loopbacks 101 – 107 on R1 for subnets 100.1.0.0 16 – 100.7.0.0 /16 (100.
  • Will ‘redistribute connected subnets’ to get some external routes going to Stub ūüôā
  • Add loopbacks for networks 172.16.8.0 /24 – 172.16.11.0 /24 on R1, and make it a summary route with the ‘area-range’ command I believe
  • Make Area 34 a Total Stub, showing the before and after output of the route table
  • Make are 15 an NSSA Total Stub, also showing route table changes as I go
  • Change the metric from Type 2 to Type 1 when Redistributing

I think this will at least set me up so I can play with Authentication, and how it works between areas and across the WAN connections, as well as some LSA type review given the Stub / Total Stub / NSSA area’s and what type of LSA’s they are letting in.

So let’s get to it. I added my 100.x.x.x loopbacks, and just went right into the changing the Metric type, as it is done on the ASBR (router doing redistribution) and my first priority is getting external routes out there, HOWEVER I WANT THEM TO HAVE THEIR TRUE METRIC AND NOT THE DEFAULT SEED METRIC OF ROUTES REDISTRIBUTED INTO OSPF OF 20:

On R1 in router config mode: “R1(config-router)#redistribute connected subnets metric-type 1”

And here is what R2 shows in its route table (R2 is never stubbed so its always pure OSPF):

R2#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:18:41, Serial0/0
100.0.0.0/16 is subnetted, 7 subnets
O E1    100.4.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.5.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.6.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.7.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.1.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.2.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
O E1    100.3.0.0 [110/84] via 172.12.123.1, 00:18:41, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:18:41, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/66] via 172.12.123.3, 00:18:41, Serial0/0
5.0.0.0/32 is subnetted, 1 subnets
O IA    5.5.5.5 [110/66] via 172.12.123.1, 00:18:41, Serial0/0
172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:18:41, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:18:42, Serial0/0
172.16.0.0/24 is subnetted, 4 subnets
O E1    172.16.8.0 [110/84] via 172.12.123.1, 00:09:52, Serial0/0
O E1    172.16.9.0 [110/84] via 172.12.123.1, 00:09:37, Serial0/0
O E1    172.16.10.0 [110/84] via 172.12.123.1, 00:09:11, Serial0/0
O E1    172.16.11.0 [110/84] via 172.12.123.1, 00:08:55, Serial0/0
R2#

So we definitely have our redistributed routes, along with Inter-Area (O IA), however I actually didn’t notice we don’t have any Intra-Area (O) routes in the route table.

So I am going to call an audible as these as both external routes are directly connected to R1 so they redistributed by default, I am going to try to summarize both of them using the two different methods:

“R1(config-router)#area 80 range 172.16.8.0 255.255.252.0”

And on R2 we now see:

R2#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:25:50, Serial0/0
100.0.0.0/16 is subnetted, 7 subnets
O E1    100.4.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.5.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.6.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.7.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.1.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.2.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
O E1    100.3.0.0 [110/84] via 172.12.123.1, 00:00:10, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:25:50, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/66] via 172.12.123.3, 00:25:50, Serial0/0
5.0.0.0/32 is subnetted, 1 subnets
O IA    5.5.5.5 [110/66] via 172.12.123.1, 00:25:50, Serial0/0
172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:25:50, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:25:51, Serial0/0
   172.16.0.0/22 is subnetted, 1 subnets
O IA    172.16.8.0 [110/65] via 172.12.123.1, 00:00:16, Serial0/0
R2#

I know you are wondering, wasn’t that just a bunch of external routes, that are now OSPF inter-Area routes? What’s the deal with that? Am I losing my mind and seeing things???

No. I had to add the 172.x.x.x networks to OSPF via the network command in router config mode for the first type of summarization to work, using the “area xx range …” command.

Now I am going to see if I can summarize these redistributed nets to make the route table easier to look at:

“R1(config-router)#summary-address 100.0.0.0 255.248.0.0”

Aaaaaaand back to R2, keep in mind this is only redistribution and summarization at this point in my network configuration:

R2#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:33:49, Serial0/0
   100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:00:16, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:33:49, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/66] via 172.12.123.3, 00:33:49, Serial0/0
5.0.0.0/32 is subnetted, 1 subnets
O IA    5.5.5.5 [110/66] via 172.12.123.1, 00:33:49, Serial0/0
172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:33:49, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:33:49, Serial0/0
172.16.0.0/22 is subnetted, 1 subnets
O IA    172.16.8.0 [110/65] via 172.12.123.1, 00:08:14, Serial0/0

And there it is, they are still redistributed connected routes, I did not add any 100.x.x.x networks to R1’s OSPF database via network commands. This brings up the very test worthy difference in OSPF summarization, that summarizing using the range command the routes must be entered into the OSPF DB but for the summary-address command it impacts ALL redistributed routes on the router AND CAN ONLY BE ISSUED ON AN ASBR AS IT DOES ONLY IMPACT REDISTRIBUTED ROUTES!

To further drive home summarization differences, in EIGRP you would summarize the route on the interface you want it broadcasted out, whereas OSPF summarization happens in router config mode no matter which way you enter it (be area range or summary-address) and this is very important to distinguish and remember!

Ok, enough bold text, back to business. I jumped around to R5 and R4 to look at their route tables, because both are both non-backbone routers connected by a Virtual-Link as previously configured, and they show the same summarized routes all around.

Now I know the drill with stub networks in OSPF, and the commands are going to decimate the route table to about nothing my total stub, but my NSSA Total Stub for some reason allowed summary routes in last time and I’m not quite sure why. Couple of things:

  • To make a stub area, “area xx stub” must be entered on both routers, in this example those routers will be R3 and R4
  • Total Stub areas require adding “no-summary” to the stub command, and it only needs it on the Backbone router
  • Stub area’s cannot contain Virtual-Links, as R3 reminded me here:

R3(config-router)#area 34 stub
% OSPF: Area cannot be a stub as it contains a virtual link
R3(config-router)#

So then we remove the Virtual-Link and add the stub command on R3:

R3(config-router)#no area 34 virtual-link 4.4.4.4
R3(config-router)#
*Mar  1 15:27:26.271: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from FULL to DOWN, Neighbor Down: Interface down or detached
R3(config-router)#
R3(config-router)#area 34 stub
R3(config-router)#
*Mar  1 15:28:22.115: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R3(config-router)#

So first we lost the Virtual-Link of course, but then it shows the neighbor going down and resetting the relationship, and it is staying that way:

R3(config-router)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DR         00:01:45    172.12.123.1    Serial0/2
4.4.4.4¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† 1¬†¬† DOWN/DROTHER¬†¬†¬†¬†¬†¬† –¬†¬†¬†¬†¬†¬†¬† 172.12.34.4¬†¬†¬†¬† FastEthernet0/1¬†¬† <- Not Cool

***One odd behavior I wanted to point out before moving on, is when configuring the virtual-link it will freak out with a repeating error until both sides are configured, but when I removed the command from R3 I went over to R4 and saw no repeating error messages flooding the console – Very interesting***

So I go to R4 which is not freaking out about the virtual-link as mentioned above, and issue the command as well to fix this relationship and make some neighbors form:

R4(config-router)#area 34 stub
% OSPF: Area cannot be a stub as it contains a virtual link
R4(config-router)#

And R4 says GTFO until this virtual-link config is removed, so even though the error wasn’t spamming, the configuration was on R4 and must be removed to create the stub. So I will go ahead and do that and see what we have for a route table on R4:

R4(config-router)#no area 34 virtual-link 3.3.3.3
R4(config-router)#area 34 stub
R4(config-router)#
*Dec 20 01:33:28.371: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
R4(config-router)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/BDR        00:00:34    172.12.34.3     FastEthernet0/1
R4(config-router)#do sh ip route ospf
(Route codes redacted)

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.34.3, 00:00:42, FastEthernet0/1
1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/66] via 172.12.34.3, 00:00:42, FastEthernet0/1
2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/66] via 172.12.34.3, 00:00:42, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/2] via 172.12.34.3, 00:00:42, FastEthernet0/1
5.0.0.0/32 is subnetted, 1 subnets
O IA     5.5.5.5 [110/67] via 172.12.34.3, 00:00:42, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA     172.12.15.0/24 [110/66] via 172.12.34.3, 00:00:42, FastEthernet0/1
O IA     172.12.123.0/24 [110/65] via 172.12.34.3, 00:00:42, FastEthernet0/1
172.16.0.0/22 is subnetted, 1 subnets
O IA     172.16.8.0 [110/66] via 172.12.34.3, 00:00:42, FastEthernet0/1
R4(config-router)#

So it came up maybe 1-2 seconds after issuing the stub command, and I see an O*IA route for the Stub Area itself we just configured, and now our Gateway of last resort (default route) is pointing at R3’s connected interface to R4. I will have to review what LSA types are being blocked at this point, the only route I see missing is the E1 (Redistributed) summary route, on top of adding that default route to the area.

Now to add no-summary to R3 and see what happens to R4’s route table:

R3(config-router)#no area 34 stub
*Mar  1 15:48:38.629: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R3(config-router)#area 34 stub no-summary
R3(config-router)#
*Mar  1 15:48:52.965: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from DOWN to DOWN, Neighbor Down: Adjacency forced to reset
R3(config-router)#
*Mar  1 15:48:56.294: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from LOADING to FULL, Loading Done
R3(config-router)#

So the adjacency popped right back up after adding the new stub command, lets see what R4 looks like in terms of routes here:

R4#sh ip route ospf
(Route codes redacted)

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.34.3, 00:01:17, FastEthernet0/1
R4#

Kaboom, this router knows only one thing, and that is all traffic is going to R3’s connected FastEthernet interface. Can we still ping other networks and get a response from them?

R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R4#

We sure can. Speaking of cans, I am going to make Area 15 first an NSSA, then an NSSA Total Stub Area, and show the route table differences every step of the way as my finisher to this post.

Firstly, R5’s OSPF route table as it stands with no Stub or NSSA configs:

R5#sh ip route ospf
(Route codes redacted)

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/2] via 172.12.15.1, 02:41:59, FastEthernet0/1
2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/66] via 172.12.15.1, 02:17:44, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/66] via 172.12.15.1, 00:10:12, FastEthernet0/1
100.0.0.0/13 is subnetted, 1 subnets
O E1     100.0.0.0 [110/21] via 172.12.15.1, 00:53:15, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA     172.12.34.0/24 [110/66] via 172.12.15.1, 00:06:13, FastEthernet0/1
O        172.12.123.0/24 [110/65] via 172.12.15.1, 02:41:59, FastEthernet0/1
172.16.0.0/22 is subnetted, 1 subnets
O IA     172.16.8.0 [110/2] via 172.12.15.1, 01:01:13, FastEthernet0/1
R5#

Looks about right, now I’ll remove the virtual-link and NSSA it:

R5(config-router)#no area 15 virtual-link 1.1.1.1
R5(config-router)#
*Dec 20 02:57:16.643: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on OSPF_VL0 from FULL to DOWN, Neighbor Down: Interface down or detached
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config-router)#
*Mar  1 15:00:44.560: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on OSPF_VL0 from FULL to DOWN, Neighbor Down: Interface down or detached
R1(config-router)#no area 15 virtual-link 5.5.5.5
R1(config-router)#area 15 nssa
R1(config-router)#
*Mar  1 15:01:07.193: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R1(config-router)#
ASR#5
[Resuming connection 5 to r5 … ]

R5(config-router)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:06    172.12.15.1     FastEthernet0/1
R5(config-router)#do sh
*Dec 20 02:58:17.747: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R5(config-router)#do sh ip ospf nei

R5(config-router)#

No neighbors to speak of until I issue the area 15 nssa command on R5, one interesting thing was that the neighbor as DOWN as soon as we switched up the commands, however the OSPF neighbor table showed they were active neighbors until the dead timer expired.

So I then apply the nssa command to R5 and lets see the route table:

R5(config-router)#do sh ip route ospf
(Route codes redacted)

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/2] via 172.12.15.1, 00:00:07, FastEthernet0/1
2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/66] via 172.12.15.1, 00:00:07, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/66] via 172.12.15.1, 00:00:07, FastEthernet0/1
100.0.0.0/13 is subnetted, 1 subnets
O N1     100.0.0.0 [110/21] via 172.12.15.1, 00:00:07, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA     172.12.34.0/24 [110/66] via 172.12.15.1, 00:00:07, FastEthernet0/1
O IA     172.12.123.0/24 [110/65] via 172.12.15.1, 00:00:07, FastEthernet0/1
172.16.0.0/22 is subnetted, 1 subnets
O IA     172.16.8.0 [110/2] via 172.12.15.1, 00:00:07, FastEthernet0/1
R5(config-router)#

If the metric was its default type 2, you would see an N2 route instead of an N1, and if they weren’t summarized it would show all 7 networks as N2’s / N1’s. Now to make it an NSSA Total Stub on R1 to complete the configuration for tonight and look at R5’s route table.

Here is R1 going through the motions of UP and DOWN neighbors while configuring:

R1(config-router)#no area 15 nssa
R1(config-router)#area
*Mar  1 15:10:57.016: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
R1(config-router)#area 15 nssa no-summary
R1(config-router)#
*Mar  1 15:11:14.072: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from EXSTART to DOWN, Neighbor Down: Adjacency forced to reset
R1(config-router)#
*Mar  1 15:11:20.695: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from LOADING to FULL, Loading Done
R1(config-router)#

And now over on R5 the OSPF route table looks a lot like this:

ASR#5
[Resuming connection 5 to r5 … ]

*Dec 20 03:07:57.875: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/1 from LOADING to FULL, Loading Done
R5(config-router)#do sh ip route ospf
(Route codes redacted)

Gateway of last resort is 172.12.15.1 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/2] via 172.12.15.1, 00:01:07, FastEthernet0/1
100.0.0.0/13 is subnetted, 1 subnets
O N1     100.0.0.0 [110/21] via 172.12.15.1, 00:01:07, FastEthernet0/1
R5(config-router)#

I remember last time it baffled me, as it still does, that this router is seeing the summary address of the redistributed routes. I know this is some type of behavior with NSSA Areas, but as of right now I am so brain dead fried from this I will stop here and write mem like a good future CCIE so I can pick up where I left off.

I know this is a repeat of a lot of information on my original post when studying, but I don’t think you can ever pound this material into your head enough, so now that my head has been pounded once again I will take my leave ūüôā

ONE THING TO ADD DAG NAB IT:

When doing wr mem to all the routers, I got to R4 wondering if it would still be able to ping that loopback 5.5.5.5 on R5 our new NSSA Total stub and got this:

R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R4#

Soggy cereal. It isn’t showing that it’s unreachable, but that it doesn’t have a return route (I believe) to R4 on an upstream router. This shall be investigated on my next session!