This is what I figured from a quick googling. Just wanted to make sure I wasn't missing anything.. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Nick Hilliard" <nick@foobar.org> Sent: Wednesday, January 08, 2014 1:03 PM To: nick@flhsi.com, nanog@nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:52, Nick Olsen wrote:
Completely agree. But this is needed to integrate into an existing network. OSPF would've been my first choice.
you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future. Nick
On Wed, Jan 8, 2014 at 1:05 PM, Nick Olsen <nick@flhsi.com> wrote:
This is what I figured from a quick googling. Just wanted to make sure I wasn't missing anything..
you could employ one of the several methods to migrate from 'less desirable igp' to 'more desirable igp' on all of the things in question... there's people that have done this before even :)
Thanks!
Nick Olsen Network Operations (855) FLSPEED x106
---------------------------------------- From: "Nick Hilliard" <nick@foobar.org> Sent: Wednesday, January 08, 2014 1:03 PM To: nick@flhsi.com, nanog@nanog.org Subject: Re: EIGRP support !Cisco
On 08/01/2014 17:52, Nick Olsen wrote:
Completely agree. But this is needed to integrate into an existing network. OSPF would've been my first choice.
you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future.
Nick
On 08/01/2014 18:14, Christopher Morrow wrote:
you could employ one of the several methods to migrate from 'less desirable igp' to 'more desirable igp' on all of the things in question... there's people that have done this before even :)
https://www.nanog.org/meetings/nanog29/presentations/gill.pdf Nick
On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard <nick@foobar.org> wrote:
On 08/01/2014 18:14, Christopher Morrow wrote:
you could employ one of the several methods to migrate from 'less desirable igp' to 'more desirable igp' on all of the things in question... there's people that have done this before even :)
https://www.nanog.org/meetings/nanog29/presentations/gill.pdf
oh yea! that guy! I hear he's done this sort of thing a few times now... probably has practice and tools and stuff :)
On Fri, Jan 10, 2014 at 9:57 AM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard <nick@foobar.org> wrote:
On 08/01/2014 18:14, Christopher Morrow wrote:
question... there's people that have done this before even :) https://www.nanog.org/meetings/nanog29/presentations/gill.pdf
oh yea! that guy! I hear he's done this sort of thing a few times now... probably has practice and tools and stuff :)
Hey... Tools.... why not... Control+Click... select all the routers.... Right click "Upgrade IGP to ISIS" Go grab a drink... Come back... "Done" click OK. No more Eigrp. I suppose PuTTy / SecureCRT haven't added the feature yet... perhaps in a few releases? :) -- -JH
Hi folks, A bunch of collaborators and I worked on the problem of IGP migration/reconfiguration before. Basically, we augmented Vijay’s methodology to guarantee its correctness. Indeed, when you start flipping Administrative Distance (AD) between IGP1 and IGP2, bad stuff (i.e., forwarding loops, BGP oscillations) can happen if you’re not careful. Also, what Vijay describes is a migration between two Link State (LS) protocols (in this case, OSPF to ISIS). Migrating from EIGRP to a LS has to be treated differently since EIGRP is a Distance Vector (DV) protocol: when you flip the AD on router X, routing decisions at router Y can be impacted (this was not the case in the AOL migration). Fortunately, we managed to get that case covered to. If you’re interested in knowing more, we covered the LS-to-LS migration case in “Seamless Network-Wide IGP Migrations” (see http://vanbever.eu/pdfs/vanbever_igpmig_sigcomm_2011.pdf). Our work about DV-to/from-LS is not published yet, but I’d be happy to share it privately (just ping me). Also, something to keep in mind when you start messing with an IGP: usually, there is BGP running on top of it… And changing the IGP can make BGP decisions go crazy (the decision process rely on IGP cost). We described this in another work “When the Cure is Worse than the Disease: the Impact of Graceful IGP Operations on BGP” (http://vanbever.eu/pdfs/vanbever_igp_bgp_infocom_2013.pdf). Nick, I’d be happy to chat OOB if you want to know more or go further with this migration. Cheers, — Laurent On Jan 24, 2014, at 8:04 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Fri, Jan 10, 2014 at 9:57 AM, Christopher Morrow <morrowc.lists@gmail.com
wrote:
On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard <nick@foobar.org> wrote:
On 08/01/2014 18:14, Christopher Morrow wrote:
question... there's people that have done this before even :) https://www.nanog.org/meetings/nanog29/presentations/gill.pdf
oh yea! that guy! I hear he's done this sort of thing a few times now... probably has practice and tools and stuff :)
Hey... Tools.... why not... Control+Click... select all the routers.... Right click "Upgrade IGP to ISIS"
Go grab a drink... Come back... "Done" click OK. No more Eigrp.
I suppose PuTTy / SecureCRT haven't added the feature yet... perhaps in a few releases? :)
-- -JH
participants (5)
-
Christopher Morrow -
Jimmy Hess -
Laurent Vanbever -
Nick Hilliard -
Nick Olsen