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

EIGRP-to-OSPF Migration

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.

Mutual Route Redistribution

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.

EIGRP-to-OSPF migration topology

Figure 4-11. EIGRP-to-OSPF migration topology

Figure 4-12 provides the summary plan of action, as derived from the design criteria provided.

EIGRP-to-OSPF migration plan overview

Figure 4-12. EIGRP-to-OSPF migration plan overview

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.

The JUNOS software OSPF configuration

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 ospf
export 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 static
term 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 IOS configuration

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 stat
              Head 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 sorted
CPU 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_EIGRP
 network 10.0.0.0
 no auto-summary
!
router ospf 10
 network 192.168.1.0 0.0.0.3 area 0
 redistribute eigrp 100 metric 4 route-map EIGRP_OSPF subnets
 redistribute static metric 3 route-map EIGRP_OSPF subnets
 redistribute connected tag 100 subnets metric 2
!
access-list 3 permit any
!
route-map OSPF_EIGRP deny 10
 match tag 100
!
route-map OSPF_EIGRP permit 20
 match ip address 3
 set tag 100
!
route-map EIGRP_OSPF deny 10
 match tag 100
!
route-map EIGRP_OSPF permit 20 match ip address 3 set 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_OSPF
term 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 set
set 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.

What about route preferences?

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....

Confirm EIGRP/OSPF Mutual Route Redistribution

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.69

From 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.0
IP-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 0        Administrator 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.

Troubleshoot a preference issue

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 Loopback1
 ip 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.0
network 200.0.100.0
passive-interface Loopback1
 no 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 eigrp
D    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.1

Type 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.3

Type 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.1
Type 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 msec

Let’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/1
Malt(config-if)# sh
Malt(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/0

The 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  36

Well, 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.100

Next, 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  36

Note 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.1141

This 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.

EIGRP-to-OSPF Migration Summary

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.

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