From: Hobbs (deadheadblues@gmail.com)
Date: Wed Jan 28 2009 - 18:01:08 ARST
I don't think "Full Mesh" was ever the requirement. You just needed to
make sure there was a consistent view of the routing table in the AS.
The RFC says a consistent view CAN be provided my having the full
mesh, but it doesn't say there NEEDS to be one.
On Wed, Jan 28, 2009 at 12:35 PM, Jared Scrivener
<jscrivener@ipexpert.com> wrote:
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
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