|
|
You should be familiar with all the OSPF options and knobs before attempting a lab examination. The following section will demonstrate how some of the remaining OSPF configuration parameters may be deployed in a lab scenario. Traffic Engineering (TE)-related OSPF options are beyond the scope of the JNCIP examination and are therefore not covered in this book.
To finish this section, you must complete the following tasks:
Ensure that r5 can load-balance to area 10 internal destinations by adjusting metrics.
Configure r6 so that other routers will not forward transit traffic through it. Your OSPF adjacencies must stay up, and you cannot change interface metrics directly.
Configure the aggregated SONET link between r3 and r4 to reflect a 4-second propagation delay.
The first configuration task requires that we determine how r5 is currently forwarding traffic into area 10, our NSSA:
lab@r5> show route 10.0.4/22 inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22 *[OSPF/10] 00:09:58, metric 3 > via at-0/2/1.35
At present, r5 is displaying only one path to area 10's internal destinations, as represented by the 10.0.4/22 summary LSA. We can gain a clue as to why r4 is not being used by examining the LSDB:
lab@r5> show ospf database netsummary area 0 detail OSPF link state database, area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Summary 10.0.4.0 10.0.3.3 0x80000083 734 0x2 0x3b82 28 mask 255.255.252.0 TOS 0x0, metric 2 Summary 10.0.4.0 10.0.3.4 0x8000005e 874 0x2 0x8957 28 mask 255.255.252.0 TOS 0x0, metric 3 . . .
From this display we can see that the summary metric received from r4 is higher than that being received from r3, which explains why load balancing is not occurring. Fixing this problem requires that the candidate understand that summary metrics are set based upon the highest metric associated with the summary's contributing routes, and that the lack of a direct link between r4 and r1 is causing r4's summary to reflect a higher cost than that sent by r3. You can correct this problem by adding 1 to the metric value of r3's fe-0/0/0 and fe-0/0/1 interfaces as shown next:
[edit protocols ospf] lab@r3# set area 10 interface fe-0/0/0 metric 2 [edit protocols ospf] lab@r3# set area 10 interface fe-0/0/1 metric 2
After committing the changes on r3, we confirm that load balancing is now possible from r5:
lab@r5> show route 10.0.4/22 inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22 *[OSPF/10] 00:02:03, metric 4 > via as1.0 via at-0/2/1.35
r5 now shows two equal-cost paths to area 10's internal routes. The next configuration requirement is to configure r6 so that other routers avoid sending transit traffic toward it. Because you cannot disrupt your adjacencies and you are not permitted to configure interface metrics directly, you pretty much have to use the overload knob as shown next. Before modifying r6 to indicate that its database is overloaded, we first confirm that it is a viable next hop for transit traffic:
lab@r5> show route 10.0.8/30 inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/30 *[OSPF/10] 00:00:36, metric 2 > to 10.0.8.5 via fe-0/0/0.0 to 10.0.8.10 via fe-0/0/1.0
Now, you configure r6 to appear overloaded:
[edit] lab@r6# set protocols ospf overload [edit] lab@r6# commit commit complete
You now confirm the effects as seen from r5:
lab@r5> show route 10.0.8/30 inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/30 *[OSPF/10] 00:02:36, metric 2 > to 10.0.8.10 via fe-0/0/1.0
Good, r5 now sees only r7 as a viable next hop when forwarding to the 10.0.8.0/30 subnet. Examining r6's router LSA displays the result of setting the overload option, which causes transit interface metrics to be set to the maximum value:
lab@r5> show ospf database router detail advertising-router 10.0.9.6 OSPF link state database, area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len OSPF link state database, area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.9.6 10.0.9.6 0x80000192 28 0x2 0xf60a 60 bits 0x2, link count 3 id 10.0.8.5, data 10.0.8.5, type Transit (2) TOS count 0, TOS 0 metric 65535 id 10.0.8.1, data 10.0.8.1, type Transit (2) TOS count 0, TOS 0 metric 65535 id 10.0.9.6, data 255.255.255.255, type Stub (3) TOS count 0, TOS 0 metric 0
The last configuration requirement in this section is to correctly set OSPF to factor in a 4-second propagation delay between r4 and r5. This is accomplished by setting the OSPF transit-delay value at both ends of the aggregated SONET interface that interconnects r4 and r5. The following setting causes the lifetime of all LSAs flooded over r4's aggregated link to be reduced by the alleged 4-second propagation delay of the interface. This transit-delay setting must also be configured on r5:
[edit protocols ospf area 0.0.0.0 interface as0.0] lab@r4# set transit-delay 4 [edit protocols ospf area 0.0.0.0 interface as0.0] lab@r4# show transit-delay 4; authentication-key "$9$3.1g/A0vMX7-w" key-id 10; # SECRET-DATA
![]() |
You have noticed an adjacency formation problem between r3 and r4 in the topology shown in the following graphic:
Displaying the adjacency status returns the following:
[edit interfaces lo0] lab@r3# run show ospf neighbor Address Interface State ID Pri Dead 10.0.2.1 at-0/1/0.35 Full 10.0.3.5 128 36 10.0.2.6 so-0/2/0.100 Down 0.0.0.0 0 106
You can ping r4's 10.0.2.6 address from r3, and the OSPF area 0 stanzas of both routers are as shown:
[edit] lab@r3# show protocols ospf area 0 authentication-type md5; # SECRET-DATA interface at-0/1/0.35 { authentication-key "$9$I-EhyKsYoaUH" key-id 1; # SECRET-DATA } interface so-0/2/0.100 { interface-type nbma; authentication-key "$9$6M9/CpBW87Nb2" key-id 1; # SECRET-DATA neighbor 10.0.2.6 eligible; } interface lo0.0; [edit] lab@r4# show protocols ospf area 0 authentication-type md5; # SECRET-DATA interface so-0/1/0.100 { interface-type nbma; authentication-key "$9$42JUH/9pu1h" key-id 1; # SECRET-DATA neighbor 10.0.4.5 eligible; } interface as0.0 { authentication-key "$9$AXiLuBEx7Vb2a" key-id 1; # SECRET-DATA } interface lo0.0;
Displaying the LSDB on r3 provides an invaluable clue as to the source of the problem. Can you spot the issue?
[edit] lab@r3# run show ospf database router area 0 OSPF link state database, area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.3.3 10.0.3.3 0x80000009 396 0x2 0x7814 72 Router *10.0.3.4 10.0.3.4 0x80000091 2 0x2 0x8491 72 Router 10.0.3.5 10.0.3.5 0x8000000a 384 0x2 0x1f41 84
Tracing hello and error messages indicates that r3 is sending hellos out its so-0/2/0.100 interface, but no hellos are shown as being received and no errors are evident in the trace output. The nature of the problem is evident in this hello message sent from r3 to r4. Have you determined the problem yet?
Jun 11 12:08:16 OSPF sent Hello 10.0.2.5 -> 10.0.2.6 (so-0/2/0.100) Jun 11 12:08:16 Version 2, length 44, ID 10.0.3.4, area 0.0.0.0 Jun 11 12:08:16 checksum 0x0, authtype 2 Jun 11 12:08:16 mask 255.255.255.252, hello_ivl 30, opts 0x2, prio 128 Jun 11 12:08:16 dead_ivl 120, DR 0.0.0.0, BDR 0.0.0.0
If you have determined that r3 is incorrectly using a router ID that rightfully belongs to r4, then a self high-five is in order! This problem is the result of incorrectly assigning r4's loopback address to r3, which has resulted in duplicate RIDs and a broken adjacency between r3 and r4.
![]() |
|
|