Migration OSPF -> EIGRP
dennis
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 !?
thx for you comments....
dennis
Trendkill
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...
Merv
Why does the sustomer want to do this migration ?
How many routers does the client have that need to be migrated ?
dennis
> > for a customer I should plan the migration from ospf -> eigrp
>
> Why does the sustomer want to do this migration ?
cisco environment
>
> How many routers does the client have that need to be migrated ?
maybe about 25
dennis
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...
dennis
Thrill5
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.
"Trendkill" <jpm...@gmail.com> wrote in message
news:115e6650-53df-4bf9...@l16g2000hsf.googlegroups.com...
stephen
--
Regards
stephe...@xyzworld.com - replace xyz with ntl
"dennis" <ukons...@cityweb.de> wrote in message
news:4207cef8-334d-42f6...@l16g2000hsf.googlegroups.com...
a tutorial on 1 way to migrate between protocols:
http://www.nil.com/ipcorner/ChangingRoutingProtocol/
the warnings on the 1st page are the important bit :)
Note - this looks like a good painless method, but i havent tried this in
anger (although it looks like i may have to in the next few months).
Also - this is for moving from EIGRP to OSPF, not the other way around (and
personally i would much rather have OSPF in place thasn EIGRP - it seems
much more predictable and reliable).
i have it done this change, and other vairations such as RIP to OSPF other
ways as well, where you configure the new protocol in the centre of the
network, redistribute, and then move the border out towards the edge of the
network.
that one i really dont recommend as it is much more disruptive, and much
more awkward if you have a resilient network with multiple paths to a
site......
k65...@gmail.com
> --
> Regards
>
> stephen_h...@xyzworld.com - replace xyz with ntl"dennis" <ukonstan...@cityweb.de> wrote in message
>
> -Ipakita ang tekstong may panipi-
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.
ex
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
hope this helps!
Thrill5
"stephen" <stephe...@xyzworld.com> wrote in message
news:siu6j.7999$KC3....@newsfe6-gui.ntli.net...
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%.)
dennis
your recommendation is really good. I think that would be work
perfectly...with maybe a small exception....so I would like to change
the dead interval under ospf to minimimal with "ip ospf dead-
interval .
So when I remove the ospf process there should be only a short
interrupt while changing the routing tables from ospf to eigrp
routes..
dennis
Merv
Why dont' you just get a 4 hour maintenance window and just replace
the OSPF routing process with EIGRP in one go
You indicated that there are only 25 routers; if there were hundreds
of routers it would be a different matter
You can always telnet from one router to the next immediate router via
the shared connected route.
Also remember to enable EIGRP stub routing feature on any spoke
routers to reduce queries
Merv
scrub
for those versions to ensure you are not going to step on known EIGRP
defects ?
Also to ensure that none of the IOS versions in use have been yanked
("deferred") by Cisco ?
stephen
news:GNCdnUxGk5_Mz8ba...@comcast.com...
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).