%CERM-4-RX_BW_LIMIT : Maximum Rx Bandwidth limit

Recently I have been doing a large number of deployments in MPLS L3 VPN networks in an effort to replace a number of very high-priced T1 circuits ($8000 a month per T1 circuit to be exact!) where we are literally doing an SVTI tunnel using the same IP addresses that were being used by the point-to-point T1 link serial interfaces.  During these efforts we have been deploying a series of Cisco 2901 routers and having to apply the SEC-K9 licenses manually (we had a few 10-pack electronically-delivered licenses).

The MPLS L3 VPN setup on our side is a simple BGP peering with the “provider”, with an SVTI tunnel as our overlay between our sites (over the “provider” network) and running IKEv2 crypto for everything.  What we noticed was that after a reboot the routers were reporting the following error in the log file (and we were seeing this for BOTH permanent licenses that had been applied as well as using the temporary “Right-to-Use” 8-week trial licenses):

%CERM-4-RX_BW_LIMIT : Maximum Rx Bandwidth limit of [dec] Kbps reached for Crypto 
functionality with temporary license for securityk9 technology package.

The irony, is that the SEC-K9 license is capable of supporting up to 85Mbps of encrypted throughput with 255 tunnels and the programs we were migrating were, at their very busiest, only sending between 4-10Mbps!  So, how was it possible that we were receiving this error???  Again, the odd thing was that the error would only post to the log file for about 60-90 seconds AFTER a reboot of the router was done!

A burst (or what I like to refer to as a micro-burst) of traffic was the culprit.  In fact, we were able to replicate this error on demand.  Just reload the router and there was enough of a burst in traffic over the tunnel (albeit a tiny one) when the BGP, SVTI, and IKEv2 traffic all flooded across the link and that was enough to generate the %CERM-4-RX_BW_LIMIT message.  After about 60-90 seconds after the tunnel interface came up (yep, we are using a single tunnel interface!) we don’t see the errors anymore.  According to the support document located at:

http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/118746-technote-isr-00.html

you can run into this issue “Even if the burst is for a few milliseconds, it is enough to trigger the curtailed crypto bandwidth limit.

I am convinced that this is what we were/are seeing and again, after 60-90 seconds it was done and the errors are long gone.  In short, don’t panic if you are seeing these messages in your log on your router if you know that you are well under the 85Mbps threshold as it appears that the router is reacting to the “millisecond” burst of traffic that it could be receiving to encrypt…and it looks like a BGP peering with an overlay SVTI tunnel and IKEv2 is enough to make that happen after a reboot 🙂  I mention BGP not because the traffic is being encrypted, but because that is the routing protocol we are using to peer with our “provider”.

You might be asking yourself about the use case of when you actually ARE sending over 85Mbps of traffic that needs to be encrypted and if that is the case, well, then you need to upgrade to the Cisco HSEC-K9 license AND get yourself an upgraded router starting with the 2921 (thanks to @rtaccon for his feedback!).  This will “unlock” the ability of your 2921 (or larger ISR G2) router to exceed the 85Mbps limit imposed by the SEC-K9 license!

Okay, I hope this helps you out and best of luck from the dark side!

/dev/null

Leave a Reply

Your email address will not be published. Required fields are marked *