From: Luan Nguyen (luan.m.nguyen@gmail.com)
Date: Sat Jun 28 2008 - 17:18:31 ART
Good blogging materials :) I'll blog this RR thingy.
I can say that the way on of the biggest ISP does thing is using RRs within
a cluster with same Cluster ID...peering using loopbacks ofcourse.
Each cluster is a subAS-confederation and fully meshed with others in
different clusters. They themselves are just iBGP peers within the
cluster.
Don't quote me on this though :)
-Luan
On Sat, Jun 28, 2008 at 6:40 AM, Tarun Pahuja <pahujat@gmail.com> wrote:
> 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
>
>
> _______________________________________________________________________
> 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