Why does EIGRP need 50% of configured Bandwidth?

[jaighobahi]

Hello there,

Please tell me: 

1.  Is there no minimum or maximum bandwidth that EIGRP can use for route updates? 

2.  Why does it need to use 50% of the available bandwidth?

3.  If I have a link with say, 256kbps, EIGRP uses 128kbps of it.  If I have a link of say, 1gbps, EIGRP uses 500mbps of it.  Why does the bandwidth required by EIGRP grow with available bandwidth?

[Richard Burts]

I believe that you have an incorrect understanding about EIGRP and bandwidth. You believe that EIGRP will use 50% of the bandwidth. The correct understanding is that EIGRP will use no more than 50% of bandwidth (or whatever percent is configured - since there is an optional configuration parameter to control the %).

When the bandwidth is fairly large the EIGRP bandwidth percent does not matter much because the amount of bandwidth that EIGRP will need is much less than 50% of that bandwidth. But when the bandwidth is small, then there is a potential issue. On a low bandwidth link if there are lots of EIGRP updates to send then EIGRP could potentially monopolize the link and have negative impact on other types of traffic that need to use that link. So Cisco added an enhancement to EIGRP to establish an upper limit and EIGRP will use no more than this upper limit and will therefore leave bandwidth available for other types of traffic.

HTH

Rick

[Rahul Kukreja]

By default EIGRP Packets on an Interface could use AT MAX 50% of the B/W configured on interface.

The 50% is just a mark, you could reduce or increase it by using interface level command -

ip bandwidth-percent eigrp 1 <>

Unless there are frequent flaps in the Network - only EIGRP Hello packets are sent, for which the B/W required is very less.

[jaighobahi]

Thanks a lot folks.  I get it now.  But then, I have another question.

I am practicing with a link that has CIR 64kbps and BW 25kbps.  I am told that EIGRP will need 50% of the CIR.  For this reason, I need to use the command "ip bandwidth-percent eigrp 1 128" so that EIGRP would then be able to use 32kbps.  If the ISP can only provide 25kbps, from where will EIGRP get 32kbps? If EIGRP takes 32kbps, is there any bandwidth left for other traffic on the link?  These question are based on the example on page 115 of Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide.

Your comments will be appreciated.

[cadet alain]

Hi,

if the CIR is 64k then this is what your provider should give you contractually, from where did you get the 25k, is it from the bandwidth value of the link ? if so then this is just a value that you can tweak and that doesn't represent the actual data rate of the interface but which is used by the router for many things like ospf cost calculation, Qos settings, EIGRP bandwidth percent.

Regards

Alain

Don't forget to rate helpful posts.

[jaighobahi]

Like I said, the questions arose from the Cisco Press book that I am reading.  The book says that the link is provisioned for 64kbps but there is inssufficient bandwidth on the headquarter router.  There are ten links and combined bandwidth required is 640kbps, but the headquarter router can only support 256kbps.  The 256kbps is shared equally amongst the links.  This gives approximatley 25kbps per link.

Perhaps, I should ask:

What does it mean to provision a link for 64kbps and then configure its bandwidth to 25kbps?

[Giuseppe Larosa]

Hello Jaighobahi,

>> What does it mean to provision a link for 64kbps and then configure its bandwidth to 25kbps?

As explained by other colleagues the bandwidth parameter has administrative meaning and does not reflect the actual access rate of each remote office.

By configuring a bandwidth of 25 Kbps the following points can be achieved:

- the bandwidth related EIGRP metric component has a value of 25 kbps for the link

- QoS configurations will use this 25 kbps as a reference for several objects like a scheduler

- there is an implicit shaper for EIGRP packets that will make each remote office to use up to 50% of 25 kbps. This means that even in the worst case of all EIGRP adjacencies restarted at the same time the total traffic used to send EIGRP updates from the then 10 remote offices to the central office will be 125 kbps.

The example of the book provides an example of tuning the implicit shaper for the EIGRP traffic: by imposing 128% of stated bandwidth each remote site can use up to 32 kbps for sending its own EIGRP update packets to the central office.  This is a way to speed up EIGRP convergence without changing the bandwidth value of 25 kbps that is used for QoS purposes like  shaping all user traffic for example or  to configure a scheduler.

Otherwise the EIGRP traffic would be limited to 12.5 Kbps per remote office to central office direction.

Hope to help

Giuseppe

[jaighobahi]

Much thanks, Giuseppe.  Your explanation surely does help.  I guess the book example assumed many underlying principles.  So, in a worse case scenario where all ten remote router are doing fast covergence, they would need up to 320kbps.  But the central office router can only support 256kbps.  What will happen, will some of the remote routers default back to 12.5kbps?

[Giuseppe Larosa]

Hello Jaighobahi,

>> So, in a worse case scenario where all ten remote router are doing fast covergence, they would need up to 320kbps.  But the central office router can only support 256kbps

Some Frame Relay frame(s)  each containing an EIGRP update could be held in the Frame Relay switch queues on the input interface(s) and output interface to the HQ  router.

However, EIGRP update packets need to be acknowledged one by one by the intended receiver, so there is no burst of EIGRP packets sent ( no train of multiple consecutive packets sent by an EIGRP router before waiting for an ack).

Taking in account this aspect of EIGRP traffic some  moderate overbooking like in the book example can be acceptable.

It is a tradeoff between safety and EIGRP speed of convergence.

The single EIGRP router will wait for an EIGRP acknowledge  after sending a single EIGRP packet and this provides flow control. And there is no synchronization in the act of sending the EIGRP packets between the different routers (also the EIGRP hellos are backed off with a random timer) so the probability that all routers send a packet at the same time is quite low.

Of course with so low bit rates the overbooking makes possible for some packet to be held in a queue for some time in the FR network. If that queue becomes full a packet ( actually a FR PDU that carries the EIGRP update) may be dropped. The router that has sent the dropped  EIGRP packet will retransmit  it.

Hope to help

Giuseppe

[jaighobahi]

Again, I say thank you for the explanations.