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!
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!
"Imagination is more important than knowledge." - Albert Einstein
Comments
-
Monkerz Member Posts: 842By 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 Member Posts: 141 ■■■□□□□□□□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?"Imagination is more important than knowledge." - Albert Einstein
-
Monkerz Member Posts: 842You 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 Mod Posts: 11,962 ModOf course there is a way to prove it! Get a sniffer or maybe some NBAR running on the router and see whats coming out.An expert is a man who has made all the mistakes which can be made.
-
fluk3d Member Posts: 141 ■■■□□□□□□□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."Imagination is more important than knowledge." - Albert Einstein
-
MrBrian Member Posts: 520Been 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.Currently reading: Internet Routing Architectures by Halabi -
xXErebuS Member Posts: 230I 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 Member Posts: 141 ■■■□□□□□□□Thanks guy that makes some sense now.. finishing up eigrp this week and then onto OSPF"Imagination is more important than knowledge." - Albert Einstein
-
instant000 Member Posts: 1,745I'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.Currently Working: CCIE R&S
LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!) -
xXErebuS Member Posts: 230instant000 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 Member Posts: 141 ■■■□□□□□□□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.."Imagination is more important than knowledge." - Albert Einstein -
instant000 Member Posts: 1,745I 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.Currently Working: CCIE R&S
LinkedIn: http://www.linkedin.com/in/lewislampkin (Please connect: Just say you're from TechExams.Net!) -
fluk3d Member Posts: 141 ■■■□□□□□□□Not to go off-topic what router IOS shows pacing time"Imagination is more important than knowledge." - Albert Einstein