OSPF Areas, Part 1, The Backbone Area

Here is the network we will use in this first post. Notice this simple network can be constructed easily in Dynamips, or with three pretty basic Cisco routers capable of OSPF version 2.


To prepare for this blog post, we have configured all of the underlying layer 2 and 3 connectivity. We have also configured  OSPF per the diagram. Note the OSPF router IDs were set using the OSPF router-mode router-id command. These addresses do not exist on the devices,  and therefore they are not advertised in the protocol, and obviously, they are not reachable.
So let us examine the first device, R1. This is an internal, backbone router. What do we expect to see in the OSPF database? Well, since there is  broadcast media at work in that area, I expect to see an LSA Type 2, and we have another area, Area 11, so we should also see an LSA Type 3. Here is the actual OSPF database on the device:

R1#show ip ospf database

            OSPF Router with ID (1.1.1.1) (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         99          0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         95          0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         99          0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         98          0x80000001 0x00F4CB
R1#

Interesting, OK, as an internal, backbone router, the first thing I notice is the fact that we only have one link state database here – it is for Area 0 of course. OK, very interesting, we have LSA 1 types (Router Link States) for the Router IDs of R1 and R2 in that area. Wow, these are not even valid (reachable) IP addresses in the scenario. I guess this is how we can use these Router IDs when we create a virtual link. These Router IDs are tracked and shared by the OSPF speakers.
The next entry is the LSA Type 2 (Net Link State) we expected. The advertising router is the local router (R1, RID: 1.1.1.1). We must be the Designated Router (DR), and that is indeed true. Finally, we have our LSA Type 3 (Summary Net Link State) that we expected from Area 11. Awesome. This is a fun and rewarding exercise. Predicting show command output based on our Core Knowledge (Level 1).
Now, close your eyes and think about the show command output for the OSPF database we will see in R2. This is an Area Border Router (ABR), and also a backbone router. We immediately realize we should see LSA entries for Area 0 and Area 11. This poor router has to maintain two databases:

R2#show ip ospf database

            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         905         0x80000002 0x001FEB 2
2.2.2.2         2.2.2.2         899         0x80000002 0x007761 1

  Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      1.1.1.1         905         0x80000001 0x009476

  Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.0     2.2.2.2         902         0x80000001 0x00F4CB

  Router Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         856         0x80000002 0x00F747 1
3.3.3.3         3.3.3.3         858         0x80000002 0x00B680 1

  Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.2     2.2.2.2         859         0x80000001 0x006D44

  Summary Net Link States (Area 11)

Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.0      2.2.2.2         904         0x80000001 0x0048C4
172.16.10.0     2.2.2.2         894         0x80000001 0x00C79B
R2#

Examine the above output line for line. There should be no surprises, and it should all fall right into place from your Core Knowledge about OSPF LSA Types now. Here is a look at the IP Routing table on this device, R2. Correlate the entries to those you see in the OSPF Database:

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.10.0 [110/11] via 10.10.10.1, 00:17:59, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
R2#

TSHOOT: Troubleshooting EIGRP, Part 1

In this blog post, we are going to provide a sneak peek into some of the awesome information shared in the TSHOOT section of the bootcamp regarding the Troubleshooting of EIGRP. This can prove critical in the Troubleshooting and Configuration sections of the CCIE R&S Lab Exam, as well as the TSHOOT CCNP exam (duh!).

Where Is My Neighbor!?!?!?

The first thing that you want to master when it comes to troubleshooting EIGRP is the ‘workflow” that EIGRP follows in its operation. We can subdivide the processes of this exciting protocol into four discrete steps:

• Discovery of neighbors
• Exchange of topology information
• Best path selection
• Neighbor and topology table maintaince

Discovery of Neighbors
Remember that EIGRP discovers neighbors through bi-directional multicast by default. IP protocol 88 and 224.0.0.10 are the key parameters we need to watch out for here. Could there be issues with NBMA pseudo-broadcast support or filtering causing neighbor discovery to fail? Certainly things to examine in the topology. Also, watch out for the neighbor command under the EIGRP routing process. This feature causes the use of unicast packets for neighbor creation exclusively and must be agreed upon by BOTH neighbors.
Another area we need to be aware of is the attributes that must match in order for neighbors to form. Sure this list is nowhere near as lengthy as the parameters that we have to watch out for in OSPF networks, but the list is just as critical:

• Common Subnet (Must be the primary address – not a secondary)
• Autonomous System Number
• Authentication
• K values (metric weights)

Exchange of Topology Information
When it comes to the exchange of topology information, this is done with unicast. Notice that connectivity for neighborship still requires mutlicast communications (unless you are using the neighbor command).
Remember that EIGRP will only advertise those prefixes that it installs in the routing table. This is an excellent time to review the difference from the Topology Table to the Routing Table.
Important troubleshooting considerations for the exchange of topology information include:

• Automatic summarization in use?
• Split horizon settings
• The use of duplicate router IDs preventing external route introduction
• No seed metric set for external prefixes
• Filtering through the use of distribute lists

Please consider these troubleshooting aspects for these two phases of EIGRP’s operation. We will cover more in the next installment coming soon…