OSPF Routing Policy

Export policy can be applied to OSPF to accommodate route redistribution, route tagging, and metric manipulation at ASBRs. JUNOS software does not support the application of import policy for link-state routing protocols such as OSPF. This makes sense when remembering that OSPF exchanges LSAs, not routes, and trying to filter or block incoming LSAs could lead to inconsistent LSDBs, which in turn could result in a protocol malfunction. LSA filtering can only be performed at area borders by deploying stub areas or through the use of area range statements as previously demonstrated in this chapter.

The use of routing policy to accomplish route redistribution has already been demonstrated several times in this chapter, as has the use of policy to set the metric value and type for a redistributed static route. The following configuration example will demonstrate the interaction between route redistribution and global route preference and will also provide examples of RIP configuration and testing in JUNOS software.

Configure OSPF Routing Policy

The topology for this configuration example is shown in Figure 3.7, and the configuration criteria are listed after the figure.

Figure 3.7: OSPF policy and redistribution

• Redistribute the 10.0.5/25 subnet from both r1 and r2 with a metric of 50 and a route tag value of 420. The metric value must remain 50 on all routers.

• Advertise the 10.0.5/24 prefix to the RIP router from both r6 and r7.

• Advertise RIP routes 192.168.0/24 through 192.168.3/24 into area 1 from both r6 and r7.

• Ensure that the RIP router, r6, and r7 can reach destinations on the 10.0.5/24 subnet.

• No single point of failure should isolate the RIP router from reaching the 10.0.5/24 subnet.

RIP Router Configuration

The pertinent portions of the RIP router configuration are shown and described next:

 [edit] lab@rip# show protocols rip group test {    export rip;    neighbor fe-0/0/0.0;  }

The RIP stanza creates a RIP group called test containing the RIP router’s fe-0/0/0 interface. The members of the test group will export routes based on a policy called rip, the contents of which is shown next:

lab@rip# show policy-options policy-statement rip {    term 1 {      from protocol [ static rip ];      then accept;    }  }

The rip policy will redistribute routes learned through the static or RIP protocols into the RIP protocol. Odd as it may seem, the default JUNOS software export policy for RIP is to reject everything, even RIP routes! This makes RIP unique in the JUNOS software environment because all other protocols have a default export policy that will accept routes learned from that particular protocol. The end result is that export policy is almost always needed when using RIP, even when it is deployed in a simple point-to-point topology with the intent of simply exchanging RIP routes. This policy will cause the RIP router to advertise all active static and RIP routes to r6 and r7, with the exception of routes that are suppressed due to split horizon.

The RIP router’s routing-options stanza contains the various 192.168.x static route definitions that are set to silent discard in this example (this is equivalent to "null 0" in Cisco’s IOS):

[edit] lab@rip# show routing-options static {    route 192.168.0.0/24 discard;    route 192.168.1.0/24 discard;    route 192.168.2.0/24 discard;    route 192.168.3.0/24 discard;    }

The RIP router’s interface configuration correctly sets the addressing for the RIP subnet, and assigns host addresses from each of the 192.168.x static routes to the lo0 address so that pings to host-id 1 on each 192.168.x subnet will complete normally:

 [edit] lab@rip# show interfaces . . . fe-0/0/0 {      unit 0 {          family inet {              address 172.16.40.1/24;         }     } } 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;         }     } }

r1 and r2 OSPF Redistribution Policy

We begin our configuration by creating and applying a policy that will redistribute the 10.0.5/24 direct route from r1 and r2 into OSPF. The following policy works for the requirements of this configuration example; other policy approaches could also be used with similar results. Because the default external metric type is type 2, there is no need to explicitly state the metric type to meet the requirements of this configuration scenario:

[edit policy-options policy-statement direct] lab@r2# show term 1 {      from {         protocol direct;         route-filter 10.0.5.0/24 exact;      }      then {         metric 50;         tag 420;         accept;      } } 

To confirm the redistribution, tagging, and proper connectivity to the 10.0.5/24 subnet, we verify the route’s presence and confirm reachability from r7:

lab@r7> show route 10.0.5/24 inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24        *[OSPF/150] 00:00:13, metric 50, tag 420                      > to 10.0.8.9 via fe-0/3/1.0

These results confirm that the metric, metric type, and tag values are correct (a type 1 metric would have been incremented above the initial setting of 50, so this must be a type 2 metric). We now confirm that r7 can reach the 10.0.5/24 subnet:

[edit] lab@r7# run traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 10.0.8.9 (10.0.8.9) 0.335 ms 0.248 ms 0.216 ms  2 10.0.2.10 (10.0.2.10) 0.280 ms 0.244 ms 0.234 ms  3 10.0.4.10 (10.0.4.10) 0.618 ms 0.694 ms 0.379 ms  4 10.0.5.1 (10.0.5.1) 0.362 ms 0.700 ms 0.377 ms

These results prove that the redistribution of 10.0.5/254 from area 10 is working properly, and that the metric and tag values have been correctly set.

Configure RIP and Redistribution Policy on r6

You will now configure r6 to redistribute routes from OSPF to RIP, and in the reverse direction, from RIP back into OSPF. We begin with the following command that configures r6 to run RIP on its fe-0/1/3 interface:

[edit protocols rip] lab@r6# set group rip neighbor fe-0/1/3 

The resulting RIP configuration is now as follows:

[edit protocols rip] lab@r6# show group rip {    neighbor fe-0/1/3.0;  } 

After committing the changes, we verify that RIP routes are being received from the RIP router:

[edit protocols rip] lab@r6# commit commit complete [edit protocols rip] lab@r6# run show route protocol rip inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24      *[RIP/100] 00:00:04, metric 2                      > to 172.16.40.1 via fe-0/1/3.0 192.168.1.0/24      *[RIP/100] 00:00:04, metric 2                      > to 172.16.40.1 via fe-0/1/3.0 192.168.2.0/24      *[RIP/100] 00:00:04, metric 2                      > to 172.16.40.1 via fe-0/1/3.0 192.168.3.0/24      *[RIP/100] 00:00:04, metric 2                      > to 172.16.40.1 via fe-0/1/3.0 224.0.0.9/32        *[RIP/100] 00:00:04, metric 1

As previously discussed, the default input policy for RIP is to accept RIP routes and the default RIP export policy is to reject everything, even routes learned through RIP. To effect the redistribution of these RIP routes into OSPF, you must now write and apply a routing policy that will accept RIP routes for export into OSPF:

[edit policy-options policy-statement rip-ospf] lab@r6# set term 1 from protocol rip [edit policy-options policy-statement rip-ospf] lab@r6# set term 1 then accept [edit policy-options policy-statement rip-ospf] lab@r6# set term 2 then reject 

The resulting RIP to OSPF redistribution policy is shown next:

[edit policy-options policy-statement rip-ospf] lab@r6# show term 1 {    from protocol rip;    then accept; }  term 2 {    then reject;  } 

The rip-ospf policy is now applied to OSPF as an export policy:

[edit] lab@r6# set protocols ospf export rip-ospf 

With the export policy in place on r6, we confirm the presence of the 192.168.x/24 routes on r5 to verify that RIP-to-OSPF redistribution is working:

lab@r5> show route 192.168/16 inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24     *[OSPF /150] 00:01:00, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0 192.168.1.0/24      *[OSPF/150] 00:01:00, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0 192.168.2.0/24      *[OSPF/150] 00:01:00, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0 192.168.3.0/24      *[OSPF/150] 00:01:00, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0

So far, so good. All the RIP routes are present on r5 as OSPF external routes, and these routes should now be present in the backbone area. The global preference for these external routes will be 150 by default. With RIP to OSPF redistribution working properly, you should now create and apply the policy needed to redistribute the 10.0.5/24 route from OSPF into RIP. The policy shown next will accommodate the requirements of this configuration example, but other policy approaches can also work:

[edit policy-options policy-statement ospf-rip] lab@r6# show term 1 {     from {         protocol ospf;         route-filter 10.0.5.0/24 exact;     }     then accept; } term 2 {     then reject; } 

We now apply the ospf-rip policy as export to the rip group using the following command:

[edit] lab@r6# set protocols rip group rip export ospf-rip 

After committing this change, we confirm that the 10.0.5/24 route is now present on the RIP router:

lab@rip> show route 10/8 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:01:38, metric 2                       > to 172.16.40.2 via fe-0/0/0.0

Great, the route is present and active on the RIP router. We now confirm that the RIP router can ping destinations on the 10.0.5/24 subnet:

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.202 ms 0.232 ms 0.095 ms  2 * * * ^C 

Bummer—despite the presence of the 10.0.5/24 route, the ping and traceroute tests are failing. Because the traceroute results indicate that the RIP router is correctly forwarding the packet to r6, we once again verify that r6 has connectivity to 10.0.5/24:

[edit] lab@r6# run traceroute 10.0.5.1 traceroute to 10.0.5.1 (10.0.5.1), 30 hops max, 40 byte packets  1 10.0.8.6 (10.0.8.6) 0.330 ms 0.257 ms 0.220 ms  2 10.0.2.10 (10.0.2.10) 0.285 ms 0.245 ms 0.233 ms  3 10.0.4.10 (10.0.4.10) 0.176 ms 0.167 ms 0.157 ms  4 10.0.5.1 (10.0.5.1) 0.508 ms 0.677 ms 0.368 ms

This is very strange. The RIP router forwards the packet to r6, and r6 can get to 10.0.5/24, but the RIP router cannot get to 10.0.5/24. Any ideas? A valuable clue can be gained by performing the traceroute from r6 with a packet that is sourced from its fe-0/1/3 interface:

 [edit] lab@r6# run traceroute 10.0.5.1 source 172.16.40.2 traceroute to 10.0.5.1 (10.0.5.1) from 172.16.40.2, 30 hops max, 40 byte packets  1 *^C 

The results obtained when the RIP router sources its traceroute from its lo0 interface are also quite revealing:

[edit] lab@rip# run traceroute 10.0.5.1 source 192.168.0.1 traceroute to 10.0.5.1 (10.0.5.1) from 192.168.0.1, 30 hops max, 40 byte packets  1 172.16.40.2 (172.16.40.2) 0.202 ms 0.224 ms 0.093 ms  2 10.0.8.6 (10.0.8.6) 0.316 ms 0.292 ms 0.278 ms  3 10.0.2.10 (10.0.2.10) 0.346 ms 0.307 ms 0.295 ms  4 10.0.4.10 (10.0.4.10) 0.232 ms 0.230 ms 0.219 ms  5 10.0.5.1 (10.0.5.1) 0.590 ms 0.358 ms 0.475 ms

The information gleaned by sourcing the traceroute from the non-default interfaces reveal the true nature of the problem—which, it would seem, has nothing to do with our OSPF and RIP redistribution policies. The real issue here is the lack of OSPF routes for the 172.16.40.x addressing being used on the r6-to-RIP router link. Listing r6’s fe-0/1/3 interface as passive under the OSPF process, or redistributing the 172.16.40.0/24 address from either the RIP router, or r6, will resolve this issue. Being inherently lazy, this author has opted to make a single change on the RIP router that will solve this problem for now for r6, and later for r7:

[edit routing-options] lab@rip# set static route 172.16.40/28 discard [edit routing-options] lab@rip# commit commit complete

The 172.16.40/28 static route will be redistributed into RIP, and from there into OSPF, by both r6 and r7. This ensures that routers within the OSPF domain will know how to route packets back to the 172.16.40/28 subnet. The effects are confirmed after the change has been committed:

[edit routing-options] lab@rip# run 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.199 ms 0.228 ms 0.096 ms  2 10.0.8.6 (10.0.8.6) 0.333 ms 0.292 ms 0.275 ms  3 10.0.2.10 (10.0.2.10) 0.331 ms 0.306 ms 0.295 ms  4 10.0.4.10 (10.0.4.10) 0.237 ms 0.229 ms 0.217 ms  5 10.0.5.1 (10.0.5.1) 0.470 ms 0.357 ms 0.479 ms 

Based on these results, it would appear that most of the configuration requirements have been met for this configuration example, at least as far as the configuration and operation of r6is concerned. You must now complete the configuration by ensuring that both r6 and r5 per- form OSPF and RIP route redistribution to ensure that neither r6 nor r7 represents a single point of failure in the network.

Why a /28 Netmask for a /24 Subnet?

The reader may find it odd that a static route for the 172.16.40/24 subnet was created with a 28-bit mask in this example. This approach was used to ensure that the static route would be active, and therefore eligible for export, when compared against the directly connected 172.16.40/24 subnet, because direct routes have a higher global preference than static routes. Because the /28 mask is more specific than the /24 direct route, the static route will now be considered active, and the /28 mask encompasses host addresses in the range of 1–15, which meets all connectivity requirements of this configuration example. This approach was taken because it eliminated the need for export policy route-filter statements that would otherwise have been needed to prevent the redistribution of other direct routes (such as the 192.168.x.1/32 lo0 addresses) on the RIP router.

Configure RIP and Policy on r7

To complete the OSPF policy task, the operator in this example has decided to mirror the RIP and routing policy configuration of r6 into r7, because this can be performed easily using load merge terminal and because this configuration appears to be working great for r6.

Because the use of load merge can be an important timesaver, the operational steps needed to rapidly modify r7 with the RIP and redistribution policy–related configuration from r6 are outlined next.

First, the operator displays the protocol and policy-options stanzas from r6’s configuration, as shown in Listing 3.4:

Listing 3.4: r6’s Protocol and Policy Stanzas

 [edit] lab@r6# show protocols ospf {     export rip-ospf;     area 0.0.0.1 {         authentication-type simple; # SECRET-DATA          interface fe-0/1/0.0 {             authentication-key "$9$GEjkPpu1Icl"; # SECRET-DATA         }          interface fe-0/1/1.0 {             authentication-key "$9$/hZQAu18LN-wg"; # SECRET-DATA         }     } } rip {     group rip {         export ospf-rip;         neighbor fe-0/1/3.0;     } } [edit] lab@r6# show policy-options policy-statement rip-ospf {      term 1 {          from protocol rip;          then accept;     }      term 2 {          then reject;     } } policy-statement ospf-rip {      term 1 {         from {              protocol ospf;             route-filter 10.0.5.0/24 exact;         }          then accept;     }      term 2 {          then reject;     } }

After verifying that the information is generic enough to apply to r7’s environment, the highlighted portions shown in Listing 3.4 are removed, the RIP interface name is changed, and curly braces are added as shown in Listing 3.5:

Listing 3.5: Modified Protocol and Policy Stanzas

protocols { rip {     group rip {         export ospf-rip;         neighbor fe-0/3/3.0;      } }           } policy-options { policy-statement rip-ospf {      term 1 {          from protocol rip;          then accept;      }      term 2 {          then reject;      } } policy-statement ospf-rip {      term 1 {         from {              protocol ospf;             route-filter 10.0.5.0/24 exact;         }          then accept;      }      term 2 {          then reject;      } }        }

The resulting code is then loaded into r7 using the load merge terminal option. After the load completes, the operator manually applies the rip-ospf policy as an OSPF export policy and commits the configuration. Many operators find that having to remember where the curly braces go, and what statements still have to be configured after the merge is performed, makes the whole "pasting from a terminal thing" too much bother for all but the most compelling of cases. In the final analysis, the time saved from cut-and-paste operations may be negligible, or may be significant, depending on your typing skill and overall familiarity with the JUNOS software command-line interface (CLI).

Warning 

Opting for load override terminal would have left you feeling relieved that your old config was only a rollback 1 away, or at least you will be relieved once you realize that you have just blown away r7’s configuration by overwriting it with a few measly code snippets intended only to augment its configuration with RIP support and route redistribution policies.

Verify OSPF Policy and Redistribution

After adding the RIP configuration and redistribution policies to r7, we now verify that all is well with our network by confirming the RIP router has two next hops for 10.0.5/25 (both r6 and r7 should be advertising the route to the RIP router), and that the RIP router can reach destinations on the 10.0.5/24 subnet:

lab@rip> show route 10/8 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24         *[RIP/100] 00:49:33, metric 2                      > to 172.16.40.2 via fe-0/0/0.0

Darn, there should be two viable and equal-cost next hops for the RIP router. Based on these results, it looks like r7 is not correctly redistributing the 10.0.5/25 prefix. We will investigate the missing next hop in a bit, but we might as well verify forwarding to the 10.0.5/24 subnet while we are on 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.196 ms 0.230 ms 0.096 ms  2 172.16.40.3 (172.16.40.3) 0.148 ms 0.141 ms 0.128 ms  3 172.16.40.2 (172.16.40.2) 0.159 ms 0.167 ms 0.158 ms  . . . 29 172.16.40.2 (172.16.40.2) 0.989 ms 0.999 ms 0.987 ms 30 172.16.40.3 (172.16.40.3) 1.021 ms 1.029 ms 1.020 ms lab@rip>

Not good, unless of course you like packet loops! As is so often the case when performing mutual route redistribution, we have managed to create a packet loop somewhere in the network. Seems like we should poke around on r7 due to the indication that it is not advertising the 10.0.5/24 route to the RIP router:

lab@r7> show route 10.0.5/24 inet.0: 30 destinations, 36 routes (30 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24          *[RIP/100] 00:37:48, metric 2                       > to 172.16.40.2 via fe-0/3/3.0 

Interesting. r7 is using a 10.0.5/24 route learned through RIP from r6, which explains why r7 was not listed as a next hop on the RIP router—split horizon is preventing r7 from advertising the 10.0.5/24 prefix back out the interface it was learned on. A quick look at r6 confirms the presence of a loop:

lab@r6> show route 10.0.5/24 inet.0: 28 destinations, 34 routes (28 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24         *[OSPF/150] 00:37:59, metric 2, tag 0                      > to 10.0.8.2 via fe-0/1/1.0 

From these displays, we see that r7 is forwarding packets addressed to 10.0.5/24 through r6 based on a RIP route, while r6 forwards these packets back to r7 based on an OSPF route. As with most tragedies, this mess is caused by a number of individual factors that happen to combine and interact in such a way that the end result can be almost impossible to predict, and in many cases, difficult to diagnose when observed. To better understand what has gone wrong, we need to analyze the network’s operation both before and after redistribution was enabled on r7. Figure 3.8 illustrates the situation that existed before r7 was configured to run RIP.

Figure 3.8: Single redistribution point.1

At step 1 we have r1 and r2 flooding type 7 LSAs (NSSA) that advertise the 10.0.5/24 prefix with a type 2 metric setting of 50. r4, the ABR with the highest RID, then translates the type 7 LSAs into a single type 5 that is flooded throughout all non-stub areas, as shown at step 2. Both r6 and r7 receive a copy and install an OSPF route to 10.0.5/24 that correctly points toward r5 with an external metric of 50. This OSPF route is then exported to the RIP segment by r6 where it is received by the RIP router at step 3 of Figure 3.8.

Figure 3.9 shows the effects of bringing r7’s RIP and redistribution configuration online, and explains how this packet loop is being created.

Figure 3.9: Two redistribution points

At step 1 on Figure 3.9 we see that, in this case, r6 generates a RIP update before r7, causing r7 to receive a RIP advertisement from r6 that indicates reachability to 10.0.5/24. Because r7’s rip-ospf policy accepts all RIP routes, and because the global preference value of RIP is preferred over the default preference value assigned to OSPF external routes, r7 installs the RIP route as active and, true to its export policy, proceeds to redistribute it back into OSPF. This is shown at step 2. By default, r7 attaches a metric value to the route that is equal to the metric that would have been advertised by RIP, which in this example is 2. When r5 and r6 receive r7’s external LSA, they both install r7 as the next hop to 10.0.5/24, due to the lower metric value advertised by r7’s LSA.

Now that the reason for the packet loop has been diagnosed, the following section will discuss and demonstrate the most common ways of resolving this type of problem.

RIP Import Policy

It is generally considered that the best approach to this problem is to create and apply a RIP import policy that prevents r6 and r7 from accepting each other’s routes. There are many ways to write such an import policy, but techniques that use the from next-hop or route filter matching conditions are most common. Typical RIP import policy solutions are shown next:

[edit] lab@r6# show policy-options policy-statement rip-in term 1 {     from {         protocol rip;         next-hop 172.16.40.1;     }      then accept; } term 2 {      then reject; }

The policy shown previously is written with a positive approach, and so requires a reject all term to override the default RIP import policy. The policy shown next uses the same principles, but involves less typing:

[edit] lab@r7# show policy-options policy-statement rip-in from {     protocol rip;     next-hop 172.16.40.2; } then reject;

And lastly, a typical route filtering approach is shown in the following:

[edit policy-options] lab@r7# show policy-statement rip-in term 1 {     from {         route-filter 192.168.0.0/22 orlonger;     }     then accept; } term 2 {     then reject; } 

Either of these policies will resolve the packet loop problem when applied to r6 and r7 as a RIP import policy. RIP import policy cannot be applied at the global or group levels, so you apply your import policy at the neighbor level of the RIP configuration hierarchy with the following command:

[edit protocols rip] lab@r7# set group rip neighbor fe-0/3/3.0 import rip-in [edit] lab@r7# show protocols rip group rip {    export ospf-rip;    neighbor fe-0/3/0.0 {       import rip-in;    }  }

The RIP import policy method is generally considered the “best” approach to this dilemma, because it results in both r6 and r7 considering the RIP routes as active, and therefore both routers will be exporting the RIP routes into OSPF as external LSAs. This is an important point because two viable next hops may be required by the specifics of your examination. Also, both r6 and r7 will forward over an optimal path to the RIP router, which may not occur with the alternative solution that is described next. The "optimal" behavior that was described previously is demonstrated in the following capture taken from r5. This screen dump shows that external LSAs are being received from both r6 and r7:

lab@r5> show ospf database extern     OSPF external link state database  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len . . . Extern   192.168.0.0      10.0.9.6         0x80000001    261  0x2  0x87c6  36 Extern   192.168.0.0      10.0.9.7         0x80000001    251  0x2  0x81cb  36 Extern   192.168.1.0      10.0.9.6         0x80000001    261  0x2  0x7cd0  36 Extern   192.168.1.0      10.0.9.7         0x80000001    251  0x2  0x76d5  36 . . . 

With two sets of LSAs confirmed, the presence of two OSPF next hops for the RIP routes is now confirmed on r5:

lab@r5> show route 192.168/16 inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24      *[OSPF/150] 00:00:01, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0                        to 10.0.8.10 via fe-0/0/1.0 192.168.1.0/24      *[OSPF/150] 00:00:06, metric 2, tag 0                        to 10.0.8.5 via fe-0/0/0.0                      > to 10.0.8.10 via fe-0/0/1.0 192.168.2.0/24      *[OSPF/150] 00:00:06, metric 2, tag 0                        to 10.0.8.5 via fe-0/0/0.0                      > to 10.0.8.10 via fe-0/0/1.0 192.168.3.0/24      *[OSPF/150] 00:00:06, metric 2, tag 0                      > to 10.0.8.5 via fe-0/0/0.0                        to 10.0.8.10 via fe-0/0/1.0

Global Preference and OSPF Export Policy

The loop condition can also be resolved by adjusting the global preference associated with either RIP or OSPF externals to cause r6 and r7 to prefer OSPF external routing information to that learned through RIP, while also filtering the 10.0.5/24 route from OSPF redistribution. The following command sets the RIP preference to 160, which will cause OSPF externals (150) to be preferred. This command is needed on both r6 and r7:

[edit protocols rip] lab@r7# set group rip preference 160 

The change in route preference combined with the application of the modified OSPF export policy shown next to both r6 and r7 eliminates the packet loop, and results in both r6 and r7 being listed as next hops for the 10.0.5/24 prefix on the RIP router:

[edit policy-options] lab@r7# show policy-statement rip-ospf term 1 {     from {         protocol rip;         route-filter 10.0.5.0/24 orlonger reject;         route-filter 0.0.0.0/0 orlonger;     }      then accept; } term 2 {      then reject; } 

Failing to change the protocol preference will result in only one next hop for 10.0.5/24 on the RIP router, because one of the ASBR routers (r6 or r7) will otherwise learn about and install the 10.0.5/25 route from RIP advertisements received over the RIP subnet, which prevents that router from sending the 10.0.5/24 prefix to the RIP router because of split horizon. The following capture displays the correct number of next hops for the 10.0.5/24 prefix, as seen from the RIP router:

lab@rip> show route 10/8 inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24         *[RIP/100] 00:05:33, metric 2                       to 172.16.40.2 via fe-0/0/0.0                     > to 172.16.40.3 via fe-0/0/0.0 

While the route preference/OSPF export approach works to break the loop and results in the RIP router correctly seeing two next hops for the10.0.5/24 prefix, this solution is a bit messy because one of the two ASBRs will wind up installing the other ASBR’s externals as the active routes. This situation will lead to less-than-optimal forwarding from that ASBR, because packets addressed to the RIP prefixes will now be forwarded through the other ASBR instead of being sent directly to the RIP router. Another side effect of this approach is that only one ASBR will be redistributing the RIP routes into OSPF at any given time because the RIP routes will be inactive on one of the ASBRs, and only active routes can be exported through policy. Should the ASBR with active RIP routes fail, the remaining ASBR will once again install and redistribute the RIP routes (due to the loss of the OSPF externals from the failed ASBR) so fail-over is still possible with this approach.

This situation is demonstrated in the next set of captures, starting with the confirmation that in this case r6 has redistributed the RIP routes as OSPF externals:

[edit] lab@r7# run show ospf database extern      OSPF external link state database  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len . . . Extern   192.168.0.0      10.0.9.6         0x80000002    806  0x2  0x85c7  36 Extern   192.168.1.0      10.0.9.6         0x80000002    806  0x2  0x7ad1  36 . . . 

The lack of external LSAs from r7 is explained by the results of the following command:

[edit] lab@r7# run show route 192.168.0.0 inet.0: 29 destinations, 36 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.0.0/24     *[OSPF/150] 00:05:49, metric 2, tag 0                      > to 10.0.8.1 via fe-0/3/0.0                      [RIP/160] 12:44:56, metric 2                     > to 172.16.40.1 via fe-0/3/3.0

This capture shows that r7 (in this case) has received the OSPF externals from r6 and, due to the modified route preference, has installed them as the active routes. Because the RIP routes are not active in r7, we expect to find that r7 does not redistribute the RIP routes as OSPF externals, and that r7 will forward through r6 to get to the RIP router, which is a suboptimal path for this topology:

lab@r7# run traceroute 192.168.0.1 source 172.16.40.3 traceroute to 192.168.0.1 (192.168.0.1) from 172.16.40.3, 30 hops max, 40 byte   packets  1 172.16.40.2 (172.16.40.2) 0.211 ms 0.126 ms 0.098 ms  2 192.168.0.1 (192.168.0.1) 0.166 ms 0.140 ms 0.125 ms

Because the RIP router knows only the 10.0.5/24 prefix, the traceroute from r7 requires the source option; otherwise r7 sources the packet from the 10.0.8.0/30 subnet, which is unknown to the RIP router. The extra hop through r6 can be observed in the previous capture.

Various other techniques could also be used to solve this mutual route redistribution problem. For example, global route preferences can remain at their default settings if the exam candidate applies the appropriate OSPF export and RIP import policies in unison. Another common variation to the route preference solution involves writing the OSPF export policy so that the redistributed routes have a metric that is greater than that being reported in the external LSA originating from area 10 (via the translation performed by the NSSA ABR r4). The higher metric setting in the LSAs generated by r6 and r7 will cause the routers in area 1 to forward through r5 for 10.0.5/ 24 destinations, which again breaks the loop. The following OSPF export policy combined with the route preference modification described previously illustrates this technique. Here, the metric setting of 400 causes the routers in area 1 to ignore the 10.0.5/24 prefix being advertised by r6 and r7 in preference of the lower metric reported in the LSA being flooded by r4:

[edit policy-options policy-statement rip-ospf] lab@r6# show term 1 {     from protocol rip;     then {         metric 400;         accept;     } } term 2 {     then reject; } 

It should be clear from these examples that JUNOS software routing policy is extremely flexible, and that this flexibility normally translates into more than one viable solution for most of the problems you will encounter in the lab. Unfortunately, this flexibility also means that there are numerous ways in which you can manage to break your network through mistakes in your routing policy or in the way that the policy is applied.

In the end, it is only the results of your policy that will matter in the JNCIP examination. It is therefore suggested that you keep your policy as simple as possible, and that you always verify correct policy behavior, because common mistakes are often difficult to catch when one simply views the policy statements.

The final verification of the OSPF policy task is to confirm that r1 and r2 have the correct connectivity to the RIP router. As the RIP router is being told only about the 10.0.5/24 subnet, ping and traceroute tests will require that you make use of the local or source switches, respectively, if you perform the tests from either r1 or r2, as shown next:

lab@r1> traceroute 192.168.0.1 traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 40 byte packets  1 10.0.4.13 (10.0.4.13) 0.341 ms 0.252 ms 0.217 ms  2 10.0.2.1 (10.0.2.1) 0.787 ms 0.663 ms 0.876 ms  3 10.0.8.10 (10.0.8.10) 0.853 ms 0.691 ms 0.878 ms  4 *^C 

Here the trace times out as the packet is sourced from r1’s fe-0/0/1 interface by default. Using the source switch and the correct interface address resolves this problem:

lab@r1> traceroute 192.168.0.1 source 10.0.5.1 traceroute to 192.168.0.1 (192.168.0.1) from 10.0.5.1, 30 hops max, 40 byte packets  1 10.0.4.13 (10.0.4.13) 0.403 ms 0.291 ms 0.262 ms  2 10.0.2.1 (10.0.2.1) 0.537 ms 0.614 ms 0.375 ms  3 10.0.8.10 (10.0.8.10) 0.294 ms 0.676 ms 0.375 ms  4 192.168.0.1 (192.168.0.1) 0.443 ms 0.649 ms 0.374 ms 

A Time for Static Routes?

Though arbitrary use of static routes is normally forbidden in lab examinations, when you are hung up on a problem and afraid of running low on time, the decision to deploy a static route is well worth considering. Unauthorized static routes may result in far less point loss than would otherwise occur if you were to leave a packet loop in place or end up running out of time because you could not work through a particularly difficult problem. Though each individual will have to weigh all factors and come to a personal decision, throwing in a static route so that you can get moving on the remaining configuration tasks can be a sound examination strategy. Ideally, you will be able to revisit the problem and resolve the issue during any spare time left over at the end of all your configuration tasks.