# BGP Maximum Prefixes

In the SPCOR blueprint, section 1.5.c is “BGP prefix suppression.” It is unclear to me whether this refers to the max prefixes feature, which limits the maximum number of prefixes the router will accept from a peer, or whether it refers to the route flap dampening feature, which penalizes routes if they flap up/down too many times in a given interval.

I think it is worth covering both features, so we will start with maximum prefixes first.

The maximum prefix feature prevents a malicious peer from advertising millions of routes in an attempt to exhaust the local router’s resources. The administrator defines a set number of maximum prefixes it is willing to learn from the peer, and the action to take when the peer exceeds that limit.

The following actions can take place when the maximum number of prefixes is exceeded:

* The session is reset. An admin must manually re-establish the peering session using **clear ip bgp**.
* The session is reset and then automatically re-established after a configured time interval.
* The session is kept intact, routes are still installed in the table as normal, but a warning syslog message is generated for every prefix received over the max prefixes limit.

For all actions, you can configure a warning syslog message at a certain percent interval, such as 80%.

The configuration command looks like this:

```
neighbor 1.1.1.1 maximum-prefix num-prefixes [warning-threshold-percentage] [restart restart-interval-in-mins] [warning-only]
```

For example, this would limit the peer 1.1.1.1 to advertising 100 prefixes, and restart the session after 30 minutes. If the peer advertises 101 prefixes, the BGP session will be brought down, and then automatically restarted after 30 minutes. If the peer is still advertising 101 prefixes upon restart, the cycle of down/restart will continue.

```
neighbor 1.1.1.1 maximum-prefix 100 restart 30
```

This would continue to accept all prefixes, but generate a warning for every prefix that after the 100th prefix:

```
neighbor 1.1.1.1 maximum-prefix 100 warning-only
```

This would do the same as the first example, but also generate a warning at 80 messages (80% of 100):

```
neighbor 1.1.1.1 maximum-prefix 100 80 restart 30
```

By default, the warning threshold is 75% if none is specified.

### Lab <a href="#a4b6fec2-d603-4c96-b4a8-bfa8f5baa888" id="a4b6fec2-d603-4c96-b4a8-bfa8f5baa888"></a>

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FQcYV0ajsdC8Nk6DjSeyx%2Fimage.png?alt=media&#x26;token=0fd083cd-bd7c-42c9-b82b-14a7229d405e" alt=""><figcaption></figcaption></figure>

We’ll reuse our peering session between R4 and XR5 to test this feature.

Your peering session should still be Established, but we’ll need to add a route-policy to XR5 to accept/advertise prefixes. In the previous article, I omitted this step, because it wasn’t necessary to establish the peering session, which is all we were trying to do in the MD5 Authentication article.

On XR5, if we look at **bgp sum**, we can see an exclamation mark (!) next to the prefixes received. This lets us know that the neighbor does not have an RPL applied to it. Inbound/Outbound policies are necessary for eBGP neighbors on IOS-XR.

<figure><img src="https://1203572585-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgAMH3CMtmYTBkob03NUj%2Fuploads%2FOZj2WDFlXASeuevq8lCN%2FUntitled.png?alt=media&#x26;token=6f74b6f2-4a69-4795-9309-5ab398b9e7c8" alt=""><figcaption></figcaption></figure>

```
RP/0/0/CPU0:XR5(config)#route-policy PASS
RP/0/0/CPU0:XR5(config-rpl)#pass
RP/0/0/CPU0:XR5(config-rpl)#end-policy 
RP/0/0/CPU0:XR5(config)#router bgp 65002
RP/0/0/CPU0:XR5(config-bgp)#neighbor 10.4.5.4
RP/0/0/CPU0:XR5(config-bgp-nbr)#address-family ipv4 uni
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#route-policy PASS in
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#route-policy PASS out
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#commit
```

On R4, we’ll limit the XR5 peer to a maximum of 3 advertised prefixes:

```
#R4
router bgp 65001
 neighbor 10.4.5.5 maximum-prefix 3
```

Let’s look at the neighbor parameters to verify the configuration worked:

```
R4#show bgp neighbors 10.4.5.5
<snip>
 For address family: IPv4 Unicast
<snip>
  Maximum prefixes allowed 3
  Threshold for warning message 75%
```

By default, BGP will bring down the neighbor when 4 prefixes are received, and **not** automatically restart the session.

On XR5, let’s create some prefixes and advertise them.

```
XR5#
int lo0
 ip address 5.5.5.5/32
int lo1
 ip address 5.5.5.6/32
int lo2
 ip address 5.5.5.7/32
int lo3
 ip address 5.5.5.8/32
!
router bgp 65002
 address-family ipv4 unicast
  network 5.5.5.5/32
  network 5.5.5.6/32
  network 5.5.5.7/32
```

R4 generates a warning that its peer has advertised the maximum number of prefixes permitted. However, the session is not down yet. The maximum has been *reached* but not *exceeded*.

```
R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002    3281    3610        4    0    0 2d06h           3

R4#
*Jul 14 03:01:33.241: %SYS-5-CONFIG_I: Configured from console by console
R4#
*Jul 14 03:01:34.023: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3
```

Let’s advertise one more prefix on XR5

```
router bgp 65002
 address-family ipv4 unicast
  network 5.5.5.8/32
```

R4 lets us know that the maximum number of prefixes has been exceeded and brings down the session

```
R4#
*Jul 14 03:03:34.251: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.4.5.5 (afi 0): 4 exceeds limit 3
*Jul 14 03:03:34.251: %BGP-3-NOTIFICATION: sent to neighbor 10.4.5.5 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000003
R4#
*Jul 14 03:03:34.251: %BGP-5-NBR_RESET: Neighbor 10.4.5.5 reset (Peer over prefix limit)
*Jul 14 03:03:34.252: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Down Peer over prefix limit
*Jul 14 03:03:34.252: %BGP_SESSION-5-ADJCHANGE: neighbor 10.4.5.5 IPv4 Unicast topology base removed from session  Peer over prefix limit
```

In the BGP summary output, we can conviently see the reason that the peer is in Idle. PfxCt stands for Prefix Count.

```
R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002       0       0        1    0    0 00:00:41 Idle (PfxCt)
```

Let’s remove that fourth prefix from XR5.

```
XR5#
router bgp 65002
 address-family ipv4 unicast
  no network 5.5.5.8/32
```

Remember that the neighborship will **not** restart on its own. We must manually clear the session.

```
R4#
clear ip bgp 10.4.5.5

*Jul 14 03:07:08.235: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Up 
R4#
*Jul 14 03:07:13.259: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3
```

Let’s change our maximum-prefixes setting on this peer to automatically restart after 60 seconds. See if you can figure out the command on your own before proceeding.

```
R4#
router bgp 65001
 neighbor 10.4.5.5 maximum-prefix 3 restart 1

R4#show bgp neighbors 10.4.5.5
<snip>
 For address family: IPv4 Unicast
<snip>
  Maximum prefixes allowed 3
  Threshold for warning message 75%, restart interval 1 min
```

Remember that the restart interval is in minutes! I kind of tricked you by giving you the value in seconds.

If we add the fourth prefix again on XR5, what will happen? The session will be brought down on R4, but after one minute, the session will restart again automatically. If we remove that fourth prefix in that period of time, the session should go Established on its own. Let’s try it out.

```
XR5#
router bgp 65002
 address-family ivp4 unicast
   network 5.5.5.8/32

R4#
*Jul 14 03:12:34.143: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.4.5.5 (afi 0): 4 exceeds limit 3
*Jul 14 03:12:34.144: %BGP-3-NOTIFICATION: sent to neighbor 10.4.5.5 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000003
R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002       0       0        1    0    0 00:00:00 Idle (PfxCt)

R4#
*Jul 14 03:12:34.144: %BGP-5-NBR_RESET: Neighbor 10.4.5.5 reset (Peer over prefix limit)
*Jul 14 03:12:34.146: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Down Peer over prefix limit
*Jul 14 03:12:34.146: %BGP_SESSION-5-ADJCHANGE: neighbor 10.4.5.5 IPv4 Unicast topology base removed from session  Peer over prefix limit

XR5#
router bgp 65002
 address-family ivp4 unicast
   no network 5.5.5.8/32

R4#
*Jul 14 03:13:40.517: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Up 
R4#
*Jul 14 03:13:45.542: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3
```

The session went Established on its own this time, because we used the **restart&#x20;*****interval*** parameter.

### Real world use <a href="#id-1ac9fff0-14ef-45dc-a7f5-08f711313d27" id="id-1ac9fff0-14ef-45dc-a7f5-08f711313d27"></a>

You probably wouldn’t want to set such a low max-prefix limit in the real world. This was obviously for demostration purposes. In the real world you would use this feature on your internet peers, limiting IPv4 counts to something like 1 million. You might also limit your L3VPN customers to something like 10,000, so they don’t accidentally send you a full table.

### IOS-XR Differences <a href="#id-20f8bf79-9571-4948-a887-094c4a0f9a55" id="id-20f8bf79-9571-4948-a887-094c4a0f9a55"></a>

IOS-XR has one additional configuration parameter option, which is **discard-extra-paths**. This is sort of a compromise between **warning-only**, which will still accept all routes (even past the maximum), and the default action, which will reset the neighborship completely. With **discard-extra-paths**, the session stays up as normal, but the router drops any *additional* paths over the maximum count.

IOS-XR also has maxium prefix automatically enabled on **all** BGP peers (iBGP and eBGP). Each address family has a different maximum prefixes default count:

| **AFI**                 | **Count** |
| ----------------------- | --------- |
| IPv4 Unicast            | 1048576   |
| IPv6 Unicast            | 524288    |
| IPv4 and IPv6 Multicast | 131072    |
| VPNv4 Unicast           | 2097152   |
| VPNv6 Unicast           | 1048576   |

We can see this default in place on XR5 right now, because we have not set any maximum-prefixes on XR5 for its peer, R4.

<pre><code>RP/0/0/CPU0:XR5#show bgp ipv4 unicast neighbors 10.4.5.4 
Thu Jul 14 03:32:33.944 UTC
&#x3C;snip>
For Address Family: IPv4 Unicast
  <a data-footnote-ref href="#user-content-fn-1">Maximum prefixes allowed 1048576</a>
  Threshold for warning message 75%, restart interval 0 min
</code></pre>

[^1]: Here we see the default max prefixes when none is configured on IOS-XR for ipv4 unicast
