BGP - Soft Reset Outbound & Verification

Question

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?

Answer 1

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.

Answer 2

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).

Answer 3

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.