cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2231
Views
0
Helpful
12
Replies

EIGRP maximum bandwidth over a tunnel interface

Dean Romanelli
Level 4
Level 4

Hi All,

Im studying for CCNP Route exam and I came across the following information:

"EIGRP can use up to 50% of the total available bandwidth of an interface if needed. For example: EIGRP can use up to 768Kbps on a T-1 line if needed.

So, my question:

What is the maximum bandwidth EIGRP will allot itself over a tunnel interface?

1 Accepted Solution

Accepted Solutions

Dean

EIGRP will assume that the bandwidth of the tunnel is either the default value (which is extremely small) or what you have configured as the interface bandwidth. It does not consider the bandwidth of the physical interface.

The statement from your team lead architect is not correct. The tunnel bandwidth is not just for path preference. The specified tunnel bandwidth also impacts EIGRP bandwidth and also impacts calculation of utilization of the interface which might impact QOS (if configured) and any network monitoring software that tries to track interface utilization.

The best practice suggested by Cisco in EIGRP to select a preferred path is to manipulate the delay on the interface and not to manipulate the bandwidth.

The good news is that the bandwidth you are specifying is lots larger than the default. And other than the advertisements when the interface is first brought up the EIGRP advertisements are likely to be pretty small.

If you continue to be concerned about the impact on EIGRP there is a command that will tell EIGRP to use more than 50 per cents, which Joseph mentions.

HTH

Rick

HTH

Rick

View solution in original post

12 Replies 12

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

I believe it will take up to 50% of whatever it believes the tunnel's bandwidth is.  (NB: also believe you can change by using the bandwidth statement on the tunnel interface.)

Hi Joseph,

What does it believe the tunnel's bandwidth is though? How does it determine that? Does it automatically assume the tunnels bandwidth is equal to the physical interface the tunnel goes out on physically (i.e. the WAN link)?

Basically the conflict I am having, is that the lead architect of my team has designed two DMVPN tunnels on every spoke router we have, and they all connect back to hubs in two data centers for redundancy. EIGRP is our routing protocol.  For path preference though, we specify "bandwidth 750" to the primary data center (tunnel 1) and "bandwidth 600" to the redundant data center (tunnel 2).  However, if the statement in my first post is correct about EIGRP using up to 50% of the available bandwidth when needed, then we seem to be severely choking out EIGRPs bandwidth needs/potential when/if it needs to burst out updates, for example, by issuing the bandwidth command with, at best, 750Kbps. By the literature, this means EIGRP could use a maximum bandwidth of 375kbps.

When I asked him about it though, he said, "it doesnt matter, its only for path preference."  But the reading states that "While the bandwidth command doesn't cause the link to only be capable of traffic up to the figure specified in the bandwidth command, it does affect other things, such as QOS dedicated media-type bandwidth percentage allocations or what EIGRP calculates 50% to be, to determine how much bandwidth it can use."

So, the only way I can justify his claim that it doesn't matter, is that perhaps since the interface is virtual and doesnt have a physical wire speed, EIGRP calculates its allocation based on 50% of the bandwidth of the physical interface the tunnel traverses over (i.e. the physical WAN interface).

Dean

EIGRP will assume that the bandwidth of the tunnel is either the default value (which is extremely small) or what you have configured as the interface bandwidth. It does not consider the bandwidth of the physical interface.

The statement from your team lead architect is not correct. The tunnel bandwidth is not just for path preference. The specified tunnel bandwidth also impacts EIGRP bandwidth and also impacts calculation of utilization of the interface which might impact QOS (if configured) and any network monitoring software that tries to track interface utilization.

The best practice suggested by Cisco in EIGRP to select a preferred path is to manipulate the delay on the interface and not to manipulate the bandwidth.

The good news is that the bandwidth you are specifying is lots larger than the default. And other than the advertisements when the interface is first brought up the EIGRP advertisements are likely to be pretty small.

If you continue to be concerned about the impact on EIGRP there is a command that will tell EIGRP to use more than 50 per cents, which Joseph mentions.

HTH

Rick

HTH

Rick

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Dean, just to add a little to Rick's excellent reply, if there are concerns about EIGRP bandwidth utilization across your DMVPN links, you can also use QoS to manage EIGRP traffic.  You might also consider, if not doing so already, and unless doing spoke-to-spoke DMVPN, making your spokes EIGRP stubs (to limit EIGRP information exchanged).

Hi Joseph & Rich,

Thank you guys, this is exactly what I needed.

Also, I did a little research based on your answers and it would appear that the default tunnel interface bandwidth is 9.6kbps, making EIGRP bandwidth allotment a maximum of 4.8kbps by default. So it definitely does seem like our 750 and 600 statementswill be fine.

One last followup:

On router startup, is 4.8kbps too little for EIGRP to efficiently bring up the neighborships/burst out updates?  If so, is 300K / 375K?

Dean

I am glad that our responses are giving you the information that you need. Thank you for using the rating system to mark this question as answered.

The answer to your follow up question is "it depends". How many routes will the router advertise over the tunnel? How many routes will the router learn over the tunnel? If the router has lots of routes that it advertises or that it learns then the default bandwidth on the tunnel might be problematic. If the number of routes advertised and the number of routes learned are small then the default bandwidth will be no problem at all. I have seen quite a few networks where 4.8 K is quite enough and I have see networks where 300/375 K would not have been enough and would have had problems. So where in that continuum does your network fit?

Let me give you an example. I have done tunnels for a customer that were GRE with IPSec (not quite the same as DMVPN but it has the same issues about bandwidth limitations). In this customer the Enterprise routing table is quite large and would cause problems with EIGRP if we were using default bandwidth. But to help the network scale we do a LOT of summarization. The hub advertises about 6 subnets to the spoke and the spoke typically advertises 4 subnets to the hub. So there is no problem with default bandwidth in this implementation. (and besides we configure a much larger bandwidth on the tunnel interfaces so that the Network Monitoring System will not complain about how over utilized the tunnels are.)

HTH

Rick

HTH

Rick

Gotcha, Thanks Richard.

We run EIGRP stub on the spoke sites, so I would say that each spoke only has to advertise at most, 2 /24's, 1 /29 & 1/27 back to the hub. That said, our hub router manages neighborships to about 100 of these spoke sites, so my biggest concern would be in the event that our hub router locked up and we had to reload it during production prime time hours.

I've read that tunnel interface bandwidth values can be increased as much as to 8mbps. Is this accurate?

Dean

EIGRP stub at the spokes is a good thing. 100 spokes for the hub to initialize is a bit of a load for the hub router. But I suspect that the impact is more in terms of CPU processing than it is bandwidth consumption. Do you do any summarization at the hub to reduce the volume of advertisements from the hub to the spokes?

I believe that the tunnel bandwidth can be set to a very large number. I can not say authoritatively what the max is, but am comfortable that 8 Mbps is probably valid.

If you continue to be concerned about the bandwidth limitation of EIGRP then you should look into using the eigrp bandwidth percent command to change the per cent of bandwidth that EIGRP will use. Instead of 50 % tell it to use 80 %. Or if the configured tunnel bandwidth is less than the bandwidth of the physical interface then tell EIGRP to use 150 % of bandwidth.

HTH

Rick

HTH

Rick

Richard,

I believe we do summarize at the hub side, but the neighborships still come up on a one-by-one basis I believe. It's been a while since the hub was reloaded/had an issue. I want to say Columbus Day 2012 or so.  Thanks for those percentage commands.  I will certainly keep them handy if it becomes a problem.

Thanks Again Sir!

Dean

I am glad that our responses have provided you with helpful information.Summarization at the hub will improve the process of establishing neighbor relationships and will help the hub handle a larger number of spoke neighbors. But if the hub must be restarted or rebooted for some reason then it will have to go through the process with each individual neighbor. What kind of router (what model) are you using for the hub?

HTH

Rick

HTH

Rick

Richard,

It's a 2801 series.

Dean

Thanks for the information. A 2801 is a good router. I am not clear at what point the number of spokes becomes too much for this platform but believe that it is well past 100. The good news is that it is easier to support a number of spokes once they get to normal operating state. The part where sizing becomes more of an issue is when the hub must initialize all remote neighbors at the same time (and that does not happen often).

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco