From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Sat Jun 28 2008 - 01:38:02 ART
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/sld020.html
HTH
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork 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
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART