Service Providers or Large enterprises commonly change routing policies from time to time, specially when adding new links or peering relationships with other entities.
When you change the inbound policy of your BGP speaker you need to reprocess the updates you received from that peer. BGP4 has no mechanism of requesting a re-advertisements from one of its peers. One solution to this problem is to store the received information local on the router and reprocess them without the need to refer to the peer who sent these updates. This option consumes a lot of resources on the router when you have multiple peering relationships.
The route refresh capability introduces another solution to the problem by allowing the local router to request a copy of the Adj-RIB-out database of its peer.
Any peer that is willing to participate in this operation should advertise its route refresh capability during the session establishment with its peer using BGP Capabilities advertisement.
When you change your inbound policy configuration the local speaker will send a Refresh-Request message with a specific <AFI,SAFI> pair asking the peer to re-advertise updates.
When a peer receives a refresh message it will advertise its Adj-RIB-out of <AFI,SAFI> pair specified in the message after applying the outbound filters.
Both Cisco and Juniper support this feature. No configuration is required, the feature is negotiated during the session establishment phase and can be used only if both BGP speakers support this capability.
Use the command show ip bgp neighbor on IOS and show bgp neighbor on JUNOS to know if your peer supports route refresh capability or not.
For more information about this feature refer to RFC2918.