EIGRP-to-OSPF migration

[Dmitriy Zhiznevskiy]

Greetings.

I'm currently planning a migration from EIGRP to single-area OSPF. The network has something about 20 core devices (Catalyst 6500, mainly SXI4a), ~500 routes in the global EIGRP database, MPLS VPN deployed (the VRFs have a small amount of routes), somewhere - BGP peering with service provider routers with routes redistributed to it from EIGRP via route-maps.

I read some best practices, including Ivan Perepelnyak's brilliant http://www.nil.com/ipcorner/ChangingRoutingProtocol/ , I fully agree with the algorythm, but the problem is, I can't see the OSPF RIB on a cat6500 device.

Is there any way I can see the routes that are to hit the routing table (if EIGRP goes away) on a catalyst switch? Remember, the IP routing table doesn't have anything injected by OSPF, as routes to the same prefix proposed by EIGRP have a smaller AD. "Show ip ospf database router/network" etc shows full LSAs, and most of the mentioned routes are invalid.

Also - are there any existing tools to compare OSPF and EIGRP databases?

[lgijssel]

Please consider using GNS3 simulation to test the initial configs.

I have found this to be almost equal to a live environment when using routing protocols.

After proper testing, you can feel confident about the implementation.

One remark about the proposed one-area design:

Your network is really too large to run in one area.

Please try to use more than just a single area.

This will improve convergence and overall performance.

regards,

Leo

[Dmitriy Zhiznevskiy]

Building the whole network on GNS3 is rather impractical. Also, there are quite many points of redistribution in the network.

After researching OSPF performance I came to a conclusion that while most of the devices are cat6500/sup720, with the worst device (participating in routing) being 2811, multi-area OSPF is useless. Maybe single-link DMVPN branch routers could be in another area (I also don't see a reason to do it), but the central sites' topology is something between multihub-and-spoke and full mesh, with MPLS everywhere.

It's possible that in the future all users, voice and servers VLANs would be put into VRFs, with only link networks in the global table.

I thought of another method of migration based on the overlay way - by EEM. On schedule, all the routers would immediately switch ADs, hiding EIGRP. Another applet would roll back the changes in two hours, if anything goes wrong, otherwise it would be manually disabled. That would definitely eliminate the possibility of loops, but has a huge risk of a network outage.

[lgijssel]

Typically you should use GNS3 for testing the critcal part of the solution.

Once you have found a suitable config, this can be reproduced to the rest of the network.

Still disagree about the ospf design. Processing power cannot undo the disadvantages of having all in one area.

For example it means you will have the full ospf database throughout the network.

Single link branch routers should be configured as stub routers.

regards,

Leo

[Dmitriy Zhiznevskiy]

Typically you should use GNS3 for testing the critcal part of the solution.

The thing is, almost everything is critical. The GNS3 lab would have to consist of at least 30 devices - and still there is a huge chance of running into a bug during the real deployment.

Processing power cannot undo the disadvantages of having all in one area.

For example it means you will have the full ospf database throughout the network.

Yes, I will. So?

I don't really care about control plane traffic, we have huge WAN links everywhere. The convergence time will definitely be lower than with EIGRP - since in our topology EIGRP doesn't ever choose the correct feasible successors, if metrics are optimized for equal-cost load-balancing. I've seen a research that showed that sup720 handled 10000 prefixes less than in a second - they used some sort of test hardware that generated the routes and measured the convergence. So I would say the multi-area configuration is outdated, if we're not concidering extremely large networks - but for them BGP must be used.

The advantage is that we could span the MPLS border even to the small branch routers if we have to.

Keep in mind that the branch routers make only about 100 routes in the table. Most of the prefixes come from the central sites that must be in 1 area for the sake of MPLS TE, which is the reason we're moving to OSPF.