[c-nsp] Re: Pointers for merging OSPF and EIGRP networks?

[Jeff Aitken]

On Mon, May 02, 2005 at 12:43:18PM -1000, Scott Weeks wrote:
> : Do any of you have pointers to documents (or comments) of various ways of
> : merging an OSPF network into an EIGRP network.  I have an idea of how I'd
> 
> I guess I should rephrase that.  I'm looking for ideas on amount of pain
> suffered initially verses pain suffered over time.  Redistributing seems
> more like pain over time and less initially, while a flag-day cut over
> seems to be painful initially, but pain over time is minimal.  I've read
> these and other ways to merge, but not a pain-benefit (so to speak)
> analysis for smaller networks.  Or, perhaps, there're other ideas from
> folks that've experienced this first hand.

A few years ago, we decided to move from OSPF to ISIS in the 
backbone, which at the time, that was something like 120 routers. 
The notion of a flag day was simply out of the question, so we went
with the phased migration approach.

In our case, part of the motivation was to reduce the number of
routes carried by the IGP.  This was to be accomplished by moving
all connected and static routes into BGP and carrying only the
minimal set of backbone and loopback routes in ISIS (i.e., the 
minimum set of routes needed to bring up the IBGP mesh).  This is
a common practice in large ISP networks which may or may not relate
to your "smaller" network ("smaller" is relative, of course).

With a few simple scripts to check/automate the process, the process
looks something like this:

1. Add connected/static/etc to BGP.
2. Verify.
3. Turn on ISIS, configured to carry only limited routes.  Since ISIS
   has a higher administrative distance than OSPF by default, this
   should be "safe". [*] 
4. Verify that ISIS is carrying only those routes it's supposed to.
5. Double-check that all routes carried by OSPF but NOT carried by
   ISIS are now in BGP.
6. Raise the administrative distance of OSPF above that of ISIS (i.e.,
   prefer ISIS routes).
7. Verify that you didn't just blow off your leg.
8. Turn off OSPF.
9. Check your leg again.

[*] If you're going the other direction (e.g., OSPF->EIGRP), you'll
    probably want to change the admin distance of your current
    protocol to a lower value in advance so that you can just leave
    the new protocol at its default value.

I don't remember the exact details, but this stretched out over quite
a bit of time, although most of that time was spent watching and looking
for problems, since the config-load portions are only a few hours of
work.  All in all, it went VERY smoothly.

Someone (Mike O'Dell, perhaps?) once said something to the effect of
"When changing the tires on a moving car, it is essential that at least
one tire remain in contact with the ground at all times!" :-)

Vijay covers a remarkably similar event at AOL in this presentation:

    www.nanog.org/mtg-0310/pdf/gill.pdf

He includes a lot of useful info, including the importance of OOB (you
do NOT want to do this without OOB, trust me), as well as some other
more esoteric issues (BGP MED behavior, etc).


--Jeff