Scenario:
A large international ISP has hired you as one of their network engineers. The ISP still has a fairly large customer that is using an older frame-relay network. All of your colleagues are too busy working with MPLS and you are the only one who is capable of fixing frame-relay problems. The network is experiencing congestion especially when router Paris is sending traffic to router New York. Can you fix this network?
Goal:
- All IP addresses have been preconfigured for you as specified in the topology picture.
- Every router has a loopback0 interface:
Tilburg: 1.1.1.1 /24
NewDelhi: 2.2.2.2 /24
Berlin: 3.3.3.3 /24
Paris: 4.4.4.4 /24
NewYork: 5.5.5.5 /24 - You are not allowed to make any changes to the frame-relay configurations.
- The ISP has configured the following CIR for each PVC:
NewDelhi: 128kbps
Berlin: 128kbps
Paris: 256kbps
NewYork: 64kbps - Configure EIGRP AS 1 on all routers and make sure you have full connectivity.
- Configure your network so the bandwidth reflects the CIR on the PVCs and there are no congestion problems with EIGRP.
It took me 1000s of hours reading books and doing labs, making mistakes over and over again until I mastered all the routing protocols for CCNP.
Would you like to be a master of routing too? In a short time without having to read 900 page books or google the answers to your questions and browsing through forums?
I collected all my knowledge and created a single ebook for you that has everything you need to know to become a master of routing.
You will learn all the secrets about EIGRP, frame-relay and making EIGRP work on frame-relay networks.
Does this sound interesting to you? Take a look here and let me show you how to Master CCNP ROUTE
IOS:
c3640-jk9s-mz.124-16.bin
Topology:
Configuration Files
You need to register to download the GNS3 topology file. (Registration is free!)Once you are logged in you will find the configuration files right here.
The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.
Written by René Molenaar - CCIE #41726
Hi, could any one please tell me how to allocate bandwidth percents to point to multipoint connections and point-to-point to connections? Is there any specific method other than allocating them by ip bandwidth-percent cmd?
This lab confuses me because the ip addresses are configured under the physical interface. There are no multi-point interfaces configured. And the lab says not to change the framerelay configurations don’t we need “frame-relay map” commands to reach full connectivity?
Hello James,
Good question. The whole EIGRP “bandwidth” pacing for frame-relay is an annoying topic if you ask me.
Everything is configured on the physical interface so the question is…what type of interface is the physical one? Is it point-to-point or multipoint?
The answer is that the physical interface is always a multipoint interface to frame-relay. You don’t need frame-relay mappings because Inverse ARP will take care of that. You only need to do mappings yourself when you use sub-interfaces because the router doesn’t know which DLCI belongs to which (sub)interface.
Does that make sense? Let me know if you have any more questions.
Rene
thanks good answer
Rene,
Router Tilburg learned all Loopback networks:
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 192.168.1.2, 00:18:52, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 00:17:29, Serial0/0
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/2297856] via 192.168.1.4, 00:00:51, Serial0/0
5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/2297856] via 192.168.1.5, 00:00:12, Serial0/0
All other routers only learned 1.1.1.0 loopback network from router Tilburg.
How can I get full connectivity on all the routers?
Thank you.
In order to get full connectivity I had to use ‘no ip split-horizon eigrp’ command under s0/0 interface, although split-horizon is disabled by default on physical interface:
Berlin#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/2297856] via 192.168.1.1, 00:10:04, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 192.168.1.1, 00:08:25, Serial0/0
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/2809856] via 192.168.1.1, 00:08:25, Serial0/0
5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/2809856] via 192.168.1.1, 00:08:25, Serial0/0
Hi Dmitri,
Good that you found the solution. EIGRP is disabled by default on the physical interface, it will be enabled on sub-interfaces.
Not sure why i had split horizon enabled on the physical interface 😀
Rene
Rene,
For the last question all I had to do is to set bandwidth to 256kbps on Tilburg and 64kbps on all other routers. Am I right?
Thank you.
Hi Dmitri,
That’s correct. If you configure bandwidth on the physical interface it will be divided by the number of PVCs.
Rene
Rene, Is there anything special or any analogy to help you remember the bandwidth calculations for the different frame relay situations other than Brute Memorization?
@Thomas
I don’t have an analogy to remember these for EIGRP & Frame-relay. I do have some for OSPF and frame-relay. I always forget about EIGRP frame-relay so i have to look it up ;D
Hey Rene’,
last part of the question:
Configure your network so the bandwidth reflects the CIR on the PVCs and there are no congestion problems with EIGRP.
Why do we use 256 kb on Tilburg, based on what info that was given? Did you say that if you config the 256, it automatically splits it evenly and the other spokes dont need BW config? Note, split horizon was disabled on the physical interface, but had to use
Tilburg(config-router)# no ip split horizon eigrp 1 command
Thats specific for the eigrp updates correct?
Thanks, until next time:)
Joe
Hi Joe,
There’s a single interface on router Tilburg (multipoint) and we have multiple PVCs with different CIR rates. If you configure multipoint interfaces EIGRP will divide the bandwidth / number of PVCs that you have. In this case the lowest CIR is 64kbps so we can set the bandwidth at 256kbps. 256 / 4 = 64kbps. We need to use the lowest CIR rate to be safe or router NewYork could be overburdened if it were any higher.
The "no ip split horizon" command is specific for EIGRP but I *think* split horizon is disabled by default on the frame-relay physical interface. It’s something to be aware of when you use a sub-interface though.
I think I’ll record the video for this one next week.
Rene
Thanks, that makes sense now.
Hi Rene,
Please post final configs for this LAB.
Thanks
Sudheer
I’m still unclear on whether we need to change bandwidth on the spokes, if we make the hub 256? I understand the default is T1, but if the hub splits its bwidth equally, it seems we could leave the spokes alone.
Or is it a best practices deal, whereby you *could* leave them alone but it’s best to go ahead and change them?
thanks!
bj
Hi Rene
Hope I can ask a couple of questions about this please. Frame-Relay is always something I have struggled to grasp!
First..
If Tilbury is set to 256 meaning that the bandwidth is 64 per PVC does the bandwidth on all spoke routers also need to be set to 64 or can the bandwidth be set to match the CIR?
Secondly..
I’m presuming that to get full connectivity that additional ‘frame-relay map ip’ commands need to be added to the spoke routers using the same PVC?
I’ve tried this but the ping fails 🙁
I can see all routes on all routers however.
Thirdly..
Fantastic site..your hard work is very appreciated
[b]Ant[/b]
Hi Antbraker,
I agree with you, the inverse ARP works for spokes-hub connections. Even if you will disable inverse-arp on spoke it will still receive INARP information from Tilburg.
However for spoke-spoke conenctions there have to be static maps configured.
I know this is extremely late to the party but……..
It is unnecessary in this lab for static maps from each spoke to spoke router. If you can see the routes, but the pings are failing, just do an extended ping and specify the source address as the loopback0 interface. If not, the router defaults to IP of the outwards facing interface, in this case the serial interface IP.
I’m inclined to think that the spokes need to be set for 64kbs otherwise they will generate an amount of multicast traffic that fits with the 50% of their current local bandwidth metric. Since the information in the bandwidth command does not explicitly pass from one router to the next, I don’t think the spokes have any way of knowing that they need to lower their traffic volume.
I guess what it comes down to is whether or not the bandwidth and percentage modifies locally sourced eigrp traffic or all traffic passing through the hub in an frame relay network.
Hi Kory315 you can adjust the bandwidthn eigrp uses with the command, ip bandwidth-percent eigrp 1 25.
Where 1 is the EIGRP AS number and 25 is the percentage that eigrp is going to use of the total interface bandwidth.
I believe you are correct. Setting the bandwidth on one router is only locally significant. The other routers will continue to use 50% of the bandwidth available from their default CIR’s. This is no good. I believe you need to statically set each spoke router’s bandwidth to use 64kbps, otherwise you could configure the bandwidth percent that eigrp uses for each of the routers (of course taking into account that each CIR is different, so the percentages will change; far easier to just set bandwidth in my opinion).
Hi Rene,
Any idea when the video solution for this lab will be available ?
according to what cisco says there are 3 rules
1) The traffic that EIGRP is allowed to send on a single virtual circuit (VC) cannot exceed the capacity of that VC.
2) The total EIGRP traffic for all virtual circuits cannot exceed the access line speed of the interface.
3) The bandwidth allowed for EIGRP on each virtual circuit must be the same in each direction.
so from the third rule by adjusting the int s0/0 BW on hub to 256 we must also adjust each spoke to have BW 64 kbps
Rene:
wouldn’t it be more precise to have a value for the PVC on hub router?
that way we could also be more free on setting BW and EIGRP percentage on each spoke separately
Rene Molenaar
As you put scenrio all spoke are have different CIR so why u put 64 at all interfaces of spoke even if you use same CIR value as u mention in Scenario it will work i did it pls validate how much is it right……………………….pls find my solution link and check config and let me know………….
http://www.mediafire.com/?vqxx7r2hxj7cqha
Hi everyone,
I can’t ping serial interfaces from spoke to spoke but I can ping loopbak to loopback. Routing tables in all routers are full i.e I can see all loopback networks and 192.168.1.x network. Shouldn’t I be able to ping serial interfaces too?
i am looking for the sol. of this goal.
please provide the video solution
Hello! There is alternative solution. I think, this solution more correctly.
1. Set bandwith on serial 0/0 of Tilburg router equal amount all PVC’s CIR. In this case bandwith is equal 576 kbit.
2. Set bandwith-percent equal 22% on serial 0/0 of Tilburg router.
As the result, max EIGRP’s bandwith is equal:
(576/4)*0.22 = 32 kbit.
In this solution, we are getting a more correct value of bandwith and value of EIGRP metric for the multipoint interface.
Hi
I disabled EIGRP split. See the routes in the spoke routers but still cannot ping
I have route to each networks in my spokes router but i can’t communicate with other except when i ping 1.1.1.1 or it’s own loop back ip address. Do i have to configure seperate pvc for spokes to communicate with eacthother ?
Hi all
I made some solution for future reference..people can refer
Tilburg#show run
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Serial0/0
bandwidth 256
ip address 192.168.1.1 255.255.255.0
ip bandwidth-percent eigrp 1 20
ip hello-interval eigrp 1 5
ip hold-time eigrp 1 15
encapsulation frame-relay
no ip split-horizon eigrp 1
serial restart-delay 0
no fair-queue
frame-relay traffic-shaping
frame-relay interface-dlci 102
class NewDelhi
frame-relay interface-dlci 103
class Berlin
frame-relay interface-dlci 104
class Paris
frame-relay interface-dlci 105
class NewYork
!
router eigrp 1
network 1.0.0.0
network 192.168.1.0
no auto-summary
!
map-class frame-relay NewDelhi
frame-relay cir 128000
frame-relay bc 16000
frame-relay be 64000
!
map-class frame-relay Berlin
frame-relay cir 128000
frame-relay bc 16000
frame-relay be 64000
!
map-class frame-relay Paris
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 128000
!
map-class frame-relay NewYork
frame-relay cir 64000
frame-relay bc 8000
frame-relay be 32000
access-list 100 deny eigrp any any
access-list 101 permit ip any any
!
NEW Delhi
!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface Serial0/0
bandwidth 128
ip address 192.168.1.2 255.255.255.0
ip bandwidth-percent eigrp 1 20
ip hello-interval eigrp 1 5
ip hold-time eigrp 1 15
encapsulation frame-relay
no ip split-horizon eigrp 1
serial restart-delay 0
frame-relay interface-dlci 201
class NewDelhi
!
router eigrp 1
network 2.0.0.0
network 192.168.1.0
no auto-summary
!
map-class frame-relay NewDelhi
frame-relay cir 128000
frame-relay bc 16000
frame-relay be 64000
!
NEWYORK
!
interface Loopback0
ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
bandwidth 64
ip address 192.168.1.5 255.255.255.0
ip bandwidth-percent eigrp 1 20
ip hello-interval eigrp 1 5
ip hold-time eigrp 1 15
encapsulation frame-relay
no ip split-horizon eigrp 1
serial restart-delay 0
frame-relay interface-dlci 501
class NewYork
!
!
router eigrp 1
network 5.0.0.0
network 192.168.1.0
no auto-summary
!
map-class frame-relay NewYork
frame-relay cir 64000
frame-relay bc 8000
frame-relay be 32000
!
!
BERLIN
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
interface Serial0/0
bandwidth 128
ip address 192.168.1.3 255.255.255.0
ip bandwidth-percent eigrp 1 20
ip hello-interval eigrp 1 5
ip hold-time eigrp 1 15
encapsulation frame-relay
no ip split-horizon eigrp 1
serial restart-delay 0
frame-relay interface-dlci 301
class Berlin
!
!
router eigrp 1
network 3.0.0.0
network 192.168.1.0
no auto-summary
!
ip http server
no ip http secure-server
!
!
!
!
map-class frame-relay Berlin
frame-relay cir 128000
frame-relay bc 16000
frame-relay be 64000
access-list 100 deny eigrp any any
access-list 100 permit ip any any
!
PARIS
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
interface Serial0/0
bandwidth 256
ip address 192.168.1.4 255.255.255.0
ip bandwidth-percent eigrp 1 20
ip hello-interval eigrp 1 5
ip hold-time eigrp 1 15
encapsulation frame-relay
no ip split-horizon eigrp 1
serial restart-delay 0
frame-relay interface-dlci 401
class Paris
!
!
router eigrp 1
network 4.0.0.0
network 192.168.1.0
no auto-summary
!
ip http server
no ip http secure-server
!
!
!
!
map-class frame-relay Paris
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 128000
!
Tilburg#show ip eigrp 1 neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
3 192.168.1.2 Se0/0 12 00:11:18 111 1422 0 4
2 192.168.1.3 Se0/0 10 00:11:23 824 4944 0 7
1 192.168.1.4 Se0/0 12 00:11:23 823 4938 0 7
0 192.168.1.5 Se0/0 14 00:11:23 56 1422 0 6
Tilburg#show ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/10639872] via 192.168.1.2, 00:11:29, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/10639872] via 192.168.1.3, 00:11:30, Serial0/0
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/10639872] via 192.168.1.4, 00:11:30, Serial0/0
5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/10639872] via 192.168.1.5, 00:11:30, Serial0/0
C 192.168.1.0/24 is directly connected, Serial0/0
Tilburg#
Paris#show ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/10639872] via 192.168.1.1, 00:11:50, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/11151872] via 192.168.1.1, 00:11:45, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/11151872] via 192.168.1.1, 00:11:49, Serial0/0
4.0.0.0/24 is subnetted, 1 subnets
C 4.4.4.0 is directly connected, Loopback0
5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/11151872] via 192.168.1.1, 00:11:50, Serial0/0
C 192.168.1.0/24 is directly connected, Serial0/0
Paris#
Paris#
Paris#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/34/60 ms
Be great to finally have the video posted for this one. 🙂
hay guys, should i configure Frame-Relay map ip in each router as the following to to able to test by ping ?
Tilburg:
frame-relay map ip 192.168.1.2 102 broadcast
frame-relay map ip 192.168.1.3 103 broadcast
frame-relay map ip 192.168.1.4 104 broadcast
frame-relay map ip 192.168.1.5 105 broadcast
New Delhi:
frame-relay map ip 192.168.1.1 201 broadcast
frame-relay map ip 192.168.1.3 201 broadcast
frame-relay map ip 192.168.1.4 201 broadcast
frame-relay map ip 192.168.1.5 201 broadcast
Berlin:
frame-relay map ip 192.168.1.1 301 broadcast
frame-relay map ip 192.168.1.2 301 broadcast
frame-relay map ip 192.168.1.4 301 broadcast
frame-relay map ip 192.168.1.5 301 broadcast
Paris:
frame-relay map ip 192.168.1.1 401 broadcast
frame-relay map ip 192.168.1.2 401 broadcast
frame-relay map ip 192.168.1.3 401 broadcast
frame-relay map ip 192.168.1.5 401 broadcast
NewYork:
frame-relay map ip 192.168.1.1 501 broadcast
frame-relay map ip 192.168.1.2 501 broadcast
frame-relay map ip 192.168.1.3 501 broadcast
frame-relay map ip 192.168.1.4 501 broadcast
Just on the Tilberg is fine, rest of the spokes will inverse arp DLCI of Tilberg. I read in above notes that multipont interface should inverse arp (on Tilberg), however in my case, i have to manually put map commands.
TILBURG:
Current configuration : 313 bytes
!
interface Serial0/0.12345 multipoint
bandwidth 256000
ip address 192.168.1.1 255.255.255.0
no ip split-horizon eigrp 1
frame-relay map ip 192.168.1.2 102 broadcast
frame-relay map ip 192.168.1.3 103 broadcast
frame-relay map ip 192.168.1.4 104 broadcast
frame-relay map ip 192.168.1.5 105 broadcast
end
NEW DELHI:
Current configuration : 133 bytes
!
interface Serial0/1
bandwidth 64000
ip address 192.168.1.2 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
end
Router#show frame-relay map
Serial0/1 (up): ip 192.168.1.1 dlci 201(0xC9,0x3090), dynamic,
broadcast,, status defined, active
Router#show ip route ei
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/679936] via 192.168.1.1, 00:08:57, Serial0/1
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/1191936] via 192.168.1.1, 00:07:50, Serial0/1
4.0.0.0/24 is subnetted, 1 subnets
D 4.4.4.0 [90/1191936] via 192.168.1.1, 00:07:50, Serial0/1
5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/1191936] via 192.168.1.1, 00:07:50, Serial0/1
Hi Rene
Is there any chance we can get the video put up to clarify the lab? 😀
Hey guys,
I have two questions.
1. If you configure 256 BW on Tilburg S0/0 interface, won’t EIGRP use 50% of 256 for VCs. Implies Each PVC would use 32 Kbps instead of 64 Kbps.
2. Is it correct that we do not need to configure spoke as spoke and hub will negotiate bandwidths and use minimum bandwidth configured for VC?
Thanks.
Ugh….understanding how bandwidth works in eigrp multipoints is a headache.
I thought that I had understood through my studies that when you set a bandwidth on an interface, the IOS by default only uses 50% of the bandwidth you set. And THEN you look at how much that result is divided between your pvc’s.
Rene commented earlier that the solution was to set the bandwidth of Tilburg’s S0/0 interface to 256, and then it will divide 256 by your four pvcs, resulting in 64K for each spoke. But if what I learned is correct, wouldn’t you want to set your bandwidth to 512K, so the default 50% rule would bring you down to the 256K to divide out to your spokes?
And even then, you’re not following the lab instructions at the end: “Configure your network so the bandwidth reflects the CIR on the PVCs” New York would be the only router with bandwidth matching its CIR (64K). Normally, you could use the ip bandwidth-percent command on each pvc to get your other spokes closer to their CIR’s but since you’re not using multipoint subinterfaces on Tilburg, you can’t set it differently for each PVC, because you only have that one s0/0 interface to work with.
If any of what I said is incorrect, I REALLY REALLY need to know.
What Egor said ^ I believe to be correct.
We have 2 options.
First: We have to set a 64Kbps bandwidth on all routers to not overload the NY router.
Second: Create a full mesh multipoint between the router NewDelhi, Paris and Berlim. And after create a point-to-point on all router to link with NY. Of course it will be divided 64/3 = 21Kbps.
So the calculation to multi-point links is showed below:
NewDelhi = 128 – 21Kbps = 109Kbps
Berlim = 128 – 21Kbps = 109Kbps
Paris = 256 – 21Kbps = 235Kbps
Am i right?
Thank you a lot.