From: nikolai (be@tweedlebee.net)
Date: Fri Aug 06 2004 - 22:42:18 GMT-3
James,
Thank you so much for the quick response. Here are a couple of notes:
"For example, if you are a service provider network, where you have 10 major
POPs with 2 core routers per POP, that leaves 80 out of 100 BGP speakers to
be Edge/Customer aggregation and Border routers."
NT: That's exactly the case.
"Within a POP, your core routers must become RR-servers and all border and
edge routers home into the core. Having this core<->distribution topology
allows only having to fully mesh 20 core routers throughout the entire
backbone AS."
NT: The core routers can't be fully meshed as of now... The edge routers
can't be fully meshed, either - they are connected in hierarchical fashion
as per local POP. It is not the ideal hierarchical CORE/DISTRIBUTION model.
That's why I mentioned the "multi-tier" Route Reflector servers, which
somehow make me feel uncomfortable.
"You can further reduce your needed IGP routes by doing next-hop-self across
core peering at the geographical barrier."
NT: That's exactly how we handle the issue with next-hop reachabilty.
BTW, what's "YMMV"?
Regards,
Nikolai
-----Original Message-----
From: James [mailto:james@towardex.com]
Sent: Friday, August 06, 2004 6:05 PM
To: nikolai
Cc: Groupstudy Email (E-mail)
Subject: Re: iBGP - Route Reflectors Vs. Confederations
> Any thoughts regarding choosing one versus the other in order to collapse
> several ASs into a single one?
>
> The single AS consists of about 100 BGP speakers, no possibility for full
> mesh, of course. IGP is OSPF, and the AS is used as a Transitive area.
>
> I personally do not like multi-tier RRs and lots of Clusters. In addition,
I
> have the feeling that implementing routing policy would be easier with
> Confederations, where we can see clearly the sub-AS PATH of the routes.
It is always YMMV, and this one in particular is dependent on the person who
is implementing this. There is no such real fact that says RR is better than
Confeds and vice versa, but what works the best for your requirements and
policy
implementations. This is like ISIS vs OSPF debate if people were to debate
which
method is better ;-)
Some people like to see sub AS paths to implement policies. Some people like
to
rely completely on communities and IGP assisted metrics to implement their
policies. Some of the people I know, who are even crazy, not only rely on
communities, they don't even configure BGP manually anymore for turning up
new
customers or peers. They simply run a perl script that associates everything
via
RADB to collect and build policy filtering configurations. That's the
powerful
aspect of BGP, being able to employ policies.
Whichever way you prefer, decides what needs to be done about the IBGP
scaling
issue.
> Having multiple geographical areas looks to me as a good argument in favor
> of Confederations, since they all would require some local authority, and
> common IGP with the backbone routers is not desired. And the BGP design
> looks much prettier...
All depends on the formulation of your business policy requirements, as well
as
your backbone topological architecture.
For example, if you are a service provider network, where you have 10 major
POPs with 2 core routers per POP, that leaves 80 out of 100 BGP speakers to
be
Edge/Customer aggregation and Border routers.
Within a POP, your core routers must become RR-servers and all border and
edge
routers home into the core. Having this core<->distribution topology allows
only having to fully mesh 20 core routers throughout the entire backbone AS.
If your network is international, you can have such configuration until you
get enough. You can break out a confederation, or have two "bordering" core
routers sitting at opposite sides of the geographical barrier (i.e.
Pacific-East
and Atlantic-West) to RouteReflect themselves accross the barrier to
eliminate
needs of having to fully mesh all cores in the entire international backbone
network (I know of one SP AS that does this. I don't know of others that do
it,
but probably there are few more). You can further reduce your needed IGP
routes
by doing next-hop-self accross core peering at the geographical barrier.
-J
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:34 GMT-3