Technical Tip: How to clear BGP Sessions

When policies such as access lists or attributes are changed, the change takes effect immediately. The next time that a prefix or path is advertised or received, the new policy is used. However, the changed policy is not applied retroactively; prefixes that were already advertised or received are not affected. In a stable network, it can take a long time for an existing prefix to be re-advertised or received again.

It is possible to trigger a manual update to ensure that the policy is applied to all affected prefixes and paths after the next advertisement-interval (default 30 seconds).

Ways to trigger an update:

• Hard reset: The BGP session will go down and be reestablished; traffic will be affected.

Command:

execute router clear bgp [ip|all|ipv6] <neighbor_ip>

As of v7.6.3, it is possible to clear all peers (IPv4 and IPv6) under one group:

execute router clear bgp group <group name>

execute router clear bgp group
    <args...> Input arguments:
    <string> group name
        [in|out]
        in prefix-filter
        soft [in|out]
        vpnv4|vpnv6 unicast soft [in|out]
        l2vpn evpn soft [in|out]

A hard reset is also triggered automatically by most changes to the BGP capability configuration. Examples of BGP capabilities include Route Refresh, Graceful Restart, and ORF.

• Soft reset.

Command:

execute router clear bgp ip <neighbor_ip> soft [in|out]

For IPv6:

execute router clear bgp ipv6 <neighbor_ip> soft [in|out]

Out: Resend all BGP information to the neighbor without resetting the connection. Routes will resend after the next advertisement-interval expires (default every 30 seconds).

Recommended when changing outbound policy. 

In: Available if soft-reconfiguration is enabled, or if the Route-Refresh BGP capability was advertised and received during BGP session setup. Recommended when changing inbound policy.

Soft-reconfiguration is not usually required for a soft reset. If soft-reconfiguration is configured, FortiGate will store an unmodified copy of all received prefixes from the neighbor in case the inbound policy is changed- this consumes more memory.

See the article 'Technical Tip: BGP - Soft Reconfiguration vs. Route Refresh' for more discussion of the differences between Route Refresh and soft-reconfiguration.

Verifying if Route Refresh is available.

get router info bgp neighbors <neighbor IP> | grep capabilities -A 1

If both peers are configured to support Route Refresh, 'Route refresh: advertised and received' is visible under Neighbor capabilities:

vdom2 # get router info bgp neighbors 10.200.2.2 | grep capabilities -A 1

Neighbor capabilities:
Route refresh: advertised and received (old and new) 

Related article: 

Technical Tip: BGP soft reset to refresh BGP routing table without tearing down existing peering sessions