[c-nsp] BGP full-mesh vs. RR

Ignacio Vazquez ignacio.vazquez at gmail.com
Thu Jan 5 04:18:11 EST 2006


I am afraid I am not able to send the diagram but I will try to explain the
reasons that lead us to full-mesh.

 Our network is an intercontinental net with about 25/30 PoPs with 2 or 3
transits router in each one. We cannot afford to have routers in the edge
with just PE feaures and others for the core with just P features, so every
router is or could it be a P/PE router.

Aswell as the routers, we are not able to afford lots of
intercontinental links, so there are few of them. So we are not have a
"core" group of routers.

Therefore, we hace very sensitive delay/jitter flows, so it is really
important to switch the packets to the nearest exit.

Anyway, I will tell you if the change was well. Hopefully it will be done in
some weeks.




2006/1/4, Pete Templin <petelists at templin.org>:
>
> Ignacio Vazquez wrote:
> >
> >  we actually are going to change from RR to Full Mesh. We have 75
> routers
> > (GSRs and 7500) with full-routing and two clusters. We will migrate to
> > Full-Mesh because we need to have the optimal path to the routes and not
> > loose information with the routers-reflectors.
>
> How many POPs do you have?  How dense is your connectivity?
>
> Planning for the future, we used the advice of AOL/ATDN when we rolled
> out RRs eight months ago.  All of our RRs are configured with 'no bgp
> client-to-client reflection', meaning the RR doesn't worry about
> reflecting routes amongst clients, only to/from non-clients.  Each POP
> is then fully meshed internally.  On each customer-attachment router, it
> has a full view of all local exit points along with a view of the best
> exit point at each remote POP (assuming that the remote POP has an exit
> of similar localpref and AS path length).  Works well for us, and
> positions us for (supposedly) stable MED behavior as we add parallel
> connections to external ASes.
>
> Not the MOST optimal as you're aiming for, but I'd campaign to say that
> it's potentially optimal enough for most cases.
>
> pt
>


More information about the cisco-nsp mailing list