EIGRP Verification Commands

R3#show ip eigrp traffic  - Self explanatory
IP-EIGRP Traffic Statistics for AS 10
  Hellos sent/received: 81/81
  Updates sent/received: 5/5
  Queries sent/received: 1/0
  Replies sent/received: 0/1
  Acks sent/received: 5/3
  SIA-Queries sent/received: 0/0
  SIA-Replies sent/received: 0/0
  Hello Process ID: 208
  PDM Process ID: 138
  IP Socket queue:   0/2000/2/0 (current/max/highest/drops)
  Eigrp input queue: 0/2000/2/0 (current/max/highest/drops)

R3#show ip eigrp topology - Shows you routes that made it into the topology table.
IP-EIGRP Topology Table for AS(10)/ID(3.3.3.3)
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 128256
        via Connected, Loopback3
P 4.4.4.4/32, 1 successors, FD is 307200
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 1.1.1.1/32, 1 successors, FD is 307200
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 3.0.0.0/8, 1 successors, FD is 128256
        via Summary (128256/0), Null0
P 192.168.1.0/24, 1 successors, FD is 284160
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 192.168.3.0/24, 1 successors, FD is 284160
        via 192.168.2.1 (307200/281600), FastEthernet0/0

R3#show ip eigrp neighbors -  Displays the neighbors discovered by EIGRP.
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.2.1             Fa0/0             13 00:03:30  865  5000  0  8

R3#show ip eigrp topology all - You can see the routes that are not feasible successors
IP-EIGRP Topology Table for AS(10)/ID(3.3.3.3)
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 128256, serno 13
        via Connected, Loopback3
P 4.4.4.4/32, 1 successors, FD is 307200, serno 10
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 1.1.1.1/32, 1 successors, FD is 307200, serno 9
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 3.0.0.0/8, 1 successors, FD is 128256, serno 14
        via Summary (128256/0), Null0
P 192.168.1.0/24, 1 successors, FD is 284160, serno 7
        via 192.168.2.1 (307200/281600), FastEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 281600, serno 6
        via Connected, FastEthernet0/0
P 192.168.3.0/24, 1 successors, FD is 284160, serno 8
        via 192.168.2.1 (307200/281600), FastEthernet0/0


R3#show ip eigrp interfaces -Which interfaces are running the EIGRP process
IP-EIGRP interfaces for process 10
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo3                0        0/0         0       0/1            0           0
Fa0/0              1        0/0       865       0/2         4260           0

R3#show ip protocols - Shows K Values, AS#, and may great details.
Routing Protocol is "eigrp 10"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.2.0/24 for Loopback3
    3.0.0.0/8 for FastEthernet0/0
      Summarizing with metric 128256
  Maximum path: 4
  Routing for Networks:
    3.3.3.3/32
    192.168.2.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      00:02:12
    192.168.2.1           90      00:02:41
  Distance: internal 90 external 170

R3#

LAN-to-LAN IPsec Tunnel Between Two Routers

I followed the instructions on this link to build the lab in figure 1. I will include some additional commands not in this article and try to clarify some things.

Figure 1

Tunnel currently down: When the tunnel is up, you should see details within the inbound and outbound ESP sections or AH depending on which protocol your using. You also would see the pkts encaps: and pkts decaps incrementing as you are sending data. local  ident and remote ident confirm which networks are part of your encryption domain. This means which networks would bring up the tunnel. local crypto endpt is the local peer address of your device and the remote crypto endpt is the other side vpn peer.

Encapsulated Security Payload ESP), protects the IP packet data from third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, 3DES).

Authentication Header (AH), protects the IP packet header from third party interference and spoofing, by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.


R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: mymap, local addr 192.168.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
   current_peer 192.168.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

Bring up the tunnel:

Lets bring up the tunnel and compare the results. Currently 1.1.1.1 and 3.3.3.3 are part of my encryption domain meaning that only traffic for these networks will traverse the tunnel.

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 40/53/72 ms

We drop one packet as the tunnel is coming up. Now you can see the ESP sections have information and the ENCAPS/DECAPS section have incremented. If you were to only see one of the sections #pkts encaps or #pkts decaps increment, then you have a routing issue.

R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: mymap, local addr 192.168.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
   current_peer 192.168.2.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.2.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x87F468E7(2280941799)

     inbound esp sas:
      spi: 0x6B548BDA(1800702938)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4578317/3524)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x87F468E7(2280941799)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4578317/3522)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R1#

Clearing Crypto Sessions:

clear crypto session remote 192.168.2.2

Debug from R3(debug crypto isakmp & debug crypto ipsec)

R3#
*Mar  1 01:08:42.863: ISAKMP (0:134217729): received packet from 192.168.1.2 dport 500 sport 500 Global (R) QM_IDLE
*Mar  1 01:08:42.867: ISAKMP: set new node 131317528 to QM_IDLE
*Mar  1 01:08:42.875: ISAKMP:(0:1:SW:1): processing HASH payload. message ID = 131317528
*Mar  1 01:08:42.879: ISAKMP:(0:1:SW:1): processing DELETE payload. message ID = 131317528
*Mar  1 01:08:42.879: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives.

*Mar  1 01:08:42.883: ISAKMP:(0:1:SW:1):deleting node 131317528 error FALSE reason "Informational (in) state 1"
*Mar  1 01:08:42.891: IPSEC(key_engine): got a queue event with 1 kei messages
*Mar  1 01:08:42.895: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
*Mar  1 01:08:42.895: IPSEC(key_engine_delete_sas): delete SA with spi 0x7CF89E55 proto 50 for 192.168.1.2
*Mar  1 01:08:42.903: IPSEC(delete_sa): deleting SA,

Further Reading:

VPNs and VPN Technologies

IPsec Troubleshooting: Understanding and Using debug Commands

New IPsec Troubleshooting Features

OSPF Internal Summarization

We are going to use the diagram in figure 1 for this post. I am going to summarize 4.0.0.0/8 from R3 into R1

Figure 1

Pre-summarization on R1 and R2:

Also note that I have three loopbacks configured on R3,  4.4.4.1/32, 4.4.5.1/32, 4.4.6.1/32.


R1#show ip route

     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 192.168.10.2, 00:14:46, FastEthernet0/0
     4.0.0.0/32 is subnetted, 3 subnets
O IA    4.4.5.1 [110/12] via 192.168.10.2, 00:01:36, FastEthernet0/0
O IA    4.4.4.1 [110/12] via 192.168.10.2, 00:01:36, FastEthernet0/0
O IA    4.4.6.1 [110/12] via 192.168.10.2, 00:01:36, FastEthernet0/0
C    192.168.10.0/24 is directly connected, FastEthernet0/0
O IA 192.168.20.0/24 [110/11] via 192.168.10.2, 00:14:46, FastEthernet0/0
R1#

R1#show ip ospf database

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         905         0x80000003 0x0055E9 1
2.2.2.2         2.2.2.2         915         0x80000005 0x00161D 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.10.2    2.2.2.2         915         0x80000001 0x00A50B

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         990         0x80000001 0x00FA31
4.4.4.1         2.2.2.2         120         0x80000001 0x0021FB
4.4.5.1         2.2.2.2         120         0x80000001 0x001606
4.4.6.1         2.2.2.2         120         0x80000001 0x000B10
192.168.20.0    2.2.2.2         990         0x80000001 0x00238A
R1#


R2#show ip route
Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
     4.0.0.0/32 is subnetted, 3 subnets
O       4.4.5.1 [110/11] via 192.168.20.2, 00:02:49, FastEthernet0/1
O       4.4.4.1 [110/11] via 192.168.20.2, 00:02:49, FastEthernet0/1
O       4.4.6.1 [110/11] via 192.168.20.2, 00:02:49, FastEthernet0/1
C    192.168.10.0/24 is directly connected, FastEthernet0/0
C    192.168.20.0/24 is directly connected, FastEthernet0/1
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
2.2.2.2         2.2.2.2         1047        0x80000001 0x00A96F 1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
4.4.4.1         2.2.2.2         172         0x80000001 0x0021FB
4.4.5.1         2.2.2.2         172         0x80000001 0x001606
4.4.6.1         2.2.2.2         172         0x80000001 0x000B10
192.168.10.0    2.2.2.2         1043        0x80000001 0x003789
192.168.20.0    2.2.2.2         1043        0x80000001 0x00238A

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         959         0x80000003 0x0055E9 1
2.2.2.2         2.2.2.2         967         0x80000005 0x00161D 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.10.2    2.2.2.2         967         0x80000001 0x00A50B

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         1044        0x80000001 0x00FA31
4.4.4.1         2.2.2.2         174         0x80000001 0x0021FB
4.4.5.1         2.2.2.2         174         0x80000001 0x001606
4.4.6.1         2.2.2.2         174         0x80000001 0x000B10
192.168.20.0    2.2.2.2         1044        0x80000001 0x00238A

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         947         0x80000002 0x008397 1
3.3.3.3         3.3.3.3         750         0x80000004 0x00D4E7 4

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.20.1    2.2.2.2         947         0x80000001 0x00A5F9

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         1044        0x80000001 0x00FA31
192.168.10.0    2.2.2.2         1045        0x80000001 0x003789
R2#

Configuring the summarization: You always configure internal ospf summarization on the ABR toward the direction of area 0.

R2(config)#router ospf 1
R2(config-router)#area 2 range 4.0.0.0 255.0.0.0


Debug output from R1(Debug ip ospf flood) - R1 received and LSU from R2 and it indicates that 4.4.4.1, 4.4.5.1 and 4.4.6.1 have been max aged to 3600(Seconds) and should be removed from the LSDB.  It also indicated that 4.0.0.0/8 should be added to the LSDB with a new age of 1(seconds).  Once the LSDB processes this data, an LSACK is sent back confirming it has received the updates.

 R1#
*Mar  1 00:24:05.391: OSPF: received update from 2.2.2.2, FastEthernet0/0
*Mar  1 00:24:05.391: OSPF: Rcv Update Type 3, LSID 4.0.0.0, Adv rtr 2.2.2.2, age 1, seq 0x80000001
*Mar  1 00:24:05.395:       Mask /8
*Mar  1 00:24:05.423: OSPF: received update from 2.2.2.2, FastEthernet0/0
*Mar  1 00:24:05.423: OSPF: Rcv Update Type 3, LSID 4.4.6.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
*Mar  1 00:24:05.427:       Mask /32
*Mar  1 00:24:05.427: OSPF: Rcv Update Type 3, LSID 4.4.5.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
*Mar  1 00:24:05.427:       Mask /32
*Mar  1 00:24:05.427: OSPF: Rcv Update Type 3, LSID 4.4.4.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
R1#
*Mar  1 00:24:05.431:       Mask /32
R1#
*Mar  1 00:24:07.895: OSPF: Sending delayed ACK on FastEthernet0/0
*Mar  1 00:24:07.895: OSPF: Ack Type 3, LSID 4.0.0.0, Adv rtr 2.2.2.2, age 1, seq 0x80000001
*Mar  1 00:24:07.895: OSPF: Ack Type 3, LSID 4.4.6.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
*Mar  1 00:24:07.895: OSPF: Ack Type 3, LSID 4.4.5.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
*Mar  1 00:24:07.899: OSPF: Ack Type 3, LSID 4.4.4.1, Adv rtr 2.2.2.2, age 3600, seq 0x80000002
R1#


Post-Configuration on R1 and R2:

R1#show ip route


Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 192.168.10.2, 00:21:05, FastEthernet0/0
O IA 4.0.0.0/8 [110/12] via 192.168.10.2, 00:03:00, FastEthernet0/0
C    192.168.10.0/24 is directly connected, FastEthernet0/0
O IA 192.168.20.0/24 [110/11] via 192.168.10.2, 00:21:05, FastEthernet0/0
R1#

R1#show ip ospf database

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1281        0x80000003 0x0055E9 1
2.2.2.2         2.2.2.2         1291        0x80000005 0x00161D 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.10.2    2.2.2.2         1291        0x80000001 0x00A50B

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         1366        0x80000001 0x00FA31
4.0.0.0         2.2.2.2         201         0x80000001 0x00879E
192.168.20.0    2.2.2.2         1366        0x80000001 0x00238A
R1#

I will throw in some additional information how the routing table determined a Metric of 12 to get to 4.0.0.0/8. If you look at the summary for 4.0.0.0 from R2 perspective,(show ip ospf database summary 4.0.0.0) you will see it has a cost(metric) of 11. This is the view again from R2 perspective when it ran its SPF algorithm. This is only 11, now how do we get that extra 1 in the metric? Keep in mind that R1 has a type1(Router LSA) to reach R2 and it has a metric of 1. We can verify this by issueing(show ip ospf database router 2.2.2.2).

R1#show ip ospf database summary 4.0.0.0

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

                Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 271
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 4.0.0.0 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x879E
  Length: 28
  Network Mask: /8
        TOS: 0  Metric: 11

R1#

R1#show ip ospf database router 2.2.2.2

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

                Router Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 1555
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 2.2.2.2
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000005
  Checksum: 0x161D
  Length: 36
  Area Border Router
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.10.2
     (Link Data) Router Interface address: 192.168.10.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

Back to the summarization, we can see that R1 now has only one entry for the 4.x.x.x network. We can now add more loopbacks(Networks) on R3 and we will still continue to see just the summary route. This greates stability in the network as its less overhead on the R1 when new networks that fall into the range are added.  On R2 we can see that a discard route has also been added and this is to prevent uneccasry traffice from flowing into area 2 as the router will drop packets if it does not have a specific match.


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

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
     4.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O       4.4.5.1/32 [110/11] via 192.168.20.2, 00:14:08, FastEthernet0/1
O       4.0.0.0/8 is a summary, 00:14:08, Null0
O       4.4.4.1/32 [110/11] via 192.168.20.2, 00:14:08, FastEthernet0/1
O       4.4.6.1/32 [110/11] via 192.168.20.2, 00:14:08, FastEthernet0/1
C    192.168.10.0/24 is directly connected, FastEthernet0/0
C    192.168.20.0/24 is directly connected, FastEthernet0/1

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
2.2.2.2         2.2.2.2         182         0x80000002 0x00A770 1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
4.0.0.0         2.2.2.2         852         0x80000001 0x00879E
192.168.10.0    2.2.2.2         182         0x80000002 0x00358A
192.168.20.0    2.2.2.2         182         0x80000002 0x00218B

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1934        0x80000003 0x0055E9 1
2.2.2.2         2.2.2.2         1942        0x80000005 0x00161D 1

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.10.2    2.2.2.2         1942        0x80000001 0x00A50B

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         182         0x80000002 0x00F832
4.0.0.0         2.2.2.2         854         0x80000001 0x00879E
192.168.20.0    2.2.2.2         184         0x80000002 0x00218B

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1923        0x80000002 0x008397 1
3.3.3.3         3.3.3.3         1725        0x80000004 0x00D4E7 4

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.20.1    2.2.2.2         1923        0x80000001 0x00A5F9

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
2.2.2.2         2.2.2.2         184         0x80000002 0x00F832
192.168.10.0    2.2.2.2         184         0x80000002 0x00358A
R2#

Cool NX-OS “show ip route” Enhancements

http://infrastructureadventures.com/2011/01/03/cool-nx-os-show-ip-route-enhancements/

Self Improvement - Troubleshooting

Great Articles that will only help you grow in your career and yes I read each and everyone one.

The Importance of Diagrams When Building a Network

The Lost Art of Troubleshooting

The science of network troubleshooting (updated)

The Ancient and Noble Art of Troubleshooting

OSPF Packet Details & Dijkstra's Algorithm: Shortest Path Video

Taken from http://cisco.iphelp.ru/faq/5/ch08lev1sec1.html#ch08fig01

Dijkstra's Algorithm: Shortest Path - Easy To Understand OSPF Packet Details OSPF has five types of packets used for various reasons. Table 8-1 documents the different OSPF packet types and describes their functionality. Table 8-1. OSPF Packet Types Type Description Functionality 1 Hello To discover neighbors and form DR/BDR relationship and exchange neighbor capabilities. 2 Database description To elect master/slave for the database exchange process and to exchange the LSA headers and select the first sequence number for database exchange. 3 Link-state request To request a specific LSA that is seen during the DBD exchange process. 4 Link-state update To send the entire LSA to the neighbor who requested the particular LSA through the link request packet. This packet is also used in flooding. 5 Link-state acknowledge To acknowledge the receipt of the link-state update packet. All the OSPF packet types share a common 20-byte OSPF protocol header. Figure 8-1 shows the common OSPF protocol header format. Figure 8-1. Common OSPF Protocol Header Format The list that follows describes the fields in the OSPF protocol header: Version Number— This field represents the current version number of OSPF. The latest version is 2. Version 1 is not compatible with Version 2. Type— This field indicates which of the five types of OSPF packets is appended at the end of this header. Packet Length— This field contains the length of the entire OSPF packet, including the OSPF header. Router ID— This field contains the 4-byte IP address. The router ID is used to uni-quely identify the router throughout the autonomous system. For a Cisco box, this field contains the highest IP address on the box. If loopbacks are configured, the highest loopback becomes the router ID. After the router ID is chosen, it will not change unless the router is restarted, the inter-face that is selected as a router ID is shut down, or the IP address has been removed or replaced on that interface. Area ID— This field designates the area number to which this packet belongs. This is also a 4-byte number. The value must be the same on both sides to form neighbor relationships. There are two ways to write this: Area 1 or Area 0.0.0.1. There is no difference between the two. Checksum— This field includes the checksum for the entire OSPF packet, excluding the authentication for data corruption. AuType— This field contains the type code for the authentication: - 0 means that there is a null authentication. - 1 means that the authentication type is plain text. - 2 means that the authentication type is MD5. Authentication— This 64-bit field contains the authentication key in case of plain-text authentication. In case of message digest, the 64-bit Authentication field is redefined into several other parameters. See Appendix D of RFC 2328 for more detail on the MD5 authentication scheme. Hello Packets Hello packets are the first type of packets in OSPF. Figure 8-2 illustrates the Hello packet format. Hello packets are used to form a neighbor relationship between two routers. In environments that include broadcast/nonbroadcast media, Hello packets are used to elect the designated (DR) and backup designated (BDR) routers. On broadcast media, the destination address of the Hello packets is 224.0.0.5. On nonbroadcast media, the destination address is unicast. Figure 8-2. Hello Packet Format The list that follows describes the fields in the Hello packet: Network Mask— Represents the network mask of the interface on which OSPF is running. The network mask is checked only on broadcast media. Hello Interval— Represents the number of seconds between two Hello packets. This interval must be the same for the two routers that are trying to form an adjacency. The Hello interval is 10 seconds on broadcast and point-to-point media, and 30 seconds on all other media. Options— Represents the optional capabilities supported by the router. The Options field has the following format: * O DC EA N/P MC E T - O bit is used for opaque LSAs, mentioned in RFC 2370 - DC is used for demand circuit capabilities, mentioned in RFC 1793 - EA is the external attribute - N/P is used for not-so-stubby area (NSSA) option, mentioned in RFC 1587 - MC designates multicast OSPF - E, when set, means that external LSA are allowed in this area - T bit is used for ToS capability (normally set to 0) The first bit in the Options field is reserved for future use. Cisco routers also do not use EA and MC bits. Rtr Pri— Used for a router's priority. By default, this value is set to 1. This field plays an important role in electing the DR and the BDR. A higher priority increases the chances that the router will become the DR. A priority of 0 means that this router will not take part in DR election. Router Dead Interval— Represents the number, in seconds, before a neighbor is declared dead. By default, the dead interval is four times the Hello interval. Designated Router— Lists the IP address of the designated router. If there is no DR, this field has a value of 0.0.0.0. The DR is elected through the Hello protocol. The router with the highest priority becomes the DR. If the priorities are equal, the router with the highest router ID becomes the DR. The purpose of the DR is to reduce the amount of flooding on multiaccess media. The DR uses multicasting to reduce the amount of flooding. All routers flood their link-state database to the DR, and the DR then floods that information back to other routers on that segment. No DRs/BDRs exist on point-to-point or point-to-multipoint segments. Backup Designated Router— Identifies the BDR and lists the interface IP address of the BDR. If no BDR exists, this field has a value of 0.0.0.0. The BDR is also elected through the Hello protocol. The purpose of the BDR is to serve as the backup of the DR, for a smoother transition in case the DR dies. BDR remains passive during flooding. Neighbor— Contains the router ID of each neighbor from which a Hello is seen. Database Description Packets The second type of OSPF packet, the database description (DBD) packet, is used mostly during the database exchange. The first DBD packet is used to elect the master and slave relationship and to set the initial sequence number elected by the master. The router with the highest router ID becomes the master and initiates the database synchronization. The master sends the sequence number, and the slave acknowledges it. After the master and the slave are elected, the database synchronization starts; in this process, the headers of all the LSAs are exchanged with neighbors. Figure 8-3 illustrates the DBD packet format. Figure 8-3. Database Description Packet Format The list that follows describes the fields in the DBD packet: Interface MTU— This field contains the largest data size, in bytes, that can be send through the associated interface. This option has been added starting from RFC 2178. This field must be set to 0 when sending the packet over a virtual link. Options— Options for this field were discussed in the previous section on the Hello packet format. I Bit— When set to 1, this means that this is the first packet in DBD exchange. M Bit— When set to 1, this means that more packets will follow. MS Bit— Use this for master and slave. When this bit is set, it means that the router is a master in the DBD exchange process. If this bit is set to 0, it means that the router is the slave. DBD Sequence Number— This field contains a unique value set by the master. This sequence number is used during database exchange. Only a master can increment the sequence number. LSA Header— This field consists of a list of the link-state database headers. Link-State Request Packets The Type 3 OSPF packet, a link-state request packet, is sent if part of the database is missing or out-of-date. The link-state request packet is used to retrieve that precise piece of database information that is missing. Link-state packets are also used after the DBD exchange is finished to request the LSAs that have been seen during the DBD exchange. Figure 8-4 illustrates the link-state request packet format. Figure 8-4. Link-State Request Packet Format The list that follows describes the fields in the link-state request packet: LS Type— Identifies what type of LSA is being requested. Link-State ID— Represents the link-state ID of that specific LSA. Link-state ID is discussed later in this chapter. Advertising Router— Contains the router ID of the router that is originating this LSA. Link-State Update Packets OSPF packet Type 4, the link-state update packet, implements flooding. Several LSAs are included in a single packet. Link-state update packets are also sent in response to link-state request packets. Flooded LSAs are acknowledged in the LSA acknowledgment packet. If an LSA is not acknowledged, it is retransmitted every retransmit interval (5 seconds, by default). Figure 8-5 illustrates the link-state update packet format. Figure 8-5. Link-State Update Packet Format As Figure 8-5 shows, this packet contains the number of LSAs (for example, 10 or 20 LSAs), followed by the LSA itself. Link-State Acknowledgment Packet The last type of OSPF packet, the link-state acknowledgment packet, is used to acknow-ledge each LSA. This packet is sent in response to link-state update packets. Multiple LSAs can be acknowledged in a single link-state acknowledgment packet. This packet is respon-sible for the reliable delivery of link-state update packets. Figure 8-6 illustrates the link-state acknowledgment packet format. Figure 8-6. Link-State Acknowledgment Packet Format Link-state acknowledgment packets are sent as multicasts. If the state of the router is DR or BDR, the acknowledgment is sent to the OSPF router multicast address of 224.0.0.5. If the state of the router is not DR or BDR, the acknowledgment is sent to the all DR router multicast address of 224.0.0.6.

Cisco Performance Routing (PfR) / Optimized Edge Routing (OER)

http://blog.ine.com/2011/11/01/cisco-performance-routing-pfr-optimized-edge-routing-oer/#more-6237

BGP Regular Expression

On R4, I only want to learn routes from R5 that originated from AS100 and deny everything else. One way of accomplishing this is to use a BGP filter-list. We will use the topology in figure 1.

Figure 1

Current BGP Config with the filter-list already applied.

R4#show running-config | section router bgp
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 network 172.17.1.0 mask 255.255.255.0
 network 175.175.1.0 mask 255.255.255.0
 neighbor 192.168.4.2 remote-as 100
 neighbor 192.168.4.2 weight 100
 neighbor 192.168.4.2 maximum-prefix 100
 neighbor 192.168.6.2 remote-as 300
 neighbor 192.168.6.2 filter-list 1 in
 no auto-summary
R4#


Verify debug:

R4#show debugging
IP routing:
  BGP updates debugging is on for address family: IPv4 Unicast


Verify AS Path Access-List:

R4#show ip as-path-access-list
AS path access list 1
    permit ^100$

Perform a route refresh for peer 192.168.6.2:

R4#clear ip bgp 192.168.6.2 in
R4#

Confirms AS Path Access-List is working as expected from debug:

*Mar  1 01:00:14.715: BGP(0): 192.168.6.2 rcvd UPDATE w/ attr: nexthop 192.168.6.2, origin i, localpref 100, metric 0
*Mar  1 01:00:14.719: BGP(0): 192.168.6.2 rcvd 176.176.1.0/24 -- DENIED due to: filter-list;
*Mar  1 01:00:14.723: BGP(0): 192.168.6.2 rcvd 172.19.1.0/24 -- DENIED due to: filter-list;
*Mar  1 01:00:14.727: BGP(0): 192.168.6.2 rcvd 172.18.1.0/24 -- DENIED due to: filter-list;
*Mar  1 01:00:14.731: BGP(0): 192.168.6.2 rcvd UPDATE w/ attr: nexthop 192.168.6.2, origin i, localpref 100, metric 0, path 100
*Mar  1 01:00:14.735: BGP(0): 192.168.6.2 rcvd 9.9.9.0/24
*Mar  1 01:00:14.743: BGP(0): 192.168.6.2 rcvd UPDATE w/ attr: nexthop 192.168.6.2, origin i
R4#, localpref 100, metric 0, path 100
*Mar  1 01:00:14.747: BGP(0): 192.168.6.2 rcvd 8.8.8.0/24
*Mar  1 01:00:14.751: BGP(0): 192.168.6.2 rcvd 7.7.7.0/24
*Mar  1 01:00:14.751: BGP(0): 192.168.6.2 rcvd UPDATE w/ attr: nexthop 192.168.6.2, origin ?, localpref 100, metric 0, path 100
*Mar  1 01:00:14.751: BGP(0): 192.168.6.2 rcvd 177.177.1.0/24

Verifying BGP database:

R4#show ip bgp
BGP table version is 32, local router ID is 175.175.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i7.7.7.0/24       192.168.6.2              0    100      0 100 i
*>                  192.168.4.2                          100 100 i
* i8.8.8.0/24       192.168.6.2              0    100      0 100 i
*>                  192.168.4.2                          100 100 i
* i9.9.9.0/24       192.168.6.2              0    100      0 100 i
*>                  192.168.4.2              0           100 100 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 172.17.1.0/24    0.0.0.0                  0         32768 i
*> 175.175.1.0/24   0.0.0.0                  0         32768 i
* i177.177.1.0/24   192.168.6.2              0    100      0 100 ?
*>                  192.168.4.2                          100 100 ?
R4#

Further Reading:

Using Regular Expressions in BGP

Juniper Using Regular Expressions

Show IP BGP Explained

show ip bgp 1.1.1.1

192.168.1.1 (metric 700) from 192.168.1.1 (192.168.1.1)
Origin IGP, Metric 1700, localpref 100, valid, internal, best

1. Next-hop.
2. IGP metric to reach next-hop. Taken directly from the routing table.
3. Address of the router that gave you the update.
4. ID of that router.
5. MED - multi-exit discriminator

Secure Cisco IOS BGP Template - BGP Best Practice

Great Read.

http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html

Cisco Nexus3064 Debug - OSPF

While troubleshooting some OSPF issues, I notice that NX_OS has a nice feature for the debug command. You can debug on a per interface basis and you can also specify multiple interfaces as well. I always recommend when you run any debug command that you open up a second session into the device in case your current window gets overloaded with debug details. This allows you to issue a undebug all on the new window. This can be a lifesaver..

Cisco3064(config)# debug-filter ip ospf interface ethernet 1/29
Cisco3064(config)# debug ip ospf hello
Cisco3064(config)# debug ip ospf retransmission
Cisco3064(config)# 2012 Aug  4 10:40:34.366851 ospf: 64996 [14437] (default)  P2P hello out, ivl 5/15, options 0x02, mask /31 nbrs 1 on Ethernet1/29 (area 0.0.0.200)
2012 Aug  4 10:40:34.390927 ospf: 64996 [14437] (default) P2P hello in, ivl 5/15, options 0x12, mask /31, on Ethernet1/29 from 192.168.222.188
2012 Aug  4 10:40:38.787021 ospf: 64996 [14437] (default)  P2P hello out, ivl 5/15, options 0x02, mask /31 nbrs 1 on Ethernet1/29 (area 0.0.0.200)
2012 Aug  4 10:40:39.309019 ospf: 64996 [14437] (default) P2P hello in, ivl 5/15, options 0x12, mask /31, on Ethernet1/29 from 192.168.222.188
2012 Aug  4 10:40:43.097571 ospf: 64996 [14437] (default)  P2P hello out, ivl 5/15, options 0x02, mask /31 nbrs 1 on Ethernet1/29 (area 0.0.0.200)
2012 Aug  4 10:40:43.869513 ospf: 64996 [14437] (default) P2P hello in, ivl 5/15, options 0x12, mask /31, on Ethernet1/29 from 192.168.222.188
2012 Aug  4 10:40:46.867897 ospf: 64996 [14437] (default)  P2P hello out, ivl 5/15, options 0x02, mask /31 nbrs 1 on Ethernet1/29 (area 0.0.0.200)
2012 Aug  4 10:40:48.686036 ospf: 64996 [14437] (default) P2P hello in, ivl 5/15, options 0x12, mask /31, on Ethernet1/29 from 192.168.222.188
2012 Aug  4 10:40:50.887911 ospf: 64996 [14437] (default)  P2P hello out, ivl 5/15, options 0x02, mask /31 nbrs 1 on Ethernet1/29 (area 0.0.0.200)
2012 Aug  4 10:40:53.242538 ospf: 64996 [14437] (default) P2P hello in, ivl 5/15, options 0x12, mask /31, on Ethernet1/29 from 192.168.222.188

Additional Commands:

Cisco3064# show debug ip ospf
debug ip ospf hello
debug ip ospf retransmission

Cisco3064# show debug-filter  ip ospf
debug-filter ip ospf interface Ethernet1/29