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.
fwilliams
Staff
Staff
Article Id 335835
Description

This article provides troubleshooting tips and possible causes of the BGP peering issue between FortiGate and AWS.

Scope FortiOS.
Solution

The number of advertised networks/prefixes that AWS can take from its BGP neighbor/peer is 100 (one hundred); this is hard-coded and cannot be changed, therefore the idea of asking AWS to change this value will not fly.

 

In a new BGP deployment to AWS (which failed to come up), if initial BGP troubleshooting like checking layer 3 reachability between the peers, ensuring no misconfiguration on both sides, etc. has been ruled out, the FortiGate peering with the AWS may be advertising too many prefixes (more than permitted), to its peer (AWS).

 

Note: This can also happen in an old setup, which has been up and running, but additional prefixes were advertised to AWS recently, causing the maximum number of prefixes to trigger.

 

As mentioned before, if the number of prefixes advertised is beyond the permitted number, the BGP neighbor will fail to form (established), or break if the neighbor-ship has been established before receiving more than the allowed prefixes.

 

Just to make sure this is the cause of the 'peering failure', run below BGP debug command on FortiGate:

 

diag debug reset

diag ip router bgp all enable

diag ip router bgp level info

diag debug enable

 

Look for the below information in the debug output (logs):

 

%BGP-3-NOTIFICATION: received from x.x.x.x 6/1 (Cease/Maximum Number of Prefixes Reached)

 

From the above information, the peering was refused by the neighbor and the reason was stated: 'Maximum Number of Prefixes Reached'.

 

Reduce the number of prefixes advertised to the AWS by doing any of the following:

 

  1. Summarize the prefixes if possible.

If the prefixes advertised to the AWS are contiguous, summarizing it can reduce the number drastically. For example:

  • 192.168.0.0/24.
  • 192.168.1.0/24.
  • 192.168.2.0/24.
  • 192.168.3.0/24.
  • 192.168.4.0/24.
  • 192.168.5.0/24.
  • 192.168.6.0/24.

This can be summarized as 192.168.0.0/21 (reducing advertised networks/prefixes from 7 to just 1).

 

  1. Use route-map/prefix-list in the outbound direction to filter what should be advertised to the AWS, leaving unnecessary prefixes behind/unadvertised. 

    Note: If only prefixes from a specific autonomous system (AS) are meant to be advertised to AWS, then using AS-PATH-LIST with route-map can be a good option. It is also appropriate if the prefixes from this AS are dynamic.