This section demonstrates a smooth migration from a legacy EIGRP network to a hierarchical OSPF IGP. You could take many approaches to facilitate such a migration. The best approach will depend on numerous factors, such as device support of old and new IGPs and whether new equipment is being added, and if so, whether it’s added to replace or augment an existing network’s infrastructure. Also of consideration is the legacy network’s design with regard to addressing and hierarchy, in combination with the design goals for the new network’s efficiency and scalability.
The tactic demonstrated here is of the route redistribution variety. But considering that Juniper Networks routers have never spoken EIGRP, a bit of the integration model has to be at work as well—after all, a new backbone is being built out. It is acknowledged that leveraging existing network infrastructure will be of prime concern for most enterprises, and therefore that a typical EIGRP-to-OSPF migration will center on the phased reconfiguration of existing IOS devices to begin running the new and stop running the old IGP. This chapter demonstrates a migration approach in which Juniper Networks routers are added to form a new OSPF backbone while minimal changes are made to the legacy infrastructure to accommodate communications between the EIGRP and OSPF domains.
The solution demonstrated accommodates graceful growth of the OSPF backbone while the legacy EIGRP backbone is phased out. The migration goals for this scenario are as follows:
There should be a minimal impact to the existing IOS configurations and existing EIGRP backbone operation.
The solution should accommodate a phasing out of the legacy backbone IGP (though not necessarily the current devices) toward an all-OSPF backbone.
The solution should be as simple as possible and be workable for small-to-large-scale enterprise migrations.
The design must minimize the impact of large numbers of AS external LSAs for low-end routers.
To make this scenario work, mutual route redistribution is needed between EIGRP and OSPF. As always, you must ensure that routes are redistributed only once, because loops will violate the “minimal impact to existing backbone” criterion. In addition, route preference adjustments may be needed to ensure optimal routing, depending on the default preferences for internal versus external EIGRP and OSPF between the two vendors.
Tip
As much as you might prefer to have all this happen on the JUNOS software devices, the simple fact is that they cannot run EIGRP, while the Cisco boxes support both EIGRP and OSPF. This means the redistribution work will have to occur in IOS land. From the viewpoint of the Juniper routers, however, this is just another OSPF network, albeit one with a lot of tagged AS externals.
Figure 4-11 provides the topology and addressing specifics to assist the reader in tracking down which devices and IGPs own which routes.
Figure 4-12 provides the summary plan of action, as derived from the design criteria provided.
The overall plan is to add an OSPF process on the Cisco routers that redistributes connected, static, and EIGRP learned routes after adding a tag value to these routes. In this case, the tag chosen is based on the EIGRP domain’s AS (process) number (it could be any unique value, however). In addition, the existing EIGRP configuration is modified to redistribute OSPF into EIGRP after tagging these routes in a similar fashion. In both cases, the first step in the respective route maps is to deny any routes that already have the EIGRP process tag value. It’s critical that the deny action occur first, as the whole point of the route tags is to simplify the blocking of routes that originated in EIGRP from being redistributed back onto EIGRP from OSPF. Likewise, we need to block routes that originated in OSPF from being sent back into OSPF by EIGRP; the same tag value is also used for this filtering requirement.
Recall that redistribution of connected, static, or EIGRP routes into OSPF results in Type 5 AS external LSAs, which are in turn flooded over the entire OSPF domain (except stub areas). This is a significant point, because one of the design goals is to minimize the impact of large numbers of external LSAs on low-end routers. This is why the new, nonbackbone OSPF areas are configured as NSSA areas in this example. As with the stub area example, the default route injected by the ABRs provides connectivity to the external destinations—for example, EIGRP—and the NSSA capability accommodates future placement of an ASBR to originate AS external routes from these areas as needed.
On the JUNOS software side, things are pretty straightforward,
and the OSPF and related policy bits are shown for Ale.
[edit] lab@Ale#show protocols ospfexport static; area 0.0.0.0 { interface fe-0/0/0.69; interface fe-0/0/0.1121; } area 0.0.0.1 { nssa { default-lsa default-metric 10; } interface fe-0/0/0.1141; } [edit] lab@Ale#show policy-options policy-statement staticterm 1 { from { protocol static; route-filter 200.0.1.0/24 exact; } then accept; }
The OSPF export policy redistributes the simulated customer
static route into OSPF. No route tagging is being performed here,
because if tag 100 were added, these routes would be filtered from
redistribution into the EIGRP domain. Area 1 is configured as an NSSA,
and a default route is configured (via the default-metric statement) for use by routers
within the NSSA when routing AS external destinations. Recall that all
the EIGRP routes will be become AS externals once they are injected
into the OSPF domain, making the presence of the default route in stub
areas critical for maintaining connectivity. The configuration of
JUNOS software router Stout is
shown for completeness, but there is not much to say, except that its
area 2 is compatibly configured as an NSSA.
[edit]
lab@stout#show protocols ospf
area 0.0.0.2 {
nssa;
interface fe-0/0/0.2131;
}The real work is being done on the IOS side because these devices are able to run both the old and the new IGPs.
Before adding the new OSPF process to any of the legacy Cisco routers, you must first verify that they have the capacity to run both IGPs without encountering performance issues. The current best practice is to confirm that CPU and memory use are less than 50% to 60%, respectively. If the router is already running short of resources, adding a new IGP and related redistribution may well push it over the limit. Older routers that are already having trouble keeping up should be replaced or upgraded before proceeding.
The show memory and show processes command output indicates that
Beer-Co’s IOS boxes are not heavily taxed, so we are free to
proceed:
Malt#show mem statHead Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 82B00CC0 18493864 6288376 12205488 12000052 11685420 I/O 3C00000 4194304 2013112 2181192 2174960 2181148 Malt#show processes cpu sortedCPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 3 15492 3513 4409 0.31% 0.80% 0.26% 0 Exec 1 0 2 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 2527 1 0.00% 0.00% 0.00% 0 Load Meter 4 320 2958 108 0.00% 0.00% 0.00% 0 OSPF Hello . . . .
Having determined sufficient resource capacity, the migration
proceeds; the modified portions of Cisco router Malt are shown here:
router eigrp 100 redistribute connected redistribute staticredistribute ospf 10 metric 10 100 255 1 1500 route-map OSPF_EIGRPnetwork 10.0.0.0 no auto-summary !router ospf 10network 192.168.1.0 0.0.0.3 area 0redistribute eigrp 100 metric 4 route-map EIGRP_OSPF subnetsredistribute static metric 3 route-map EIGRP_OSPF subnetsredistribute connected tag 100 subnets metric 2!access-list 3 permit any!route-map OSPF_EIGRP deny 10match tag 100!route-map OSPF_EIGRP permit 20match ip address 3set tag 100!route-map EIGRP_OSPF deny 10match tag 100!route-map EIGRP_OSPF permit 20match ip address 3set tag 100
The modified portions of the IOS configuration are highlighted
to help to call out the delta. The EIGRP process was instructed to
redistribute routes from the OSPF process identified as “10,” setting
the EIGRP bandwidth, delay, reliability, loading, and MTU values to
10, 100, 255, 1, and 1500, respectively. The redistribution is
controlled by the logic in the route map named OSPF_EIGRP.
The entire OSPF process is new and was added to integrate with
the new Juniper router-based backbone. Because connected routes could
not be filtered through the existing EIGRP_OSPF route map, tagging for the
connected routes is configured directly on the distribute line.
In contrast, both static and EIGRP routes are being
redistributed through the control of the common EIGRP_OSPF route map. The subnet keyword inverts the default behavior
of redistributing only classful networks. Lastly, you’ll see that OSPF
area 0 is configured to run on the link connecting Malt to Ale.
Both route maps make use of an initial deny term for any route with a tag value of 100. Remaining routes are then matched against the match-all IP access list 3, with the result being the addition of tag value 100. When combined, the operation of the two route maps serves to ensure that a route is never redistributed back into the IGP from where it originated, which should prevent loop formation.
Tip
You use JUNOS software routing policy to combine the various
effects of IOS’s distribute,
distribute-list, ACL, and route-map functions. For example, here is
a policy example that functions to reject and tag routes, much as
the EIGRP_OSPF route map does,
albeit for RIP and OSPF given the lack of EIGRP support. The
RIP_to_OSPF policy is applied to
the OSPF protocol as an export policy to redistribute only untagged
RIP routes into OSPF, at which time a tag value of 100 is
added:
[edit policy-options] regress@plato#show policy-statement RIP_to_OSPFterm 1 { from tag 100; then reject; } term 2 { from protocol rip; then { tag 100; accept; } } [edit policy-options] regress@plato#show policy-statement RIP_to_OSPF | display setset policy-options policy-statement RIP_to_OSPF term 1 from tag 100 set policy-options policy-statement RIP_to_OSPF term 1 then reject set policy-options policy-statement RIP_to_OSPF term 2 from protocol rip set policy-options policy-statement RIP_to_OSPF term 2 then tag 100 set policy-options policy-statement RIP_to_OSPF term 2 then accept
To better understand how the tagging works, refer back to Figure 4-12 and then consider
an EIGRP (or connected, or static) route x that
originates in the EIGRP domain and is evaluated for redistribution
into OSPF. According to the EIGRP_OSPF route map, the first action is to
deny any route with the tag value 100. Because route
x originates within EIGRP, it has no tag and
therefore the route falls to the next term. Action 20 adds tag 100 to
the route and sends it into OSPF. Route x, which
is now an OSPF Type 5 LSA, is then flooded into the OSPF RD, where it
arrives at Cisco router Barley. In
most cases, Barley will already
have a more preferred EIGRP route to this destination (recall that it
originated in EIGRP to begin with), but if not, it will install the
OSPF route to x, as learned from Malt’s OSPF advertisement.
Now Barley’s OSPF process
considers OSPF route x for redistribution into
EIGRP. Fortunately, the first term in its OSPF_EIGRP route map denies any routes with
tag 100. This action serves to prevent route x
from being sent back into its originating EIGRP IGP. Any routes that
originate in the OSPF domain, regardless of whether they are internal
or AS external, arrive at Barley
with no tag. This permits the redistribution of these routes into the
EIGRP process, after they have been tagged. This tag will in turn keep
router Malt from sending the route
back into the OSPF domain.
Referring back to Figure 4-11, you can see the
default preferences for the route sources used in this example. At
first glance, it seems that we want both Malt and Barley to prefer all OSPF routes
regardless of whether they are internal or external. This is to
ensure that both Cisco routers forward directly into the OSPF cloud
when routing to OSPF originated routes, rather than backhauling over
the EIGRP backbone because they prefer a redistributed EIGRP version
of the same route. This is fortunate here because the OSPF routes
redistributed into EIGRP are considered EIGRP externals, and the
default distance for these routes is 170, making them less preferred
than the native OSPF copy with a default distance of 110.
The default settings mean that the EIGRP domain will always prefer a learned OSPF route over the same copy in the (redistributed) external EIGRP form. The JUNOS software boxes have only one IGP, so there is no need to alter any preference there, of course. Time will tell whether we need to revisit this thinking....
With all routers configured, confirm proper redistribution and
forwarding. Begin at Cisco router Malt, where the IP route table is
displayed:
Malt#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
O E2 200.0.200.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.4.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.5.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O E2 200.0.1.0/24 [110/0] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.1.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O E2 200.0.2.0/24 [110/0] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
O IA 200.10.2.0/24 [110/3] via 192.168.1.2, 00:05:09, FastEthernet0/1.69
S 200.0.100.0/24 is directly connected, Null0
O IA 200.10.3.0/24 [110/3] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 03:10:02, Serial0/0
O 10.10.129.0/24 [110/2] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
O 10.10.128.1/32 [110/1] via 192.168.1.2, 00:05:10, FastEthernet0/1.69
O IA 10.10.130.0/24 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O 10.10.128.2/32 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.10.131.0/24 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.20.128.4/32 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
O IA 10.20.128.3/32 [110/2] via 192.168.1.2, 00:05:14, FastEthernet0/1.69
C 10.10.128.100/32 is directly connected, Loopback0
C 10.1.254.0/24 is directly connected, Serial0/0
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, FastEthernet0/1.69
192.168.2.0/30 is subnetted, 1 subnets
O 192.168.2.0 [110/3] via 192.168.1.2, 00:05:14, FastEthernet0/1.69From a quick look, it seems that all the routes are there:
PBR’s five
200.10.x/24 routes as network summaries
(interarea), the simulated customer routes from Ale and Lager as AS externals, and their loopback/OSPF
interface routes appearing as OSPF internals (intraarea). It certainly
appears that these routes are preferred in their OSPF form, despite
their being redistributed into EIGRP at Barley, which is desired behavior for optimal
routing between the EIGRP and OSPF domains. Note how Barley’s loopback 0 address (10.10.128.200) is
displayed as an EIGRP learned internal route with a distance of
90.
To confirm that the OSPF routes are really being redistributed
into EIGRP (IOS displays only the active route), the EIGRP topology
table for one of PBR’s 200.0.1.0/24
routes is shown here:
Malt#show ip eigrp topology 200.0.1.0IP-EIGRP (AS 100): Topology entry for 200.0.1.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256025600 Routing Descriptor Blocks:192.168.1.2, from Redistributed, Send flag is 0x0 Composite metric is (256025600/0), Route is External Vector metric: Minimum bandwidth is 10 Kbit Total delay is 1000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0 External data:Originating router is 10.10.28.100 (this system)AS number of route is 10External protocol is OSPF, external metric is 0Administrator tag is 100 (0x00000064)
The route’s presence is confirmed in the EIGRP topology table, and
the tag value of 100 proves that the OSPF_EIGRP route map is working.
Overall, the output from the show ip
route command at Malt is
what you want to see. There is one problem, however, with respect to
the simulated customer route owned by Barley: the display shows that Malt prefers the OSPF external version of
the 200.0.200/24 route because the EIGRP external distance is higher
(less preferred) than OSPF’s (as noted previously, this is part of the
migration plan). This occurs only for the
simulated customer routes because EIGRP is set to run on the serial
and loopback interfaces as a result of the network 10.0.0.0 statement. These routes are
therefore considered internal to the EIGRP
process and they have a distance of 90. In contrast, the simulated
customer static route is redistributed into
EIGRP, making it an EIGRP external. This situation results in an extra
hop when Malt tries to reach
Barley’s customer network, and vice
versa:
Malt#trace 200.0.200.1
Type escape sequence to abort.
Tracing the route to 200.0.200.1
1 192.168.1.2 4 msec 8 msec 8 msec
2 10.10.129.2 8 msec 8 msec 8 msec
3 192.168.2.1 12 msec 8 msec 12 msec
4 192.168.2.1 !H !H *Rethinking the default preferences, it was correct to assert that all OSPF routes would be preferred over EIGRP externals, which for the majority of our routes is exactly what is desired. The redistributed statics are causing issues with this plan, however. Changing OSPF external preferences may fix the issue with the problematic static routes, but will then create problems for the other OSPF routes that are now doing what they should be doing.
Some possible solutions include running EIGRP passively on the related customer interface so that the route is advertised as an EIGRP internal. This solution requires an actual interface (or loopback instance), and these statics were used to reduce gear requirements in the first place. Still, no new gear is needed for an IOS loopback 1 interface. Or, you could define a static route, but this represents administrative work and may lead to a black hole if the legacy EIGRP backbone fails. Using a qualified/recursive static should result in traffic falling back to the learned OSPF version should the static route’s next hop become unreachable, but this would need to be tested to make sure of failover behavior. Yet another solution would be to simply tolerate the inefficient routing, given that connectivity is still provided and the condition should be transient as the EIGRP network is phased out. Being a purist, you opt to alter the IOS configurations to add a new loopback instance that will run EIGRP on behalf of the simulated customer network. Such changes are shown here:
!interface Loopback1ip address 200.0.100.1 255.255.255.0! . . . router eigrp 100 redistribute connected redistribute static redistribute ospf 10 metric 10 100 255 1 1500 route-map OSPF_EIGRP network 10.0.0.0network 200.0.100.0passive-interface Loopback1no auto-summary
A new loopback instance has been defined to represent the
simulated customer network that previously was represented by a static
route. The static route has also been removed (not shown), and the
EIGRP process is configured to run passively on the loopback 1
interface. The passive declaration ensures that CPU cycles are not
wasted on the EIGRP neighbor discovery that is doomed to fail, given
the lonely neighborhood that is loopback 1. And yes, loopback 0 should
be set to be passive for the same reasons, but that is saved for
another day. After similar changes are made at Barley, the active EIGRP routes are
displayed and the previous traceroute is repeated:
Malt#showip route eigrpD 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:11:42, Serial0/0 10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:24:16, Serial0/0 Malt#traceroute 200.0.200.1Type escape sequence to abort. Tracing the route to 200.0.200.1 1 10.1.254.2 16 msec 12 msec *
Excellent, just what you wanted to see. Before moving on,
traceroutes to a few other destinations in the OSPF domain are
executed for added confirmation. Note that the simulated customer
network routes at Ale and Lager are set to discard, so you should
expect no reply from them:
Malt#trace 10.20.128.3Type escape sequence to abort. Tracing the route to 10.20.128.3 1 192.168.1.2 4 msec 4 msec 12 msec 2 10.20.128.3 4 msec 8 msec 8 msec Malt#trace 200.10.5.1Type escape sequence to abort. Tracing the route to 200.10.5.1 1 192.168.1.2 8 msec 8 msec 8 msec 2 200.10.5.1 4 msec 20 msec 100 msec
The traceroutes to the loopback address and OSPF area 1 routes
on PBR are successful and are
observed to take a reasonable forwarding path. Similar results are
observed at Barley:
Barley#trace 200.10.2.1
Type escape sequence to abort.
Tracing the route to 200.10.2.1
1 192.168.2.2 20 msec 4 msec 12 msec
2 10.10.129.1 4 msec 28 msec 12 msec
3 200.10.2.1 8 msec 8 msec 8 msecLet’s temporarily down the OSPF adjacency at Malt (traffic will reroute through Barley) to confirm that Malt falls back to the EIGRP versions of the
OSPF domain’s routes and actually begins to forward through Barley:
Malt(config)#interface fastEthernet 0/1Malt(config-if)#shMalt(config-if)#^Z. . .
After a few moments, the route table is again displayed at
Malt:
Malt#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
D 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:31:34, Serial0/0
D EX 200.10.4.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.5.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.0.1.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.1.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.0.2.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
D EX 200.10.2.0/24 [170/256537600] via 10.1.254.2, 00:00:36, Serial0/0
C 200.0.100.0/24 is directly connected, Loopback1
D EX 200.10.3.0/24 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:44:10, Serial0/0
D EX 10.10.129.0/24 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
D EX 10.10.128.1/32 [170/256537600] via 10.1.254.2, 00:00:37, Serial0/0
D EX 10.10.130.0/24 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.10.128.2/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.10.131.0/24 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.20.128.4/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
D EX 10.20.128.3/32 [170/256537600] via 10.1.254.2, 00:00:39, Serial0/0
C 10.10.128.100/32 is directly connected, Loopback0
C 10.1.254.0/24 is directly connected, Serial0/0
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
D EX 192.168.1.0 [170/256537600] via 10.1.254.2, 00:00:34, Serial0/0
192.168.2.0/30 is subnetted, 1 subnets
D EX 192.168.2.0 [170/2172416] via 10.1.254.2, 00:00:40, Serial0/0The display confirms that the EIGRP versions of the
redistributed OSPF routes are now active. A traceroute confirms the
expected forwarding path, given the down fa
0/0 interface at Malt:
Malt#traceroute 200.10.5.1
Type escape sequence to abort.
Tracing the route to 200.10.5.1
1 10.1.254.2 12 msec 12 msec 12 msec
2 192.168.2.2 20 msec 16 msec 20 msec
3 10.10.129.1 116 msec 24 msec 20 msec
4 200.10.5.1 48 msec 28 msec 36 msec
Malt#Malt’s fa 0/1 interface is returned to operation
and the OSPF adjacency is allowed to reform. You should then inspect
the route table to ensure that the network state has returned to the
initial state. Issues with route redistribution/preference are often
timing-dependent, and you may find that after a failure, the network
does not return to the desired state. Here, expect to find that the
OSPF versions of the routes are again preferred over the EIGRP
version:
Malt#
*Mar 1 06:02:24.202: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.128.1 on FastEthernet0/1.
69 from LOADING to FULL, Loading Done
Malt#
Malt#show ip route eigrp
D 200.0.200.0/24 [90/2297856] via 10.1.254.2, 00:36:14, Serial0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
D 10.10.128.200/32 [90/2297856] via 10.1.254.2, 04:48:48, Serial0/0
Malt#The display confirms that the native OSPF routes are again active, being they are preferred over redistributed EIGRP copies. This validates that the network is able to fail over, and then switch back to a steady state. Connectivity between the two RDs has already been demonstrated, so let’s conclude our IGP migration verification with some selective captures in the OSPF domain, starting by examining the “large” external LSA database now on backbone routers:
[edit]
lab@Ale#run show ospf database extern
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 10.1.254.0 10.10.28.100 0x8000000b 850 0x20 0xe0c4 36
Extern 10.1.254.0 10.10.28.200 0x8000000b 783 0x20 0x86ba 36
Extern 10.1.254.1 10.10.28.200 0x8000000b 783 0x20 0x7cc3 36
Extern 10.1.254.2 10.10.28.100 0x8000000b 850 0x20 0xccd6 36
Extern 10.10.128.100 10.10.28.100 0x80000009 1607 0x20 0xfbbc 36
Extern 10.10.128.100 10.10.28.200 0x80000009 1531 0x20 0xb59c 36
Extern 10.10.128.200 10.10.28.100 0x80000009 1607 0x20 0x242e 36
Extern 10.10.128.200 10.10.28.200 0x80000009 1531 0x20 0xb53a 36
Extern *200.0.1.0 10.10.128.1 0x80000005 2101 0x22 0x87c7 36
Extern 200.0.2.0 10.10.128.2 0x80000005 2427 0x22 0x76d6 36
Extern 200.0.100.0 10.10.28.100 0x8000000d 592 0x20 0xdda2 36
Extern 200.0.100.0 10.10.28.200 0x80000002 526 0x20 0xad77 36
Extern 200.0.200.0 10.10.28.100 0x80000002 351 0x20 0xb76d 36
Extern 200.0.200.0 10.10.28.200 0x80000002 526 0x20 0x4979 36Well, it seems that large truly is a subjective term. However, more than 10 Type 5 LSAs are in the backbone area’s database, and considering the small scope of the EIGRP network in this lab example, it’s safe to say that a large enterprise could easily generate hundreds if not thousands of these AS external LSAs.
[edit]
lab@Ale#run show ospf database extern detail | match tag
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 0, fwd addr 0.0.0.0, tag 0.0.0.0
Type 2, TOS 0x0, metric 0, fwd addr 0.0.0.0, tag 0.0.0.0
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 4, fwd addr 0.0.0.0, tag 0.0.0.100
Type 2, TOS 0x0, metric 2, fwd addr 0.0.0.0, tag 0.0.0.100Next, the CLI’s matching function, combined with the detail switch, allows confirmation that most
of these externals originated in the EIGRP domain, given that the
majority are sporting a tag with an EIGRP process number.
The new OSPF network was designed to be hierarchical to promote
scaling. To take this a step further, let’s also deploy NSSAs to
reduce the processing demands on nonbackbone routers. Internal routers
within a stub area do not see any AS external LSAs, which in this type
of a migration can substantially reduce their load. Confirm this fact
at router PBR:
[edit]
lab@PBR#run show ospf database
OSPF link state database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.10.128.1 10.10.128.1 0x8000000c 273 0x20 0xac79 48
Router *10.20.128.3 10.20.128.3 0x80000008 928 0x20 0x6124 108
Network *10.10.130.2 10.20.128.3 0x80000007 928 0x20 0x7b49 32
Summary 10.10.128.2 10.10.128.1 0x80000008 2223 0x20 0xda30 28
Summary 10.10.129.0 10.10.128.1 0x80000008 2073 0x20 0xe328 28
Summary 10.10.131.0 10.10.128.1 0x80000008 1773 0x20 0xd731 28
Summary 10.20.128.4 10.10.128.1 0x80000007 1473 0x20 0x5aa4 28
Summary 192.168.1.0 10.10.128.1 0x8000000b 625 0x20 0x9a9c 28
Summary 192.168.2.0 10.10.128.1 0x80000006 573 0x20 0xa396 28
NSSA 0.0.0.0 10.10.128.1 0x80000008 423 0x20 0xa1ea 36
NSSA 200.0.1.0 10.10.128.1 0x80000005 2373 0x20 0x89c5 36Note the absence of Type 4 and Type 5 LSAs, and the presence of the default route, which provides the internal stub area routers with a route to external destinations.
[edit]
lab@PBR#run show route 200.0.200.4
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 04:26:43, metric 11, tag 0
> to 10.10.130.1 via fe-0/0/0.1141This last display confirms the use of the default route for AS
external destinations by the internal NSSA router PBR.
With initial connectivity confirmed, the EIGRP-to-OSPF migration can proceed through a phased movement of legacy EIGRP segments to the new OSPF backbone. Alternatively, the EIGRP domain can be shrunk back by increasing the scope of the OSPF domain and moving the EIGRP redistribution points until there is no EIGRP left.
This section demonstrated how you can integrate a new OSPF backbone into an existing EIGRP infrastructure, while maintaining loop-free connectivity through careful use of route filtering. Filtering is needed to ensure that those routes are redistributed only once. The example used route tags to simplify filtering. Address-based filters can also work, especially if the two IGP domains have distinct numbering that can easily be summarized.
Mutual route redistribution is always a bit tricky, and careful thought should be leveled against any migration plan to try to head off potential issues stemming from protocol preferences or incomplete route filtering. In this example, the interaction of OSPF and EIGRP external preferences created a problem for static routes redistributed into EIGRP. Although connectivity was maintained and no loops were formed, the condition resulted in suboptimal forwarding for some destinations. The specifics of this example allowed the creation of a new loopback interface, which then ran a passive instance of EIGRP to stand in for the static route, yielding optimal connectivity for all destinations in the test bed.
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.
