From: Bogdan Sass (bogdan.sass@catc.ro)
Date: Wed Jan 28 2009 - 17:10:05 ARST
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