My understanding of the command:

clear ip bgp * soft out

is that the router on which the command is issued will re-advertise everything it knows about BGP to it's neighbors. As I see it, it's as if the two routers are creating a brand new adjacency, without severing the adjacency first (which would adversely affect the BGP reliability metrics).

My question is this: How can I verify that the command has been successful? When I issue

show ip bgp nei

the "Route Refresh" column still displays 0 sent and 0 received. I don't have access to the provider device (my BGP Neighbor), but I need to verify that my changes have been received by the provider. Any suggestions?

3 Answers 3


Soft reconfig (inbound) is only used if route refresh isn't supported (you also have to explicitly configure this); They're two different things. Does "show ip bgp neighbor x.x.x.x" output show route refresh in its advertised capabilities - "advertised & received"? To answer your question, the only way that you can verify that the "soft reconfig out" took effect (because this basically tells your router to refresh your outbound policy and send the updates to the neighbor) is to verify this with your provider.

Edit: To clarify, I suppose it depends on what policy you're trying to set. You can always do "show ip bgp neigh x.x.x.x advertised-routes" but AFAIK you can't get all the bits of info, i.e. communities (disclaimer: this was how it worked with Cisco kit I've worked on, not sure if Juniper/whomever else is better here or not).

One last edit (to clear up any possible confusion):

Soft reconfig inbound is used really to refresh your inbound policy in accordance to what someone is sending you. It basically stores a copy of the Adj-RIB(s)-In and when "clear ip bgp neigh x.x.x.x soft in" is run, it refreshes your inbound policy by applying it to the [copy] Adj-RIB-In prefixes before inserting them into the Loc-RIB.

With the route refresh capability, it eliminates the need to store a copy of the Adj-RIB-In and (assuming the neighbor supports it) will allow you to request a route refresh from the neighbor via just doing "clear ip bgp neigh x.x.x.x in" - no "soft" needed. In addition, even if your neighbor is capable of route refresh, and you've configured that neighbor with soft-reconfig, the soft-reconfig will take precedence over route refresh (not ideal due to the increased memory footprint with running soft-reconfig).

Soft reconfig outbound (you don't need anything to turn this on, you get it for free) will re-run your Loc-RIB (Adj-RIB-Out is just a pointer back to the Loc-RIB) through your outbound policies and send those updates to the peer.

  • By the way, here's a bit from cisco.com/en/US/products/ps6599/…. "If all BGP routers support the route refresh capability, use the clear ip bgp {* | address | peer-group name} in command. You need not use the soft keyword, because soft reset is automatically assumed when the route refresh capability is supported." May 22, 2013 at 5:57
  • I already noted that in my answer. :-) May 22, 2013 at 6:05
  • Oops. Must have missed that. The link to the Cisco doc seems useful, though. May 22, 2013 at 6:09
  • If the router does not support route refresh, if you omit the 'soft' keyword and just use clear ip bgp [] in what happens? Does the router attempt a soft-reconfiguration if preconfigured? May 22, 2013 at 6:17
  • I'd assume that if you do this without configuring the neighbor with soft reconfiguration, it would actually tear down the sessions and re-establish them, akin to a hard BGP clear. However if soft-reconfig was enabled, I'm not sure if IOS would "fall back" to a soft-clear inbound if you didn't specify the 'soft' keyword. Worth labbing it up to see though. May 22, 2013 at 6:25

To clarify the original question -

Route refresh message is sent to request the peer to advertise its routes back to you. It is thus useful if you issue 'clear bgp ... in' command.

For the command you are interested in, 'route refresh message' statistics won't go up.

There is no easy way to test the success of 'clear bgp * soft out'. The best bet is to look at the outgoing message counters (e.g. updates sent). Those should go up considerably compared to what they were before you issued the command (based on the number of prefixes you have).


If your BGP neighbor of your provider is "Established", and you're still seeing 0 routes in the "Prefixes Current" line of "show ip bgp neighbor x.x.x.x", and "show ip bgp" isn't showing your paths, then I suspect either:

  • you don't have any routes to send or receive
  • your filtering prefixes by policy, like with a route-map

If there is any policy attached to the neighbor or group, perhaps try applying a test route-map that sets the local-preference value very low for all the incoming prefixes. Send nothing outbound. This will still potentially install routes in your table, but shouldn't take precedence over other normal routes. If you're really paranoid, you can rewrite the next-hop to Null0 for testing, but beware that this'll blackhole any destinations that are more specific routes through the provider-under-test, or any unique routes out that provider.

  • 1
    OP's concern was with route refresh messages sent/received rather than actual BGP updates/prefixes received. May 22, 2013 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.