O'Reilly logo

JUNOS Enterprise Routing by Harry Reynolds, Doug Marschke

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Overlay Migration Scenario: RIP to OSPF

Just when you are considering some well-deserved time off, given the success of the recently deployed RIPv2 internetwork, you receive notification from the new CIO that the Beer-Co network must migrate to OSPF as part of a modernization initiative. Beer-Co has conducted a design review and determined that a single OSPF area with the ability to expand to a hierarchal design in the near future is required.

Considering the migration methods described in the previous section and the current design criteria, you propose an overlay-based migration. The reasons for this recommendation include the following:

  • Both the legacy and planned networks are flat.

  • Both the legacy Cisco and new Juniper Networks gear support the legacy and new IGPs.

  • It’s the most direct migration strategy, and you are still smarting from tilting at RIP.

Figure 4-9 shows the before, during, and after networks. In the middle, both IGPs are running, but altered preferences ensure that RIP routes remain active, which provides you the chance to verify all aspects of OSPF before its routes become active. The key to the overlay model is altered protocol preferences, and the figure also shows the beginning, initial modification, and final preference values for RIP and OSPF internal/external routes.

RIP-to-OSPF overlay topology

Figure 4-9. RIP-to-OSPF overlay topology

The critical point occurs before OSPF is activated (especially in IOS, where changes take effect immediately as they are entered). Both the internal and external preferences are set so that RIP remains unperturbed until you are ready to retire it. Failing to ensure that OSPF external preference is set lower (is more preferred) than RIP leads to a Frankenstein-like forwarding model that has the simulated customer networks and redistributed loopback routes forwarding over OSPF paths while the internal routes continue to forward via RIP.

The Juniper boxes are configured first (recall that, until you commit, no change takes effect, so you have a safety net of rollback or commit confirmed in case you do not like the results). The OSPF stanza is displayed at Ale along with the associated set commands using the CLI’s show | display set command. The authentication key value jncie is reused here. Also of note are the altered preference values for OSPF internal and external routes—that authentication is configured at the area level while the specifics are set on a per-interface basis:

[edit protocols ospf]
lab@Ale#show
preference 105;
external-preference 106;
export ospf_export; ## 'ospf_export' is not defined
area 0.0.0.0 {
    authentication-type md5;
    interface fe-0/0/0.69 {
        authentication {
            md5 1 key "$9$Yb4JD3nCu0I.PF/"; ## SECRET-DATA
        }
    }
    interface fe-0/0/0.1121 {
        authentication {
            md5 1 key "$9$WitXNbiHmTQn4ajq"; ## SECRET-DATA
        }
    }
}

[edit protocols ospf]
lab@Ale# show | display set
set protocols ospf preference 105
set protocols ospf external-preference 106
set protocols ospf export ospf_export
set protocols ospf area 0.0.0.0 authentication-type md5
set protocols ospf area 0.0.0.0 interface fe-0/0/0.69 authentication
md5 1 key "$9$Yb4JD3nCu0I.PF/"
set protocols ospf area 0.0.0.0 interface fe-0/0/0.1121 authentication
md5 1 key "$9$WitXNbiHmTQn4ajq"

Like RIP, OSPF requires an export policy for route redistribution, and the CLI’s copy feature is evoked to save some effort:

[edit protocols ospf]
lab@Ale#top edit policy-options

[edit policy-options]
lab@Ale# copy policy-statement rip_export to policy-statement
ospf_export

[edit policy-options]
lab@Ale# edit policy-statement ospf_export

[edit policy-options policy-statement ospf_export]
lab@Ale# show
term 1 {
    from protocol direct;
    then accept;
}
term 2 {
    from {
        protocol static;
        route-filter 200.0.1.0/24 exact;
    }
    then {
        metric 3;
        accept;
    }
}
term 3 {
    from protocol rip;
    then accept;
}

Looking over the copy of the RIP policy, now in its renamed ospf_export form, it seems that the only term that is out of place is term 3 and the bit about matching RIP. You certainly do not want any RIP-to-OSPF redistribution in this example! We remove term 3 (committing the changes) and make similar changes to Lager:

[edit policy-options policy-statement ospf_export]
lab@Ale#delete term 3

After a few moments, the OSPF adjacency status is confirmed between Ale and Lager. Recall that Malt and Barley have not been configured with OSPF at this time:

[edit]
lab@Ale#run show ospf interface
Interface        State     Area      DR ID        BDR ID       Nbrs
fe-0/0/0.1121    DR       0.0.0.0   10.10.128.1  10.10.128.2     1
fe-0/0/0.69      DR       0.0.0.0   10.10.128.1  0.0.0.0         0

The output from the show ospf interface command confirms that OSPF is running on the desired interfaces and that local router Ale has won the DR election on both of its interfaces. Considering that Ale is alone (zero neighbors have been detected) on its fe-0/0/0.69 interface, its DR status on that segment should be no surprise. You can also verify the area 0 setting and that the only other router on the fe0-0/0/0.1121 link has delegated itself to be the backup DR. Remember that priority and RID factor only during an active election. Given the matched priority and Ale’s lower RID (its lo0 address is lower than Lager’s), this must be a case of Ale having been configured for OSPF first. The first non-0 priority router up always becomes the DR:

[edit]
lab@Ale#run show ospf neighbor
  Address         Interface        State      ID           Pri  Dead
10.10.129.2      fe-0/0/0.1121     Full      10.10.128.2   128    38

The show ospf neighbor command verifies that a full adjacency has been formed between Ale and Lager, which is a very good sign indeed:

[edit]
lab@Ale#run show route protocol ospf

inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.128.2/32      [OSPF/105] 00:01:03, metric 1
                    > to 10.10.129.2 via fe-0/0/0.1121
192.168.2.0/30      [OSPF/105] 00:01:03, metric 2
                    > to 10.10.129.2 via fe-0/0/0.1121
200.0.2.0/24        [OSPF/106] 00:01:03, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
224.0.0.5/32       *[OSPF/10] 00:07:52, metric 1
                      MultiRecv

Showing the routes learned via OSPF confirms several important points. One is simply that routes are being learned via OSPF (Lager’s 10.10.126.2 loopback and the 192.168.2.0 link to Barley), and equally significant is that none of these learned OSPF route are currently active.

Tip

Unlike IOS, which requires that you run OSPF on the loopback interface to advertise its associated route, JUNOS software automatically advertises a stub route to the default address used as the source of the RID, assuming that a RID has not been explicitly set under [routing-options]. Because the lo0 interface is the first to be activated, the lo0 interface’s primary address is used as the RID. In contrast, for IOS it is common to either run a passive OSPF instance on the loopback interface or to redistribute the connected router into OSPF, as shown in the following example.

A final confirmation that our route preference changes are working comes when we display the route to Lager’s customer network at Ale:

[edit]
lab@Ale#run show route 200.0.2.0

inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.2.0/24       *[RIP/100] 02:47:22, metric 4, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [OSPF/106] 00:09:29, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121

Perfect! Ale has both OSPF and RIP copies of the customer route. The key thing here is that the original RIP version is, and has always been, active. Unlike RIP, the displayed OSPF route metric does not reflect Ale’s interface costs to reach Lager. With the default scaling factor of 100,000,000, the cost for Ale’s Fast Ethernet interface is 1 (you can confirm this with a show ospf interface detail command), so you might expect to see Ale display a cost of 4 for the 200.0.0.2/24 prefix. The reason for this situation is that the OSPF_export policy at Lager did not bother to specify a Type 1 external metric, so the default Type 2 metric is generated, and by OSPF standards this metric is never incremented by other routers. A sample of a policy modification that alters the metric type is provided, along with the results observed back at Ale. These changes are then rolled back to restore the initial behavior:

[edit policy-options policy-statement ospf_export]
lab@Lager#show
term 1 {
    from protocol direct;
    then accept;
}
term 2 {
    from {
        protocol static;
        route-filter 200.0.2.0/24 exact;
    }
    then {
        metric 3;
        external {
            type 1;
        }
        accept;
    }
}
[edit]
lab@Ale# run show route 200.0.2.0

inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.2.0/24       *[RIP/100] 03:03:06, metric 4, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [OSPF/106] 00:02:35, metric 4, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121

With the OSPF overlay working on the Juniper Networks portion of the network, we place the equivalent configuration into effect at the Cisco boxes. It is critical that the modified OSPF preference (setting both the internal and external to a distance higher than RIP’s) be the first thing configured to help ensure that RIP is not impacted—in IOS land, changes go into effect as soon as they are entered. By default, IOS assigns the same administrative distance to OSPF internals and externals (and interarea, for that matter), so we should adopt the same approach—as long as the distance for all OSPF routes is less preferred than RIP, it will be OK. The commands entered on Malt are shown. Similar commands are also entered on Barley.

Malt#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Malt(config)# router ospf 10
Malt(config-router)# distance 125
Malt(config-router)# area 0 authentication message-digest
Malt(config-router)# redistribute static route-map TAGGING
% Only classful networks will be redistributed
Malt(config-router)# network 10.0.0.0 0.255.255.255 area 0
Malt(config-router)# network 192.168.2.0 0.0.0.3 area 0
Malt(config-router)# default-information originate route-map FOO
Malt(config-router)# exit
Malt(config)# interface fastEthernet 0/1.69
Malt(config-subif)# ip ospf message-digest-key 1 md5 jncie
Malt(config-router)# exit
Malt(config)# interface serial 0/0
Malt(config-subif)# ip ospf message-digest-key 1 md5 jncie
Malt(config)# route-map FOO permit 20
Malt(config-route-map)# match ip address 4
Malt(config-route-map)# set tag 100
Malt(config-subif)# ^Z
Malt#
*Mar  1 04:01:28.603: %SYS-5-CONFIG_I: Configured from console by
console
*Mar  1 04:01:30.495: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.128.1 on FastEthernet0/
1.69 from LOADING to FULL, Loading Done

The resultant OSPF portion of the configuration is shown next, along with the new route map. Note the log message in the previous capture reporting an up adjacency on Malt’s fa 0/1.69 interface. This is a good indication that we have compatible OSPF settings between the Cisco and Juniper routers.

router ospf 10
 log-adjacency-changes
 area 0 authentication message-digest
 redistribute static route-map TAGGING
 network 10.0.0.0 0.255.255.255 area 0
 network 192.168.2.0 0.0.0.3 area 0
 default-information originate route-map FOO
 distance 125
!
. . .
route-map FOO permit 20
 match ip address 4
 set tag 100
!

The configuration creates an OSPF instance identified as 10, enables MD5 authentication in area 0, redistributes and route-maps the same routes used in the RIP example, and enables OSPF area 0 in the serial 0/0 and fa 0/1.60 interfaces. Note that in the IOS implementation, OSPF will not redistribute a default static route. You must use the default-information originate command instead. Using the preexisting TAGGING route map did not work, so a new route map named FOO was created. It’s things such as this that make you appreciate the consistent nature of JUNOS software routing policy.

In an approach that is similar to JUNOS software OSPF configuration, the specific MD5 key ID and key value are set under each interface. The difference is that for JUNOS software, this was done within the OSPF configuration proper, whereas for IOS, it is under the interface configuration. The OSPF authentication settings are also shown for one of Malt’s interfaces:

interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/1.69
 encapsulation dot1Q 69
 ip address 192.168.1.1 255.255.255.252
 ip rip authentication mode md5
 ip rip authentication key-chain test
 ip ospf message-digest-key 1 md5 jncie
 no snmp trap link-status
!

After a few moments, the OSPF status is analyzed on Malt:

Malt#show ip ospf interface fastEthernet 0/1.69
FastEthernet0/1.69 is up, line protocol is up
  Internet Address 192.168.1.1/30, Area 0
  Process ID 10, Router ID 10.10.128.100, Network Type BROADCAST,
Cost: 1
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 10.10.128.1, Interface address 192.168.1.2
  Backup Designated router (ID) 10.10.128.100, Interface address
192.168.1.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40,
Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:05
  Index 3/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 10.10.128.1  (Designated Router)
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

The show ip ospf interface command for Malt’s fa 0/1.69 verifies the presence of a neighbor with RID 10.10.128.1 (Ale’s loopback address/RID) and confirms the authentication and timer settings that are in effect. As expected, Ale remains the DR because in OSPF, this DR election is not revertive.

Malt#show ip ospf neighbor
Neighbor ID   Pri  State    Dead Time  Address     Interface
10.10.128.1   128  FULL/DR  00:00:38   192.168.1.2 FastEthernet0/1.69
10.10.128.200   0  FULL/  - 00:00:36   10.1.254.2  Serial0/0

The show ip ospf neighbor command confirms the expected adjacencies to both Barley and Ale. We next display a simulated customer route to confirm that the RIP copy is still being used at the Cisco boxes:

Malt#show ip route 200.0.2.0
Routing entry for 200.0.2.0/24
  Known via "rip", distance 120, metric 4
  Redistributing via rip
  Last update from 10.1.254.2 on Serial0/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.1.254.2, from 10.1.254.2, 00:00:03 ago, via Serial0/0
      Route metric is 4, traffic share count is 1
    192.168.1.2, from 192.168.1.2, 00:00:14 ago, via FastEthernet0/1.69
      Route metric is 4, traffic share count is 1

The output confirms that the RIP version of the route is still active. Unfortunately, IOS displays only the active route, making it hard to confirm that OSPF shadow versions also exist. The LSDB is inspected to make this determination:

Malt#show ip ospf database external adv-router 10.10.128.2

            OSPF Router with ID (192.168.1.1) (Process ID 120)

            OSPF Router with ID (10.10.128.100) (Process ID 10)

                Type-5 AS External Link States

  LS age: 97
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.128.2 (External Network Number )
  Advertising Router: 10.10.128.2
  LS Seq Number: 80000006
  Checksum: 0x2858
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 0
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 397
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 200.0.2.0 (External Network Number )
  Advertising Router: 10.10.128.2
  LS Seq Number: 80000006
  Checksum: 0x92B6
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 3
        Forward Address: 0.0.0.0
        External Route Tag: 0

The external (in fixed code) argument to the show ip ospf database command filters the output such that only AS LSAs sent by Lager are shown. The adv-router argument specified Lager’s OSPF RID to identify it from all other sources of AS external LSAs in the OSPF RD. The output confirms that Lager’s customer route (200.0.2/24) is being advertised into OSPF.

RIP-to-OSPF Migration: Cutover to OSPF

With various aspects of OSPF operation confirmed, it’s time to make the cut from RIP to OSPF. This should be a nondisruptive process, but as with all IGP migration procedures, it’s best to perform the cutover in a maintenance window as added insurance—the interplay of complex internetworking protocols is sometimes hard to predict. The actual transition normally occurs in two phases. First, make the OSPF routes active, and then, after you confirm proper operation, remove all traces of the legacy protocol and reset the new protocol to its default preference values.

To achieve the first goal you could reconfigure the OSPF internal and external preferences to be more preferred than RIP, or you could alter RIP’s preference to be less preferred than OSPF. Either way, if something blows up, you can roll back or simply remove the OSPF configuration, and return to RIP operation while determining what went wrong. Given that IOS is now set with a single preference for both OSPF and RIP, the amount of change is a wash. On the JUNOS devices, it will be easier to change the one RIP preference rather than both OSPF values. Therefore, the plan is to set the RIP administrative distance to 126 on the IOS devices, while setting the RIP preference to 107 on the JUNOS devices. In both cases, the change will make RIP a less-preferred protocol.

The changes are shown for the Juniper router Ale. Similar commands are also executed at Lager:

[edit protocols]
lab@Ale#set rip group rip preference 107

The RIP administrative distance is altered on both IOS boxes:

Malt#conf terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Malt(config)# router rip
Malt(config-router)#distance 126

After a few moments, it’s confirmed that the OSPF version of Lager’s 200.0.2.0 route is now preferred at Barley:

Barley#show ip route 200.0.2.0
Routing entry for 200.0.2.0/24
  Known via "ospf 10", distance 125, metric 3, type extern 2, forward
metric 1
  Last update from 192.168.2.2 on FastEthernet0/1.70, 00:03:42 ago
  Routing Descriptor Blocks:
  * 192.168.2.2, from 10.10.128.2, 00:03:42 ago, via FastEthernet0/1.70
      Route metric is 3, traffic share count is 1

Back at the Juniper side of things, you should make a similar determination as to which set of routes is preferred. Note how routes learned through multiple sources are clearly shown in JUNOS software, and that the active versions of these routes are now OSPF-based:

lab@Ale#run show route

inet.0: 19 destinations, 26 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/106] 00:00:25, metric 1, tag 200
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 06:14:07, metric 2, tag 100
                    > to 192.168.1.1 via fe-0/0/0.69
10.1.254.0/24      *[OSPF/105] 00:08:03, metric 66
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 06:14:07, metric 2, tag 0
                    > to 192.168.1.1 via fe-0/0/0.69
10.1.254.1/32      *[RIP/107] 04:14:22, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
10.1.254.2/32      *[RIP/107] 06:14:07, metric 2, tag 0
                    > to 192.168.1.1 via fe-0/0/0.69
10.10.128.100/32    *[OSPF/105] 00:08:03, metric 67
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 06:14:07, metric 2, tag 0
                    > to 192.168.1.1 via fe-0/0/0.69
10.10.128.200/32    *[OSPF/105] 00:08:03, metric 3
                    > to 10.10.129.2 via fe-0/0/0.1121
10.10.128.1/32     *[Direct/0] 3d 21:34:05
                    > via lo0.0
10.10.128.2/32     *[OSPF/105] 00:08:03, metric 1
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 05:45:43, metric 2, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
10.10.129.0/24     *[Direct/0] 2d 22:32:39
                    > via fe-0/0/0.1121
10.10.129.1/32     *[Local/0] 3d 21:34:05
                      Local via fe-0/0/0.1121
192.168.1.0/30     *[Direct/0] 2d 22:32:39
                    > via fe-0/0/0.69
192.168.1.2/32     *[Local/0] 3d 06:03:32
                      Local via fe-0/0/0.69
192.168.2.0/30     *[OSPF/105] 00:08:03, metric 2
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 05:45:43, metric 2, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
200.0.1.0/24       *[Static/5] 2d 07:10:57
                      Discard
200.0.2.0/24       *[OSPF/106] 00:08:03, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 05:45:43, metric 4, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
200.0.100.0/24     *[OSPF/106] 00:08:03, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
                    [RIP/107] 06:14:07, metric 4, tag 0
                    > to 192.168.1.1 via fe-0/0/0.69
200.0.200.0/24     *[OSPF/106] 00:08:03, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121
224.0.0.5/32       *[OSPF/10] 03:14:39, metric 1
                      MultiRecv
224.0.0.9/32       *[RIP/100] 00:08:03, metric 1
                      MultiRecv

The display shows the default route in its OSPF and RIP forms, both of which are tagged due to route-map actions. Here, Ale has installed the default generated by Barley (tag 200), with the RIP version learned directly from Malt also listed (tag 100). The JUNOS software CLI’s matching function is used to identify any remaining active RIP routes. The \ is used here to escape the * character, so it is not incorrectly expanded as a shell wildcard, rather than a specific match condition:

[edit protocols]
lab@Ale#run show route protocol rip | match \*
+ = Active Route, - = Last Active, * = Both
10.1.254.1/32      *[RIP/107] 04:16:48, metric 3, tag 0
10.1.254.2/32      *[RIP/107] 06:16:33, metric 2, tag 0
224.0.0.9/32       *[RIP/100] 00:10:29, metric 1

Besides the multicast route associated with RIPv2, only the /32 host routes from the MaltBarley serial link are still active as a RIP route. This is not an issue, as the related subnet 10.1.254.0/24 is correctly advertised into OSPF (see the previous route display). These results confirm that it’s safe to remove RIP from the internetwork. Things begin first at the Juniper Networks boxes:

[edit]
lab@Ale#delete protocols rip

And then the change occurs at the Cisco boxes:

Malt#conf terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Malt(config)# no router rip
Malt(config)# ^Z
Malt#

Though not shown, the related RIP policy and route maps can now be safely removed. After a few moments of waiting, no angry users surface, and OSPF routing is verified at Ale. Perhaps it’s now time for that vacation....

[edit]
lab@Ale#run show route protocol rip

inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

_  _juniper_private1_  _.inet.0: 2 destinations, 2 routes (2 active,
0 holddown, 0 hidden)

No more RIP routes, as planned:

[edit]
lab@Ale#run show route 200.0.200.0

inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

200.0.200.0/24     *[OSPF/106] 00:16:20, metric 3, tag 0
                    > to 10.10.129.2 via fe-0/0/0.1121

The active route is still OSPF, and a traceroute confirms identical connectivity:

[edit]
lab@Ale#run traceroute 200.0.200.1 no-resolve
traceroute to 200.0.200.1 (200.0.200.1), 30 hops max, 40 byte
packets
 1  10.10.129.2  17.647 ms  14.877 ms  14.854 ms
 2  192.168.2.1  8.879 ms  10.982 ms  9.878 ms
 3  192.168.2.1  10.287 ms !H *  10.282 ms !H

Before You Go, Can You Set Up Area 1 Real Quick?

So, the CIO of Beer-Co is so impressed with the success of the RIP-to-OSPF migration that you have been asked to bring up an Area 1 attachment to router PBR. This is to be a stub area, with a default route injected by the area’s ABR so that PBR can reach the various OSPF external destinations now present in the new network. Figure 4-10 shows the new topology. You may assume that interface parameters are correctly set.

A hierarchical OSPF network

Figure 4-10. A hierarchical OSPF network

In Figure 4-10’s example, PBR’s fe-0/0/1 interface has been looped back (to ensure that it’s declared up, even if not connected), and five VLANs have been created, each with an IP address in the form of 200.10.x.1/24. All five of these logical interfaces have been placed into OSPF area 1, which has been set as a stub area. PBR’s OSPF and fe-0/0/1 configuration is as follows:

[edit]
lab@PBR#show interfaces fe-0/0/1
vlan-tagging;
fastether-options {
    loopback;
}
unit 1 {
    vlan-id 1;
    family inet {
        address 200.10.1.1/24;
    }
}
unit 2 {
    vlan-id 2;
    family inet {
        address 200.10.2.1/24;
    }
}
unit 3 {
    vlan-id 3;
    family inet {
        address 200.10.3.1/24;
    }
}
unit 4 {
    vlan-id 4;
    family inet {
        address 200.10.4.1/24;
    }
}
unit 5 {
    vlan-id 5;
    family inet {
        address 200.10.5.1/24;
    }
}

[edit]
lab@PBR# show protocols ospf
area 0.0.0.1 {
    stub;
    interface fe-0/0/1.1;
    interface fe-0/0/1.2;
    interface fe-0/0/1.3;
    interface fe-0/0/1.4;
    interface fe-0/0/1.5;
    interface fe-0/0/0.1141;
}

Meanwhile, a compatible OSPF area 1 configuration has been added at Ale:

[edit protocols ospf area 0.0.0.1]
lab@Ale#show
stub default-metric 10;
interface fe-0/0/0.1141;

Note that to inject a default route into the stub, you must specify a default metric. After a few moments, OSPF operation is confirmed at PBR. The show ospf neighbor command confirms that the adjacency to Ale is established:

[edit protocols ospf]
lab@PBR#run show ospf neighbor
  Address         Interface      State      ID              Pri  Dead
10.10.130.1      fe-0/0/0.1141   Full      10.10.128.1      128    39

The display of OSPF routes verifies the presence of the default route, injected by ABR router Ale, and reveals an absence of AS externals, which are not permitted in a stub network. Only LSA types 1, 2, and 3 are permitted in a stub area—the OSPF route table at PBR contains only intraarea and interarea routes, thus confirming this aspect of OSPF stub area operation:

[edit]
lab@PBR#run show ospf route
Prefix         Path   Route    NH   Metric  NextHop       Nexthop
               Type   Type     Type         Interface     addr/label
10.10.128.1    Intra  Area BR  IP   1       fe-0/0/0.1141 10.10.130.1
0.0.0.0/0      Inter  Network  IP   11      fe-0/0/0.1141 10.10.130.1
10.10.128.1/32 Intra  Network  IP   1       fe-0/0/0.1141 10.10.130.1
10.10.128.2/32 Inter  Network  IP   2       fe-0/0/0.1141 10.10.130.1
10.10.129.0/24 Inter  Network  IP   2       fe-0/0/0.1141 10.10.130.1
10.10.130.0/24 Intra  Network  IP   1       fe-0/0/0.1141
10.10.131.0/24 Inter  Network  IP   3       fe-0/0/0.1141 10.10.130.1
192.168.1.0/30 Inter  Network  IP   2       fe-0/0/0.1141 10.10.130.1
192.168.2.0/30 Inter  Network  IP   3       fe-0/0/0.1141 10.10.130.1
200.10.1.0/24  Intra  Network  IP   1       fe-0/0/1.1
200.10.2.0/24  Intra  Network  IP   1       fe-0/0/1.2
200.10.3.0/24  Intra  Network  IP   1       fe-0/0/1.3
200.10.4.0/24  Intra  Network  IP   1       fe-0/0/1.4
200.10.5.0/24  Intra  Network  IP   1       fe-0/0/1.5

PBR relies on the ABR-generated default route to reach external destinations because AS external LSAs are not advertised into stub areas:

[edit protocols ospf]
lab@PBR#run show route 200.0.200.1

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/10] 00:04:31, metric 11
                    > to 10.10.130.1 via fe-0/0/0.1141

You can add the no-summaries keyword to the area 1 configuration at the stub area’s ABR (Ale) to also filter Type 3 network summary LSAs, which also result in the use of a default route for interarea destinations. With this change, a totally stubby area is born:

[edit protocols ospf area 0.0.0.1]
lab@Ale#set stub no-summaries

[edit protocols ospf area 0.0.0.1]
lab@Ale#commit

The results are confirmed at PBR, whose LSDB just got much smaller:

[edit]
lab@PBR#run show ospf route
Prefix          Path   Route   NH   Metric  NextHop       Nexthop
                Type   Type    Type      Interface     addr/label
10.10.128.1     Intra  Area BR IP   1    fe-0/0/0.1141 10.10.130.1
0.0.0.0/0       Inter  Network IP   11   fe-0/0/0.1141 10.10.130.1
10.10.128.1/32  Intra  Network IP   1    fe-0/0/0.1141 10.10.130.1
10.10.130.0/24  Intra  Network IP   1    fe-0/0/0.1141
200.10.1.0/24   Intra  Network IP   1    fe-0/0/1.1
200.10.2.0/24   Intra  Network IP   1    fe-0/0/1.2
200.10.3.0/24   Intra  Network IP   1    fe-0/0/1.3
200.10.4.0/24   Intra  Network IP   1    fe-0/0/1.4
200.10.5.0/24   Intra  Network IP   1    fe-0/0/1.5

[edit protocols ospf]
lab@PBR# run show route 192.168.1.1

inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/10] 00:01:41, metric 11
                    > to 10.10.130.1 via fe-0/0/0.1141

A final task: Aggregate network summaries into the backbone

Area 1 is now quite optimized, but it has been called to your attention that the five 200.10.x.1/24 networks owned by PBR are being flooded into the backbone as individual Type 3 network summary LSAs. This is normal for OSPF, but your CIO wants to run a tight ship and has asked that you generate a single summary LSA into area 0 in place of the current five. Before making changes, you confirm that the CIO has correctly described the network summary situation by displaying Type 3 LSAs generated by ABR Ale. Note that these summaries are in backbone area 0.

[edit]
lab@Lager#runshow ospf database netsummary advertising-router
10.10.128.1

    OSPF link state database, Area 0.0.0.0
 Type       ID           Adv Rtr       Seq    Age  Opt  Cksum  Len
Summary  10.10.130.0  10.10.128.1  0x80000003 421  0x22 0xc449  28
Summary  10.20.128.3  10.10.128.1  0x80000002 421  0x22 0x46bd  28
Summary  200.10.1.0   10.10.128.1  0x80000002 421  0x22 0xb11f  28
Summary  200.10.2.0   10.10.128.1  0x80000002 421  0x22 0xa629  28
Summary  200.10.3.0   10.10.128.1  0x80000002 421  0x22 0x9b33  28
Summary  200.10.4.0   10.10.128.1  0x80000002 421  0x22 0x903d  28
Summary  200.10.5.0   10.10.128.1  0x80000002 421  0x22 0x8547  28

Taking note of Lager’s current area 0 LSDB state, you make a change to the area 1 portion of Ale, which results in the summarization of matching network summary LSAs:

[edit protocols ospf area 0.0.0.1]
lab@Ale#set area-range 200.10/16

[edit protocols ospf area 0.0.0.1]
lab@Ale# show
stub default-metric 10 no-summaries;
area-range 200.10.0.0/16;
interface fe-0/0/0.1141;

The area-range statement replaces individual network summaries that fall within the configured range with a single network summary representing the entire range. Adding the restrict keyword as part of the area-range statement serves to block any network summaries that are equal in length to the area-range’s mask. In other words, the area-range is normally a longer function with regard to prefix length, but adding the restrict keyword alters this match type to that of orlonger. The latter results in filtering of any summaries equal in length to the specified area-range prefix length.

Your work is confirmed with a look at the network summaries now advertised into area 0 by Ale:

[edit]
lab@Lager#show ospf database netsummary advertising-router
10.10.128.1
    OSPF link state database, Area 0.0.0.0
 Type       ID            Adv Rtr      Seq    Age  Opt  Cksum  Len
Summary  10.10.130.0   10.10.128.1 0x8000000a   9  0x22 0xb650  28
Summary  10.20.128.3   10.10.128.1 0x80000009   9  0x22 0x38c4  28
Summary  200.10.0.0    10.10.128.1 0x80000001   9  0x22 0xbe14  28

As a final check, the connectivity from Cisco router Barley to one of the 200.10.x.1/24 networks on PBR is confirmed:

Barley#traceroute 200.10.1.1

Type escape sequence to abort.
Tracing the route to 200.10.1.1

  1 192.168.2.2 4 msec 4 msec 12 msec
  2 10.10.129.1 8 msec 4 msec 12 msec
3 200.10.1.1 4 msec 8 msec 8 msec

Awesome! This result completes the RIP-to-OSPF migration. This example also touched on stub area and area-range summarization configuration.

RIP Migration with the Overlay Model Summary

This section demonstrated a typical RIP-to-OSPF IGP migration using the overlay model. This was demonstrated in a multivendor environment to help show that the principles and procedures are somewhat universal, albeit with slightly varied command syntax that serves only to confuse the innocent. The modification of global route preferences allowed a smooth, hitless transition. Once the new IGP was found to be operating as expected, a quick change of preference resulted in use of the new IGP’s forwarding paths while retaining the legacy IGP’s configuration (and legacy protocol neighbors/adjacency state), in the event that the change needs to be backed out quickly. The migration ends with the removal of all legacy IGP traces from the router configurations.

This section also showed the conversion of a flat OSPF network into a hierarchical design that included the function of stub networks, totally stubby networks, and area-range syntax to consolidate network summaries as they enter the backbone.

Now is a good time to take another break. The next section continues our discussion of IGP migration, but this time in the context of an EIGRP-to-OSPF scenario.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required