Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Junos Platform] Received BGP routes with the same local cluster-id suppressed when using hierarchical route-reflection



Article ID: KB34163 KB Last Updated: 03 May 2019Version: 1.0

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 ( and and another configured as route-reflector (for the neighbor). Note that the cluster-id used is the same as that used by its route-reflector routers.

group ibgp-client {
    type internal;
group route-reflector {
    type internal;
    cluster;          <<< Same cluster-id used by its Route-reflectors.
    neighbor {
        description test;

The above configuration will suppress routes learned from and 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 (Internal AS 65522) UPDATE with local cluster-id ( in clusterlist
Apr  4 16:02:39.109730 bgp_rcv_nlri: Peer (Internal AS 65522)
Apr  4 16:02:39.109733 bgp_rcv_nlri:
Apr  4 16:02:39.109735 bgp_rcv_nlri: Uninstalling 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).


Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search