|
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 the below BGP debug command on FortiGate:
diagnose debug reset
diagnose ip router bgp all enable
diagnose ip router bgp level info
diagnose debug enable
Later to disable BGP debugs:
diagnose ip router bgp all disable
diagnose ip router bgp level none
diagnose debug reset
Note:
Starting from v7.2.0+, it is possible to collect BGP debugs for a specific neighbor by using the filter command 'diag ip router bgp set-filter neighbor <neighbor address>'. Follow this KB article for more details Technical Tip: Capture BGP debugs for a specific neighbor.
Look for the information below 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 AWS by doing any of the following:
- Summarize the prefixes if possible.
If the prefixes advertised to AWS are contiguous, summarizing them can drastically reduce the number. 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).
-
Use route-map/prefix-list in the outbound direction to filter what should be advertised to 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 a route-map can be a good option. It is also appropriate if the prefixes from this AS are dynamic.
|
