From: Jared Scrivener (jscrivener@ipexpert.com)
Date: Wed Jan 28 2009 - 17:35:57 ARST
Hey Bogdan,
OK, I think I understand where you're coming from. You're trying to
ascertain the comparison between your hypothetical meshing situation and a
fully-meshed iBGP scenario. In that comparison I don't think you'd see any
difference.
The extension to that though, is that your comparison is almost moot - which
is what I'd tell your student. Fully meshed iBGP doesn't scale well for a
number of reasons and neither would your student's proposed solution. The
major reasons stopping it are both the number of peerings that would be
required by the ingress PE router (even in your student's proposed solution
the peerings haven't been reduced enormously) AND that all policy based
filtering or manipulation of traffic is forced to the ingress edge router
(or egress edge router).
Part of the usefulness of route-reflectors and confederations is that we can
channel the BGP update flows along specific paths with certain points of
aggregation where filtering or manipulation could occur - either close to
the source or the destination as best fits the network. Fully meshed
solutions like we're discussing negate that virtue.
I would simplify this and explain it back to your student with another
question: How could we set policies on the last-hop P router for traffic
that originated from multiple ingress PE routers that need to be applied
before traffic is sent to the PE egress router?
In this case generally the P router would act as a router reflector for the
PE router (and most likely multiple PE routers) who are its route-reflector
clients. Without route reflectors (or potentially confederations) we'd have
to consolidate the policy on the PE routers directly.
Cheers,
Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
Technical Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
Mailto: jscrivener@ipexpert.com
-----Original Message-----
From: Bogdan Sass [mailto:bogdan.sass@catc.ro]
Sent: Wednesday, 28 January 2009 2:10 PM
To: jscrivener@ipexpert.com
Cc: 'Cisco certification'
Subject: Re: BGP full-mesh
Jared Scrivener wrote:
> Hey Bogdan,
> Hey Bogdan,
>
> The first thing that comes to my mind is not the basic stuff (like getting
> the BGP updates to pass) but the more complex stuff - like manipulating
the
> aforementioned updates.
>
> The logic you're running with (or your student is) is that the ingress
edge
> router will be sending the update directly to every transit and edge
router
> (so you've managed to avoid peering between the transit routers). This
> effectively means that we can't do most kinds of filtering on the transit
> routers in the network (setting communities, changing local preference
etc.)
> as each of them would have to pass that change either back upstream to the
> ingress edge router (which would create a loop) or directly to the egress
> edge router (which would create a situation where each transit router may
> send different values in its update).
>
> So whilst the BGP network paths should pass in your situation, you'd most
> likely have serious issues with update management and manipulation.
>
>
I see what you mean - but wouldn't that kind of filtering have to be
done on the edge routers anyhow?
What I mean is - even if we had a full-mesh iBGP topology, all the
transit routers would receive their routes from the ingress edge
routers. If we tried to do filtering (or attribute changes) on another
transit router, we wouldn't accomplish anything - since those routes
wouldn't have been sent to another iBGP peer anyway.
Am I missing something here? Could you please provide an example in
which this problem occurs?
Thank you very much,
-- Bogdan Sass CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS) Information Systems Security Professional "Curiosity was framed - ignorance killed the cat"Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:40 ARST