Packet Tracer - Frame Relay

I'm trying to set up the example in PT using the examples in the Odom ICND2 book, in Chapter 14: Fully Mesh Network with One IP Subnet.

I had a couple of questions.

1) This book doesn't show how to create the telco's portion of the switch, so does it matter which WAN Emulation I use? Cloud-PT or Cloud-PT-Empty?

I'm not sure really what the difference other than some modules being populated.

2) How would I setup the clouds configuration?

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

notgoing2fail

How are you going to emulate the frame relay switch?

Do you have a router with some serial interfaces? You can use a router for it....

mikej412

notgoing2fail wrote: »

How are you going to emulate the frame relay switch?

Do you have a router with some serial interfaces? You can use a router for it....

Packet Tracer doesn't let you configure a router to act as a frame relay switch like you can with Dynamips (or real hardware).

It looks like the Cloud-PT has some serial interfaces that you can configure for frame relay. The Cloud-PT-Empty has other options like cable & dsl -- and lots of empty slots that you'd have to fill if you wanted to configure frame relay in that cloud.

Click on the cloud, add or change interfaces if you need more, and go to the config tab, select frame relay, then assign the DLCIs to the serial port pairs.

fieldmonkey

mikej412 wrote: »

Click on the cloud, add or change interfaces if you need more, and go to the config tab, select frame relay, then assign the DLCIs to the serial port pairs.

Yup... thought I would play through trial / error, so I added the Cloud-PT since it had (4) NM-1S. Gave it a shot and plugged the DLCIs into the Cloud and now appears to be working, but I cannot ping the subnets IPs ... I'm in an up/up state on all three interfaces. EIGRP hasn't learned any routes yet thought, and the sh ip route only list C routes...

So now I am trying to figure out why EIGRP isn't learning any routes.

Questions though

1) I thought I was suppose to configure the DLCIs on the routers interfaces like on Mayberry, Mount Pilot and Raleigh?

2) When you mention "pairs", am I correct when I assume you mean the connection from the DTE to DCE?

notgoing2fail

fieldmonkey wrote: »

Yup... thought I would play through trial / error, so I added the Cloud-PT since it had (4) NM-1S. Gave it a shot and plugged the DLCIs into the Cloud and now appears to be working, but I cannot ping the subnets IPs ... I'm in an up/up state on all three interfaces. EIGRP hasn't learned any routes yet thought, and the sh ip route only list C routes...

So now I am trying to figure out why EIGRP isn't learning any routes.

Questions though

1) I thought I was suppose to configure the DLCIs on the routers interfaces like on Mayberry, Mount Pilot and Raleigh?

2) When you mention "pairs", am I correct when I assume you mean the connection from the DTE to DCE?

My bad, I misread your title. So you are using PT. I'm not familiar with that.

As for your question, hmm.....

Well, from what I read, the DLCI's are configured automatically using the Inverse ARP? Or something like that? But if you do it manually you would use the frame-relay map ip command.

frame-relay map ip <destination ip> <DLCI number> broadcast

I think the DLCI number is suppose to be the local DLCI?

fieldmonkey

Yes, I think your statements are correct, but I have configured the frame relay with all defaults to avoid confusing myself. However it confused me that I would add the DLCIs onto the Cloud that I created, which in real would be the telco.

My problem now is the configuration isn't learning any routes and I cannot ping Mayberry, Raleigh or Mount Pilot and EIGRP isn't learning routes.

mikej412

Full mesh or Hub & Spoke?

Inverse ARP or manual layer 3 to layer 2 address resolution with the frame-relay map commands?

Multipoint interfaces or Point-to-Point?

Are your frame relay PVCs active on your routers?
What about your frame relay maps?
(use your show frame-relay commands)

Can you ping across your frame relay cloud?

Can you see your EIGRP neighbors across the frame relay cloud?

Do you have other routers or loopback interfaces that you are in EIGRP that should be going across the frame relay cloud?

notgoing2fail

I'd be interested in how you figure this out. Configuring the FR switch side is obviously out of the scope of the CCNA but I'd like to know how you'll end up getting your DTE's to communicate.

It's tough because we don't know and can't tell if the FR switche (which is really your router) is configured properly from the start...

Do you have the encapsulation correct on the FR switch? Do you have the clock rate set?

fieldmonkey

mikej412 wrote: »

Full mesh or Hub & Spoke?

I attempting to do a Full mesh thru the cloud.

Are your frame relay PVCs active on your routers?
What about your frame relay maps?
(use your show frame-relay commands)

If I configure the setting below to match a particular router I can get some data back from these commands.

Can you ping across your frame relay cloud?

Only in one direction, depending on which router is proper configured according to the diagram below.

Can you see your EIGRP neighbors across the frame relay cloud?

only the router configured correctly shows the neighbor I can ping.

Do you have other routers or loopback interfaces that you are in EIGRP that should be going across the frame relay cloud?

Mike,

It has something to do with the screenshot below. I can only configure ONE LINK. Something is not acceptable to configure any additional links, I'm beginning to assume I need to configure some subinterfaces on each of the routers (Mayberry, Mount Pilot & Raleigh or MMR). I guess that is my next step?

Frame Relay is the toughest subject for me by far at this point!

attachment.php?attachmentid=370&stc=1&d=1269749791

attachment.php?attachmentid=370&stc=1&d=1269749791

fr7.jpg

fieldmonkey

So currently I can ping Mount Pilot from Mayberry, and the only neighbor EIGRP shows is Mount Pilot and Mayberry.

If I use the clouds config page shown, that info moves with the configuration change. So I am beginning to think I only actually have 1 VC active in this attempt at a Full Mesh using one subnet.

That being said, I think I need to look into how to configure my subinterfaces on the MMR routers? Is that right?

mikej412

notgoing2fail wrote: »

It's tough because we don't know and can't tell if the FR switche (which is really your router) is configured properly from the start...

It's packet tracer -- you "configure" the cloud.

Dynamips also has a "simple" frame relay cloud you can configure in the .NET file defining the VC connections -- or it lets you configure a router as a frame relay switch.

If the PT Cloud has four serial interfaces, Serial0, Serial1, Serial2, and Serial3 and you want to configure 3 routers -- it's easier to skip Serial0 and just
hook R1 to Serial1
hook R2 to Serial2
hook R3 to Serial3

Then configure the DLCIs for the Serial Interfaces
Serial1 DLCI:102 name:R1 to R2
Serial1 DLCI:103 name:R1 to R3
Serial2 DLCI:201 name:R2 to R1
Serial2 DLCI:203 name:R2 to R3
Serial3 DLCI:301 name:R3 to R1
Serial3 DLCI:302 name:R3 to R2

Then configure Frame relay for the Cloud using the drop downs & Add button
Serial1 -- R1 to R2 -- Serial2 -- R2 to R1
Serial1 -- R1 to R3 -- Serial3 -- R3 to R1
Serial2 -- R2 to R3 -- Serial3 -- R3 to R2

While the DLCIs can be any valid available DLCI number -- you should notice the usual pattern that gets used in labs (at least to start).
R1 uses 102 to talk to R2
R1 uses 103 to talk to R3
R2 uses 201 to talk to R1
R2 uses 203 to talk to R3
R3 uses 301 to talk to R1
R3 uses 302 to talk to R2

This is a full mesh configuration where each router can talk to the other routers.

==============

To do a hub and spoke configuration, you could disable Inverse Arp and not configure R2/R3 to use the 203/302 DLCIs.

Or you can just configure the DLCIs in the cloud for a hub and spoke configuration (with R1 as the Hub).

For a hub & spoke configuration with R1 as the Hub, configure the PT Cloud Serial Interfaces:
Serial1 DLCI:102 name:R1 to R2
Serial1 DLCI:103 name:R1 to R3
Serial2 DLCI:201 name:R2 to R1
Serial3 DLCI:301 name:R3 to R1

Then configure Frame relay for the Cloud using the drop downs & Add button
Serial1 -- R1 to R2 -- Serial2 -- R2 to R1
Serial1 -- R1 to R3 -- Serial3 -- R3 to R1

Once you figure out the "easy standard lab frame relay configuration" then you'd be ready to deal with a config where the routers are hooked up to random serial ports and the DLCIs are just random available DLCIs.

fieldmonkey

I take it I am seeing PT's limitations at this point. Do GSN and / or Dynamips basically have the same limitations.

mikej412

You need more configured on that Frame Relay screen....

So PT Full Mesh...
Cloud Serial 0 <--> MountPilot
Cloud Serial 1 <--> Raleigh
Cloud Serial 2 <--> Mayberry

Since you didn't mention DLCIs, I'll keep my "simple ones" and just shift the serial ports down

Serial0 DLCI:102 name:MountPilot2Raleigh
Serial0 DLCI:103 name:MountPilot2Mayberry
Serial1 DLCI:201 name:Raleigh2MountPilot
Serial1 DLCI:203 name:Raleigh2Mayberry
Serial2 DLCI:301 name:Mayberry2MountPilot
Serial2 DLCI:302 name:Mayberry2Raleigh

Cloud Frame Configuration:
Serial0 -- MountPilot2Raleigh -- Serial1 -- Raleigh2MountPilot
Serial0 -- MountPilot2Mayberry -- Serial2 -- Mayberry2MountPilot
Serial1 -- Raleigh2Mayberry -- Serial2 -- Mayberry2Raleigh

============

But you can simplify it like you have, where the name is just the destination it connects to -- as long as you remember to select the correct serial ports that corresponds to the source.
Serial0 DLCI:102 name:Raleigh
Serial0 DLCI:103 name:Mayberry
Serial1 DLCI:201 name:MountPilot
Serial1 DLCI:203 name:Mayberry
Serial2 DLCI:301 name:MountPilot
Serial2 DLCI:302 name:Raleigh

Cloud Frame Configuration:
Serial0 -- Raleigh -- Serial1 -- MountPilot
Serial0 -- Mayberry -- Serial2 -- MountPilot
Serial1 -- Mayberry -- Serial2 -- Raleigh

============

I closed PT, so this is just a notepad copy & paste & hack. Beware of typos and backwards interfaces

mikej412

fieldmonkey wrote: »

I take it I am seeing PT's limitations at this point. Do GSN and / or Dynamips basically have the same limitations.

PT can do this -- it's just annoying since you need to learn how to work the software.

If you had configured a real router before as a frame relay switch, then PT isn't that bad. But any skill you acquire configuring the PT frame relay cloud may not transfer to real hardware.

The FAKE frame relay switch in the NET file for Dynamips/Dynagen (and the 3 routers) looks like this:

# A Simple frame relay lab

autostart = false

[localhost]

7200
image = C:\Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image
npe = npe-400
ram = 160

ROUTER R1
s1/0 = F1 1

ROUTER R2
s1/0 = F1 2

ROUTER R3
s1/0 = F1 3

FRSW F1
1:102 = 2:201
1:103 = 3:301
2:203 = 3:302

The Dynagen config for a frame relay switch is the FRSW section named F1

You can **** the FAKE Dynagen frame relay switch and add another router into the NET file with serial ports, configure the proper connections, and then configure that router to act as the frame relay switch via IOS configuration (which is a useful CCIE skill).

fieldmonkey

mikej412 wrote: »

You need more configured on that Frame Relay screen....

So PT Full Mesh...
Cloud Serial 0 <--> MountPilot
Cloud Serial 1 <--> Raleigh
Cloud Serial 2 <--> Mayberry

Since you didn't mention DLCIs, I'll keep my "simple ones" and just shift the serial ports down

Serial0 DLCI:102 name:MountPilot2Raleigh
Serial0 DLCI:103 name:MountPilot2Mayberry
Serial1 DLCI:201 name:Raleigh2MountPilot
Serial1 DLCI:203 name:Raleigh2Mayberry
Serial2 DLCI:301 name:Mayberry2MountPilot
Serial2 DLCI:302 name:Mayberry2Raleigh

Cloud Frame Configuration:
Serial0 -- MountPilot2Raleigh -- Serial1 -- Raleigh2MountPilot
Serial0 -- MountPilot2Mayberry -- Serial2 -- Mayberry2MountPilot
Serial1 -- Raleigh2Mayberry -- Serial2 -- Mayberry2Raleigh

============

Ok, I have completed the clouds configuration above and I can ping everyone from everyone. Thanks so much!

Current Network Diagram: Frame Relay Configuration: Full Mesh with One IP Subnet

attachment.php?attachmentid=371&stc=1&d=1269800510

attachment.php?attachmentid=371&stc=1&d=1269800510

I do have few questions to help me better understand this and apply it to the "real world".

1) If one is administering a cisco network with frame-relay, all the configuration in the cloud is done by the telco/vendor, is that correct? The reason I ask, is that ...

In the Odom reference it states that:

"Figure 14-1 does not even bother listing the DLCIs used for the VCs. The configurations work as stated, and frankly, if you never knew the DLCIs, this network would work!"

So the configuration above is basically mapping the DLCIs "in the Cloud", which the telco would do first. After that assuming all the defaults for frame relay, one would enter the commands below on each router and s/he would be able to ping across the cloud?

Also after the configuration is entered below Inverse ARP would then take over and indentify the VCs via LMI messages?

Is that right?

int s0/0/0
encapsulation frame-relay
ip address x.x.x.x x.x.x.x

router eigrp 1
network x.x.x.x
network x.x.x.x

2) I am not certain why, probably something simple I'm not seeing, but when I issue the sh ip eigrp neighbors command on each router, each router is a neighbor of the other. However when I issue the sh ip route command it returns only "C routes". So why isn't it learning about the other routes via the cloud?

hexem

DLCI's are given to you by provider and you can map them manually or let inverse arp do the job, of course there's a delay in using inverse up (up to a minute) so people prefer to do things manually.

As for you're routing issue, split horizon rule (route's are never sent back out on the interface they were learned on)

best way around it is to use point-to-point subinterfaces.

fieldmonkey

hexem wrote: »

As for you're routing issue, split horizon rule (route's are never sent back out on the interface they were learned on)

I don't understand how this can be correct. I am using EIGRP, which is a link-state routing protocol. I believe split horizon is only associated with distance vector protocols only?

hexem

eigrp is an 'advanced dynamic distance vector' or hybrid...

EIGRP Frequently Asked Questions [IP Routing] - Cisco Systems

Q. Why are routes received from one neighbor on a point-to-multipoint interface that runs EIGRP not propagated to another neighbor on the same point-to-multipoint interface?

A. The split horizon rule prohibits a router from advertising a route through an interface that the router itself uses to reach the destination. In order to disable the split horizon behavior, use the no ip split-horizon eigrp as-number interface command. Some important points to remember about EIGRP split horizon are:

* Split horizon behavior is turned on by default.
* When you change the EIGRP split horizon setting on an interface, it resets all adjacencies with EIGRP neighbors reachable over that interface.
* Split horizon should only be disabled on a hub site in a hub-and-spoke network.
* Disabling split horizon on the spokes radically increases EIGRP memory consumption on the hub router, as well as the amount of traffic generated on the spoke routers.
* The EIGRP split horizon behavior is not controlled or influenced by the ip split-horizon command.

fieldmonkey

hexem--I forgot it's considered a hybrid!

Thanks! That makes sense now.

I still don't understand why I cannot ping the s0/0/0 interface on Mount Pilot from PC1, I can get to the fa0/0, but not on the otherside.

hexem

What router is PC1 connected to?

use tracert to find out where the packet's are dropping off at and check you're routes.

mikej412

fieldmonkey wrote: »

I do have few questions to help me better understand this and apply it to the "real world".

1) If one is administering a cisco network with frame-relay, all the configuration in the cloud is done by the telco/vendor, is that correct?

Yup. In the simplest case magic occurs and you have IP connectivity between all your routers.

But Inverse Arp only works for directly connected routers -- and since a full mesh can get expensive for a large number of locations, eventually you have to do some manual configuration to get spoke to spoke connectivity once you go to a hub & spoke configuration. And when you go with point-to-point configurations, you'll need to know which one of the available DLCIs to map to the interface -- since the Telco could configure a 100 PVCs between each of your locations (and bill you for the ones you use).

fieldmonkey wrote: »

2) I am not certain why, probably something simple I'm not seeing, but when I issue the sh ip eigrp neighbors command on each router, each router is a neighbor of the other. However when I issue the sh ip route command it returns only "C routes". So why isn't it learning about the other routes via the cloud?

The 3 routers are connected across the frame relay network. Do you have that network hanging off of the MountPilot Ethernet network advertised into EIGRP?

What's your routing table look like on MountPilot? Do you see the frame relay network as connected and the Ethernet segment as connected?

Can the PC ping the MountPilot Ethernet address?
Do you have the Mount Pilot Ethernet address configured as the default gateway on the PC?

Is the switch on MountPilot's Ethernet network setup with an administrative IP on that network segment? Can it ping both the MountPilot Ethernet interface IP address and the PC IP Address?

Are MountPilot's Ethernet interface and the PC's Ethernet interface plugged into enabled switch ports and configured for the same active VLANs (or the default VLAN 1)?

And then jumping ahead -- can Mayberry or Raleigh see that network hanging off of MountPilot's Ethernet segment?

fieldmonkey

Got it! Stupid typo on the IP address on the fa0/0 int!

Now I can ping across the cloud within the 1 subnet!

Also split horizon was not keepinp EIGRP from learning about the routes. I suppose the routes didn't exist actually because I didn't have anything connected to them and also one of them didn't have the no shut command entered on it.

Now I have the output I was looking for!

=============================================
Mayberry#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 199.1.1.3 Ser0/0/0 13 01:50:39 40 1000 0 9
1 199.1.1.2 Ser0/0/0 14 01:00:43 40 1000 0 12

Mayberry#sh ip route
!
Gateway of last resort is not set
C 199.1.1.0/24 is directly connected, Serial0/0/0
C 199.1.10.0/24 is directly connected, FastEthernet0/0
D 199.1.11.0/24 [90/2172416] via 199.1.1.2, 00:25:56, Serial0/0/0
D 199.1.12.0/24 [90/2172416] via 199.1.1.3, 00:03:52, Serial0/0/0
Mayberry#
==========================================

fieldmonkey

Ok... I have a birthday party to attend where adult beverages are being served... putting this chapter on hold and will return to do partial mesh!

mikej412

fieldmonkey wrote: »

I have a birthday party to attend where adult beverages are being served...

Oooooooooooh!! That's convenient. I still remember my first victory over frame relay -- and it is worthy of an adult beverage celebration

You'll have fun with split horizon (and some broadcast issues) when you hit the partial mesh hub & spoke scenarios. Work through them one at a time and use your show commands (and maybe a couple of debug commands).

fieldmonkey

Just adding a pic to complete the thread. Maybe it will provide a better understanding for others.

attachment.php?attachmentid=373&stc=1&d=1269822549

attachment.php?attachmentid=373&stc=1&d=1269822549

fr9.jpg

saravanaboobathy

Better try on GNS3 Simulator .... its also easy to use ...

The_master

mikej412 wrote: »

It's packet tracer -- you "configure" the cloud.

Dynamips also has a "simple" frame relay cloud you can configure in the .NET file defining the VC connections -- or it lets you configure a router as a frame relay switch.

If the PT Cloud has four serial interfaces, Serial0, Serial1, Serial2, and Serial3 and you want to configure 3 routers -- it's easier to skip Serial0 and just
hook R1 to Serial1
hook R2 to Serial2
hook R3 to Serial3

Then configure the DLCIs for the Serial Interfaces
Serial1 DLCI:102 name:R1 to R2
Serial1 DLCI:103 name:R1 to R3
Serial2 DLCI:201 name:R2 to R1
Serial2 DLCI:203 name:R2 to R3
Serial3 DLCI:301 name:R3 to R1
Serial3 DLCI:302 name:R3 to R2

Then configure Frame relay for the Cloud using the drop downs & Add button
Serial1 -- R1 to R2 -- Serial2 -- R2 to R1
Serial1 -- R1 to R3 -- Serial3 -- R3 to R1
Serial2 -- R2 to R3 -- Serial3 -- R3 to R2

While the DLCIs can be any valid available DLCI number -- you should notice the usual pattern that gets used in labs (at least to start).
R1 uses 102 to talk to R2
R1 uses 103 to talk to R3
R2 uses 201 to talk to R1
R2 uses 203 to talk to R3
R3 uses 301 to talk to R1
R3 uses 302 to talk to R2

This is a full mesh configuration where each router can talk to the other routers.

==============

To do a hub and spoke configuration, you could disable Inverse Arp and not configure R2/R3 to use the 203/302 DLCIs.

Or you can just configure the DLCIs in the cloud for a hub and spoke configuration (with R1 as the Hub).

For a hub & spoke configuration with R1 as the Hub, configure the PT Cloud Serial Interfaces:
Serial1 DLCI:102 name:R1 to R2
Serial1 DLCI:103 name:R1 to R3
Serial2 DLCI:201 name:R2 to R1
Serial3 DLCI:301 name:R3 to R1

Then configure Frame relay for the Cloud using the drop downs & Add button
Serial1 -- R1 to R2 -- Serial2 -- R2 to R1
Serial1 -- R1 to R3 -- Serial3 -- R3 to R1

Once you figure out the "easy standard lab frame relay configuration" then you'd be ready to deal with a config where the routers are hooked up to random serial ports and the DLCIs are just random available DLCIs.

I was trying to configure frame-relay through packet tracer (particularly the hub and spoke method ) and i was not able to do so, I searched on the internet and came across your thread and I have been able to configure the same through packet tracer. thank you so much for your help.

billyr

fieldmonkey wrote: »

I don't understand how this can be correct. I am using EIGRP, which is a link-state routing protocol. I believe split horizon is only associated with distance vector protocols only?

I know this was an old post, but just a quick point to make:

Split Horizon is actually disabled by default in Frame Relay on physical interfaces, however it is enable on sub-interfaces.

-DeXteR-

billyr wrote: »

I know this was an old post, but just a quick point to make:

Split Horizon is actually disabled by default in Frame Relay on physical interfaces, however it is enable on sub-interfaces.

Ok i have a doubt over here , the other day i was going through CBT videos and jeremy said multi-point is not preffered coz of split horizon and point-to-point is always the feasible one .

1. So if Split horizon is disabled by default in frame relay on physical interfaces then what else is the problemo with multi-point . It can be used just like point - point ?

2. Which is the more common type out their in REAL WORLD ?

-DeXteR-

*Bump*
Any replies guys!!

-DeXteR-

*Bump*
Guys either me asking stupid questions ? or it's just that frame-relay isn't any one's Favourite part