BGP Soft Reconfiguration

When we change the BGP routing policy (changing the attributes or adding filters) we need to reset the BGP session before the new policy takes effect. This is no problem in a lab but it’s something you don’t want to do in a production network. In fact, there are 3 methods how you can refresh your BGP policies:

  • Hard reset
  • Dynamic Soft Reset (route refresh)
  • Soft reset with pre-stored information

The hard reset is the most simple method (clear ip bgp command). It kills the TCP session with your BGP neighbor which forces it to restart and as a result you’ll receive all prefixes from your neighbor again. It works, but it’s cruel…

Dynamic soft reset is the most preferred method, it requires the route refresh capability. Simply said, this feature lets your router request its BGP neighbor to send its prefixes again.

Routers that don’t support the route refresh capability will have to use the soft reset option. That’s what this lesson is about. You can read about dynamic soft reset / route refresh in my other lesson.

Normally I talk about “prefixes” or “routes” but technically the information that BGP exchanges in update messages is called NLRI (Network Layer Reachability Information). The NLRI field contains the prefixes and length.

The soft reset option uses “pre-stored” information. Basically when we receive prefixes from a BGP neighbor we will store this information in a new table and we don’t make any changes to it. Our router will then apply its inbound BGP policy to this table and stores the end result as the BGP table.

Since you are now storing another table for each neighbor instead of one BGP table you will have some overhead, your router will require more memory. This is especially true when you enable soft reset for all your BGP neighbors…keep this in mind before you configure this.

The tables that I’m talking about have some special names, let me show you a picture and explain this a bit more:

BGP adj-rib-in loc-rib adj-rib-out

On the left side we see a table called adj-RIB-in. This is the unedited routing information from a BGP neighbor. There’s a separate table for each BGP neighbor that you peer with. We apply our inbound BGP policy to this information and the result is a table called the loc-RIB, this is the actual BGP table.

BGP will select the best path from the BGP table and the router will install this in the routing table. Also, the best paths can be advertised to other BGP neighbors. We can apply an outbound BGP policy to outbound updates and when this is done we have a table called adj-RIB-out (per neighbor). The adj-RIB-in table is actually stored in memory for each neighbor, the adj-RIB-out table not.

Now you have an idea about the different tables and how soft reconfiguration works, let’s take a look at this on some BGP routers.


To demonstrate the soft reset we only need two routers. R1 has two loopback interfaces so that we have a couple of networks to advertise:

AS1 AS2 R1 R2 BGP External

First we will configure BGP between the two routers:

R1(config)#router bgp 1
R1(config-router)#neighbor remote-as 2
R1(config-router)#network mask
R1(config-router)#network mask
R2(config)#router bgp 2
R2(config-router)#neighbor remote-as 1

Nothing special here, we run EBGP and R1 advertises its two loopback interfaces. By default the soft reset option is disabled, let’s configure it on R2:

R2(config)#router bgp 2
R2(config-router)#neighbor soft-reconfiguration inbound

The soft-reconfiguration inbound command tells R2 to save the routing information from R1 unmodified in the adj-RIB-in table. It will then apply the inbound BGP policy and store the information in the BGP table.

Let’s take a look at these tables, a good way to do this is by changing some of the BGP attributes. I’ll change the local preference for the prefixes we receive from R1:

R2(config)#route-map LOCALPREF permit 10
R2(config-route-map)#set local-preference 200
R2(config-route-map)#router bgp 2
R2(config-router)#neighbor route-map LOCALPREF in

This will set the local preference to 200 for all incoming prefixes from R1. Instead of clearing the TCP session, we’ll do a soft reset:

R2#clear ip bgp soft in

Use the soft in parameter to do a soft reset. Now look at the BGP table first:

R2#show ip bgp
BGP table version is 3, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>             0    200      0 1 i
*>             0    200      0 1 i

The BGP table (loc-RIB) was modified as expected, now take a look at the adj-RIB-in table:

R2#show ip bgp neighbors received-routes
BGP table version is 3, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*             0             0 1 i
*             0             0 1 i

Total number of prefixes 2

Above you see the raw routing information from R1 before we applied the inbound BGP policy. You can see that no changes were made to the local preference of my prefixes.

Another nice experiment is to filter some of the prefixes:

R2(config)#access-list 1 permit host
R2(config)#router bgp 2
R2(config-router)#neighbor distribute-list 1 in

I’ll use a distribute-list so that /32 is not allowed anymore. Before I do another soft reset I’ll enable a debug, this allows you to see what the router is doing with the BGP updates:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 739 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

545 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Davis,

    When you don’t have soft configuration configured then that command will use the route refresh:

    R1#clear ip bgp soft in

    Here’s what you will see:

    BGP: sending REFRESH_REQ(5) for afi/safi: 1/1, refresh code is 0
    BGP: rcv message type 5, length (excl. header) 4
    BGP: rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 1
    BGP: rcv message type 5, length (excl. header) 4
    BGP: rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 2

    About the commands:

    • clear ip bgp x.x.x.x in:
    ... Continue reading in our forum

  2. Hi Rene and Team,

    Is the adj-RIB-In-In table for each neighbor static, as in it doesn’t dynamically update once it is initially populated when neighbor first comes up?

    If we want to repopulate the adj-RIB-In can this only be done with a hard reset?


  3. Hello Robert

    The adj-RIB-In table will not be refreshed when using a soft reset. The table is static only in the sense that it will not change when implementing a soft reset. But this table isn’t static in general. If there are changes to routing that BGP neighbours send to the local router, these will go into the adj-RIB-In table and be updated.

    A hard reset will repopulate the adj-RIB-In table, however, like Rene mentions, it is not preferred. If the router in question supports it, the most preferred method is the Dynamic Soft Reset option also known as R

    ... Continue reading in our forum

  4. Hello Laz.
    Thanks for the response. You cleared it up for me.

  5. Ingore the above, i see its automatically updates after the advertisement interval configured.

25 more replies! Ask a question or join the discussion by visiting our Community Forum