From: Anthony Faria (tfaria72@gmail.com)
Date: Sat Jun 28 2008 - 03:07:23 ART
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
> 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
> > >> 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
> > 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
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART