iBGP - Route reflector

[chiragom2341]

Hi,

We will be changing the route reflector server location from one site to another. Hence, I also need to move the loopback IP from one site to another. By doing this, I need to update all the clients (they all have peering with the RR loopback IP's but not new site router which will be become a new RR server). 

Is there another method I could use to simplify things so I don't have to go to every client and change the new RR server loopback IP?

Thank you.

[M02@rt37]

Hello @chiragom2341 

Yes, there is a way to simplify the process of updating the clients' peering configurations when changing the location of the [RR] server and its loopback IP. You can use BGP graceful restart feature, which allows routers to maintain their forwarding state during a restart or reconfiguration.

To use BGP graceful restart, you can follow these steps:

-- Configure the new RR server with the same ASN and the same router ID as the old RR server.

-- Configure the new RR server with the same BGP neighbor statements as the old RR server.

-- Configure BGP graceful restart on both the old and new RR servers and on all the clients.

-- Initiate the changeover by shutting down the BGP process on the old RR server.

-- After the old RR server has fully shut down, bring up the BGP process on the new RR server.

-- During the changeover process, the clients will continue to use the old RR server for peering. However, the old RR server will send a notification to the clients, indicating that it is going down and that they should use the new RR server.

-- The clients will then initiate a new peering session with the new RR server and start sending their routing updates to it.

With BGP graceful restart, the clients will not need to be reconfigured with the new loopback IP address of the new RR server. Instead, they will learn about the change automatically and switch to the new RR server without any disruption to the network.

[chiragom2341]

Thanks for the reply.

[paul driver]

Hello
Please note GR is only applicable if both ends of peers is advertising it own capability , meaning it t need to be enabled on all rtrs peering in to RR cluster(s)

[M02@rt37]

hello @paul driver 

Yes, you are correct GR requires that both BGP peers have the GR capability enabled, and that they have agreed to use GR during BGP session establishment. This means that @chiragom2341  will need to enable GR on all the routers that peer with the RR cluster, not just on the RR cluster itself.

In this case, GR can help minimize BGP disruptions during a network change or router failure, it does not completely eliminate the possibility of disruptions. Some BGP paths may still be lost during the restart process, and it's important to plan for and minimize the impact of these disruptions.

[paul driver]

Hello
Why do you need to relocate the loopback, why not just create a new RR with a new Loopback?

[chiragom2341]

Hi Paul,

Even if I create a new loopback in new RR I need to replace the current RR server loopback in the clients. 

[paul driver]

Hello
Correct, but you have deterministic approach to a migration, but this depends on how many clients you have which may not be administrative applicable, The other alternative is drop the RR entirely then relocate providing the clients do have resilient RR.

[MHM Cisco World]

I see same issue before but it was with DMVPN, the engineer use SCP to paste config in all Spokes
but to be honest it was not easy task, and he failed many times before he success. 
so I prefer change the RR IP in each client manually.  

[chiragom2341]

Thanks all for your valuable input, appreciated. I will check whether GR is enabled or not in all clients. All clients/peers currently have access to the RR servers at both the PROD and DR locations. The PROD RR server is presently the central point for all traffic. This activity will be performed at the DR site, no changes at PROD RR servers so from the viewpoint of the clients/peers, communication continues through PROD RR servers at the time of migration.