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

0

0

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

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.

 

Symptoms:

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

 

Cause:

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

 

Solution:

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