From: Tarun Pahuja (pahujat@gmail.com)
Date: Sat Jun 28 2008 - 07:40:47 ART
There are Plenty of RFC revolving around route reflectors. Lets Just
summarize the concept for ease of understanding. If one method is preferred
over the other in the industry their must be a reason for it ;-)
*Router Reflectors with in a cluster with same Cluster-ID*
1) Loop prevention using Cluster-list and Originator-ID concept.
2) One Path from each Route Reflector client.
3) 100% redundancy difficult to accomplish. ( using loopbacks you can get
close to 100%).
4) comparatively less memory and cpu Utilization.
*Router Reflector with in a Cluster with different Cluster-ID*
1) One Path from Router Reflector Client and one path from Route Reflector (
you just doubled the size of your bgp table!, Hence more memory
consumption).
2) You can achive 100% redundancy.
3) BGP has to do more work as it has 2 paths for each prefix, hence more CPU
Utilization.
As you can see it all depends on the design and what the customer
expectations are:
1) Does he want 100% redundant RR design or close to 100% using loopbacks
would be fine?
2) Do his routers have enough power(memory and CPU) to accommodate 2 next
hops for the same prefix?
3) Budget limitations.
Since today's ISPs are running Voice,Video and Data majority of the ISP's do
not want to take any chances with a RR design which is less than 100%
redundant. Moreover, Routers have become much more faster which are capable
of accommodating much more routes and processing them faster than their
predecessor.
HTH,
Tarun
On 6/28/08, Narbik Kocharians <narbikk@gmail.com> wrote:
>
> I agree, but if you look at the design within most if not all ISPs you will
> NEVER see redundant RRs configured, you will see that a client is a client
> in couple of clusters (Different ones). The identical cluster-id is no
> longer in practise. Without getting into word games no one practises that
> RFC.
>
> On Fri, Jun 27, 2008 at 11:07 PM, Anthony Faria <tfaria72@gmail.com>
> wrote:
>
> > Be afraid very afraid. Petr Is an endless wealth of knowledge.
> >
> > Tony
> >
> > On Fri, Jun 27, 2008 at 9:41 PM, Joseph Brunner <joe@affirmedsystems.com
> >
> > wrote:
> >
> > > Petr,
> > >
> > > Are the proctor's afraid of you yet?
> > >
> > > LOL
> > >
> > > -Joe
> > > (up soon in SJ)
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > > Petr
> > > Lapukhov
> > > Sent: Saturday, June 28, 2008 12:38 AM
> > > To: Marc La Porte; Brian McGahan; netplusca@rogers.com; Cisco
> > > certification
> > > Subject: Re: the relation between the route-reflector servers within
> the
> > > same bgp cluster id?
> > >
> > > Just to make it more clear,
> > >
> > > per RFC 4456:
> > >
> > > <rfc>
> > >
> > > Usually, a cluster of clients will have a single RR. In that case,
> > >
> > > the cluster will be identified by the BGP Identifier of the RR.
> > >
> > > However, this represents a single point of failure so to make it
> > >
> > > possible to have multiple RRs in the same cluster, all RRs in the
> > >
> > > same cluster can be configured with a 4-byte CLUSTER_ID so that an RR
> > >
> > > can discard routes from other RRs in the same cluster.
> > >
> > > </rfc>
> > >
> > > OK, so let's hold here for a second. What is an RR cluster? A group of
> > > fully
> > > meshed RRs with the *same* cluster ID. That is, if they are on the same
> > > cluster, they should have the same Cluster ID, otherwise the definition
> > > makes no sense. Of course, we usually think of clusters from the
> > "peering"
> > > perspective, but the ID is what makes the definition strict. To
> > summarize:
> > > strictly speaking, configuring RRs with different cluster-IDs puts them
> > > into
> > > *separate* RR clusters.
> > >
> > > As for BGP route distribution redundancy. It's kind of a tricky,
> > > "CCDE-level" question ;). Should RRC (RR Clients) peer with RRs in the
> > same
> > > cluster (same cluster-ID) or with RRs in different clusters? Narbik
> > > demostrated a classic example of what happens when you have RRC peering
> > > with
> > > redundant RRs in the same cluster. However, even in this case, the
> > > situation
> > > is not so serious if you deal with a real-life scenario. This is due to
> > the
> > > fact that iBGP peerings are usually sourced off Loopbacks, and
> therefore
> > > massive peering failures should not happen often. On the contrary side,
> a
> > > drawback of "redundant peering with RRC in different clusters"
> approach,
> > > one
> > > can point out excessive routing information stored on RRs, due to the
> > fact
> > > that they don't discard it based on CLUSTER_ID.
> > >
> > > Here is a nice Cisco presentation being held on RIPE session back in
> > days,
> > > which discusses the questions mentioned above:
> > >
> > >
> > >
> >
> http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/sld02
> > > 0.html<
> >
> http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/sld020.html
> > >
> > >
> > > HTH
> > > --
> > > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
> > > petr@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com <http://www.internetworkexpert.com/>
> > > 2008/6/28 Narbik Kocharians <narbikk@gmail.com>:
> > >
> > > > If anyone needs the topology i will attach it so you will see what i
> am
> > > > talking about. Marc, Look at the attached topology that i just sent
> > you:
> > > > When C2 receives an update, it sends the update to RR-1 and RR-2.
> RR-2
> > > will
> > > > set the cluster-id in the update and send the update to RR-1, RR1
> will
> > > > reject the update because it sees that the cluster-ids in the update
> > > match
> > > > its own.
> > > > Now Let's say the link between C2 and RR-1 and C1 and RR-2 goes down,
> > > now,
> > > > C2 gets the update and it sends it to RR-1 and RR-2, RR-2 sets the
> > > > cluster-id and sends it to RR-1, and RR-1 will reject the update
> > because
> > > it
> > > > will see its own cluster-id in the update.
> > > > Note half of the cluster has no idea about the update.
> > > >
> > > > But if they had different cluster-ids RR-1 will process the update
> and
> > > send
> > > > it to C1.
> > > >
> > > >
> > > > On Fri, Jun 27, 2008 at 11:29 AM, Marc La Porte <
> > > marc.a.laporte@gmail.com>
> > > > wrote:
> > > >
> > > > > Narbik,
> > > > >
> > > > > Why's that?
> > > > >
> > > > > Marc
> > > > >
> > > > > On Fri, Jun 27, 2008 at 7:49 PM, Narbik Kocharians <
> > narbikk@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Basically the cluster-ids should NOT match when you have redundant
> > > > >> route-reflectors, for the CCIE lab, you should make sure that they
> > do,
> > > > but
> > > > >> NOT in the real world scenario.
> > > > >>
> > > > >> On Fri, Jun 27, 2008 at 10:30 AM, Brian McGahan <
> > > > >> bmcgahan@internetworkexpert.com> wrote:
> > > > >>
> > > > >> > Hi Mohamed,
> > > > >> >
> > > > >> > The BGP router-id comes from the highest loopback address, or
> > if
> > > > >> > there is no loopback, your highest interface IP address. The
> > > > cluster-id
> > > > >> > comes from the router-id. In a real design you would always
> want
> > to
> > > > >> > hard code at least the BGP router-id, and possibly the
> cluster-id
> > > > >> > depending on the design. There are certain designs that if your
> > BGP
> > > > >> > router-id overlaps with someone else's there could be a problem,
> > > such
> > > > as
> > > > >> > if you're doing Anycast RP for multicast. As a general rule
> OSPF,
> > > > >> > EIGRP, and BGP router-id's should always be hardcoded. In the
> lab
> > > > exam
> > > > >> > if there isn't a requirement *not* to hardcode them, you should
> > set
> > > it
> > > > >> > to a unique IP address configured on the router.
> > > > >> >
> > > > >> > HTH,
> > > > >> >
> > > > >> > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > >> > bmcgahan@internetworkexpert.com <mailto:
> > > > bmcgahan@internetworkexpert.com
> > > > >> >
> > > > >> >
> > > > >> > Internetwork Expert, Inc.
> > > > >> > http://www.InternetworkExpert.com<
> http://www.internetworkexpert.com/><
> > > http://www.internetworkexpert.com/
> > > > >
> > > > >>
> > > > >> > Toll Free: 877-224-8987 x 705
> > > > >> > Outside US: 775-826-4344 x 705
> > > > >> > 24/7 Support: http://forum.internetworkexpert.com
> > > > >> > Live Chat: http://www.internetworkexpert.com/chat/
> > > > >> >
> > > > >> >
> > > > >> > Net Plus wrote:
> > > > >> > > Hi Brian,
> > > > >> > >
> > > > >> > > It means;
> > > > >> > >
> > > > >> > > Once you set the bgp Router-id, You don't need any Cluster-id,
> > As
> > > > per
> > > > >> > your
> > > > >> > > statement, bgp cluster-id is derived from Router-id.
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Mohamed.
> > > > >> > > -----Original Message-----
> > > > >> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > > Behalf
> > > > >> Of
> > > > >> > > Brian McGahan
> > > > >> > > Sent: Friday, June 27, 2008 9:55 AM
> > > > >> > > To: cciestruggle; Cisco certification
> > > > >> > > Subject: Re: the relation between the route-reflector servers
> > > within
> > > > >> the
> > > > >> > > same bgp cluster id?
> > > > >> > >
> > > > >> > >
> > > > >> > > You should statically set the BGP router ID to a globally
> > > > significant
> > > > >> > > address on the router. The cluster-ID is inherited from
> > router-id
> > > > >> > > regardless if you hardcode it or the router-id though.
> > > > >> > >
> > > > >> > > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > >> > > bmcgahan@internetworkexpert.com <mailto:
> > > > >> bmcgahan@internetworkexpert.com>
> > > > >> > >
> > > > >> > > Internetwork Expert, Inc.
> > > > >> > > http://www.InternetworkExpert.com<
> http://www.internetworkexpert.com/><
> > > > http://www.internetworkexpert.com/
> > > > >> >
> > > > >>
> > > > >> > > Toll Free: 877-224-8987 x 705
> > > > >> > > Outside US: 775-826-4344 x 705
> > > > >> > > 24/7 Support: http://forum.internetworkexpert.com
> > > > >> > > Live Chat: http://www.internetworkexpert.com/chat/
> > > > >> > >
> > > > >> > > cciestruggle wrote:
> > > > >> > >
> > > > >> > >> Hello Brain,
> > > > >> > >>
> > > > >> > >> We do need to have the cluster id on the router reflectors to
> > > avoid
> > > > >> > >> loops ? right?
> > > > >> > >>
> > > > >> > >> And further more do we need to explicitly specify the cluster
> > id?
> > > > the
> > > > >> > >> command reference says that it is automatically set to the
> > local
> > > > >> > >> router id (of which reflector ?)
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> > >
> >
> http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#
> > > > >> > > wp1012377
> > > > >> > >
> > > > >> > >> Zealot
> > > > >> > >>
> > > > >> > >> On Fri, Jun 27, 2008 at 3:52 PM, Brian McGahan
> > > > >> > >> <bmcgahan@internetworkexpert.com
> > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>> wrote:
> > > > >> > >>
> > > > >> > >> You can, but you don't necessarily have to. Most large
> > scale
> > > > >> route
> > > > >> > >> reflection designs include a full mesh of peerings
> between
> > > > >> > >> clusters via
> > > > >> > >> the route reflectors, but the route reflectors are not
> > > clients
> > > > of
> > > > >> > each
> > > > >> > >> other. This means that if reflector A peers with
> reflector
> > > B,
> > > > >> and
> > > > >> > >> reflector B peers with reflector C, reflector C cannot
> > learn
> > > a
> > > > >> route
> > > > >> > >> from reflector A's cluster through B's cluster, because
> if
> > A
> > > is
> > > > a
> > > > >> > >> non-client of B, B cannot advertise an iBGP route from A
> to
> > > C.
> > > > >> > >> However
> > > > >> > >> if these is a full mesh of non-client iBGP peerings
> between
> > > A,
> > > > B,
> > > > >> > >> and C,
> > > > >> > >> reflector C wouldn't need to use B to get to A, since it
> > has
> > > a
> > > > >> > direct
> > > > >> > >> peering.
> > > > >> > >>
> > > > >> > >> Ultimately for production it depends on your redundancy
> > > design.
> > > > >> > >> Technically you can have every single router be a router
> > > > >> reflector
> > > > >> > >> with
> > > > >> > >> everyone else beings its clients. You won't cause any
> > > routing
> > > > >> > loops,
> > > > >> > >> since the cluster list prevents this, but instead you'll
> > just
> > > > >> have
> > > > >> > >> a lot
> > > > >> > >> of unnecessary route replication. However when we are
> > > talking
> > > > >> about
> > > > >> > >> update messages in the order of 300,000 routes for the
> full
> > > BGP
> > > > >> > table,
> > > > >> > >> scalability from a resource management perspective is
> > highly
> > > > >> > >> affected by
> > > > >> > >> route reflection design.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> HTH,
> > > > >> > >>
> > > > >> > >> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > >> > >> bmcgahan@internetworkexpert.com
> > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>
> > > > >> > >> <mailto:bmcgahan@internetworkexpert.com
> > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>>
> > > > >> > >>
> > > > >> > >> Internetwork Expert, Inc.
> > > > >> > >> http://www.InternetworkExpert.com<
> http://www.internetworkexpert.com/>
> > <
> > > > >> http://www.internetworkexpert.com/>
> > > > >>
> > > > >> > >> Toll Free: 877-224-8987 x 705
> > > > >> > >> Outside US: 775-826-4344 x 705
> > > > >> > >> 24/7 Support: http://forum.internetworkexpert.com
> > > > >> > >> Live Chat: http://www.internetworkexpert.com/chat/
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> ccie wrote:
> > > > >> > >> > Hi experts,
> > > > >> > >> >
> > > > >> > >> > Assume I have 5 router within the same AS, and two of
> > them
> > > > will
> > > > >> > >> have IBGP
> > > > >> > >> > peer with the rest, So I configure these two with the
> > same
> > > > bgp
> > > > >> > >> cluster-id,
> > > > >> > >> > and configure the rest to be their
> > route-reflector-clients.
> > > > >> Should
> > > > >> > I
> > > > >> > >> > configure these two to be route-reflector-clients to
> each
> > > > >> > others!!!
> > > > >> > >> >
> > > > >> > >> > Thanks in advance
> > > > >> > >> >
> > > > >> > >> > Amin
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >>
> > > _______________________________________________________________________
> > > > >> > >
> > > > >> > >> > Subscription information may be found at:
> > > > >> > >> > http://www.groupstudy.com/list/CCIELab.html
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >>
> > > _______________________________________________________________________
> > > > >> > >
> > > > >> > >> Subscription information may be found at:
> > > > >> > >> http://www.groupstudy.com/list/CCIELab.html
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > > --
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >>
> > > _______________________________________________________________________
> > > > >> > > Subscription information may be found at:
> > > > >> > > http://www.groupstudy.com/list/CCIELab.html
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > __________ NOD32 3223 (20080627) Information __________
> > > > >> > >
> > > > >> > > This message was checked by NOD32 antivirus system.
> > > > >> > > http://www.eset.com
> > > > >> >
> > > > >> >
> > > > >> >
> > > >
> _______________________________________________________________________
> > > > >> > Subscription information may be found at:
> > > > >> > http://www.groupstudy.com/list/CCIELab.html
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Narbik Kocharians
> > > > >> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> > > > >> www.Net-Workbooks.com <http://www.net-workbooks.com/>
> > > > >> Sr. Technical Instructor
> > > > >>
> > > > >>
> > > > >>
> > > _______________________________________________________________________
> > > > >> Subscription information may be found at:
> > > > >> http://www.groupstudy.com/list/CCIELab.html
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > Narbik Kocharians
> > > > CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> > > > www.Net-Workbooks.com <http://www.net-workbooks.com/>
> > > > Sr. Technical Instructor
> > > >
> > > >
> > > >
> _______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
>
>
> --
> Narbik Kocharians
> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> www.Net-Workbooks.com
> Sr. Technical Instructor
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART