Practical configurations, Part 4

This tip on verification and troubleshooting in networking configuration teaches simple commands that will help not only in making a network run more smoothly, but also in learning how the individual protocols work.

The last tip in this series focused on configuring a dynamic routing protocol between the distribution and core layers of a network and using a few commands to verify the accuracy of the configurations. This week, I'm going to focus more on the verification and troubleshooting aspect of network configurations. Using these simple commands will help not only in making a network run more smoothly, but also in learning how the individual...

protocols work.

OSPF configuration verification
Recall from the last tip that I showed you how to configure OSPF between our core routers. The figure below illustrates the OSPF network:

Let's examine the configuration for Core-1 and Core-2 and sample some output from verification commands:

Core-1
Core-1(config)#interface loopback0
Core-1(config-if)#description Interface used for OSPF, BGP, etc.
Core-1(config-if)#ip address 150.10.33.1 255.255.255.255
Core-1(config-if)#interface GigabitEthernet 0/0
Core-1(config-if)#description Link to Core-2
Core-1(config-if)#ip address 150.1.1.33 255.255.255.252
Core-1(config-if)#interface GigabitEthernet0/1
Core-1(config-if)#description Link to D1
Core-1(config-if)#ip address 150.1.1.1 255.255.255.252
Core-1(config-if)#interface GigabitEthernet0/2
Core-1(config-if)#description Link to D2
Core-1(config-if)#ip address 150.1.1.9 255.255.255.252
Core-1(config-if)#interface GigabitEthernet0/3
Core-1(config-if)#description Link to D3
Core-1(config-if)#ip address 150.1.1.17 255.255.255.252
Core-1(config-if)#interface GigabitEthernet0/4
Core-1(config-if)#description Link to D4
Core-1(config-if)#ip address 150.1.1.25 255.255.255.252
Core-1(config)#router ospf 1
Core-1(config-router)#router-id 150.10.33.1
Core-1(config-router)#network 150.10.33.1 0.0.0.0 area 0
Core-1(config-router)#network 150.1.1.0 0.0.0.3 area 0
Core-1(config-router)#network 150.1.1.8 0.0.0.3 area 0
Core-1(config-router)#network 150.1.1.16 0.0.0.3 area 0
Core-1(config-router)#network 150.1.1.24 0.0.0.3 area 0
Core-1(config-router)#network 150.1.1.32 0.0.0.3 area 0
Core-1(config-router)#network 10.2.1.0 0.0.0.255 area 2

Core-2
Core-2(config)#interface loopback0
Core-2(config-if)#description Interface used for OSPF, BGP, etc.
Core-2(config-if)#ip address 150.10.33.2 255.255.255.255
Core-2(config-if)#interface GigabitEthernet 0/0
Core-2(config-if)#description Link to Core-1
Core-2(config-if)#ip address 150.1.1.34 255.255.255.252
Core-2(config-if)#interface GigabitEthernet0/1
Core-2(config-if)#description Link to D1
Core-2(config-if)#ip address 150.1.1.5 255.255.255.252
Core-2(config-if)#interface GigabitEthernet0/2
Core-2(config-if)#description Link to D2
Core-2(config-if)#ip address 150.1.1.13 255.255.255.252
Core-2(config-if)#interface GigabitEthernet0/3
Core-2(config-if)#description Link to D3
Core-2(config-if)#ip address 150.1.1.21 255.255.255.252
Core-2(config-if)#interface GigabitEthernet0/4
Core-2(config-if)#description Link to D4
Core-2(config-if)#ip address 150.1.1.29 255.255.255.252
Core-2(config)#router ospf 1
Core-2(config-router)#router-id 150.10.33.6
Core-2(config-router)#network 150.10.33.2 0.0.0.0 area 0
Core-2(config-router)#network 150.1.1.4 0.0.0.3 area 0
Core-2(config-router)#network 150.1.1.12 0.0.0.3 area 0
Core-2(config-router)#network 150.1.1.20 0.0.0.3 area 0
Core-2(config-router)#network 150.1.1.28 0.0.0.3 area 0
Core-2(config-router)#network 150.1.1.32 0.0.0.3 area 0
Core-2(config-router)#network 10.2.1.0 0.0.0.255 area 2

If we configure our core devices with the configurations above we can use certain commands to verify our operation is running smoothly.

Checking Neighbors
Using the command show ip ospf neighbor on Core-1, we should see output similar to the one below:

Core-1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.33.2       1   FULL/DR         00:00:39    150.1.1.34 G0/0
150.10.33.3   1   FULL/BDR         00:00:31    150.1.1.2    G0/1

This output tells us we have a full adjacency across G0/0 to Core-2 (150.10.33.2) and to D2 (G0/1).

Keep in mind that the Neighbor ID field represents the neighbor's Router ID. If we wanted more information about a certain neighbor to verify other aspects of an OSPF neighbor's capabilities, or to see whether or not the adjacency has gone up and down, we could use the command show ip ospf neighbor detail.

Core-1#show ip ospf neighbor 150.10.33.2 detail

 Neighbor 150.10.33.2, interface address 150.1.1.2
    In the area 0 via interface Vlan121
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 150.1.1.2 BDR is 150.1.1.1
    Options is 0x42
    Dead timer due in 00:00:39
    Neighbor is up for 44w4d
    Index 6/1, retransmission queue length 0, number of retransmission 2105
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 36
    Last retransmission scan time is 0 msec, maximum is 0 msec

This command is very useful when verifying the stability of a neighbor.

Database Checking
We've verified that our OSPF neighbor adjacency is up and operational, but we can't seem to find a certain route to a destination within our network. Yes, you could verify the route by viewing the IP routing table first -- but that would be too easy, so let's look at where a route destination goes before it enters the routing table by using the command show ip ospf database.

Core-1#show ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1     150.1.1.2   68          0x800080D5 0x658A   0

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         0.0.0.0     68       0x80000326   0x94AD   1

By verifying that links for the networks you seek are in the OSPF database, you can be assured that they will show up in your routing table. Note that in some cases, when a route is learned from two neighbors and has unequal costs, it will show up twice in the OSPF database and only once in the IP routing table.

Core-1#show ip route 1.1.1.0

  Known via "ospf 1", distance 114, metric 0, type internal
  Last update from 150.1.1.2 on G0/0, 1w4d ago
  Routing Descriptor Blocks:
  * 1.1.1.1, from 150.1.1.2, 1w4d ago, via G0/0
      Route metric is 100, traffic share count is 1

We can verify the IP routing information of the database entry by using the command show ip route.

Troubleshooting
Each of these verification commands can also be used to troubleshoot various components of your network. If we use the show ip ospf neighbor command and see a large number of state changes, you might want to check the physical path between the two devices. Just because you can't ping something doesn't mean the Internet is down!

The golden rule to troubleshooting (in my own words, of course): "Is it turned on, plugged in? Is there paper in it?!" Simply stated: the simple answer is usually the right one, in life and in your network. Understanding the operation of the protocol itself is the key to troubleshooting efficiently and successfully. Verify the correct operation at each layer using some of these commands.

  • Layer 1: show interface, show interface stats, show interface status
  • Layer 2: show mac-address-table, show arp, show spanning-tree vlan, show interface trunk, show cdp neighbor, show cdp neighbor detail
  • Layer 3: show ip interface brief, show ip route, show ip ospf database, show ip ospf neighbor, show ip ospf interface
  • Now you should have a good idea how to configure, verify and troubleshoot the devices in your network. Make it a point to understand the output you get from entering these commands and you'll begin to break down the different mechanisms of each protocol within your network. In the next tip, I'll show you how to add a network and manipulate the routes throughout your network.


    Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, Inc., a wholly owned subsidiary of SBC Communications. Doug has over seven years experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington D.C. area.
    This was first published in September 2005

    Dig deeper on Network Hardware

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    -ADS BY GOOGLE

    SearchSDN

    SearchEnterpriseWAN

    SearchUnifiedCommunications

    SearchMobileComputing

    SearchDataCenter

    SearchITChannel

    Close