What is a route reflector? What is a cluster-id or originator-id and why should i need id?
If you start google for cluster-id it will not bring up many explanations about what is a clusters in bgp. However it’s quite simple. Because you can have multiple route reflectors inside one AS and this might break the normal AS path loop prevention mechanism. So normally AS path takes care of loop, but inside the AS it’s done with cluster-id and originator-id.
Let’s start with a route reflector. In BGP you would need a full mesh for all iBGP client peerings, to have routes propagated from client to client. Route reflection overcomes the need for a full mesh. The Route reflector reflects routes coming from a client to his route reflector clients.
Here a sample full mesh configuration within AS 200:
Here is a replaced full mesh example with one route reflector, which copies all updated to his clients. So if an update from AS100 is received it’s send to the route reflector and the route reflector copied the update to all of it’s clients:
Make sure next hop is reachable from within the peer. In case of this example, if no next-hop-self is configured from route reflector clients to the route reflector, the next hop for routes coming into AS 200 are pointing to AS100 and as AS300 gateways. This might be a problem for AS200 RR’s, if next hop self is not reachable via a local route.
The cluster is defined by the route reflector and the route reflector client(s). The cluster id will be the router reflector client if unset (for ex. 192.168.1.1). Or the cluster ID can be set with the „bgp cluster-id [number]“ command. So here one cluster is formed:
There are several way’s in configuring route reflector and clients in this scenario. It could be a demand that more than one route reflector should be available for redundancy. If in the above scenario the route reflector fails, there is no way to cope with the situation.
So it might be necessary to have more than one route reflector in the AS. A possible solution would be:
Cluster id is not passed between different sub asses inside the same confederation. The cluster id can avoid unwanted traffic by denying updates, here for example, if you set „bgp cluster-id 1“ on both router A and router B, they would deny accepting updates from each other, when they receive updates with the same cluster-id.
Updates are not needed because of the hierarchical route reflector setup. Since if an update come from router C, it will be propagated to A and B. Since A and B are from their perspective „None Clients“ to each other, cluster-id comes into place. Using the same cluster-id on both, will deny updates being accepted.
Example for „debug ip bgp 135.1.12.4 updates“ on Router B if Router C is sending a new prefix and Router B is recieving the update from Router A (135.1.12.4) also (assuming A and B have the same cluster-id configured). Clusterlist is the inside AS path replacement, for avoiding routing loops. As can be seen here clusterlist holds cluster-id 1 and cluster-id 2. Cluster-id 1 is configured for both A and B, as cluster-id 2 is configured on router D. Originator ID 2.2.2.2 is router C in this example:
*Mar 1 05:40:29.650: BGP(0): 135.1.12.4 rcv UPDATE w/ attr: nexthop 135.1.13.3, origin i, localpref 100, metric 0, originator 2.2.2.2, clusterlist 0.0.0.1 0.0.0.2, path , community , extended community
*Mar 1 05:40:29.658: BGP(0): 135.1.12.4 rcv UPDATE about 1.1.1.0/24 — DENIED due to: reflected from the same cluster;
The originator id is the last step, after cluster id has not effect, in preventing updates being sent in loops. At least, when the originator recieves his own update, then it will be dropped. If cluster-id is not by „bgp cluster-id [number]“ then, it will be set by the route-reflector-client sending updates to non clients with it’s own router-id.
Source:
Internet Routing Architectures, CiscoPress, P. 268ff
RFC2796, Route Reflection, http://www.faqs.org/rfcs/rfc2796.html
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml