EIGRP WAN Links

Hey guys,

I'm working through the CCNP Route Lab Manual and I'm on Lab 2-4 and I'm trying to confirm my answer. I attached the question and answer, and to confirm is the answer 32Kbps due to the fact that EIGRP uses by default 50% of the total bandwidth of the link and that R2(EAST) has a 64Kbps WAN link so 64/2 = 32?

Thanks!

Question.jpg

Topology.JPG

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

Monkerz

By default EIGRP is allotted 50% of the link's bandwidth. I wouldn't think this is a directional calculation, so to me the "to EAST" part of the question is irrelevant. I would think that the answer is 64, as 50% of bandwidth on HQ's S0/0/1 is reserved for EIGRP traffic regardless of destination.

I could be wrong, but this just feels right.

fluk3d

I would agree with you however the answer indicates 32Kbps which threw me off. It could be the wording of the question, or maybe I'm not thinking it through properly?

Monkerz

You would think that if this was such a problem over <1.5M links, Cisco would have created a show command to show EIGRP's usage out an interface, but they didn't.

I suppose this is just theory, as there is no way to prove what is used by the protocol. Would be nice to lab it up and see what the threshold is.

networker050184

Of course there is a way to prove it! Get a sniffer or maybe some NBAR running on the router and see whats coming out.

fluk3d

I think I know why the answer is 32Kbps. It's because the max speed of that link to EAST is only 64Kbps so regardless what the WAN speed between the HQ router and the SP won't matter.

MrBrian

Been awhile since I looked into EIGRP WAN bandwidth, but I know for multipoint int's over nbma the bandwidth will be further subdivided for each pvc. Which makes sense to how they came up with 32kbps.

Off the top, the HQ router will say.. I can use 50% of my 128 kbps interface for EIGRP traffic (which is 64kbps). Then it says.. I have two pvc's out this interface, so that 64kbps will get divided by 2. So HQ will allow up to 32kbps for EIGRP traffic to teach neighbor. If HQ had 5 pvc's, then it would be 64/5 kbps= EIGRP bw for each pvc. The ROUTE OCG discusses this on page 68 (not sure for flg). In the book it mentions that EIGRP does this for multipoint int's, but the logic must be the same for this setup.

xXErebuS

fluk3d wrote: »

I think I know why the answer is 32Kbps. It's because the max speed of that link to EAST is only 64Kbps so regardless what the WAN speed between the HQ router and the SP won't matter.

;
I am having trouble seeing the diagram so I am hoping I'm not too far off topic ---- IN EIGRP with NBMA you are expected to take the CIR speed of the lowest speed connection and multiply it by the number of VC connections and apply that to the main connection, therefore if you have a 64K connection you can assume to see 50% of that on your EIGRP links.

fluk3d

Thanks guy that makes some sense now.. finishing up eigrp this week and then onto OSPF

instant000

I'm not saying that your answer was wrong, I'm saying that your reason for coming up with the answer ... I actually disagree with. The reason for the answer is totally with regards to HQ router R1, and not the East router.

1. This configuration notes article covers the case you bring up. Look at the example with hub-and-spoke frame relay.

Configuration Notes for the Implementation of EIGRP over Frame Relay and Low Speed Links - Cisco Systems

2. According to the command reference, the default is 50 percent.

Cisco IOS IP Command*Reference, Volume 2*of 3: Routing Protocols, Release*12.2 - EIGRP Commands* [Cisco IOS Software Releases 12.2 Mainline] - Cisco Systems

3. In this case, I think it helps to look at what is actually happening here. The reason that the answer to the question is 32 kb/s is NOT because the max speed of the link to East branch is 64. The reason it is 32 kb/s is because EIGRP is dividing the bandwith to both neighbors, so, if it had only one neighbor out that interface, sure, it would actually allocate 64kb/s to EIGRP, but since it has two neighbors, it is actually allocating 32 instead.

That is, EIGRP is using this formula:

EIGRP BANDWIDTH USED = (1/N) * .50 * BW

Where N = number of neighbors, and BW = bandwidth

1/2 *.50 * 128 = 32

EIGRP and its Bandwidth Consumption

I feel that this is really an important distinction to make.

Because, if you had this question on a test, AND the scenario was that this HQ router had 4 neighbors, the most that HQ router R1 would use for eigrp would be 16 kb/s per neighbor, based on the default of using 50% link bandwidth.

So, if the bandwidth isn't allocated carefully, and you have a lot of EIGRP traffic going on here with a lot of updates, you could potentially get issues in your routing updates, missed hellos, SIA, etc.

What Sequiera says is actually the same thing you have in the first picture attached to this post, read the referenced statements carefully.

I hope this helps.

xXErebuS

instant000 wrote: »

I'm not saying that your answer was wrong, I'm saying that your reason for coming up with the answer ... I actually disagree with. The reason for the answer is totally with regards to HQ router R1, and not the East router.

1. This configuration notes article covers the case you bring up. Look at the example with hub-and-spoke frame relay.

Configuration Notes for the Implementation of EIGRP over Frame Relay and Low Speed Links - Cisco Systems

2. According to the command reference, the default is 50 percent.

Cisco IOS IP Command*Reference, Volume 2*of 3: Routing Protocols, Release*12.2 - EIGRP Commands* [Cisco IOS Software Releases 12.2 Mainline] - Cisco Systems

3. In this case, I think it helps to look at what is actually happening here. The reason that the answer to the question is 32 kb/s is NOT because the max speed of the link to East branch is 64. The reason it is 32 kb/s is because EIGRP is dividing the bandwith to both neighbors, so, if it had only one neighbor out that interface, sure, it would actually allocate 64kb/s to EIGRP, but since it has two neighbors, it is actually allocating 32 instead.

That is, EIGRP is using this formula:

EIGRP BANDWIDTH USED = (1/N) * .50 * BW

Where N = number of neighbors, and BW = bandwidth

1/2 *.50 * 128 = 32

EIGRP and its Bandwidth Consumption

I feel that this is really an important distinction to make.

Because, if you had this question on a test, AND the scenario was that this HQ router had 4 neighbors, the most that HQ router R1 would use for eigrp would be 16 kb/s per neighbor, based on the default of using 50% link bandwidth.

So, if the bandwidth isn't allocated carefully, and you have a lot of EIGRP traffic going on here with a lot of updates, you could potentially get issues in your routing updates, missed hellos, SIA, etc.

What Sequiera says is actually the same thing you have in the first picture attached to this post, read the referenced statements carefully.

I hope this helps.

I see the diagram now! I have to disagree on one small thing.... The reason you get 32kb/s is everything to do with the max speed of the EAST (in a correct topology). If East was 32kb/s it would in return make the HQ link total bandwith 64kb/s instead of 128kb/s....

The problem is that you can specify incorrect bandwith on that HQ router and end up using all the traffic for EIGRP and even dropping traffic. For example; your example of 4 neighbors is incorrect.

If you had 4 64kb/s neighbors your main HQ link would need to be 256K bandwith; then you divide by N = 64kb/s x .5 = 32kb/s still.

So what if you don't increase the 128k? Well you have 64k connections sending up to 32kb/s x 4 = 128kb/s... the entire HQ link is being used for EIGRP (Potentially)...

From your reference....

fluk3d

xXErebuS wrote: »

I see the diagram now! I have to disagree on one small thing.... The reason you get 32kb/s is everything to do with the max speed of the EAST (in a correct topology). If East was 32kb/s it would in return make the HQ link total bandwith 64kb/s instead of 128kb/s....

The problem is that you can specify incorrect bandwith on that HQ router and end up using all the traffic for EIGRP and even dropping traffic. For example; your example of 4 neighbors is incorrect.

If you had 4 64kb/s neighbors your main HQ link would need to be 256K bandwith; then you divide by N = 64kb/s x .5 = 32kb/s still.

So what if you don't increase the 128k? Well you have 64k connections sending up to 32kb/s x 4 = 128kb/s... the entire HQ link is being used for EIGRP (Potentially)...

From your reference....

I believe that's what I came up with before if you check out my previous post regardless what the HQ bandwidth is to the SP won't matter because the EAST router's uplink is only capped @ 64Kb if it was a different WAN topology the game changes now..

instant000

I set up a frame lab, similar to, but not exactly like the one given (my interface names are different, but the basic point is the same).

Hardware:  3725
modules:  2 x wic-2T per router

Connections:
R3 S0/0 - R1 S0/1
R3 S0/1 - R2 S0/1
R3 S0/2 - R4 S0/0



R1:
config t
hostname HQ 
! 
interface Loopback1 
 ip address 10.1.1.1 255.255.224.0 
interface Loopback33 
 ip address 10.1.33.1 255.255.224.0 
interface Loopback65 
 ip address 10.1.65.1 255.255.224.0 
interface Loopback97 
 ip address 10.1.97.1 255.255.224.0 
interface Loopback129 
 ip address 10.1.129.1 255.255.224.0 
interface Loopback161 
 ip address 10.1.161.1 255.255.224.0 
!
interface serial 0/1 
bandwidth 128
ip address 172.16.124.1 255.255.255.248 
encapsulation frame-relay ietf 
no frame-relay inverse-arp 
frame-relay map ip 172.16.124.2 102 broadcast 
frame-relay map ip 172.16.124.3 103 broadcast 
frame-relay map ip 172.16.124.1 201
no shutdown 
!
router eigrp 1
network 0.0.0.0
no auto
end







R2:
config t
hostname EAST 
! 
interface Loopback1 
 ip address 10.2.1.1 255.255.224.0 
interface Loopback33 
 ip address 10.2.33.1 255.255.224.0 
interface Loopback65 
 ip address 10.2.65.1 255.255.224.0 
interface Loopback97 
 ip address 10.2.97.1 255.255.224.0 
interface Loopback129 
 ip address 10.2.129.1 255.255.224.0 
interface Loopback161 
 ip address 10.2.161.1 255.255.224.0 
! 
interface serial 0/1 
bandwidth 64
ip address 172.16.124.2 255.255.255.248 
clock rate 64000 
encapsulation frame-relay ietf 
no frame-relay inverse-arp 
frame-relay map ip 172.16.124.1 201 broadcast 
frame-relay map ip 172.16.124.3 201
frame-relay map ip 172.16.124.2 201 
no shutdown 
!
router eigrp 1
network 0.0.0.0
no auto
end



end






R4:
config t
hostname WEST 
! 
interface Loopback1 
 ip address 10.3.1.1 255.255.224.0 
interface Loopback33 
 ip address 10.3.33.1 255.255.224.0 
interface Loopback65 
 ip address 10.3.65.1 255.255.224.0 
interface Loopback97 
 ip address 10.3.97.1 255.255.224.0 
interface Loopback129 
 ip address 10.3.129.1 255.255.224.0 
interface Loopback161 
 ip address 10.3.161.1 255.255.224.0 
! 
interface serial 0/0
bandwidth 64
ip address 172.16.124.3 255.255.255.248 
encapsulation frame-relay ietf 
no frame-relay inverse-arp 
frame-relay map ip 172.16.124.1 301 broadcast 
frame-relay map ip 172.16.124.2 301 
no shutdown 
!
router eigrp 1
network 0.0.0.0
no auto
end




R3:

hostname FRS 
! 
frame-relay switching 
! 
interface Serial0/0
 description FR to HQ S0/1
 no ip address 
 encapsulation frame-relay ietf 
 clock rate 128000 
 frame-relay lmi-type cisco 
 frame-relay intf-type dce 
 frame-relay route 102 interface Serial0/1 201 
 frame-relay route 103 interface Serial0/2 301 
 no shutdown 
! 
interface Serial0/1 
 description FR to EAST S0/1
 no ip address 
 encapsulation frame-relay ietf 
 frame-relay lmi-type cisco 
 frame-relay intf-type dce 
 frame-relay route 201 interface Serial0/0 102 
 no shutdown 
! 
interface Serial0/2
 description FR to WEST S0/0
 no ip address 
 encapsulation frame-relay ietf 
 clock rate 64000 
 frame-relay lmi-type cisco 
 frame-relay intf-type dce 
 frame-relay route 301 interface Serial0/0 103 
 no shutdown 
! 
End

Now, go and do a sh ip eigrp int serial on each router:

WEST#sh ip eigrp int s0/0
IP-EIGRP interfaces for process 1

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0              1        0/0      1277      10/380       5488           0
WEST#


EAST#sh ip eigrp int s0/1
IP-EIGRP interfaces for process 1

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/1              1        0/0      1236      10/380       5324           0
EAST#


HQ#sh ip eigrp int s0/1
IP-EIGRP interfaces for process 1

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/1              2        0/0        32       5/190        504           0
HQ#

The "pacing time" is a value EIGRP uses to determine how often it sends updates for routing protocols. This is what really determines how much "bandwidth" the protocol uses. There isn't a handy "show" command to say how much bandwidth it uses, as its not that simple. The protocol uses this timer to control how often it sends updates (which effectively does the same thing). My assertion is that the question asked about HQ R1, and HQ R1 bases its pacing time on the bandwidth assigned to its local interfaces. Thus, it bases it upon how much bandwidth it thinks the interface has. I am saying that what HQ R1 decides to do with how much bandwidth it uses HAS NOTHING AT ALL to do with however much bandwidth is on EAST. The router just decides how much bandwidth to use for EIGRP, and just splits that up between its neighbors. it really is that simple. the more neighbors it has, the less bandwidth used per neighbor.

Anyway, so, to test this, you can independently modify the bandwidth on HQ's interface, to 256, and note that its pacing time will adjust, but the pacing time on EAST will not adjust. Likewise, you can make bandwidth changes on EAST, and they will have no bearing on the pacing time of HQ.

That is to say, the bandwidth value is locally significant for EIGRP bandwidth consumption. Therefore, it is upon YOU as the network engineer, to be aware of this, and plan accordingly.

If you still disagree, I'm not sure why at this point, but my point is that a question about HQ R1 posed here , the answer had nothing to do with the EAST router. Of course, as an admin, YOU have to consider everything that's going on in the network, but it doesn't apply to this particular question. Even, I AGREE that you MUST consider the bandwidth of all your links, when making this type of decision, BUT ... for the router itself, it only knows what is going on locally.

source: Enhanced Interior Gateway Routing Protocol - Cisco Systems

Hope this helps.

fluk3d

Not to go off-topic what router IOS shows pacing time