Route Reflector full mesh

Wed Feb 6 08:03:13 UTC 2008

On Feb 5, 2008, at 11:56 PM, Adhy wrote:
>
> 1. If the update is propagated from RR1 to RR2 then RR3, will the
> ORIGINATOR_ID on the update mesg still RR1 ?

Yes, the originator ID is preserved, while the cluster
list would be additive.

> 2. and will the CLUSTER_LIST being used ? the cisco specs only said
> that the CLUSTER_LIST being used if the update mesg is reflected from
> clients to non clients. how about from clients to other client (which
> this client also a RR for another cluster) ?

There are typically two models for deployment within a cluster.
Either fully-meshed clients with no client-to-client reflection, or
clients that only peer with the RRs, with client-to-client reflection.
If client-to-client reflection is employed then the RR will attach
the RR attributes, including the originator ID set to the router
ID of the client, and the local cluster ID value will be added to
the cluster list.

We did see some routing information loops on early deployments
where client-to-client reflection is employed AND the RR would
reflect a route back to a client that it learned from the client.  The
issue here is that the client is now required to know it's a client
and poison updates it receives if the originator ID value equals
the local router ID.  The strict "don't reflect a route learned from a
client back to that client because if you do a client would need
to know about RR and know it's a client" behavior changed from
RFC 1996 to RFC 2796 (perhaps so that some implementations
could optimize message copy across client groups).

> I've assumed that both ORIGINATOR_ID and CLUSTER_LIST is always used
> when route is being reflected and come to conclusion that the loops
> will not occur. Is it correct ?

Yes, when acting on behalf of a client, or if received and
already attached to a prefix, unless sent to an eBGP peer.
The originator ID should be preserved if it already exists.

The real offshoot with RRs employing unique cluster IDs sharing
common client sets is that you trigger unnecessary replication of
updates, additional churn, require additional BGP RIB space
in RRs, and require that routing information originated by a client
be poisoned by that client potentially multiple times, rather than
avoided through routing topology.  Unique cluster IDs within
topological clusters can be especially problematic hierarchical
route reflection.

Specifically to your question, see this text in Section 8 of
RFC 4456:  "A BGP speaker SHOULD NOT create an
ORIGINATOR_ID attribute if one already exists".  I'd consider
modification/replacement of an existing originator ID value
brokenness, and the topology you illustrate broken anyway.

-danny