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.
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#showpreference 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 setset 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-statementospf_export[edit policy-options] lab@Ale#edit policy-statement ospf_export[edit policy-options policy-statement ospf_export] lab@Ale#showterm 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 3After 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 0The 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 38The 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
MultiRecvShowing 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.1121Perfect! 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#showterm 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.0inet.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 terminalEnter configuration commands, one per line. End with CNTL/Z. Malt(config)#router ospf 10Malt(config-router)#distance 125Malt(config-router)#area 0 authentication message-digestMalt(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 0Malt(config-router)#network 192.168.2.0 0.0.0.3 area 0Malt(config-router)#default-information originate route-map FOOMalt(config-router)#exitMalt(config)#interface fastEthernet 0/1.69Malt(config-subif)#ip ospf message-digest-key 1 md5 jncieMalt(config-router)#exitMalt(config)#interface serial 0/0Malt(config-subif)#ip ospf message-digest-key 1 md5 jncieMalt(config)#route-map FOO permit 20Malt(config-route-map)#match ip address 4Malt(config-route-map)#set tag 100Malt(config-subif)#^ZMalt# *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 1The 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/0The 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.0Routing 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: 0The 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.
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 107The RIP administrative distance is altered on both IOS boxes:
Malt#conf terminalEnter configuration commands, one per line. End with CNTL/Z. Malt(config)#router ripMalt(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.0Routing 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
MultiRecvThe 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 1Besides the multicast route associated with RIPv2, only the /32
host routes from the Malt—Barley 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 ripAnd then the change occurs at the Cisco boxes:
Malt#conf terminalEnter configuration commands, one per line. End with CNTL/Z. Malt(config)#no router ripMalt(config)#^ZMalt#
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.1121The 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 !HSo, 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.
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/1vlan-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 ospfarea 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 39The 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.5PBR 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.1141You 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 routePrefix 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.1inet.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
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-router10.10.128.1OSPF 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#showstub 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-router10.10.128.1OSPF 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 msecAwesome! This result completes the RIP-to-OSPF migration. This example also touched on stub area and area-range summarization configuration.
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.
Get JUNOS Enterprise Routing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
