Case Study: OSPF

The following case study is designed to simulate a typical JNCIP OSPF configuration scenario. You should refer to the criteria listing and Figure 3.10, the case study topology, for the information needed to complete the OSPF case study. It is assumed that you will be building your OSPF configuration on top of the interface configuration that was left from the case study at the end of Chapter 2. You should remove any protocol, policy, and static route configurations related to the previous examples given in this chapter from all seven routers before starting.

click to expand
Figure 3.10: OSPF case study topology

It is expected that a prepared JNCIP exam candidate will be able to complete this case study in approximately one hour, and that the resulting OSPF network will have no serious operational problems. Sample OSPF configurations for all seven routers are provided at the end of the case study to compare with your own configurations. Multiple solutions to the same requirement are often possible, so differences between these sample configurations and those created by you will not necessarily indicate that mistakes have been made. Because you are graded on the overall functionality of your IGP, and its conformance to the specified configuration criteria, various operational mode commands will be shown to allow you to compare the behavior of your network to a known good example.

To complete this case study, you must ensure that your OSPF configuration meets the following criteria:

  • RID based on lo0 address and reachable via OSPF for all routers.

  • Loopback addresses from the backbone must appear as summary LSAs in area 20.

  • The 10.0.5/25 subnet between r1 and r2 must appear in area 0 as an external route. Ensure that no adjacencies can be established over this subnet.

  • Set the metric of the 10.0.5/24 route to reflect an initial value of 10 and ensure that all routers adjust this value to reflect their internal OSPF cost. Tag this route with the value 420.

  • Ensure that r1 never generates a network LSA.

  • No type 3 or type 5 LSAs in area 1.

  • You must elect a DR on the 10.0.2.4/30 subnet.

  • Summarize all routes (internal and external) into the backbone area, including the 192.168.x/ 24 routes from the RIP router. You must not modify the RIP router's configuration.

  • Area 0 must use md5 authentication with secret of jnx. Configure r6 and r7 to advertise 10.0.5/24 to the RIP router, and ensure that the rip metric sent by r7 is higher than that sent from r6.

  • Advertise the 172.16.40.x RIP router subnets as OSPF internal routes, while ensuring that no adjacency can be established over these interfaces.

  • Except for r5, ensure that no single ABR or link failure will break communications between area 1 routers and the RIP router.

  • Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 10. You may manually set metrics as needed to allow load balancing from r5 to area 1 internal destinations.

  • No static routes.

  • The 10.0.5/24 subnet must be reachable from the RIP router and the path must be optimal.

In this case study, the RIP router is preconfigured and its configuration cannot be modified. Key aspects of the RIP router's configuration are shown in Listing 3.6.

Listing 3.6: RIP Router's Configuration

start example
[edit] lab@rip# show policy-options policy-statement rip {     term 1 {         from protocol [ static rip ];         then accept;     } } [edit] lab@rip# show routing-options static route 192.168.0.0/24 receive; route 192.168.1.0/24 receive; route 192.168.2.0/24 receive; route 192.168.3.0/24 receive; route 192.168.4.0/24 receive; [edit] lab@rip# show interfaces lo0 unit 0 {     family inet {          address 192.168.0.1/32;          address 192.168.1.1/32;          address 192.168.2.1/32;          address 192.168.3.1/32;          address 192.168.4.1/32;     } }
end example

OSPF Case Study Analysis

Each configuration requirement for the case study will now be matched to the necessary configuration steps, and will be confirmed operational within all specified case study guidelines. We begin with the first two configuration criteria:

  • RID based on lo0 address and reachable via OSPF for all routers.

  • Loopback addresses from the backbone must appear as summary LSAs in area 20.

As long as you do not manually specify a RID, your router's RID will be based on its lo0 address. By including the lo0 interface under the area 0 configuration of backbone routers, you ensure that the lo0 address will be injected as a network summary into other areas. These requirements are met with the highlighted configuration entry shown next:

 [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; 

The results are now confirmed in area 20:

lab@r7> show ospf database netsummary advertising-router 10.0.3.5  OSPF link state database, area 0.0.0.20  Type       ID          Adv Rtr       Seq     Age  Opt  Cksum  Len Summary  10.0.2.0    10.0.3.5    0x80000008  1036  0x2  0x61d3  28 Summary  10.0.2.4    10.0.3.5    0x8000000c   900  0x2  0x6db9  28 Summary  10.0.2.8    10.0.3.5    0x80000007   765  0x2  0x131b  28 Summary  10.0.3.3    10.0.3.5    0x80000007   736  0x2  0x4ce2  28 Summary  10.0.3.4    10.0.3.5    0x80000007   601  0x2  0x42eb  28 Summary  10.0.3.5    10.0.3.5    0x80000007   465  0x2  0xfb37  28 Summary  10.0.7.255  10.0.3.5    0x80000007   436  0x2  0x5cb6  28 

We next deal with the following configuration criteria:

  • The 10.0.5/25 subnet between r1 and r2 must appear in area 0 as an external route. Ensure that no adjacencies can be established over this subnet.

  • Set the metric of the 10.0.5/24 route to reflect an initial value of 10 plus OSPF internal cost. Tag this route with the value 420.

  • Ensure that r1 never generates a network LSA.

You must use OSPF export policy on both r1 and r2 to make the 10.0.5/24 subnet appear as an external route in the backbone area. There is no need to run OSPF on the 10.0.5/24 subnet, but if you do, you must include the passive keyword on r1 and r2's fe-0/0/0 interface to prevent adjacency formation. The OSPF export policy must set the correct metric type (a type 1 metric will be increased to reflect internal OSPF cost), initial metric value, and tag setting. The priority setting of 0 on r1's OSPF interfaces ensures it can never be a DR or BDR, and that it can therefore never generate a network LSA in accordance with your configuration requirements. The highlights in the screen captures shown next call out the configuration additions needed to address the requirements listed previously:

[edit] lab@r1# show protocols ospf export external; reference-bandwidth 1g; area 0.0.0.1 {     nssa;     interface fe-0/0/2.0 {          priority 0;      }     interface fe-0/0/1.200 {          priority 0;      } } lab@r1# show policy-options policy-statement external {      term 1 {          from {             route-filter 10.0.5.0/24 exact;         }          then {              metric 10;              tag 420;              external {                 type 1;             }              accept;         }      }      term 2 {          then reject;      } } 

The DR status of r1 is now confirmed:

lab@r1> show ospf interface Interface              State     Area            DR ID           BDR ID       Nbrs fe-0/0/1.200           DRother   0.0.0.1         10.0.3.3        0.0.0.0         1 fe-0/0/2.0             DRother   0.0.0.1         10.0.6.2        0.0.0.0         1

The status of DRother indicates that r1 is neither the DR nor the BDR, despite being one of only two nodes on a broadcast network. This proves that r1 is not eligible to become the DR or BDR. The following test confirms proper operation of the r1 and r2 OSPF export policy:

lab@r5> show ospf database extern detail  OSPF external link state database  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Extern   10.0.5.0         10.0.3.4         0x80000002    170  0x2  0xed80  36   mask 255.255.255.0   Type 1, TOS 0x0, metric 30, fwd addr 0.0.0.0, tag 0.0.1.164 

The 10.0.5/24 prefix appears in the backbone as an external LSA. The metric type, value, and tag setting all appear correct (note that the metric value has increased to reflect r5's cost to the advertising ASBR). In this display, the tag is shown in dotted decimal notation. To view its decimal setting, you can view the resulting route:

lab@r5> show route 10.0.5/24 inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[OSPF/150] 00:27:12, metric 36, tag 420                       > via as1.0

The following configuration requirements must now be addressed:

  • No type 3 or type 5 LSAs in area 1.

  • You must elect a DR on the 10.0.2.4/30 subnet.

  • Area 0 must use md5 authentication with a secret of jnx.

You must configure area 1 as a NSSA with the no-summaries option to meet the area's LSA restrictions. The default-metric option instructs the ABRs to generate the default route needed for area 1 routers to reach inter-area and external destinations. The type-7 keyword is needed to ensure that the default route is generated as a NSSA type 7 LSA, which is in accordance with the requirement that there be no type 3 LSAs in area 1:

[edit] lab@r3# show protocols ospf area 1 nssa {      default-lsa {         default-metric 1;         type-7;     }      no-summaries; } . . . 

The following commands confirm that no type 3 or type 5 LSAs are present in area 1:

[edit] lab@r3# run show ospf database netsummary area 1     OSPF link state database, area 0.0.0.1 [edit] lab@r3# run show ospf database extern area 1 [edit] lab@r3#

The DR requirement for the 10.0.2.4/30 subnet means that you must configure the Frame Relay link between r3 and r4 as an NBMA network so that the DR election algorithm is performed. While it is odd to see a point-to-point WAN link running in NBMA mode, this is a legal NBMA topology and can be fully justified with plans for future backbone expansion. This approach also proves useful for practicing WAN interface configurations in a test bed that forces back-to-back connections due to lack of switching gear.

This example shows a correct area 0 authentication configuration from r3. The key-id value of 1 was not specified in the case study, and so was left to the operator's discretion. This key-id value must be used in all backbone routers for proper area 0 authentication. You can also see that the so-0/2/0.100 interface has been correctly configured for OSPF NBMA operation:

[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;

The following confirms that authentication and DR router election is functional. The presence of neighbors on area 0 interfaces indicates that compatible authentication has been configured, and it is clear from the following output that a DR and BDR have been elected on the so-0/2/0.100

interface in keeping with its NBMA network type. Though not shown, all area 0 adjacencies are confirmed to be in the full state:

[edit] lab@r3# run show ospf interface Interface              State     Area            DR ID           BDR ID       Nbrs at-0/1/0.35            PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         1 lo0.0                  DR       0.0.0.0         10.0.3.3        0.0.0.0         0 so-0/2/0.100           DR       0.0.0.0         10.0.3.3        10.0.3.4        1 fe-0/0/0.0             DR       0.0.0.1         10.0.3.3        0.0.0.0         1 fe-0/0/1.0             BDR      0.0.0.1         10.0.6.2        10.0.3.3        1

We next examine the following configuration criterion:

  • Summarize all routes (internal and external) into the backbone area. You must not modify the RIP router's configuration.

Internal route summarization is performed by the ABRs, and is configured under areas 1 and 20. Your summarization must include the area's physical, loopback, and RIP router subnets as applicable. Area 1 summarization is configured as shown next:

[edit] lab@r3# show protocols ospf area 1 nssa {      default-lsa {         default-metric 1;         type-7;     }      no-summaries; } area-range 10.0.4.0/22; interface fe-0/0/0.0 {      metric 20; } interface fe-0/0/1.0 {      metric 20; } 

Because there is only one NSSA external route in area 1, there is no need for NSSA summarization through an area range specified within the NSSA stanza. Summarization for area 20, as configured on r5, is shown next:

[edit] lab@r5# show protocols ospf area 20 area-range 172.16.40.0/28; area-range 10.0.8.0/21; interface fe-0/0/0.0; interface fe-0/0/1.0;

Because type 5 LSAs can be summarized only at the originating ASBR, the summarization of the 192.168.x/24 RIP routes must be performed on r6 and r7 using OSPF export policy and a locally configured aggregate route, as shown next. The presence of any 192.168.x/24 RIP routes will cause the aggregate route to be active:

[edit] lab@r7# show policy-options policy-statement ospf-out term 1 {     from {         protocol aggregate;         route-filter 192.168.0.0/22 exact;     }      then accept; } term 2 {      then reject; } [edit] lab@r7# show routing-options aggregate route 192.168.0.0/22; 

Address summarization is confirmed in area 0 with the commands shown in Listing 3.7:

Listing 3.7: Verify Address Summarization in the Backbone

start example
[edit] lab@r3# run show route 192.168/16 inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/22     *[OSPF/150] 01:14:08, metric 0, tag 0                     > via at-0/1/0.35 [edit] lab@r3# run show route 10.0.8.0 inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/21         *[OSPF/10] 00:13:58, metric 26                      > via at-0/1/0.35 [edit] lab@r3# run show route 10.0.9.0 inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.8.0/21         *[OSPF/10] 00:14:03, metric 26                      > via at-0/1/0.35 lab@r5>  show route 10.0.4.0 inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22         *[OSPF/10] 01:16:25, metric 36                      > via at-0/2/1.35 lab@r5>  show route 10.0.6.0 inet.0: 26 destinations, 29 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22         *[OSPF/10] 01:16:33, metric 36                      > via at-0/2/1.35 
end example

The results shown in Listing 3.7 confirm that the internal and external addresses associated with the non-backbone areas are being correctly summarized before injection into the backbone area.

We now address the following configuration criteria:

  • Configure r6 and r7 to advertise 10.0.5/24 to the RIP router. Ensure that the rip metric sent by r7 is higher than that sent from r6.

  • Advertise the 172.16.40.x RIP router subnets as OSPF internal routes, while ensuring that no adjacency can be established over these interfaces.

For the first of the two requirements, r7 is configured to set the metric of advertised routes to 2, which is higher than the metric of 1 associated with the routes sent by r6. The rip-out export policy causes the OSPF route 10.0.5/24 to be exported into RIP:

[edit] lab@r7# show protocols rip group rip {     metric-out 2;     export rip-out;     neighbor fe-0/3/3.0 {          import rip-in;      } } [edit] lab@r7# show policy-options policy-statement rip-out term 1 {     from {          protocol ospf;         route-filter 10.0.5.0/24 exact;      }      then accept; } term 2 {      then reject; }

To address the second requirement, both r6 and r7 have been configured to list their RIP router interfaces as passive under OSPF. This prevents adjacency formation while causing the associated routes to be advertised as OSPF internals:

[edit] lab@r7# show protocols ospf export ospf-out; reference-bandwidth 1g; area 0.0.0.20 {      interface fe-0/3/0.0;      interface fe-0/3/1.0;     interface fe-0/3/3.0 {         passive;     } } 

To prevent loops and the possibility of inefficient routing, a RIP import policy has been defined (and applied to RIP) to ensure that r6 and r7 will accept only the 192.168.x/24 routes from the RIP router:

[edit] lab@r7# show policy-options policy-statement rip-in term 1 {     from {         protocol rip;         route-filter 192.168.0.0/22 orlonger;      }      then accept; } term 2 {      then reject; } [edit] lab@r7# show protocols rip group rip {     metric-out 2;     export rip-out;     neighbor fe-0/3/3.0 {         import rip-in;      } }

We next analyze the following requirement:

  • Except for r5, ensure that no single ABR or link failure will break communications between area 1 routers and the RIP router.

To achieve this requirement, you must ensure that both r3 and r4 are generating a default route into area 1, and that both r6 and r7 are advertising the aggregate for the RIP routes. Load balancing from the RIP router will not function because of the different metrics being advertised by r6 and r7, but the failure of r6 will not isolate the RIP router once network reconvergence is complete. The following commands confirm that the redundancy requirements have been met:

lab@r1> show ospf database nssa  OSPF link state database, area 0.0.0.1  Type   ID            Adv Rtr         Seq      Age  Opt  Cksum  Len NSSA   0.0.0.0     10.0.3.3      0x80000007    692  0x0  0xdd5e  36 NSSA   0.0.0.0     10.0.3.4      0x80000007   1246  0x0  0xd763  36 

The presence of two default routes in area 1 confirms that the loss of either r3 or r4 will not isolate area 1 routers. We now confirm that both r6 and r7 are advertising the RIP aggregate:

lab@r5# run show ospf database extern     OSPF external link state database  Type        ID            Adv Rtr         Seq      Age  Opt  Cksum  Len Extern    10.0.5.0       10.0.3.4     0x8000000b    380  0x2  0xdb89  36 Extern    192.168.0.0    10.0.9.6     0x80000003   1313  0x2  0x60f0  36 Extern    192.168.0.0    10.0.9.7     0x80000009    451  0x2  0x4efb  36

We now verify that the RIP router correctly points to r6 when forwarding to 10.0.5/24, until r6 has its RIP interface deactivated:

[edit] lab@rip# run show route protocol rip inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24        *[RIP/100] 02:02:48, metric 2, tag 420                     > to 172.16.40.2 via fe-0/0/0.0 [edit] lab@r6# deactivate interfaces fe-0/1/3 [edit] lab@r6# commit commit complete

After taking r6 out of the equation, you confirm that r7 takes over:

[edit] lab@rip# run show route protocol rip inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[RIP/100] 00:00:09, metric 3, tag 420                        > to 172.16.40.6 via fe-0/0/1.0 

Great-the RIP router fails over to r7 as expected, so we can reactivate r6's fe-0/1/3 interface. We now address the following (and last) configuration requirement:

  • Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 10, excepting manual settings needed to allow load balancing from r5 to internal destinations in area 1.

To meet this requirement, you must set the OSPF reference bandwidth to 1 Gig on all routers, which will result in an automatic metric setting of 10 for 100Mbps interfaces. The default OSPF reference bandwidth of 100Mbps had caused all interface used in this sample JNCIP test bed to have a metric of 1, which results in path optimization based on hop count. To achieve the required load balancing at r5, you must manually set metrics in area 1 (so that both r3 and r4 advertise the same metric in their network summary) and you must set the metric of the aggregated SONET link so that it has the same OSPF cost as the slower ATM link. The load-balancing requirement can be met with an asymmetric metric assignment on the aggregated SONET interface, which is the approach taken in the following, in that the default metric has been left in place for r4's as0 interface:

[edit] lab@r3# show protocols ospf reference-bandwidth 1g; area 0.0.0.1 {     nssa {          default-lsa {             default-metric 1;             type-7;         }          no-summaries;      }      area-range 10.0.4.0/22;      interface fe-0/0/0.0 {          metric 20;      }      interface fe-0/0/1.0 {          metric 20;      } } area 0.0.0.0 {      . . . [edit] lab@r5# show protocols ospf area 0 authentication-type md5; # SECRET-DATA interface lo0.0; interface at-0/2/1.35 {    authentication-key "$9$LaA7dskqf5F/" key-id 1; # SECRET-DATA  } interface as1.0 {    metric 6;    authentication-key "$9$LBa7dskqf5F/" key-id 1; # SECRET-DATA  } 

You now confirm the correct load-balancing behavior at r5:

[edit] lab@r5# run show route 10.0.4/22 inet.0: 26 destinations, 28 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.4.0/22        *[OSPF/10] 00:53:46, metric 36                        via as1.0                     > via at-0/2/1.35 10.0.5.0/24        *[OSPF/150] 00:53:46, metric 36, tag 420                      > via as1.0

The presence of a single next hop for the 10.0.5/24 prefix is not a problem because this is not an area 1 internal route.

The last check is to verify RIP router connectivity and optimal forwarding paths through your network, in accordance with this stipulation:

  • The 10.0.5/24 subnet must be reachable from the RIP router using optimal paths.

Forwarding to 10.0.5/24 from area 20 is confirmed with the following test performed at the RIP router:

lab@rip> traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 172.16.40.2 (172.16.40.2) 0.194 ms 0.248 ms 0.095 ms  2 10.0.8.6 (10.0.8.6) 0.326 ms 0.295 ms 0.277 ms  3 10.0.2.10 (10.0.2.10) 0.331 ms 0.314 ms 0.294 ms  4 10.0.4.10 (10.0.4.10) 0.234 ms 0.256 ms 0.218 ms  5 10.0.5.1 (10.0.5.1) 0.314 ms 0.296 ms 0.283 ms 

The results of the RIP router traceroute indicate that it is forwarding through r6, so we now know that r6 will use the path shown in the traceroute to reach the 10.0.5/24 subnet. Some candidates may be thrown by the extra hop caused by r5 forwarding through r4 instead of r3. This inefficiency is the result of r4 having a higher RID than r3, and therefore being the only ABR that is performing the type 7 to type 5 LSA translations for the NSSA. This is confirmed by changing the traceroute target to the address owned by r2, which confirms optimal forwarding:

lab@rip> traceroute 10.0.5.2 traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets  1 172.16.40.2 (172.16.40.2) 0.196 ms 0.229 ms 0.094 ms  2 10.0.8.6 (10.0.8.6) 0.332 ms 0.294 ms 0.276 ms  3 10.0.2.10 (10.0.2.10) 0.330 ms 0.307 ms 0.294 ms  4 10.0.5.2 (10.0.5.2) 0.238 ms 0.228 ms 0.220 ms

We now verify that r7 can also reach the 10.0.5/24 subnet using an optimal path, because the failure of r6 would cause r7 to become part of the forwarding path:

lab@r7> traceroute 10.0.5.2 traceroute to 10.0.5.2 (10.0.5.2), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.351 ms 0.257 ms 0.216 ms  2 10.0.2.10 (10.0.2.10) 0.274 ms 0.247 ms 0.243 ms  3 10.0.5.2 (10.0.5.2) 0.179 ms 0.169 ms 0.155 ms

OSPF Case Study Configurations

The configuration changes needed to complete the OSPF IGP case study for all routers in the test bed are provided in Listings 3.8 through 3.14.

Listing 3.8: r1 OSPF-Related Configuration

start example
[edit] lab@r1# show policy-options policy-statement external {     term 1 {          from {              route-filter 10.0.5.0/24 exact;         }          then {              metric 10;             tag 420;              external {                 type 1;             }              accept;         }      }     term 2 {         then reject;      } } [edit] lab@r1# show protocols ospf export external; reference-bandwidth 1g; area 0.0.0.1 {      nssa;     interface fe-0/0/2.0 {          priority 0;      }     interface fe-0/0/1.200 {          priority 0;      } } 
end example

Listing 3.9: r2 OSPF-Related Configuration

start example
[edit] lab@r2# show protocols ospf reference-bandwidth 1g; area 0.0.0.1 {      nssa;      interface fe-0/0/1.0;      interface fe-0/0/2.0;      interface fe-0/0/3.0; } [edit] lab@r2# show policy-options policy-statement external {     term 1 {         from {              route-filter 10.0.5.0/24 exact;         }         then {              metric 10;              tag 420;              external {                 type 1;             }             accept;         }      }     term 2 {          then reject;      } }
end example

Listing 3.10: r3 OSPF-Related Configuration

start example
[edit] lab@r3# show protocols ospf reference-bandwidth 1g; area 0.0.0.1 {     nssa {          default-lsa {             default-metric 1;             type-7;         }          no-summaries;      }      area-range 10.0.4.0/22;      interface fe-0/0/0.0 {          metric 20;      }      interface fe-0/0/1.0 {          metric 20;      } } area 0.0.0.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; } 
end example

Listing 3.11: r4 OSPF-Related Configuration

start example
[edit] lab@r4# show protocols ospf reference-bandwidth 1g; area 0.0.0.1 {     nssa {          default-lsa {             default-metric 1;             type-7;         }          no-summaries;      }      area-range 10.0.4.0/22;     interface fe-0/0/1.0; } area 0.0.0.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; }
end example

Listing 3.12: r5 OSPF-Related Configuration

start example
[edit] lab@r5# show protocols ospf reference-bandwidth 1g; area 0.0.0.0 {     authentication-type md5; # SECRET-DATA     interface lo0.0;      interface at-0/2/1.35 {          authentication-key "$9$LaA7dskqf5F/" key-id 1; # SECRET-DATA      }     interface as1.0 {         metric 6;          authentication-key "$9$LBa7dskqf5F/" key-id 1; # SECRET-DATA      } } area 0.0.0.20 {     area-range 172.16.40.0/28;      area-range 10.0.8.0/21;      interface fe-0/0/0.0;      interface fe-0/0/1.0; } 
end example

Listing 3.13: r6 OSPF- and RIP-Related Configuration

start example
[edit] lab@r6# show routing-options aggregate route 192.168.0.0/22; [edit] lab@r6# show policy-options policy-statement rip-in {      term 1 {          from {             protocol rip;             route-filter 192.168.0.0/22 orlonger;         }          then accept;      }      term 2 {          then reject;      } } policy-statement ospf-out {      term 1 {          from {             protocol aggregate;             route-filter 192.168.0.0/22 exact;         }          then accept;     }      term 2 {          then reject;     } } policy-statement rip-out {      term 1 {         from {             protocol ospf;             route-filter 10.0.5.0/24 exact;         }          then accept;     }      term 2 {          then reject;     } } [edit] lab@r6# show protocols ospf {      export ospf-out;     reference-bandwidth 1g;     area 0.0.0.20 {          interface fe-0/1/0.0;          interface fe-0/1/1.0;         interface fe-0/1/3.0 {              passive;          }     } } rip {     group rip {         export rip-out;          neighbor fe-0/1/3.0 {             import rip-in;          }     } } 
end example

Listing 3.14: r7 OSPF- and RIP-Related Configuration

start example
[edit] lab@r7# show routing-options aggregate route 192.168.0.0/22; [edit] lab@r7# show policy-options policy-statement rip-in {      term 1 {          from {             protocol rip;             route-filter 192.168.0.0/22 orlonger;         }          then accept;      }      term 2 {          then reject;      } } policy-statement ospf-out {      term 1 {          from {             protocol aggregate;             route-filter 192.168.0.0/22 exact;         }          then accept;      }      term 2 {          then reject;      } } policy-statement rip-out {      term 1 {          from {             protocol ospf;             route-filter 10.0.5.0/24 exact;         }          then accept;      }      term 2 {          then reject;     } } [edit] lab@r7# show protocols ospf {      export ospf-out;     reference-bandwidth 1g;     area 0.0.0.20 {          interface fe-0/3/0.0;          interface fe-0/2/1.0;         interface fe-0/3/3.0 {              passive;         }     } } rip {     group rip {         metric-out 2;         export rip-out;          neighbor fe-0/3/3.0 {             import rip-in;         }     } }
end example




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