.. _example_protocols_bgp_parameters_cluster-id:

##########
Cluster-Id
##########

Scenario to verify BGP **cluster-id** parameter configuration for Route Reflectors.

In iBGP networks, the split-horizon rule prevents a router from re-announcing routes
learned from one iBGP peer to another iBGP peer. This creates a full-mesh requirement
that does not scale well in large networks. Route Reflectors (RR) solve this problem
by reflecting routes between their clients, eliminating the need for a full mesh.

The ``cluster-id`` parameter identifies a cluster of Route Reflectors. By default,
the cluster-id equals the router-id of the RR. When you have redundant Route Reflectors
serving the same clients, you should configure them with the same cluster-id to prevent
routing loops. The cluster-id is included in the CLUSTER_LIST attribute of reflected
routes, and if a router receives a route with its own cluster-id in the list, it
discards the route to prevent loops.

*******************
Test BGP Cluster ID
*******************

Description
===========

This test demonstrates the effect of ``cluster-id`` and route reflection in iBGP.
First, without route-reflector configuration, the iBGP split-horizon rule prevents
**DUT0** from re-announcing routes learned from **DUT1** to **DUT2**. **DUT1** has
redistribute connected configured, so it announces its network ``10.10.0.0/24``.
Then, after configuring **DUT0** as a Route Reflector with cluster-id ``10.10.10.1``
and marking both neighbors as route-reflector-client, the route gets reflected and
**DUT2** receives it with the cluster-id in the attributes.

Scenario
========

.. include:: cluster-id/testbgpclusterid

.. raw:: html

  <hr>