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:
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.
This would continue to accept all prefixes, but generate a warning for every prefix that after the 100th prefix:
This would do the same as the first example, but also generate a warning at 80 messages (80% of 100):
By default, the warning threshold is 75% if none is specified.
Lab
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.
On R4, we’ll limit the XR5 peer to a maximum of 3 advertised prefixes:
Let’s look at the neighbor parameters to verify the configuration worked:
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.
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.
Let’s advertise one more prefix on XR5
R4 lets us know that the maximum number of prefixes has been exceeded and brings down the session
In the BGP summary output, we can conviently see the reason that the peer is in Idle. PfxCt stands for Prefix Count.
Let’s remove that fourth prefix from XR5.
Remember that the neighborship will not restart on its own. We must manually clear the session.
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.
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.
The session went Established on its own this time, because we used the restart interval parameter.
Real world use
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
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.
Last updated
