North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Route Reflector full mesh
On Feb 5, 2008, at 11:56 PM, Adhy wrote:
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) ?
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 ?
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.