In an MPLS Layer 3 VPN environment with two VPNv4 RRs and all the PE routers have iBGP sessions with both RRs, what's the implication if no cluster ID is configured on the RRs? And what's the implication if the same cluster ID is configured on both RRs?
I have an MPLS network that's running fine with no cluster ID configured on the RRs.
There is no difference in behaviour between IPv4 and VPNv4 RRs. So not configuring the cluster ID means you have the local BGP router ID choosen as cluster ID (default behaviour). This basically means your clients are connected to two different clusters. The adverse effect of this is, that a RR will also forward BGP updates received by the other RR, as it comes from a different cluster.
This might result in more BGP update processing than needed, as a client might be presented with its own BGP updates (Client->RR1->RR2->Client). A RR will not reflect routes, if his own cluster ID is present in the update received. Cluster ID and originator ID (BGP router ID of initial client) were introduced to avoid routing loops and to optimize update processing.
So common best practice is to configure cluster ID first on all RRs in a cluster and then add clients, because you cannnot change the cluster ID once clients are connected.
To quote you, "...as a client might be presented with its own BGP updates (Client->RR1->RR2->Client)", how does the client detect this loop? via ORIGINATOR_ID?
Picture an MPLS network with two RRs (RR1 and RR2) and two PE routers (PE1 & PE2). Each PE router has iBGP sessions to both RRs.
If I configure both RRs in the same cluster, what happens if the sessions PE1-RR2 and PE2-RR1 are down? Will the PE routers lose each others' VPNv4 routes due to the fact that the RRs are ignoring each others advertised routes (the RR receives an update with its own cluster ID in the CLUSTER_LIST, therefore identifying a loop)?
I have tested the scenario myself. RR1 and RR2 belong to the same cluster. When the sessions PE1-RR2 and PE2-RR1 are down, PE1 lost the routes advertised by PE2 and vice versa. RR1 doesn't learn the routes advertised by PE2 and RR2 doesn't learn the routes advertised by PE1.
Given this scenario, do you advise to configure both RRs in the same cluster?
When a route is reflected, it is possible through misconfiguration to form route re-distribution loops. The route reflection method defines the following attributes to detect and avoid routing information loops:
ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID.
CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the route has passed.
When an RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it MUST create a new one. Using this attribute an RR can identify if the routing information has looped back to the same cluster due to misconfiguration. If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement received SHOULD be ignored."
So the main reason of using the cluster list ID is to avoid routing loops in certain scenarios.
You understood and verified, that this means connectivity is broken, if two select sessions are down. However, in a full mesh iBGP even one session being down will break connectivity. As such you would gain and not loose something with RRs. Long story short: to my knowledge it is best practice to use a single cluster ID for a cluster.
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...