Managing EIGRP Bandwidth with ip bandwidth-percent
When configuring Enhanced Interior Gateway Routing Protocol (EIGRP) on Cisco routers, it is essential to control how much interface bandwidth is consumed by routing updates. This is especially important on low-bandwidth or congested links, where excessive control traffic can negatively affect application performance.
In this post, we explore how to manage EIGRP bandwidth usage using the
ip bandwidth-percent command, examine differences across IOS versions,
and compare EIGRP’s approach with OSPF bandwidth tuning.
For a comprehensive overview of EIGRP, refer to the Wikipedia article on EIGRP .
Controlling Bandwidth Usage for EIGRP
EIGRP uses a portion of the interface’s configured bandwidth to send routing updates. By default, EIGRP limits itself to 50% of the interface bandwidth. This behavior can be adjusted using the following interface-level command:
ip bandwidth-percent eigrp <AS-number> <percentage>
- AS-number: Autonomous System number of the EIGRP process
- Percentage: Maximum bandwidth EIGRP is allowed to consume
Example Configuration
Router1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)# interface Serial0/1
Router1(config-if)# ip bandwidth-percent eigrp 100 40
Router1(config-if)# end
Router1#
In this example, EIGRP is restricted to using no more than 40% of the interface bandwidth for routing updates.
Checking Interface Bandwidth
Router1# show interface Serial0/1
Serial0/1 is up, line protocol is up
Hardware is HD64570
Internet address is 10.1.1.1/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec
Encapsulation HDLC
Viewing EIGRP Traffic Statistics
Router1# show ip eigrp traffic
EIGRP-IPv4 Traffic Statistics for AS 100
Hellos sent/received: 145 / 140
Updates sent/received: 20 / 18
Queries sent/received: 3 / 3
Replies sent/received: 3 / 3
These outputs help confirm that EIGRP is functioning correctly and allow you to monitor control-plane traffic after bandwidth adjustments.
Syntax and Behavior Differences Across IOS Versions
Key Differences
- Subinterface Support: Older IOS versions may behave inconsistently on subinterfaces, while newer versions support reliable subinterface-level control.
- Bandwidth Calculation: Older IOS versions rely on default interface bandwidth values unless manually set. Newer IOS versions automatically factor in updated bandwidth settings.
- Precision: Newer IOS versions allow finer-grained bandwidth allocation. Older versions support only whole-number percentages.
- Dynamic Adjustment: Recent IOS releases apply changes dynamically without dropping neighbors. Older versions may briefly reset EIGRP adjacencies.
Comparison with OSPF Bandwidth Tuning
| Feature | EIGRP | OSPF |
|---|---|---|
| Bandwidth Control Method | ip bandwidth-percent eigrp |
Indirect (Hello/Dead timers) |
| Default Bandwidth Usage | 50% of interface bandwidth | No fixed percentage |
| Granular Control | Yes (percentage-based) | Limited |
| Effect on Adjacencies | Minimal (new IOS) | Timer changes may reset neighbors |
| Low-Bandwidth Optimization | Excellent | Moderate |
Unlike EIGRP, OSPF does not provide a direct mechanism to limit bandwidth usage. Instead, OSPF tuning relies on adjusting hello and dead intervals, which indirectly influences protocol traffic but can impact convergence time.
Best Practices
-
Set Accurate Interface Bandwidth:
Always configure the correct interface bandwidth using the
bandwidthcommand before tuning EIGRP. -
Monitor After Changes:
Use
show ip eigrp trafficandshow interfaceto validate behavior. - Use Subinterfaces Carefully: Apply bandwidth limits per subinterface on multipoint links.
Final Thoughts
Properly managing EIGRP bandwidth usage is critical for maintaining predictable
network performance, especially on low-speed or shared links. The
ip bandwidth-percent command provides precise and effective control,
making EIGRP particularly well-suited for constrained environments.
Have you encountered challenges while configuring EIGRP bandwidth limits? Share your experience in the comments and help others learn from real-world deployments.
No comments:
Post a Comment