Metrics and Various Other Knobs

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 

start sidebar
Troubleshoot an Adjacency Problem

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.

end sidebar




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net