FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
aionescu
Staff
Staff
Article Id 190141

Description

 

This article describes how to refresh a BGP routing table without disturbing a BGP peering session.

 

Scope

 

Any supported version of FortiGate.

Solution

 

A soft reset can be performed with or without 'soft-reconfiguration enable' configured on the BGP neighbor.

 

To refresh IPV4 and IPV6 routes received from a single IPV4 BGP neighbor:

 

The following CLI commands are equivalent. 'soft' here does not refer to soft-reconfiguration.

 

execute router clear bgp ip A.B.C.D soft in
execute router clear bgp ip A.B.C.D in

 

Refreshing received routes can be necessary after changing an inbound route-map, access-list, or prefix list. The route updates take effect immediately if soft-reconfiguration was already enabled. If soft-reconfiguration is disabled, the route update takes effect after the next advertisement-interval configured on the remote BGP neighbor. See the article 'Technical Tip: BGP - Soft Reconfiguration vs. Route Refresh' for differences between the mechanism for soft-reconfiguration and 'Route Refresh'.

 

To refresh IPV4 and IPV6 routes advertised to single IPV4 BGP neighbor:

 

The following CLI commands are equivalent. 'soft' here does not refer to soft-reconfiguration.

 

execute router clear bgp ip A.B.C.D soft out
execute router clear bgp ip A.B.C.D out

 

After executing one of those commands, a BGP UPDATE message is sent to the remote BGP neighbor at the next configured advertisement-interval. Refreshing advertised routes can be necessary after changing an outbound route-map, access-list, or prefix list. Route Refresh capability and soft-reconfiguration setting are not relevant when refreshing advertised routes.

 

To refresh IPV4 and IPV6 routes received from and advertised to a single IPV4 BGP neighbor:

 

execute router clear bgp ip A.B.C.D soft

 

Hard Reset:

 

execute router clear bgp ip A.B.C.D

 

  • Tears down the existing BGP session and removes existing advertised and received routes until BGP peering re-establishes.
  • It is not necessary or recommended in most cases.
  • It is triggered automatically if configured BGP capabilities are changed.
  • A Hard reset is not triggered by changing soft-reconfiguration settings.
  • It is necessary to apply any changes to configured BGP timers, see 'Technical Tip: All configurable BGP timers on the FortiGate explained'.

 

Sample reset commands:

 

execute router clear bgp ip 10.0.0.1 in <----- perform a soft reset for IPV4 and IPV6 routes received from IPV4 neighbor 10.0.0.1.
execute router clear bgp all soft <----- perform a soft reset for all routes received from or advertised to any BGP neighbors.
execute router clear bgp as 65002 out <----- perform a soft reset for routes advertised to any BGP neighbors which have remote AS 65002.

execute router clear bgp ipv6 fd70::1 in <----- perform a soft reset for IPV4 and IPV6 routes received from IPV6 neighbor fd70::1.

execute router clear bgp ip *  <----- perform a hard reset for all IPV4 and IPV6 BGP neighbors. Equivalent to 'execute router clear bgp all'.


Lab test results:


In the following example, the BGP peer is up and has received three prefixes from the BGP neighbor:

 

get router info bgp summary
BGP router identifier 2.2.2.2, local AS number 65002
BGP table version is 4
2 BGP AS-PATH entries
0 BGP community entries

Neighbor           V        AS      MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  State/PfxRcd
10.56.244.207   4      65003   11550     11555          3          0       0        6d01h18m         3

Total number of neighbors 1

FGT1 # get router info routing-table database | grep B
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       > - selected route, * - FIB route, p - stale info
B    *> 3.3.3.3/32 [20/0] via 10.56.244.207, port1, 00:25:29
B       10.56.244.0/22 [20/0] via 10.56.244.207, 00:25:29
B    *> 10.161.0.0/20 [20/0] via 10.56.244.207, port1, 00:25:29

 

Remote side advertising of prefix 50.50.50.50/32 was previously filtered out by an outbound route-map on the remote side. The administrator of the remote device has modified the route-map to allow subnet (50.50.50.50/32) to be advertised to the FortiGate. In this scenario, the remote peer will wait until the BGP connection goes down or its own route to 50.50.50.50/32 flaps before updating the advertised route.

 

To force BGP to learn new route without resetting the BGP peering, run the command below. An example output is attached.

 

exe router clear bgp ip 10.56.244.207 soft in  

get router info bgp summary
BGP router identifier 2.2.2.2, local AS number 65002
BGP table version is 4
2 BGP AS-PATH entries
0 BGP community entries
Neighbor           V         AS     MsgRcvd   MsgSent   TblVer  InQ   OutQ  Up/Down     State/PfxRcd
10.56.244.207   4      65003   11551        11555        3            0      0         6d01h19m                4

 

The uptime is not reset. After a delay of up to the remote side's advertisement-interval, the prefix received count shows as and the new route is installed in the routing table.

 

get router info routing-table database | grep B
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       > - selected route, * - FIB route, p - stale info
B    *> 3.3.3.3/32 [20/0] via 10.56.244.207, port1, 00:26:24
B       10.56.244.0/22 [20/0] via 10.56.244.207, 00:26:24
B    *> 10.161.0.0/20 [20/0] via 10.56.244.207, port1, 00:26:24
B    *> 50.50.50.50/32 [20/0] via 10.56.244.207, port1, 00:00:05             <----- New subnet received.

 

Note that scenario above only triggered the route update because the FortiGate has soft-reconfiguration disabled. If soft-reconfiguration is enabled, only the local database is checked when refreshing inbound routes- in that case any pending changes by remote side are not applied. Use the following BGP debug outputs to troubleshoot where necessary:

 

diagnose debug reset
diagnose ip router bgp all enable
diagnose ip router bgp level info
diagnose debug enable

 

Example debug snippet:

 

id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [FSM] State: Established Event: 34"
id=20301 logdesc="Routing log" msg="BGP: [RIB] Scanning BGP Network Routes..."
id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [DECODE] Msg-Hdr: type 2, length 48"
id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [DECODE] Update: Starting UPDATE decoding... Bytes To Read (29), msg_size (29)"
id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [DECODE] Update: NLRI Len(5)"
id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [FSM] State: Established Event: 27"
id=20301 logdesc="Routing log" msg="BGP: 10.56.244.207-Outgoing [RIB] Update: Received Prefix 50.50.50.50/32"
id=20301 logdesc="Routing log" msg="BGP: [RIB] Scanning BGP Network Routes..."

 

To stop the debug, run the following command:

 

diagnose debug disable

diagnose debug reset

 

Related documents:
v7.6.1 Administration Guide: Basic BGP example
Technical Tip: How to clear BGP Sessions