Knowledge Search


×
 

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

  [KB34163] Show Article Properties


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).

 

Related Links: