In a route-reflector cluster, a route-reflector client that is also a route-reflector for a lower hierarchy suppresses all received Border Gateway Protocol (BGP) routes.

In this article, the cause for the received BGP routes to be suppressed is explained, along with the solution.

 

The routes sent by the route-reflectors are not seen in route-reflector client. They are not even seen as hidden.

 

When you check the route-reflector client configuration in this example, it has two groups: one for ibgp-clients (192.168.100.1 and 192.168.100.2) and another configured as route-reflector (for the 190.100.100.201 neighbor). Note that the cluster-id used is the same as that used by its route-reflector routers.

group ibgp-client {
    type internal;
    local-address 192.168.100.192;
    neighbor 192.168.100.1
    neighbor 192.168.100.2
}
group route-reflector {
    type internal;
    local-address 192.168.100.192;
    cluster 192.168.2.1;          <<< Same cluster-id used by its Route-reflectors.
    neighbor 190.100.100.201 {
        description test;
    }
}

 

The above configuration will suppress routes learned from 192.168.100.1 and 192.168.100.2 because a route reflector that supports multiple clusters does not accept a route within the same cluster ID from a non-client router. See Example: Configuring BGP Route Reflectors for more information.

 

To confirm this cluster-id problem, BGP update traceoptions must be run on the receiving route-reflector client.

set protocols bgp group ibgp-client traceoptions file test-bgp
set protocols bgp group ibgp-client traceoptions file size 10m
set protocols bgp group ibgp-client traceoptions file files 3
set protocols bgp group ibgp-client traceoptions flag update receive
set protocols bgp group ibgp-client traceoptions flag update detail

 

When you check the traceoptions log, you can see that the peer UPDATE is showing that the cluster-id is in the "clusterlist." The received route is then shown to be uninstalled.

Apr  4 16:02:39.109720 bgp_read_v4_update: peer 192.168.100.2 (Internal AS 65522) UPDATE with local cluster-id (192.168.2.1) in clusterlist
Apr  4 16:02:39.109730 bgp_rcv_nlri: Peer 192.168.100.2 (Internal AS 65522)
Apr  4 16:02:39.109733 bgp_rcv_nlri: 10.16.144.0/23
Apr  4 16:02:39.109735 bgp_rcv_nlri: Uninstalling 10.16.144.0/23: route entry not found

 

This is configuration is incorrect and therefore, this behavior is expected. When using hierarchical route-reflectors, the cluster-id must be unique in each hierarchy.

To know about the correct cluster design configuration, refer to Understanding BGP Route Reflectors (Figure 3).