for a customer I should plan the migration from ospf -> eigrp What is the best practice.. Should I run on all the routers/switches two protocols (eigrp and ospf) and should I also do a mutual redistribution ?
And on the last step I would remove the ospf process with no router ospf 1 !? Then there should all the routes learnd via eigrp !?
Turn up both, do not redistribute (since it will not be there post migration), but do redistribute from other sources if you do it today via ospf (ie, statics, bgp, etc). Then check routing tables as eigrp should be preferred out of the getgo due to the lower administrative distance (internal eigrp at least). Lastly, you can rip out ospf one at a time, but I would save the config first, then do a 'reload in 10' command, and that way if a remote router drops after you remove ospf, then it will bounce in 10 minutes to the saved config and come back up. Do the rip-out slow and steady, and make sure each device stays up as expected before moving on...
thanks a lot for the detailed informations... There are several staticroutes in the ospf process redistributed which have an admin distance of 110. Then I redistribute the static without an metric command into eigrp the admin distance is 170....from this point...the static routes are only learnded from ospf while better admin distance....what do you think...when I change the admin distances from eigrp internal 90 and external to 100...all the static routes are now learned from eigrp ...end the network interuppt is really short...
Ben there, done that. I would not recommend running both protocols even without redistribution because the routing tables get all screwed up because OSPF and EIGRP use different metrics. We bought another company that was running OSPF, and we were running EIGRP. The decision was made to go with EIGRP. Our plan was to add EIGRP one weekend and then remove OSPF the next. We ran into big problems and ended up removing OSPF the same night. We did NOT redistribute any routes but we ran into a problem where routes were getting redistributed! It seems that even though you don't have redistribution turned on. If you have a route being learned via EIGRP and OSPF, and the OSPF route is the better route, then it is the one installed into the routing table. Now, since this route was learned via EIGRP, it is also advertised via EIGRP. The problem is that the metrics EIGRP uses to advertise this route come from the routing table, not from the EIGRP topology table, so you in affect you get redistribution without redistribution being turned on. This was a number of years ago and I think this was only happening on static routes being redistributed into EIGRP. I remember this because our default route was being blackholed at various locations, when it suppose to be pointing to our core location.
how about if you use the "distance" command? an option would be to add the new protocol without removing the old one but since the default admin distance of eigrp is lower than ospf (90, 110), once u add in eigrp those routes will be preffred, unless you lower the admin distance of ospf (lower than 90) until you are ready to convert to eigrp.
router eigrp 1 network 172.16.0.0
router ospf 1 network 172.16.0.0 distance 70
once the eigrp process is added, ospf will still be preferred and when u are ready to go to eigrp, just change the distance of ospf back to the default distance of 110, then the ospf routes will age out and voila! your eigrp routes are now preferred. (or u can force it via clear ip route *), if something goes wrong, u can back out easily by returning the distance command under ospf to 70 so the ospf routes will be preferrd. once everything is working and stable, u can remove the ospf process on all the routers without further distruptions
I have worked with both OSPF and EIGRP in very large networks (more that
1000 routers), and EIGRP is just as predictable and reliable as OSPF, but by far it is much easier to manage. There is a reason that Cisco has never submitted EIGRP to standards bodies for adoption as a standard routing protocol, and why most enterprises run EIGRP (unofficially, according to Cisco it is over 80%.)
there are some good arguments for EIGRP, and it is easy to turn on and get working.
my experience has been that it is much easier for changes in EIGRP to leave you with something that mainly works, but has problems with scale. OSPF has some pretty "hard" built in rules about structure that mean it needs clean design - but that isnt a disadvantage when you see what unconstrained growth can do to EIGRP.
the killer negative ones are when you need to integrate with other manufacturers (or even some of the niche Cisco gear that doesnt speak EIGRP).
my 1st intro to EIGRP problems was adding VPN 3000s to an existing EIGRP system (they only spoke OSPF / RIP at the time). The 1st one was trivial, but several with resilience and failover was painful.
A big current network i work on has Foundry L3 switches everywhere as well as Cisco. OSPF, or BGP were the choices, but only OSPF would give the failover times we needed.
And the latest at work was adding the control system for a DWDM long haul OADM deployment. it provides a 100 Mbps "telemetry" network as a side effect which is really useful - but the existing control net is EIGRP, and sprawls across 500 sites with dual feeds everywhere. Integrating the 2 was a major problem, which would have been much more controllable with existing routing on OSPF (or even BGP).