Category Archives: CCNP ROUTE – Deep Dives!

OSPF: Important details regarding Summarization and Default Routes for exam day, it’s a long but worthwhile read!

OSPF_Base_Topology

OSPF Summarization is done only on ABR and ASBR routers in your OSPF domain, and use two completely different commands, but what if a router is an ABR and an ASBR?

For example, did you know that using the command “default-information originate …” you are telling the router to create a Type 5 LSA to be propagated throughout the network, thus turning that router into an ASBR?

Another very interesting fact I did not know – OSPF will not allow you to redistribute a static default route. It cannot be done.

Being that I have never knew either of these things that seem like fairly good questions for exam day, I wanted to give them a run for their money to see if that they are true:

R1(config)#ip route 0.0.0.0 0.0.0.0 null0
R1(config)#router ospf 1
R1(config-router)#redistribute static subnets
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:00:11, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:00:11, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:00:11, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
R2#sh ip ospf data

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         45          0x80000005 0x00DC9D 1
2.2.2.2         2.2.2.2         1013        0x80000004 0x009AD9 1
3.3.3.3         3.3.3.3         132         0x80000005 0x006008 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    1.1.1.1         905         0x80000004 0x0023BE

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         1.1.1.1         1416        0x80000003 0x0043EE
2.2.2.2         2.2.2.2         1013        0x80000003 0x00F633
3.3.3.3         3.3.3.3         321         0x80000001 0x00AE75
172.12.15.0     1.1.1.1         1154        0x80000005 0x0072F9
172.12.23.0     2.2.2.2         696         0x80000001 0x000460
172.12.23.0     3.3.3.3         692         0x80000009 0x00D582

Nothing! I never knew that was a behavior before, so you HAVE to use the default-information originate command to propagate a static route even though it still uses a Type 5 LSA just like redistribution would have!!!

Keep that in mind on exam day, if you see redistribution in ospf of a static default route, that is beyond a red flag.

Now. Back to this about the default-information originate command making a router an ASBR, I don’t really want to assign a default route to the logical trash bin (null0), so I’m just going to add “always” so no static default route is needed:

R1(config)#router ospf 1
R1(config-router)#default-information originate always
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:07:10, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 00:07:10, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:07:10, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:12, Serial0/0

R2#

There we go, now R2 has a default route, and what appears to be an External Type 5 LSA route so I am guessing when I go back to R1:

R1(config-router)#do sh ip ospf
 Routing Process “ospf 1” with ID 1.1.1.1
 Start time: 00:00:18.800, Time elapsed: 01:39:06.588
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 It is an area border and autonomous system boundary router

 Redistributing External Routes from,
 Router is not originating router-LSAs with maximum metric

The interesting thing here is that I’ve never seen any other protocol leave the “Redistributing External Routes from” field empty, and it sure is both an ABR and an ASBR now.

So can I do both types of Summarization now? Lets break some stuff and find out! To be clear on how real this is getting:

R1(config-if)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down
FastEthernet0/1            172.12.15.1     YES NVRAM  up                    up
Serial0/0/0                172.12.123.1    YES NVRAM  up                    up
Serial0/0/1                100.100.100.1   YES NVRAM  administratively down down
Loopback1                  1.1.1.1         YES NVRAM  up                    up
Loopback8                  172.16.8.1      YES manual up                    up

Loopback9                  172.16.9.1      YES manual up                    up

Loopback10                 172.16.10.1     YES manual up                    up

Loopback11                 172.16.11.1     YES manual up                    up

Loopback101                100.1.0.1       YES manual up                    up

Loopback102                100.2.0.1       YES manual up                    up

Loopback103                100.3.0.1       YES manual up                    up

Loopback104                100.4.0.1       YES manual up                    up

Loopback105                100.5.0.1       YES manual up                    up

Loopback106                100.6.0.1       YES manual up                    up

Loopback107                100.7.0.1       YES manual up                    up

Summary Address = 172.16.8.0 /22
Summary Address = 100.0.0.0  /13

Now for the ABR, the routes need to be put in via the “network” command, being that you are specifying the Area containing the routes, so they need to be entered into OSPF in the same Area.

I was actually just cursing looking at that for some reason thinking the Loopback # dictated the Area # or something, but I got it now lets give it a go here:

R1(config-if)#router ospf 1
R1(config-router)#network 100.1.0.0 0.0.255.255 area 100
R1(config-router)#network 100.2.0.0 0.0.255.255 area 100
R1(config-router)#network 100.3.0.0 0.0.255.255 area 100
R1(config-router)#network 100.4.0.0 0.0.255.255 area 100
R1(config-router)#network 100.5.0.0 0.0.255.255 area 100
R1(config-router)#network 100.6.0.0 0.0.255.255 area 100
R1(config-router)#network 100.7.0.0 0.0.255.255 area 100
R1(config-router)#area 100 range 100.0.0.0 255.248.0.0 ?
  advertise      Advertise this range (default)
  cost           User specified metric for this range
  not-advertise  DoNotAdvertise this range
  <cr>

R1(config-router)#area 100 range 100.0.0.0 255.248.0.0
R1(config-router)#

Cost can be defined as a modifier to the command as highlighted in red there, otherwise OSPF will use the best Prefix’s Cost value for the Summary Route which I think should be left alone unless you have a reason to change it.

So lets take a look at R2’s OSPF route table to verify we have one type of summarization at work:

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:43:36, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:16:54, 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:43:36, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:43:36, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:16:49, Serial0/0
R2#sh ip ospf data

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         750         0x80000006 0x00DA9E 1
2.2.2.2         2.2.2.2         1590        0x80000005 0x0098DA 1
3.3.3.3         3.3.3.3         920         0x80000006 0x005E09 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    1.1.1.1         1487        0x80000005 0x0021BF

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         1.1.1.1         1971        0x80000004 0x0041EF
2.2.2.2         2.2.2.2         1590        0x80000004 0x00F434
3.3.3.3         3.3.3.3         920         0x80000002 0x00AC76
100.0.0.0       1.1.1.1         1028        0x80000001 0x00409A
172.12.15.0     1.1.1.1         1730        0x80000006 0x0070FA
172.12.23.0     2.2.2.2         1347        0x80000002 0x000261
172.12.23.0     3.3.3.3         1421        0x8000000A 0x00D383

So it is being advertised as an Inter-Area (Type 3 LSA) route as can be seen both in the IP route table, as it should because this is the ABR way to summarize routes. Ahem.

Also if you want to get granular with how you look at the LSA Database, to see this summary route for example, you can type in as follows:

R2#sh ip ospf data summ 100.0.0.0

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1347
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 100.0.0.0 (summary Network Number)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x409A
  Length: 28
  Network Mask: /13

        TOS: 0  Metric: 1

This command will give you a ton of output, like the Database itself, except with details which makes it incredibly hard to dig through if you have a decent amount of Areas it is reporting all these details before.

However, I did want you to see, you can verify if a route is a Summary from the LSA Database – And that is a good thing to know. You can also look at sections of it with “sh ip ospf data summ” and so on but I won’t flood the page with all that output.

So all this ABR Summarization is all fine and good you say, but what about ASBR Summarization? I am glad you asked.

I am not sure if it requires the networks to be entered via the “network” command, so I’ll test out whether they need to be added, lets take a look:

R1(config-router)#summary-address 172.16.8.0 255.255.252.0
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

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:55:55, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:29:13, 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:55:55, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:55:55, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:29:08, Serial0/0
R2#

Well that stinks. Let me add the routes via “network” on R1 and try that again:

R1(config-router)#
R1(config-router)#network 172.16.8.0 0.0.0.255 area 51
R1(config-router)#network 172.16.9.0 0.0.0.255 area 51
R1(config-router)#network 172.16.10.0 0.0.0.255 area 51
R1(config-router)#network 172.16.11.0 0.0.0.255 area 51
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

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:58:21, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:31:40, 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:58:21, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:58:21, Serial0/0
     172.16.0.0/32 is subnetted, 4 subnets
O IA    172.16.9.1 [110/65] via 172.12.123.1, 00:00:11, Serial0/0

O IA    172.16.8.1 [110/65] via 172.12.123.1, 00:00:21, Serial0/0

O IA    172.16.11.1 [110/65] via 172.12.123.1, 00:00:01, Serial0/0

O IA    172.16.10.1 [110/65] via 172.12.123.1, 00:00:11, Serial0/0

O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:06, Serial0/0
R2#

Now things are getting interesting, because if I remove the summarization R1 is doing as an ABR, will the summarization command as an ASBR kick into action? Lets see:

R1(config-router)#no area 100 range 100.0.0.0 255.248.0.0
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

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, 01:01:04, Serial0/0
     100.0.0.0/32 is subnetted, 7 subnets
O IA    100.5.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.4.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.7.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.6.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.1.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.3.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

O IA    100.2.0.1 [110/65] via 172.12.123.1, 00:00:12, Serial0/0

     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 01:01:04, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 01:01:04, Serial0/0
     172.16.0.0/32 is subnetted, 4 subnets
O IA    172.16.9.1 [110/65] via 172.12.123.1, 00:02:54, Serial0/0

O IA    172.16.8.1 [110/65] via 172.12.123.1, 00:03:04, Serial0/0

O IA    172.16.11.1 [110/65] via 172.12.123.1, 00:02:45, Serial0/0

O IA    172.16.10.1 [110/65] via 172.12.123.1, 00:02:55, Serial0/0

O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:00:08, Serial0/0
R2#

No it did not, so I am wondering if perhaps order of commands comes into play here, as I configured the summary-address of routes that weren’t in the OSPF config yet.

So after a lot of failure with trying to redistribute an actual static route to make it an official “ASBR”, remove and re-add commands, I caved and watched the Summarization portion of my training video for summary address and I’ll be damned if this can’t ONLY be done by the ASBR because you redistribute the friggin connected routes! Gah!

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#no network 172.16.8.0 0.0.0.255 area 51
R1(config-router)#no network 172.16.9.0 0.0.0.255 area 51
R1(config-router)#no network 172.16.10.0 0.0.0.255 area 51
R1(config-router)#no network 172.16.11.0 0.0.0.255 area 51
R1(config-router)#redistribute connected subnets
R1(config-router)#area 100 range 100.0.0.0 255.248.0.0
R1(config-router)#summary-address 172.16.8.0 255.255.252.0
R1(config-router)#

Now for the moment of truth (I removed 172.x routes from 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, 01:31:24, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:01:19, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 01:31:24, Serial0/0
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 01:31:24, Serial0/0
     172.16.0.0/22 is subnetted, 1 subnets
O E2    172.16.8.0 [110/20] via 172.12.123.1, 00:01:14, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:01:14, Serial0/0
R2#

FINALLY!! So that is why summary-address can only be done on the ASBR, because you need to redistribute the sequential routes to be summarized before entering the command to summarize them!

Also we now know that we can issue both commands on R1 as an ABR, and an ASBR with no problems.

HOWEVER WE ARE NOT DONE YET, AS WE HAVEN’T GONE INTO THE SECOND WAY OSPF CAN CREATE A STATIC ROUTE – AND THIS TIME IT AIN’T A TYPE 5 LSA!

The other way is to make an Area a Stub Area. By doing this, the Stub creates a default route for itself out of the network, does not allow LSA Type 5’s into the Area at all actually, so the default route created in this case is a Summary Type 3 LSA.

Lets look at Area 34 quick to wrap this one up:

R3(config-router)#area 34 stub
R3(config-router)#
ASR#4
[Resuming connection 4 to r4 … ]

R4#
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#area 34 stub

That is all there is to the stub command, and the default route can be seen here, but there is still a LOT of clutter from Inter-Area routes:

R4(config-router)#do sh ip route ospf

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:15, 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:15, 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:15, 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:15, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
O IA     100.0.0.0 [110/66] via 172.12.34.3, 00:00:15, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
O IA     172.12.15.0/24 [110/66] via 172.12.34.3, 00:00:15, FastEthernet0/1
O IA     172.12.23.0/24 [110/2] via 172.12.34.3, 00:00:15, FastEthernet0/1
O IA     172.12.123.0/24 [110/65] via 172.12.34.3, 00:00:15, FastEthernet0/1
R4(config-router)#

In the LSDB under the Area 34 Summary Header we can see the route there as well:

 Summary Net Link States (Area 34)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         3.3.3.3         320         0x80000001 0x0057DA

1.1.1.1         3.3.3.3         320         0x80000001 0x00AB42
2.2.2.2         3.3.3.3         320         0x80000001 0x007D6C
3.3.3.3         3.3.3.3         320         0x80000001 0x00CC59
100.0.0.0       3.3.3.3         320         0x80000001 0x00A4EF
172.12.15.0     3.3.3.3         320         0x80000001 0x00DE4B
172.12.23.0     3.3.3.3         320         0x80000001 0x00045E
172.12.123.0    3.3.3.3         320         0x80000001 0x002C92

Now the thing that kind of amazes me, is the only verification command I could find outside of “show run” to verify this router is a stub router, was to do “sh ip ospf” and scroll all the way down under the Area 34 Header to find it:

Area 34
        Number of interfaces in this area is 1
        It is a stub area
        Area has no authentication
        SPF algorithm last executed 00:09:14.524 ago
        SPF algorithm executed 4 times
        Area ranges are
        Number of LSA 11. Checksum Sum 0x0528C8
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

So to finish this off, lets make it a total stub, and get rid of those Inter-Area routes all together:

R3(config-router)#no area 34 stub
R3(config-router)#area 34 stub no-summary
R3(config-router)#
ASR#4
[Resuming connection 4 to r4 … ]

*May 19 00:03:42.155: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done

R4#sh ip route ospf

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:12:49, FastEthernet0/1
R4#

So lets see if waaaay across the Topology R5 can still ping 4.4.4.4:

R5#ping 4.4.4.4

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

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.15.1 0 msec 0 msec 4 msec
  2 172.12.15.1 !H  *  !H
R5#

That was interesting traceroute traffic, upon looking at R1, it does have the network 172.12.34.0 in its Summary Type 3 LSA’s, but no Area 34 or Area 4 at all in its LSDB. However I know what’s going on here, as 4.4.4.4 belong to Area 4 which to Area 34 would be blocked as an Inter-Area route, so if we do this:

R4(config)#router ospf 1
R4(config-router)#no network 4.4.4.4 0.0.0.0 area 4
R4(config-router)#network 4.4.4.4 0.0.0.0 area 34
R4(config-router)#

Then we should now be able to do this:

R5#ping 4.4.4.4

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

There we go, logical thinking isn’t always easy, but it does usually work.

I have one very last thing to add to this and I am done on this topic, seriously.

It has to do with the default-information originate command, because you can actually set it to track a certain route, and if that route goes down OSPF “Poisons” the default route and removes it from route tables / LSDB’s.

Lets take a look at the configuration:

R1#conf t
R1(config)#int lo99
R1(config-if)#ip add 99.99.99.99 255.255.255.255
R1(config)#access-list 99 permit 99.99.99.99
R1(config)#route-map 99bananas permit 10
R1(config-route-map)#match ip add 99
R1(config-route-map)#route-map 99bananas permit 20
R1(config-route-map)#exit
R1(config)#router ospf 1
R1(config-router)#default-information originate always route-map 99bananas

R1(config-router)#

Adding this route-map to it will “track” that route, so if that route or interface goes bye bye, so does our default route! Lets see this in action:

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 02:13:02, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O IA    100.0.0.0 [110/65] via 172.12.123.1, 00:42:57, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/65] via 172.12.123.3, 02:13:02, 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:09:41, Serial0/0
     99.0.0.0/32 is subnetted, 1 subnets
O E2    99.99.99.99 [110/20] via 172.12.123.1, 00:05:35, Serial0/0

     172.12.0.0/24 is subnetted, 4 subnets
O IA    172.12.34.0 [110/65] via 172.12.123.3, 00:18:17, Serial0/0
O IA    172.12.15.0 [110/65] via 172.12.123.1, 02:13:06, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     172.16.0.0/22 is subnetted, 1 subnets
O E2    172.16.8.0 [110/20] via 172.12.123.1, 00:09:38, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 172.12.123.1, 00:01:02, Serial0/0

R2#

Now lets remove the loopback and see the havoc it wreaks:

R1(config)#no int lo99
R1(config)#
*May 19 01:32:13.539: %LINK-5-CHANGED: Interface Loopback99, changed state to administratively down
*May 19 01:32:14.539: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback99, changed state to down
R1(config)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route

Gateway of last resort is not set

So that is something excellent to know for exam day and the real world, that your default routes can have dependencies or be conditional upon other routes being available.

Pretty cool stuff. Ok this post has gone on way too long, that its for these topics!

A collection of IMPORTANT links to review and know for exam day, then a quick overview of LSA Types / OSPF Router Types!

(This post will be replacing the subnetting post in my sticky threads up top the blog)

I pulled this topology from my older posts when I took a deep dive into the world of LSA’s, how to read the Topology table like a laundry list and under stand it, and what type of routers did what.

First I want to list links that are absolutely vital to read and understand for exam day, as you will run into questions regarding these in some fashion or another, and then I will sticky this post up top so the links are available there as well:

LSA Part 1 – https://loopedback.com/2017/04/24/part-1-ospf-lsa-deep-dive-starting-with-lsa-types-1-2-3-and-an-intro-to-all-lsa-types-and-ospf-routers-types/

LSA Part 2 – https://loopedback.com/2017/04/25/part-2-ospf-lsa-deep-dive-lsa-types-4-5-and-turn-area-15-to-an-nssa-to-see-what-happens-with-the-ls-database/

LSA Part 3 – https://loopedback.com/2017/04/25/part-3-ospf-lsa-deep-dive-lsa-type-7-deep-dive-into-every-type-of-ospf-stub-area-and-how-it-impacts-lsas/

VPN types and Tunnel Modes – https://loopedback.com/2017/04/28/vpn-deep-dive-into-different-vpn-packet-types-differences-in-security-and-differences-in-modes-between-them/

OSPF Distribute-List vs Filter-List – https://loopedback.com/2017/04/27/ospf-deep-dive-distribute-list-vs-filter-list-in-and-reviewing-prefix-lists-as-they-filter-lists-use-prefixes-to-filter/

Quick methods to Subnet – https://loopedback.com/2017/05/09/important-subnetting-review-to-quickly-find-network-address-ranges-and-a-great-cheat-sheet-for-exam-day/

IPv6 Migration Strategies – https://loopedback.com/2017/03/11/ipv6-migration-strategies-from-ipv4-networks-need-to-know-details-for-exam-day-explained/comment-page-1/#comment-56

Identifying IPv6 Address Types – https://loopedback.com/2017/05/08/ipv6-quick-tips-on-some-good-to-knows-and-need-to-knows-for-ipv6-on-exam-day-may-be-adding-info-to-this-in-the-future/

EIGRP Distribute-List / Prefix-List configuration – https://loopedback.com/2017/05/10/eigrp-deep-dive-into-prefix-list-configurations-access-list-vs-prefix-list-using-prefix-lists-to-filter-eigrp-routes-with-distribute-lists/

I could keep adding posts to that list all day, as they are pretty important, but you need to have a solid understanding of VPN Types and Tunnel Modes (and what they do), LSA Types and Database understanding, the IPv6 material and knowing how to configure and apply Prefix-Lists, etc. I’d say read all my posts, but I wrote them and my mind still slips on the materials!

Now I pulled this explanation of the LSA types from an older post where I summarized them using the Topology above, so I will paste these into this post, and sticky this thread up top for visibility and move on to the next topic for review!

So first, I will start with a description of each LSA type of the 7 of them:

  • LSA Type 1 “Router” – “Router Link States” will be its header in the LSA DB, and the name is self explanatory, these LSA’s are generated by each router with updates on its local Link States, all router types generate and flood this LSA Type.
  • LSA Type 2 “Network” – “Net Link States” are only generated and sent by DR’s and BDR’s to routers in the Same Area, that are also on the same multi-access network type, LSA type stays within its own Area, only seen in NON-Point-to-Point network types
  • LSA Type 3 “Summary” – “Summary Net Link States” has nothing to do with summarization, but floods its summary of networks from one Area into others except for the Area it is part of – Not flooded into Total-Stub’d Areas (Stub or NSSA)
  • LSA Type 4 “Summary ASB” – “Summary ASB Link States” LSA type is only created by ABR’s back to the ASBR, so when redistribution is configured on the ASBR Router it flips a bit in its “Router LSA” (Type 1!), and the ABR(s) then create LSA type 4’s to pass along throughout the network giving OSPF neighbors the path back to the ASBR – Not flooded into Stub Areas.
  • LSA Type 5 “Autonomous System External Link State” – or “AS External Link States” in the OSPF LSA DB, these are your “O E1” and “O E2”  Redistributed routes, generated from the ASBR itself OUTSIDE an NSSA Area – Not flooded into Stub Areas.
  • LSA Type 6 – Not needed for the CCNP ROUTE, but it is for Multicast Extensions of OSPF (MOSPF), but again is not referenced in the the ROUTE exam, just wanted to mention for the sake of thoroughness
  • LSA Type 7 “NSSA LSA’s” – This type of LSA is generated by the ASBR INSIDE an NSSA Area does Redistribution, as Type 5 Redistribution LSA’s cannot enter an NSSA Area

Phew. So to cover what type of routers create which type of LSA’s ONE MORE TIME:

  • Type 1 – All Routers
  • Type 2 – All DR’s
  • Type 3, 4 – All ABR’s
  • Type 5 – ASBR’s OUTSIDE the NSSA Areas (NSSA’s don’t allow LSA type 5)
  • Type 6 – Reserved for MOSPF
  • Type 7 – ASBR’s INSIDE the NSSA Areas (Type 7 LSA’s [N1, N2 in route table])

 

If you don’t fully understand LSA’s, please review Part 1, 2, and 3 of the OSPF LSA posts linked above as this is crucial to exam success if you get some OSPF questions!

EIGRP: DEEP Dive into Route Filtering with Distribute-Lists using ACL’s – Important notes on using Extended ACL’s for exam day!

EIGRP_New_Topology

Only the NBMA and Ethernet segments will be used for quick demonstrations and clarity, unless R4 or R5 is needed for demonstration.

The first mechanism specifically for EIGRP to filter EIGRP learned routes is by distribute lists, which have a similar syntax structure and function in ways as an offset-list, in the ways that:

  • It requires an ACL, Prefix-List, or Route-Map to be referenced by the distribute-list
  • The distribute-list is configured in EIGRP router configuration mode
  • It is configured with “in” and “out” options for directional route filtering
  • An interface is a optional on distribute-list’s just like with offset-lists
  • Can use both Extended and Standard ACL’s as demonstrated below

Now with OSPF the directional options are a bit tricky, however with EIGRP distribute-list’s it is either filtering “in”coming routing updates before placing them in the routing table, or filtering “out”going routing updates.

Also as mentioned and bears repeating, you can specify an interface in the distribute-list command, if no interface is specified it is applied to routes coming in or going out any interface.

When using an Access-List to be called out in the distribute-list, Permit statements allow routes to be accepted / sent out, and Deny statements block routes from being accepted or sent out from the specified ACL.

***Random piece of information from lesson, each line of an ACL is called an ACE (Access Control Entry), I did not know that before so thought it should be mentioned***

Here is a demonstration of how to configure a distribute-list using an ACL:

R1#sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0/0
P 172.12.15.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 172.12.23.0/24, 2 successors, FD is 2173416
        via 172.12.123.2 (2173416/29160), Serial0/0/0
        via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
        via 172.12.123.2 (2297856/128256), Serial0/0/0
        via 172.12.123.3 (2300416/156160), Serial0/0/0
P 3.3.3.3/32, 1 successors, FD is 2297856

        via 172.12.123.3 (2297856/128256), Serial0/0/0

        via 172.12.123.2 (2300416/156160), Serial0/0/0

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 3 deny 3.3.3.3
R1(config)#access-list 3 permit any
R1(config)#router eigrp 100
R1(config-router)#distribute-list 3 in
R1(config-router)#
*May 11 02:03:58.759: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is resync: route configuration changed
*May 11 02:03:58.759: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is resync: route configuration changed
R1(config-router)#do sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0/0
P 172.12.15.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 172.12.23.0/24, 2 successors, FD is 2173416
        via 172.12.123.2 (2173416/29160), Serial0/0/0
        via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
        via 172.12.123.2 (2297856/128256), Serial0/0/0
        via 172.12.123.3 (2300416/156160), Serial0/0/0

R1(config-router)#

Now route 3.3.3.3 is being filtered, and as you will notice like an offset-list, it resets your adjacencies with your EIGRP neighbors, so it’s pretty straight forward.

To verify if any filtering is being done by EIGRP on your local router, use the command “sh ip proto” and it will display in the output:

R1(config-router)#do sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 100”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is 3

  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  Redistributing: eigrp 100
  EIGRP-IPv4 Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 1.1.1.1

Now if we want to filter outbound, it works the same way:

R1(config-router)#int lo11
R1(config-if)#ip add
*May 11 02:20:03.731: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback11, changed state to up
R1(config-if)#ip add 11.11.11.11 255.255.255.255
R1(config-if)#exit
R1(config)#access-list 11 deny 11.11.11.11
R1(config)#access-list 11 permit any
R1(config)#router eigrp 100
R1(config-router)#network 11.11.11.11 0.0.0.0
R1(config-router)#distribute-list 11 out
R1(config-router)#
*May 11 02:21:37.599: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is resync: route configuration changed
*May 11 02:21:37.599: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is resync: route configuration changed

And to verify:

R1(config-router)#do sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 11.11.11.11/32, 1 successors, FD is 128256
        via Connected, Loopback11
P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0/0
P 172.12.15.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 172.12.23.0/24, 2 successors, FD is 2173416
        via 172.12.123.2 (2173416/29160), Serial0/0/0
        via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
        via 172.12.123.2 (2297856/128256), Serial0/0/0
        via 172.12.123.3 (2300416/156160), Serial0/0/0

R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip eigrp top
IP-EIGRP Topology Table for AS(100)/ID(2.2.2.2)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 3.3.3.3/32, 1 successors, FD is 156160
        via 172.12.23.3 (156160/128256), FastEthernet0/0
P 2.2.2.2/32, 1 successors, FD is 128256
        via Connected, Loopback2
P 172.12.15.0/24, 1 successors, FD is 2172416
        via 172.12.123.1 (2172416/28160), Serial0/0
P 172.12.23.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0
R2#

No 11.11.11.11/32 route being Advertised by R1, however what if we want to add more than one distribute list to EIGRP? That is a good question to lab:

R1(config-router)#exit
R1(config)#access-list 2 deny 2.2.2.2
R1(config)#access-list 2 permit any
R1(config)#router eigrp 100
R1(config-router)#distribute-list 2 in
R1(config-router)#
*May 11 02:28:35.003: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is resync: route configuration changed
*May 11 02:28:35.003: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is resync: route configuration changed
R1(config-router)#do sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 100”
  Outgoing update filter list for all interfaces is 11
  Incoming update filter list for all interfaces is 2

So as demonstrated here, you can have multiple ACE’s to filter routes in a single ACL, however you cannot use multiple distribute-list’s on a given direction, I’ll spare the output but route 3.3.3.3/32 is once again in the Topology table and 2.2.2.2/32 is gone.

***Another random but important note, the command “show ip eigrp top all-links” will show all learned EIGRP routes, specifically including the ones that do NOT meet the Feasibility condition to become a Feasible Successor in the Topology table***

The feasibility condition states if a routes Reported Distance is greater than the Successor routes Feasible Distance, it is not put into the Topology table, but it is still learned and can be seen using the “sh ip eigrp top all-links” command.

Another good note more geared for TSHOOT but could show up on ROUTE, if a route you are expecting to be in the Topology table is not there and the “… all-links” command does show it was learned, it may have a Bandwidth or Delay configuration on the interface that needs to be removed that is altering the Metric.

So if you are expecting a route, or are just asked how you see all routes in the Topology table, use “all-links” in the show command.

NOW, FOR AN IMPORTANT LOOK AT HOW EXTENDED ACCESS-LISTS WORK WITH EIGRP DISTRIBUTE-LISTS, VERY IMPORTANT BEHAVIOR TO UNDERSTAND!

If using an Extended ACL rather than a standard to just block any incoming or outgoing routes, you can use an extended ACL not to filter by a source its coming from and a destination its going to, but to filter routes only from a particular source.

This is done by actually reversing how the router looks at the ACL, how it normally views it by source and destination, the “source” portion will identify the router advertising the route and the “destination” portion will define the route being advertised.

So for example, I only want to know about the Ethernet segment 172.12.23.0/24 from R3, and I only want to know of 3.3.3.3/32 from R2. Lets step through this, starting with verification that we can see all routes initially on R1:

R1

R1(config)#do sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 11.11.11.11/32, 1 successors, FD is 128256
        via Connected, Loopback11
P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0/0
P 172.12.15.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 172.12.23.0/24, 2 successors, FD is 2173416
        via 172.12.123.2 (2173416/29160), Serial0/0/0
        via 172.12.123.3 (2173416/29160), Serial0/0/0
P 2.2.2.2/32, 1 successors, FD is 2297856
        via 172.12.123.2 (2297856/128256), Serial0/0/0
        via 172.12.123.3 (2300416/156160), Serial0/0/0
P 3.3.3.3/32, 1 successors, FD is 2297856
        via 172.12.123.3 (2297856/128256), Serial0/0/0
        via 172.12.123.2 (2300416/156160), Serial0/0/0

R1(config)#

We have selected our routes to be filtered in red. Now lets right an Extended ACL where the source defines the router advertising the route, and the destination defining the route being advertised:

R1(config)#access-list 123 deny ip host 172.12.123.2 172.12.23.0 0.0.0.255
R1(config)#access-list 123 deny ip host 172.12.123.3 host 3.3.3.3
R1(config)#access-list 123 permit ip any any
R1(config)#router eigrp 100
R1(config-router)#distribute-list 123 in
R1(config-router)#
*May 11 03:10:57.967: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is resync: route configuration changed
*May 11 03:10:57.967: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is resync: route configuration changed
R1(config-router)#

So we should now see our path to the network 3.3.3.3/32 is through 172.12.123.2, and that our Ethernet segment 172.12.23.0/24 is only available via R3 (hopefully):

R1(config-router)#do sh ip eigrp top
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
       r – reply Status, s – sia Status

P 11.11.11.11/32, 1 successors, FD is 128256
        via Connected, Loopback11
P 172.12.123.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0/0
P 172.12.15.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet0/1
P 172.12.23.0/24, 1 successors, FD is 2173416

        via 172.12.123.3 (2173416/29160), Serial0/0/0

P 2.2.2.2/32, 1 successors, FD is 2297856
        via 172.12.123.2 (2297856/128256), Serial0/0/0
        via 172.12.123.3 (2300416/156160), Serial0/0/0
P 3.3.3.3/32, 1 successors, FD is 2297856

        via 172.12.123.2 (2300416/156160), Serial0/0/0

R1(config-router)#

Beautiful, works exactly how it should, you just need to keep in mind for EIGRP ACL Distribute-Lists that the source is the advertising router and the destination is the route to be filtered!

I will stop this here because this about covers all bases for EIGRP Distribute-List / route filtering using Distribute-Lists and Access-Lists, and will make a separate post regarding the use of Prefix-Lists and why we would bother to use them over this method.

Important Subnetting review to quickly find network address, ranges, and a great “cheat sheet” for exam day!

Let me preface this by advising you write some sort of version of this chart on your dry erase board before beginning the exam, so you are not scrambling to remember it while the clock is ticking down during the exam, and if you don’t understand this chart read about it below until you do!

While going through some practice tests, I realized how stagnant my subnetting had become, and the only thing I remember was writing everything out in binary which was a time killer both on the practice exam in definitely will be in the class room.

That being said, I stole the above graphic from Keith Bogart’s CCNA subnetting class (with his express permission), and wanted to post this up not only for my but anyone elses review how to come up with answers fast on exam day for questions regarding different subnets.

You may be presented with a question like “A carrier provides an IP Subnet of 150.200.100.0/24, and you must make x amount of subnets that provides for the most amount of users”

Given that we already know from CCNA studies, that /24 indicates that the first 3 octets are spoken for, and we can borrow bits from the host bits we are provided to create subnets, and any left over bits are our available host bits (minus 2 for network and broadcast address of course).

“From the right rearmost we discover our hosts”

This is a way of saying that we can start at a /32, and find how many bits we have entirely, then apply the formulas -2 for subnet / broadcast address as such:

/32 = 0 bits available
/31 = 2 bits available
/30 = 4 bits available
/29 = 8 bits available
/28 = 16 bits available
/27 = 32 bits available
/26 = 64 bits available
/25 = 128 bits available
/24 = 256 bits available
/23 = 512 bits available
/22 = 1028 bits available
Etc.

Beyond that, I will let you continue to double the number, minus two bits for network / broadcast addresses. So you can count backwards from 32 and get the above values, but again I strongly recommend you write a chart out to reference quickly for subnetting on the dry erase board your provided, even if it’s just a tiny table in the corner of the sheet.

What this information does is given you three things: The number of available hosts, the subnet range of available hosts once you find the network number, and also the available number of subnets.

Number of Available Subnets

As seen in the chart, the subnet bits are counted from where the assigned mask stops, and grows exponentially by the power of two (fancy way of saying they double) as they go further into the “Host Bits” available.

So if we go with our example of 150.200.100.0/24 from our ISP, lets borrow 1 host bit from our 8 host bits available and see the networks we have:

150.200.100.0/25 = 150.200.100.1 – 150.200.100.126 (150.200.100.127 Broadcast)
150.500.100.128/25 = 150.200.100.129 – 150.200.100.254 (150.200.100.255 Broadcast)

Now if we were to borrow two host bits for our subnet mask, we get the following ranges:

150.200.100.0/26 = 150.200.100.1 – 150.200.100.62 (150.200.100.63 Broadcast)
150.200.100.64/26 = 150.200.100.65 – 150.200.100.126 (150.200.100.127 Broadcast)
150.200.100.128/26 = 150.200.100.129 – 150.200.100.190 (150.200.100.191 Broadcast)
150.200.100.192/26 = 150.200.100.193 – 150.200.100.254 (150.200.100.255 Broadcast)

And so on.

Now to find a network range from a single IP address, given the examples above, lets say we are given asked what the range is of 150.200.100.174, we can immediately skip the first 3 octets.

So we skip to the 4th octet, and break the IP address of 174 into binary along with the mask, and perform the boolean “AND” process to find our network number:

/26 (4th octet) = 11000000

.174 IP Addy   = 10

That is actually as far as we need to go, because that is how far the IP matches the subnet mask, so this would be in the 150.200.100.128/26 network.

To explain why this works so quickly and easily, because there is only 4 possible subnets that can come from the /26 mask in respect to the 4th octet in binary:

00000000 = .0
01000000 = .64
10000000 = .128
11000000 = .192

Red being the host bits available for the network (except of course all 0’s and all 1’s for network / broadcast addresses).

However on the CCNP, you are more likely to encounter questions that require quickly identifying host ranges that do not overlap when looking at multiple network, so being able to identify that kind of information quickly is key.

For example, we don’t even need the IP address, if we are asked “X company requires at least 26 subnets with the most amount of hosts, how many hosts will be available per subnet if the ISP assigns X company 150.200.100.0/24?”

Going along the chart, we know we need to borrow 5 bits which will give us 32 subnets, meeting the requirement (/29) and we know that a /29 mask will leave us with 8 host bits – 2 for network and broadcast address.

So the network numbers in the above question / answer would be as follows:

150.200.100.0
150.200.100.8
150.200.100.16
150.200.100.24
150.200.100.32

And so on 🙂

That is all I will beat that horse to death about subnetting, just be very clear on the concept of borrowing network bits, and host ranges.

AND FOR ONE LAST TIME, BE SURE TO WRITE OUT SOME KIND OF CHART BEFORE YOU START THE CLOCK ON THE EXAM, UNLESS YOUR ARE A SUBNETTING GENIUS (AND EVEN THEN WRITE IT OUT BEFORE STARTING THE TIMER)!

ROUTE Blueprint “Network Principles” section topics all covered within this post (briefly, but covered)!

Directly from Cisco’s website:

1.1 Identify Cisco Express Forwarding concepts

  • 1.1.a FIB – Forwarding Information Base, “sh ip cef” to view, used to determine next hop IP addresses, performs Layer 3 “Packet Switching” or Packet forwarding
  • 1.1.b Adjacency table – Correlates with FIB to find corresponding MAC addresses for Packet Switching / Forwarding
  • Both these exist on the “Data Plane” where actual forwarding occurs, and populates the IP Route Table (RIB) which exists on the “Control Plane”

1.2 Explain general network challenges

  • 1.2.a Unicast – “Unknown Unicasts” are generated when a Destination MAC is unknown, switches will flood these packets to all members within the VLAN, possibly causing a “Traffic Storm” which can impact network performance
  • 1.2.b Out-of-order packets – Each Packet is forwarded by the best metric to its destination, so this can happen if metrics change during transmission. TCP solves this issue with Ack and Seq numbers to re-order packets when they arrive
  • 1.2.c Asymmetric routing – This occurs when traffic takes a different return path then the traffic was sent on, specifically this is an issue with Firewalls and NAT. For example the devices will keep track of the connection states, SYN is sent through a router to a server, but servers Default Gateway is through a different device (Firewall), that device will have no “State Record” of the connection and drop the packets ACK it is trying to send back.

1.3 Describe IP operations

  • 1.3.a ICMP Unreachable and Redirects – Redirects are found when debugging ICMP packets, sent back to the source when a better route is found to the Destination by Gateways only (NOT hosts). Unreachable responses come in the form of (U.U.U) meaning the upstream router has no route to the destination network
  • 1.3.b IPv4 and IPv6 fragmentation – IPv4 Fragmentation happens when an IP Datagram is passing through a device with a smaller MTU (Maximum Transmission Unit) than the original Sender, and the receiver must reassemble the fragments based upon the flags in the Fragment Offset field in the IPv4 Header. IPv6 does not have a “Fragmentation” field in it’s IPv6 Header, so it must be inserted into the IP Packet “Extension” field by the sender if its determined Fragmentation is needed before transmission rather than during transmission.
  • 1.3.c TTL -Time To Live is a value in the Header of an IPv4 Packet, that is decremented (decreased) in value by 1 for each hop or router it passes through, until it hits the value of 0, at which point it is discarded.

1.4 Explain TCP operations

  • 1.4.a IPv4 and IPv6 (P)MTU – MTU refers to the Maximum Transmission Unit size that can be sent to a host. IPv4 “may” use Path MTU Discovery to avoid packet framentation along the way, IPv6 “must” use Path MTU Discovery so it can set the Fragmentation in its IPv6 Headers “Extension” field. So (P)MTU = Path MTU.
  • 1.4.b MSS – “Maximum Segment Size” is an optional field in the TCP SYN Packet, which can adjust the MTU of a router, generally used for PPPoE (PPP over Ethernet), as the default size of MTU’s is 1500, and PPPoE only supports up to 1492 MTU Size – So it will discard any packets (most default ones) if not adjusted in the MSS
  • 1.4.c Latency – The time it takes for a packet to travel from its Source to its Destination, and used by some routing protocols (EIGRP) to determine its metric, and if packets are dropped TCP will request re-transmission of discarded packets
  • 1.4.d Windowing – The amount of TCP segments that a Receiver can successfully have transmitted, acknowledged with an ACK back to the Sender. Sliding-Window is a type of Windowing where the segments sent increases until the Receiver can no longer Ack the amount of segments, and the Sender then slows down transmission of segments being sent until Ack’s are again received
  • 1.4.e Bandwidth-delay product – The maximum amount of bits that can be on a segment at any given time
  • 1.4.f Global synchronization – Also known as TCP Synchronization, is when a routers interface output queue fills to capacity and it must start discarding TCP packets, taking longer for TCP transmissions to go through and ACK’s to be sent. One way to prevent this condition is Weighted Random Early Detection (WRED) that can randomly drop packets from the queue if it gets near capacity.

1.5 Describe UDP operations

  • 1.5.a Starvation – When “Connectionless” UDP Packets flood the interface or “starve” the line of bandwidth, causing TCP connections to drop excessive packets, and slow down the transmission of them
  • 1.5.b Latency – Any packets discarded will not be re-transmitted as UDP is connectionless, QoS solves this issue between a source and destination

1.6 Recognize proposed changes to the network

  • 1.6.a Changes to routing protocol parameters – Understand network wide impact on routing behaviors, plan phases of the protocol behaviors, and have an action plan to migrate back to the initial parameters to minimize downtime
  • 1.6.b Migrate parts of the network to IPv6 – Check and confirm LAN nodes are IPv6 compatible, run IPv4 and IPv6 concurrently (Dual-Stack) to confirm compatibility, user IPv6-over-IPv4 tunnels for IPv6 LAN’s to be able to communicate over IPv4 tunnels between sites, and also using NAT64 which converts IPv6 Address to IPv4 addresses entering the LAN
  • 1.6.c Routing protocol migration – One method for migration would be to run both protocols concurrently, so if one fails the other can continue to run, another method would be route redistribution one network segment at a time to see how it reacts to the migration

VPN: DEEP Dive into GRE over IPSec configuration, explanation, and very easy actually once you are familiar with GRE and IPSec!

OSPF_GRE_Over_IPSec2So this is very odd to me after going through the last two posts of GRE and IPSec configuration, however once I found good information, configuration was a breeze.

**PLEASE READ EXAM DAY NOTE AT END OF POST FOR SCENARIOS WHERE THE ROUTES HAVE TO BE IN THE DYNAMIC ROUTING PROTOCOL FOR OTHER ROUTERS**

You do need the basic GRE Tunnel configurations plus a little extra, and you need a LOT less IPSec configuration, though I am sure there are ways to make it more complex and add configurations on top of it.

I took a step back, and took multi-area OSPF out of it, and just used the NBMA routers with a specified loopback as take the IPSec GRE tunnel.

First important thing to note, and this I’m sure changes once you spend more time with this, however from what I found that if you are using dynamic routing protocols you DO NOT want your traffic on either side participating in those that will take the VPN tunnel!

Dynamic routing protocols can help get the encrypted traffic from point A to point B by learning the path to the remote router (when traversing multiple routers), however you will want a static route with GRE over IPSec which you will see why!

(So I actually could have left OSPF off completely with this network, because all of the interfaces showed as connected, except our loopbacks which we couldn’t add)

THAT BEING SAID, LETS CONFIGURE US SOME IPSEC GRE TUNNEL!

So to begin the configuration, first we make our GRE Tunnel, just as we did before, with the addition of one command to start the tie back to IPSec:

R2(config)#int tu0
R2(config-if)#tunnel
*Mar 31 00:11:11.825: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add 10.1.1.2 255.255.255.0
R2(config-if)#tunnel source s0/0
R2(config-if)#tunnel destination 172.12.123.3
R2(config-if)#
*Mar 31 00:12:16.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#
R2(config-if)#tunnel mode ipsec ipv4

ASR#3
[Resuming connection 3 to r3 … ]

R3(config)#int tu0
R3(config-if)#tunn
*Mar 31 21:07:10.592: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add 10.1.1.3 255.255.255.0
R3(config-if)#tunnel source s0/2
R3(config-if)#tunnel destination 172.12.123.2
R3(config-if)#
R2(config-if)#tunnel mode ipsec ipv4

*Mar 31 21:07:55.618: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#do ping 10.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 156/159/168 ms

These commands break down to:

  • Creating the tunnel interface
  • Setting the IP Address / Network it belongs to (10.1.1.0 /24)
  • Tunnel Source points at the WAN or Outbound interface
  • Tunnel Destination points at the Remote physical interface IP
  • Tunnel mode ipsec ipv4 tells GRE it will be using IPSec for communication
  • Once configured on both sides, ping the remote GRE IP to confirm connectivity

Notice that from the first router, as soon as you define an IP / Source / Destination for a Tunnel interface it is Up / Up. You will see it drop again throughout the configuration, but for the initial setup, that is a good behavior to know.

Next is some IPSec configs we know, such as Policy Creation, Pre-Shared Key creation, and define a Transform Set (no need to define a tunnel mode):

R2(config)#crypto isakmp policy 10
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)#exit
R2(config)#crypto isakmp key CCNP address 172.12.123.3
R2(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
R2(cfg-crypto-trans)#exit
R2(config)#
ASR#3
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)# encr 3des
R3(config-isakmp)# hash md5
R3(config-isakmp)# authentication pre-share
R3(config-isakmp)#exit
R3(config)#crypto isakmp key CCNP address 172.12.123.2
R3(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
R3(cfg-crypto-trans)#exit
R3(config)#

What a world of difference, no Crypto ACL’s / Crypto Maps / Lifetimes / Interface configuration / Etc. I won’t go through the above configurations as you should be familiar with these by now, and if not, you need to review this post.

However, there is one additional command that ties GRE and IPSec together, which I will demonstrate here:

R2(config)#crypto ipsec profile PROTECT
R2(ipsec-profile)#set transform-set VPNLAB
R2(ipsec-profile)#int tu0
R2(config-if)#tunnel protection ipsec profile PROTECT
R2(config-if)#
*Mar 31 00:59:19.287: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R2(config-if)#

So almost immediately you see the IPSec ISAKMP turn on, however I think I jumped over to R3 too fast to catch Tunnel0 going down, however we do see it coming back up here:

R3(config)#crypto ipsec profile PROTECT
R3(ipsec-profile)#set transform-set VPNLAB
R3(ipsec-profile)#int tu0
R3(config-if)#tunnel protection ipsec profile PROTECT
R3(config-if)#
*Mar 31 21:55:08.017: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R3(config-if)#
*Mar 31 21:55:10.437: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#exit
R3(config)#

So to break down these new commands:

  • The IPSec side of the commands: “crypto ipsec profile (word)” defines an IPSec profile, you will need a Transform-Set defined as it will drop you into profile mode to “set transform-set (name)” which I’ve color-coded to see where the transform-set name is derived from in the config
  • The GRE side of the commands: “tunnel protection ipsec profile PROTECT” defines the transform-set to be used to secure / encrypt data during transmission

Now here comes the tricky part to me, as there is no Crypto ACL, or Crypto Map to call out that ACL, and we aren’t applying a Crypto Map calling out a Crypto ACL on the outside facing interface – So how the heck do we define our interesting traffic?

I was able to ping, but no encaps / decaps from “sh cry ipsec sa” were incrementing. So what the answer? Static Routes!

Now this took some real attention to detail, and my brain is working at 25% today, so the struggle is real – But I found the correct syntax for your static routes:

R2(config)#ip route 33.33.33.33 255.255.255.255 10.1.1.3

And

R3(config)#ip route 22.22.22.22 255.255.255.255 10.1.1.2

I kept trying to use an exit interface of tu0, however, it needed the GRE Tunnels remote peer IP address.

I entered the outside IP of the router, the tunnel0 interface, nothing was working until I caught that – This is why you want to keep all routes using IPSec GRE tunnels out of dynamic routing protocols!

(Note that I did have to put static routes on R1 pointing to 22.22.22.22 and 33.33.33.33 because it was not learning them via a Dynamic routing protocol)

Once all of that was complete, I verified my work:

R3#ping 22.22.22.22 source 33.33.33.33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 33.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/186/193 ms
R3#sh cry ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.12.123.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 172.12.123.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

There is our encaps and decaps we want to see! Looking good!

R3#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.12.23.3     YES NVRAM  up                    up
FastEthernet0/1            172.12.34.3     YES NVRAM  up                    up
Serial0/2                  172.12.123.3    YES NVRAM  up                    up
Serial0/3                  unassigned      YES NVRAM  administratively down down
Loopback3                  3.3.3.3         YES NVRAM  up                    up
Loopback33                 33.33.33.33     YES manual up                    up
Tunnel0                    10.1.1.3        YES manual up                    up
R3#

Our Tunnel0 interface is Up/Up just how we want to see it, aaaaand:

R3#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.12.123.2    172.12.123.3    QM_IDLE           1001    0 ACTIVE

The Phase 1 portion of our tunnel is obviously happy as well if we are even getting to the point of encaps and decaps, so on all accounts we have success!!!

The nice thing about this is, really you can add networks via static route that can take this tunnel without any Crypto ACL’s defining the traffic, so it is much more scalable of a solution in my opinion with less configuration / things that can go wrong.

However, as I feel I have done my job here getting this to work, I’m not digging any further into this topic – Time to move onto greener pastures which I am not sure what yet but it will come in the form of another DEEP Dive soon 🙂

One final note that is VERY important for exam day:

If the route / network needs to be in a dynamic routing protocol, you may be tasked to leave it in their to propagate to other routers, and in this scenario you may need for example a Distribute-List to prevent the type 3 LSA Prefix from creating an OSPF route on the router. Be very careful to watch for this on exam day!!!

VPN: DEEP Dive into different VPN Packet Types, Packet Headers, and the differences between VPN Packets and their Modes!

VPN_Headers

This first image is a break down of the different types of VPN Packet Type by the headers / trailers (or lack thereof), and the following of your typical IPSec VPN Packet Type:

packet_segments_ipsec

The VPN generic representation of the IPSec VPN Packet above works for a general review, but there are details in the headers that are begging for exam questions and must be broken down and committed to memory if asked about them.

  • AH (Authentication Header) = Security, Data Origin Authentication (also offers anti-reply protection)
  • ESP (Encapsulating Security Payload) = Method of authentication / securing / encrypting the Data payload
  • IKE (Internet Key Exchange) – The protocol to negotiate security parameters and authentications keys to form an SA (Security Association)

Going from top to bottom, lets review each Packet type going down the list above from the top of the page:

  • Generic Frame = Ethernet Header | IP Header | Protocol Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 4. Data / Payload = “Blah blah blah”

Used by GRE, which is mostly mentioned regarding mGRE for DMVPN Functionality, it can also be configured to be encapsulated INSIDE IPSec VPN tunnels because it does not have limitations that IPSec VPN’s have which is as follows:

  • 1. IPSec tunnels can Secure and Encrypt Unicast Information, but not Multicast or Broadcast traffic, which may be needed between sites
  • 2. GRE tunnels send Unicast Packets that can encapsulate Multicast and Broadcast traffic, which can than be placed into a new IPSec packet as a unicast packet so Multicast and Broadcast traffic can traverse VPN tunnels!

There will be a separate lab for GRE / IPSec that will demonstrate this concept as it is important to know both for the lab and real world as we always want more tools to get the job done!

Tunnel modes for VPN types explained in detail

First to be discussed will be the two Transport Modes, as they are hiding a field switcheroo in the packet fields you’d overlook at first glance:

  • 1. Tunnel mode will encrypt the packet, and place that packet into a new packet, which will then route on agreed IP addresses between the Tunnel Endpoints
  • 2. Transport mode will encrypt the IP packets payload, but the IPSec Header is inserted behind the IP Header, exposing the source address of the data, and only truly secures data from the Transport Layer up as the Source IP is used

So if you are not looking again at that top illustration and saying “Oh, I didn’t see that, good to know” you either already know it or did not understand what you just read 🙂

AH Tunnel / Transport Mode explained in detail

First we will review the 2 different flavors of AH Packets, explained from most protect to least, with details about each segments purpose:

  • AH Tunnel Mode = Ethernet Header | New IP Header | AH Header| IP Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”

 

  • AH Transport Mode = Ethernet Header | IP Header | AH Header | TCP/UDP Header | Payload
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. AH Header = Security, Data Origin Authentication, optional Anti-Replay Protection (No Data Confidentiality / Encryption)
  • 3. IP Header = Source IP Address
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”

It is a viable VPN solution to use, as it will protect the IP Packets payload, however the Authentication it provides is not complete. As some of the IP Header fields may be changed in transmission,  the receiver cannot accurately predict the IP fields, thus making it complete but it still offers all attributes mentioned in the AH Header.

The one big strike against AH is that although it does protect the data Payload and is considered secure, the Payload is NOT encrypted so AH is considered non-Confidential.

The IP Header:

ipv4_header

The Authentication Header:

AH_Header

Next is the two more secured options of ESP, offering an ESP Header / Trailer, as well as ESP Authentication – Lets review both again, most secure to least:

  • ESP Tunnel Mode = Ethernet Header | New IP Header | ESP Header| IP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. New IP Header = Usually IP of the Security Gateway / Peer IP
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. IP Header = Source IP Address
  • 5. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 6. Data / Payload = “Blah blah blah”
  • 7. ESP Trailer = Encapsulates Data / Padding
  • 8. ESP Authentication =  Authentication Data / Hash Checksum

 

  • ESP Transport Mode = Ethernet Header | IP Header | ESP Header | TCP/UDP Header | Payload | ESP Trailer | ESP Authentication
  • 1. Ethernet Header = Encapsulates Ethernet Frame
  • 2. IP Header = Source IP Address
  • 3. IPSec / ESP Header = Encapsulates data / Encryption, Data Confidentiality
  • 4. TCP/UDP Header = Port information, for a quick read on  TCP vs UDP Headers that link is gold for a brief but concise comparison
  • 5. Data / Payload = “Blah blah blah”
  • 6. ESP Trailer = Encapsulates Data / Padding / Pad Length / Next Header
  • 7. ESP Authentication =  Authentication Data / Hash Checksum

Now I want to post the image at the top right here for quick comparison among all of these different methods of VPN / Modes:

VPN_Headers

So as can be seen, ESP is highly preferred over AH if you have the resources to run it, and that “Tunnel” mode is preferred over “Transport” mode because it keeps the Source IP Address secure.

Here is an image that I thought was very visual and helpful to seeing the difference in ESP Tunnel vs Transport mode:

IP_Security_IPSec_ESP_01

I am completely fried so that will be it for thd packet details, next DEEP Dive will be GRE over IPSec lab to see if we can brainwash the configuration just like all of this information – I can’t wait 🙂