Feral Packet

Fun with “bgp cluster-id <num>”

Cisco documentation states that the cluster-id must be set for router reflectors in a cluster.  But setting the cluster-id actually causes problems.

Cisco’s 15M&T documentation (note:  This doesn’t actually say the cluster-id must be the same on all route reflectors, but it’s easy to come to the conclusion the cluster-id must be the same):

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/configuring_internal_bgp_features.html#GUID-77A9DCF1-E771-4148-AEE7-D0202AACC290

“Usually a cluster of clients will have a single route reflector. In that case, the cluster is identified by the router ID of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more than one route reflector. In this case, all route reflectors in the cluster must be configured with the 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster.”

BGP Case Studies (note:  This does say the cluster-id must be the same):

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#routereflectors

“Usually, a cluster of clients has a single RR. In this case, the router ID of the RR identifies the cluster. In order to increase redundancy and avoid single points of failure, a cluster can have more than one RR. You need to configure all RRs in the same cluster with a 4-byte cluster ID so that an RR can recognize updates from RRs in the same cluster.”

BGP Command Reference (note:  This does say the cluster-id must be the same):

http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp1.html#wp1112974

“The bgp cluster-id command is used to assign a cluster ID to a route reflector when the cluster has one or more route reflectors. Multiple route reflectors are deployed in a cluster to increase redundancy and avoid a single point of failure. When multiple route reflectors are configured in a cluster, the same cluster ID is assigned to all route reflectors. This allows all route reflectors in the cluster to recognize updates from peers in the same cluster and reduces the number of updates that need to be stored in BGP routing tables.”

Scott Morris states in this thread that, “Current best practice is different cluster id’s on each RR.”  This is kind of redundant, because if a cluster-id is not configured, the router-id is used as the cluster-id.  

Brian McGahan points to Cisco BGP Case Studies documentation later in the thread that says the cluster-id must be the same on all router-reflectors.

http://ieoc.com/forums/p/5326/17969.aspx

Ivan Pepelnjak points out that with RFC 4456 added new route selection rules.  Routes with a shorter Cluster-list are preferred.  He feels this makes setting “bgp cluster-id <num>” obsolete.

http://wiki.nil.com/BGP_route_reflectors

 Filip Burda goes a step further and points out setting a cluster-id can cause loss of redundancy and connectivity.  The scenario:  redundant route reflectors are configured and both are set with the same cluster-id.  If one of the router reflectors lose connectivity with one of the clients, that route reflector will not receive the routes through the other route reflector.  Why?  The cluster-id is set.  When route reflector that lost connectivity receives an update from the other route reflector, it will see it’s cluster-id in the cluster-list and drop the update.  He doesn’t show any debug output though.

https://rekrowten.wordpress.com/2013/05/24/bgp-route-reflector-and-why-is-cluster-id-obsolete/

If you lab this up to test and run “debug ip bgp updates in”, you’ll see the following message:

BGP(0): 14.1.1.1 rcv UPDATE about 2.0.0.0/8 —  DENIED due to: reflected from the same cluster;

http://www.dasblinkenlichten.com/bgp-route-reflectors/