By default, EIGRP is allowed to use up to 50% of the bandwidth of an interface or subinterface. EIGRP uses the default bandwidth of the link, or the bandwidth set by the bandwidth interface subcommand when calculating how much bandwidth to use.
The EIGRP pacing feature allows the fine-tuning of the bandwidth usage of a link for transmitting EIGRP traffic. The ip bandwidth-percent eigrp {as-num} {percent} interface subcommand adjusts the EIGRP link utilization for an [sub]interface based on the interface’s bandwidth value. The percent value is ranging from 1 to 999999. A percent value greater than 100 is reasonable if the bandwidth is configured artificially low for some routing policy reasons or to accommodate an oversubscribed multipoint Frame Relay interface.
Ex: A 512kbps interface is configured with a logical bandwidth of 56kbps. 200% is configured when 112kbps (2 x 56) is allocated for EIGRP traffic.
Note: Make sure that the physical link is provisioned to handle the configured capacity.
Cisco IOS treats Frame Relay point-to-point subinterfaces in the same manner as serial interfaces in terms of bandwidth. It assumes both of them are operating at full T1 link speed. However, only fractional T1 speeds are available in most implementations. Therefore, always remember to set the bandwidth to match the provisioned CIR when configuring these subinterfaces.
When configuring Frame Relay multipoint interfaces, remember that the bandwidth is shared equally by all neighbors – EIGRP uses the bandwidth of the physical interface divided by the number of Frame Relay neighbors connected on the physical interface to obtain the bandwidth attributed to each neighbor. EIGRP configuration should be fine-tuned to reflect the appropriate percentage of the actual available bandwidth for the link.
Figure 1: Frame Relay Multipoint with all VCs Share the Bandwidth Evenly
Figure 1 shows a Frame Relay network where RT1 has a Frame Relay multipoint interface and all VCs share the bandwidth evenly. The RT1 Frame Relay multipoint interface is configured for a bandwidth of 168kbps (3 x 56kbps CIR).
The sample network in Figure 2 have the same configuration as for Figure 1, where one of the circuits has been provisioned for a 56kbps CIR, and the other circuits have a higher CIR. RT1 Frame Relay multipoint interface is configured for a bandwidth that represents the lowest CIR multiplied by the number of circuits – 56 x 3 = 168. This approach might not fully utilize the higher-speed circuits, but it protects the circuit with the lowest CIR from being overwhelmed.
Figure 2: Frame Relay Multipoint with all VCs Have Different CIRs
Figure 3: Hybrid Frame Relay Network with Multipoint and Point-to-Point
Figure 3 shows a hybrid Frame Relay network, where there is 1 low-speed circuit and other VCs provisioned for a higher CIR. The lowest CIR VC is configured as point-to-point with the bandwidth equals to CIR; the higher CIR VCs are configured as multipoint with combined CIRs.
Figure 4: Frame Relay Hub-and-Spoke Network
Figure 4 shows a common oversubscribed Frame Relay hub-and-spoke topology with 10 VCs to the remote sites (only 3 remote sites are shown in the figure). The circuits are provisioned with 56kbps CIR, but there is insufficient bandwidth at RT1 interface to support the allocation.
All VCs are treated equally and are configured for about 1/10 (25kbps) of the RT1 link speed, and EIGRP link utilization is increased to 50% of the actual point-to-point VC capacity (56kbps). By default, EIGRP uses 50% of the bandwidth of a circuit. EIGRP configuration should reflect the correct percentage of the actual available bandwidth on the line. Therefore, each subinterface has the EIGRP allocation percentage raised up to 110% (~28kbps) of the specified bandwidth in order to ensure enough bandwidth to deliver EIGRP packets through the Frame Relay network. This configuration restores the 50-50 ratio when the bandwidth value was set artificially low for some reasons, eg: manipulation of the routing metric or to accommodate an oversubscribed multipoint Frame Relay configuration on the hub router interface.
The ip bandwidth-percent command relies upon the value set by the bandwidth command.
EIGRP can further conserve WAN bandwidth by suppressing ACKs. An ACK will not be sent if a unicast data packet is ready for transmission, as the ACK field in any RTP unicast packet is sufficient to acknowledge the EIGRP packets received from a neighboring router, therefore the ACK packet will be suppressed to conserve bandwidth. This is an essential feature for point-to-point links and NBMA networks, as on those environments, all data packets are sent as unicasts, and hence can carry an acknowledgement themselves (also known as piggyback ACK). In those environments, there is no need for ACK packets.
The show ip eigrp interfaces detail [intf-type intf-num] EXEC command shows the numbers of ACK packets suppressed for a particular interface.
Router#sh ip eigrp interfaces detail s0/0 IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/0 0 0/0 0 0/10 0 0 Hello interval is 5 sec Next xmit serialUn/reliable mcasts: 0/0 Un/reliable ucasts: 0/0 Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0 Retransmissions sent: 0 Out-of-sequence rcvd: 0 Authentication mode is not set Router#
No comments:
Post a Comment