[31660] in North American Network Operators' Group
Re: BGP Confederations
daemon@ATHENA.MIT.EDU (Daniel L. Golding)
Wed Oct 4 22:25:03 2000
Date: Wed, 4 Oct 2000 22:23:05 -0400 (EDT)
From: "Daniel L. Golding" <dan@netrail.net>
To: ccie10 <ccie10@hotmail.com>
Cc: nanog@merit.edu
In-Reply-To: <OE42u3q1vblaLJPv00J0000084c@hotmail.com>
Message-ID: <Pine.LNX.4.10.10010042215480.6933-100000@outage.netrail.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
It's not a fun process. I've given the matter quite a lot of thought.
There are no easy ways to do this. Of course, with sufficient planning,
some scripts, a good lab environment, and a few hours of downtime, a
network can be transitioned. I don't recommend it for faint of heart. The
best candidates for a BGP Confederation design are isolated eBGP networks
(i.e. networks where AS border routers run eBGP, with no iBGP mesh) and
greenfield networks. The last network I worked with that made a successful
transition was Mindspring, AS4355, and they fell into the former category.
The big question is, how big is the network. It's a trivial transition
with 10 routers, lets say. If you have 100 fully meshed iBGP peers, I
wouldn't bet on it. Also, implement communities - they make certain
aspects of confederation configuration much easier.
For more information on confeds, check on the NANOG web site. There are
several archived presentations on the subject.
- Dan Golding
On Wed, 4 Oct 2000, ccie10 wrote:
>
> Is there an easy way to migrate an existing network running IBGP full mesh
> to a
> Condederation based configration. Any documentation that I have come across
> states that current BGP configs need to be redone and all peering
> relationships must torn down and rebuilt. Any addtional info/links regarding
> confederations would be appreciated
>
> thanks
>
>
>
>
