Showing results for 
Search instead for 
Did you mean: 

ASR BGP routing MAX prefix?

Today, I found the log:

RP/0/RSP0/CPU0:Aug 30 18:28:24.645 : bgp[1052]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes received from x.155.224.185 has reached 786768, max 1048576

That appear every 30 seconds. And found that it is the default limit on ASR

So, do you have any recommend for the ASR which received internet routes should I change the maximum prefix or change the threshold would be better? And what is the recommended value?


Thank you very much.

Cisco Employee

Either way is acceptable, it really depends on how many routes you expect and when you want to be warned.


This is an older guide but command hasn't changed



If I only change the threshold, is there any service impact or reset BGP peer?


Thank you very much.

Only if the number of prefixes known by the peer(s) exceeds the configured maximum value would the peering go down.



I am seeing this same message on an ASR 9904 running 6.1.4.


RP/0/RSP0/CPU0:Feb  2 19:58:36.820 CST: bgp[1054]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes received from [ip removed] has reached 789285, max 1048576


I added the "maximum-prefix 4294967295 80 warning-only" command to my configuration and reset the peer, but this did not resolve the issue. Here's my configuration:


router bgp 65500

neighbor [ip removed]

  remote-as [as removed]

  timers 10 40

  local-as [as removed] no-prepend replace-as

  description Internet

  update-source HundredGigE0/1/0/7

  address-family ipv4 unicast

   route-policy Internet in

   maximum-prefix 4294967295 80 warning-only <<< added this

   route-policy sample out

   remove-private-AS entire-aspath

   soft-reconfiguration inbound always



Does anyone have any ideas as to why this didn't stop the warning messages from coming in? The router logs are getting flooded with these messages.




Hi Chuck,


from the logs looks like your changes didn't take effect, max number still showing the default limit.


RP/0/RSP0/CPU0:Feb  2 19:58:36.820 CST: bgp[1054]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes received from [ip removed] has reached 789285, max 1048576


Can you make sure you applied max-prefix to the correct neighbor/afi also make sure to reset the neighbor "clear bgp <ip>" after config change.


you can look at  "# show bgp  neighbor <neighbor> | i Max   " to see the configured value.


regards/Anoop K V

Don’t do warning-only,

And don’t do maximum-prefix 4294967295 80,

Have you tested what happens with your BGP when a valid peer sends you ~4billion prefixes please?


My guess is the BGP runs out of memory and restarts -what happens to the FIB on all line-cards of your box I'm not even guessing...

And then the Route-Reflectors pushing 4bilion prefixes to all other PEs in your BGP Autonomous System…

I actually haven't tested so would be interested to know.


Anyways I'd rather have the offending internet peer/peers reset at around 1M or so -while BGP and line-cards can still cope with the load.

Of course VPN customers should have much lower thresholds.

The only safe place to do this is on iBGP sessions.






Thanks for your reply. I was thinking that by setting the threshold to the max value (~4B), I would never see these error messages in the logs again. Set it once and forget it. Also, I wanted the "warning-only" option so that my BGP peers dont get reset.


What are your thoughts on a more realistic threshold setting? 2 or 3 million? The default appears to be 1 million and the router is already at 75% of that threshold, thus the warning messages. Maybe I should consider a default route + customer routes only from my ISP, instead of a full routing table?




I think this could be a new thread, actually.


Depending on your place in the universe, default route may be all you need.  I've also recently heard talk of partial routes, which sounds like nothing longer than /16 or /20.  That seems like a good balance.  Rumor has it that there are some /32's in the table right now.


It seems like a major carrier located at an exchange and doing transit would have full tables.  A small/mid-tier provider that does not play a transit role, but that has multiple upstream providers, would benefit from partial tables.


Hi Chuck,


Yes setting to 4B would be the "let it wide open and never get logs" approach, but doing that would leave your box unprotected.

Internet is a wild west an anything possible however crazy it might sound will eventually happen.


Like some ISP prepending their AS# 255 times -and send the update to the Internet where number of boxes crashed (or bgp on them crashed) cause they did not expect that. (that’s why now we have the feature for limiting the AS-PATH length (I do max 51).

elseif as-path length ge 51 then



Or another example where university did an experiment and send out route update to the Internet with a never seen before BGP attribute -again number of BGP sessions got reset, and that’s why now we have the “BGP Attribute Filter” (which I’m not using, yet) and “Enhanced Attribute Error Handling” (enabled by default) features.


There's actually a whole lot of conditioning we do at ingress in order to make sure we shield ourselves from all the garbage:

Dropping prefixes too long/short, bogons, bogon AS numbers, long as paths, bleaching communities, etc..



With regards to your question on more realistic thresholds,

I use the following facing transit providers:

maximum-prefix 1000000 90 restart 2

-and once I get alarms I’ll crank it up to 1.5M


Regarding the “default route + customer routes” v “full feed”

If you have multiple transit providers (or even some peers, via IX or direct) then full feed from each transit will provide you with the best path to each destination out there and will also allow you to do traffic engineering.

If you have a single link to the outside world then default-route is the way to go.

But there’s a ton of documentation out there explaining when to do full-feed and wen default route is enough.