OSPF Virtual Links & Redistribution

Router 4 has a problem because it has an area that isn't on a router directly connected to the backbone (area 0) The loopback 4.4.4.4 will not be reachable unless we create a virtual link to area 0. Also R5, will not be able to communicate with the rest of the network unless it uses route redistribution.


R1#show ip route ospf 
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:02:08, 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:02:08, Serial0/0
O IA 192.168.1.0/24 [110/65] via 172.12.123.2, 00:02:08, Serial0/0
R1#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 0 percent (0/5)
R1#ping 5.5.5.5

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

R4(config)#router ospf 1

R4(config-router)#area 13 virtual-link 2.2.2.2

R2#

*Mar  1 02:08:55.195: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 192.168.1.4, FastEthernet0/0

R2(config)#router ospf 1                  

R2(config-router)#area 13 virtual-link 4.4.4.4   

R2(config-router)#

*Mar  1 02:10:15.134: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 192.168.1.4, FastEthernet0/0

*Mar  1 02:10:16.933: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL1 from LOADING to FULL, Loading Done

R1#show ip route ospf 

     2.0.0.0/32 is subnetted, 1 subnets

O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:01:18, 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:01:18, Serial0/0

     4.0.0.0/32 is subnetted, 1 subnets

O IA    4.4.4.4 [110/66] via 172.12.123.2, 00:01:18, Serial0/0

O IA 192.168.1.0/24 [110/65] via 172.12.123.2, 00:01:18, Serial0/0

R1#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 = 24/34/40 ms

R5#show ip route rip

R5#

R3(config)#router ospf 1

R3(config-router)#redistribute rip subnets 

R3(config)#router rip

R3(config-router)#redistribute ospf 1 metric 2

R5#show ip route rip

     1.0.0.0/32 is subnetted, 1 subnets

R       1.1.1.1 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

     2.0.0.0/32 is subnetted, 1 subnets

R       2.2.2.2 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

     3.0.0.0/32 is subnetted, 1 subnets

R       3.3.3.3 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

     4.0.0.0/32 is subnetted, 1 subnets

R       4.4.4.4 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

     172.12.0.0/24 is subnetted, 1 subnets

R       172.12.123.0 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

R    192.168.1.0/24 [120/2] via 10.1.1.3, 00:00:04, FastEthernet0/0

R1#show ip route ospf 

     2.0.0.0/32 is subnetted, 1 subnets

O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:04:06, 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:04:06, Serial0/0

     4.0.0.0/32 is subnetted, 1 subnets

O IA    4.4.4.4 [110/66] via 172.12.123.2, 00:04:06, Serial0/0

     5.0.0.0/32 is subnetted, 1 subnets

O E2    5.5.5.5 [110/20] via 172.12.123.3, 00:04:06, Serial0/0

     10.0.0.0/24 is subnetted, 1 subnets

O E2    10.1.1.0 [110/20] via 172.12.123.3, 00:04:06, Serial0/0

O IA 192.168.1.0/24 [110/65] via 172.12.123.2, 00:04:06, Serial0/0

R1#ping 5.5.5.5       

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/33/40 ms

OSPF Multi-Area

OSPF is a hierarchical because it allows the configuration of multi-areas. Having a layer approach does benefit an organization by having more efficient and concise routing tables, less SPF recalculations and less LSU and LSA traffic. Areas can retain problem from spreading across the enterprise. Below I configured OSPF on each router with their respect areas.

In this frame relay topology, the hub is the only DR and the spokes have been manually remove from the election process.

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    00:01:53    172.12.123.2    Serial0/0
3.3.3.3           0   FULL/DROTHER    00:01:43    172.12.123.3    Serial0/0

Here is some more useful information about the setup. I can see that the network type is non-broadcast, that R1 is the DR, the timer intervals are set at default .

R1#show ip ospf interface

Serial0/0 is up, line protocol is up

  Internet Address 172.12.123.1/24, Area 0

  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1

  No backup designated router on this network

  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

    oob-resync timeout 120

    Hello due in 00:00:29

  Index 1/1, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 3

  Last flood scan time is 0 msec, maximum is 4 msec

  Neighbor Count is 2, Adjacent neighbor count is 2

    Adjacent with neighbor 2.2.2.2

    Adjacent with neighbor 3.3.3.3

  Suppress hello for 0 neighbor(s)

Loopback0 is up, line protocol is up

  Internet Address 1.1.1.1/32, Area 1

  Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1

  Loopback interface is treated as a stub Host

IP routes with the O IA  label are inter-area routes learned by OSPF.

R1#show ip route ospf
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:06:30, 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:06:30, Serial0/0

EIGRP Neighbor Authentication

There are a few steps needed to setup MD5 authentication between EIGRP neighbors. Authentication prevents a router from creating an adjacency with a rogue router trying to inject malicious routes. The pay load of the packets aren't encrypted.

First a key chain name is needed, then a key number, a key chain can have multiple keys. The key string command defines the password.

R1(config)#key chain EIGRPNEI
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string CCNP


Authentication is configured at the interface level, with two commands, ip authentication mode and ip authentication key chain. Adjacencies with neighbors will break and won't come back up until authentication is setup correctly on both sides.

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip authentication mode eigrp 51 md5

R1(config-if)#

*Mar  1 00:09:40.727: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 10.1.1.2 (FastEthernet0/0) is down: authentication mode changed

R1(config-if)#ip authentication key-chain eigrp 51 EIGRPNEI

The show key chain command can be used to verified the password and lifetime.

R1#show key chain

Key-chain EIGRPNEI:

    key 1 -- text "CCNP"

        accept lifetime (always valid) - (always valid) [valid now]

        send lifetime (always valid) - (always valid) [valid now]

R2(config)#key chain EIGRPNEI2

R2(config-keychain)#key 1

R2(config-keychain-key)#key-string CCNP

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip authentication key-chain eigrp 51 EIGRPNEI2

R2(config-if)#ip authentication mode eigrp 51 md5

R2(config-if)#

*Mar  1 00:16:25.033: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 10.1.1.1 (FastEthernet0/0) is up: new adjacency

R2(config-if)#do show key chain

Key-chain EIGRPNEI2:

    key 1 -- text "CCNP"

        accept lifetime (always valid) - (always valid) [valid now]

        send lifetime (always valid) - (always valid) [valid now]

Propagating Default Route via EIGRP

Here I created a hub and spoke topology over Frame Relay using EIGRP AS 51. There is a design flaw;R1 will not be able to tell R3 about R2 routes and vice-versa because of split-horizon. Routes can't be sent out an interface in which it was learned. I want R2 and R3 to communicate so I have a few options. First option is I can turn off split horizon on interface serial 0/0 for just EIGRP 51, create static routes for each other or configure default routes. The best design here will be a default route because the spoke routers (R2,R3) have no other paths but to R1. EIGRP by default will query R2 and R3 for a route when it doesn't have a feasible successor to a lost network. This is a waste of router resources and can eat up CPU cycles if there is a flapping interface. EIGRP can use stub routers to prevent update queries from being sent, received or both.


Here I verify that R2 and R3 don't have each other routes.

R1#show ip route eigrp 
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2297856] via 172.12.123.2, 00:01:04, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:11, Serial0/0

R2#show ip route eigrp 

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 172.12.123.1, 00:02:21, Serial0/0

R3#show ip route eigrp 

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 172.12.123.1, 00:01:20, Serial0/0

First I will demonstrate turning off split horizon. In a simple scenario this might be ok but in complex designs a routing loop can now form without the protect of split horizon. 

R1(config)#interface serial 0/0

R1(config-if)#no ip split-horizon eigrp 51

R1(config-if)#

*Mar  1 00:10:52.112: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.3 (Serial0/0) is down: split horizon changed

*Mar  1 00:10:52.112: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.2 (Serial0/0) is down: split horizon changed

*Mar  1 00:10:58.130: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.3 (Serial0/0) is up: new adjacency

R3#

*Mar  1 00:10:51.640: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.1 (Serial0/0) is down: Interface Goodbye received

*Mar  1 00:11:45.925: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.1 (Serial0/0) is up: new adjacency

Taking a look at R3, I can see that it has now learned the route to R2 and I went ahead and pinged R2 loopback to verify connectivity.

R3#show ip route eigrp 

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 172.12.123.1, 00:00:34, Serial0/0

     2.0.0.0/32 is subnetted, 1 subnets

D       2.2.2.2 [90/2809856] via 172.12.123.1, 00:00:34, Serial0/0

R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/40 ms

Next I turned split horizon back on and I will create two stub routers, R2 and R3. Here I can view the options for a stub network, default is advertises connected, summary routes.

R3(config)#router eigrp 51

R3(config-router)#eigrp stub ?

  connected      Do advertise connected routes

  receive-only   Set IP-EIGRP as receive only neighbor

  redistributed  Do advertise redistributed routes

  static         Do advertise static routes

  summary        Do advertise summary routes

  <cr>

R3(config-router)#eigrp stub 

*Mar  1 00:16:11.011: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 51: Neighbor 172.12.123.1 (Serial0/0) is down: peer info changed

At this point both spoke routers still don't know how to reach each other but the good news is that they will not be queried for routes. Static default routes is another design option that will allow these two spokes to communicate.I created a null route on the hub router to redistribute into EIGRP, metric should be set when redistributing. 

R1(config)#ip route 0.0.0.0 0.0.0.0 null 0 

R1(config)#router eigrp 51

R1(config-router)#redistribute static metric 1544 10 255 1 1500

I can now see a default route in R3's table pointing to R1. The AD is 170 because the route was redistributed into EIGRP it's an external route.

R3#show ip route eigrp 

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 172.12.123.1, 02:25:52, Serial0/0

D*EX 0.0.0.0/0 [170/2172416] via 172.12.123.1, 00:01:55, Serial0/0

Connectivty between both spokes is successful because R1 knows how to reach all networks

R3#ping 2.2.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/36/60 ms

A static route can also be advertised via EIGRP and the route will have an AD of 90 because it is an internal EIGRP route.

R1(config)#router eigrp 51

R1(config-router)#no redistribute static 

R1(config-router)#network 0.0.0.0 

R3#show ip route eigrp 

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/2297856] via 172.12.123.1, 00:00:39, Serial0/0

D*   0.0.0.0/0 [90/2169856] via 172.12.123.1, 00:00:09, Serial0/0

Using the ip default-network command requires some strict requirements, the route must be in classfully learned and redistributed. I accomplished this by turning on auto summary on the hub router. The asterisk means the route is a candidate default route. Compared to other scenarios ip defualt-network option is the least desired.

R1(config)#ip default-network 1.0.0.0

R1#show ip route eigrp 

 *   1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D*      1.0.0.0/8 is a summary, 00:00:42, Null0

     172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks

D       172.12.0.0/16 is a summary, 00:00:42, Null0

R3#show ip route eigrp 

D*   1.0.0.0/8 [90/2297856] via 172.12.123.1, 00:00:03, Serial0/0

     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       3.0.0.0/8 is a summary, 00:05:15, Null0

     172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks

D       172.12.0.0/16 is a summary, 00:05:15, Null0

EIGRP Advance Topics

EIGRP has five packet types

Hello- packets are used to build and maintain neighbor relationships, multicast 224.0.0.10
Acknowledge- packets are empty hello packets used to acknowledge EIGRP packets
Update - packets are used first in a new neighbor relation to build routing and topology table and also when a network changes. Uses RTP.
Query- packets are used when a router loses a successor route and doesn't have a fesiable successor. Uses RTP.
Reply- packets are used to send routing information when a router receives a query packet

Using the show ip eigrp traffic command will display these packets types


R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 1
  Hellos sent/received: 77/27
  Updates sent/received: 4/6
  Queries sent/received: 0/0
  Replies sent/received: 0/0
  Acks sent/received: 4/2
  Input queue high water mark 2, 0 drops
  SIA-Queries sent/received: 0/0
  SIA-Replies sent/received: 0/0
  Hello Process ID: 71
  PDM Process ID: 70

Designing EIGRP to meet certain goals requires configuring more advance EIGRP attributes. EIGRP neighbors converge using hello and hold down timers. Unlike OSPF, hello and hold down (Dead) timers do not need to match between neighbors but the rule of having the hold down timer be three times the hello interval is good practice. My default on high speed links (Ethernet) the hello timer is 5 seconds while the hold timer is 15 seconds. EIGRP will consider a neighbor down after not receiving a hello in 15 seconds. On slower links (T1)the hello timer will default to 60 seconds while the hold down is 180 seconds. Timers can be adjusted to speed time of convergence at the interface level. The command ip hello-interval eigrp <AS> <seconds> similarly with the hold down timer. To verify timers, the show ip eigrp neighbor command will show the hold down timer while the show ip eigrp interfaces detail <interface> command will show the hello timer.


R1#show ip eigrp neighbors 
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.1.2                Se0/0             14 00:01:50    1  3000  0  1

R1(config-if)#ip hello-interval eigrp 100 2 
R1(config-if)#ip hold-time eigrp 100 6

R1#show ip eigrp interfaces detail serial 0/0

IP-EIGRP interfaces for process 100

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Se0/0              1        0/0         0       0/15           0           0

  Hello interval is 2 sec

  Next xmit serial <none>

  Un/reliable mcasts: 0/0  Un/reliable ucasts: 0/2

  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0

  Retransmissions sent: 1  Out-of-sequence rcvd: 0

  Authentication mode is not set

R1#show ip eigrp neighbors 

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   10.1.1.2                Se0/0              5 00:09:03    1  3000  0  1

There might be a time when a connected interface needs to be advertised via EIGRP but no hello messages should be sent because a neighborship should never be formed. Using passive interfaces can accomplish this feat.  In the example below, I used the network command 192.168.1.0 0.0.0.255 in EIGRP 100 because I wanted to advertised the network but by doing so , EIGRP my default is sending hello packets trying to find a neighbor which will never happen. Using passive-interface under router EIGRP mode, I can prevent an accidental EIGRP adjacency and remove wasted bandwidth.

Here we can see EIGRP enable on interface Fa 0/0, which we don't want.

R1#show ip eigrp interfaces 
IP-EIGRP interfaces for process 100

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0              1        0/0        24       0/15          50           0
Fa0/0              0        0/0         0       0/10           0           0

R1(config)#router eigrp 100
R1(config-router)#passive-interface fastEthernet 0/0

After configuring the passive-interface, I can verify that EIGRP is no longer enable on the interface but still being advertised in EIGRP. R2 can still see the routes and ping the Fa0/0 interface.

R1#show ip eigrp interfaces 

IP-EIGRP interfaces for process 100

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Se0/0              1        0/0        24       0/15          50           0

R2#show ip route eigrp 

D    192.168.1.0/24 [90/2172416] via 10.1.1.1, 00:06:51, Serial0/0

R2#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/16 ms

EIGRP has three conditions in which it won't create a neighbor adjacency, AS mismatch, not on the same subnet and metric weights (k-values) are mismatched. Hello and dead timers don't need to match unlike OSPF.

When no subinterfaces are used, just add each VC to get the total bandwidth for the link.

R5(config)# int serial 0/0

R5(config)# bandwidth 768

When no subinterfaces are used and each VC is a different CIR, take the lowest rate and multiply it by the number of VCs. The recommended solution is to use subinterface if possible.

R5(config)# int serial 0/0

R5(config)# bandwidth 168

When using point-to-point subinterfaces with VC of different CIR, set each subinterface to its CIR.

R5(config)# int serial 0/0.1 point-to-point

R5(config-subif)# bandwidth 512

R5(config)# int serial 0/0.2 point-to-point

R5(config-subif)# bandwidth 256

R5(config)# int serial 0/0.3 point-to-point

R5(config-subif)# bandwidth 56

When using mutlipoint subinterfaces with VC of different CIRs, total the CIR for each VC.

R5(config)# int serial 0/0.1 multipoint

R5(config-subif)# bandwidth 824