Re: Cluster-ID and Originator-ID of group RR

Good explanation Brian,

It all boils down to the originating protocol to avoid control plane loops
i.e. the the control plane Updates should be checked properly by the
protocol
Data plane loops is manually triggered i.e. by misconfiguration

thanks again brian for ur explanation.

On Mon, Jul 23, 2012 at 8:46 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:

> A data plane loop means that an actual users packets are looping around
> the network indefinitely until they are dropped by mechanisms like TTL
> expired. An example of this would be if you do a traceroute and you see
> the same couple of hops over and over and over. Loops in the data plane
> are caused by bad information being fed from the control plane. For
> example if two routers have static default routes pointing at each other
> that would cause a loop in the data plane.****
>
> ** **
>
> A loop in the control plane is when routing or other control information
> keeps getting passed back and forth between devices. An example of this
> would be a routing loop due to errors in redistribution and administrative
> distance. Loops in the control plane dont always cause problems though.
> For example assume you have 3 routers connected in a triangle, R1, R2, and
> R3, and they are all EBGP peers with each other. When R1 originates a
> route into BGP, it will advertise it to R2 and R3. R2 and R3 will then
> advertise the same route to each other. If R3 chooses to route to R1 via
> R2, then R3 will advertise R1s route back to R1. This is technically a
> loop in the control plane because the routing advertisement went from R1 >
> R2 > R3 > R1, however it shouldnt cause any negative effects because BGP
> has mechanisms to prevent this. Mainly in this case it would be loop
> prevention via the AS-Path attribute.****
>
> ** **
>
> The same could be said about other protocols, like OSPF for example. When
> you flood an LSA into OSPF, there are many cases where your own locally
> originated LSA will be flooded back to you. This is because OSPF doesnt
> implement split-horizon, since its not a distance vector protocol. This
> is okay though, because OSPF has loop prevention mechanisms built in to
> figure out that a self-originated LSA should be dropped instead of flooded
> when it is received inbound.****
>
> ** **
>
> In general loops in the data plane are bad, but (finite) loops in the
> control plane are normal.****
>
> ** **
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)****
>
> bmcgahan_at_INE.com****
>
> ** **
>
> Internetwork Expert, Inc.****
>
> http://www.INE.com****
>
> ** **
>
> *From:* CCIE KID [mailto:eliteccie_at_gmail.com]
> *Sent:* Monday, July 23, 2012 8:04 AM
> *To:* Brian McGahan
> *Cc:* jeremy co; Cisco certification
> *Subject:* Re: Cluster-ID and Originator-ID of group RR****
>
> ** **
>
> Hi Brian****
>
> ** **
>
> U always use these terms Control Plane Loop and Data Plane loop****
>
> ** **
>
> Can u brief me about which are the features avoid control plane loops and
> data plane loops****
>
> ** **
>
> Data plane loops are avoided by TTL only.. Is there any other way to avoid
> data plane loops ****
>
> ** **
>
> Control Plane loops: Multicast RPF, Cluster ID, Originator ID, Duplicate
> LSA from Sequence Number, ADv Router ID and Link ID in OSPF, ****
>
> ** **
>
> Add more to this..****
>
> On Mon, Jul 23, 2012 at 8:04 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:**
> **
>
> Even if you don't configure a cluster-id it is inherited from your
> router-id. The only case where you really need to configure the cluster-id
> manually is when you have multiple route reflectors in the same cluster.
> Specifically this means that you would have two or more route reflectors
> that are servicing the same set of clients, and are also peering with each
> other as either clients or non-clients. When the route reflectors reflect
> the same set routes to each other, they will drop the incoming updates if
> they share the same cluster-id.
>
> Really at the end of the day it doesn't matter how you configure it,
> because BGP will eventually stop the looping of updates either based on the
> originator-id or the cluster-id. The only difference is how far the update
> message is passed around before it is dropped. Also remember this is just
> a loop of control plane information, not of the data plane. In other words
> you could basically configure a full mesh of iBGP peers with every router
> as a route reflector, and each of their peers are clients, and the network
> would eventually work itself out.
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> bmcgahan_at_INE.com
>
> Internetwork Expert, Inc.
> http://www.INE.com****
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> jeremy co
> Sent: Monday, July 23, 2012 3:57 AM
> To: Cisco certification
> Subject: Cluster-ID and Originator-ID of group RR
>
> Hi,
>
>
> I understand that Originator-ID is a new way of detecing loop in group of
> Route reflectors insteadof cluster-ID
>
>
> So if I have a scenario of group of RRs, to my understanding there is no
> need for cluster-ID to be configured under BGP process and originator-ID
> will take are of it.
>
>
>
> Is that a correct assumption ?
>
>
> thanks.
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
> ****
>
>
>
> ****
>
> ** **
>
> --
> With Warmest Regards,
>
> CCIE KID
> CCIE#29992 (Security)
>
> ****
>

--
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net