From: Narbik Kocharians (narbikk@gmail.com)
Date: Sat Jun 28 2008 - 06:31:43 ART
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/
> > > >
> > > >>
> > > >> > 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/
> > > >> >
> > > >>
> > > >> > > 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/>
> > > >>
> > > >> > >> 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
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART