Packet Tracer CCNA Lab Tutorial: A Scenario with Frame Relay
We have come across a long path with our discussion about Cisco’s first and most popular exam, the CCNA. With this article, I am going to discuss “Frame Relay” in practical environment. Some people will argue why we should learn about Frame Relay technology, as we have upgraded our WAN links with ATM and later on with MPLS. As Frame Relay still exist in our today’s network and it is present in new version of CCNA exam, you have to learn and master this technology for your exam and professional perspective. In this article, I used a typical OSPF over Frame Relay problem which will cover all versions of CCNA materials (including new one CCNA-X), so make a cup of tea or coffee and spend some time with me to configure and test your skills!
If you check the frame relay scenario in packet tracer, you will find that we have two Virtual Circuits available. One is between Router 1 and Router 2, and the other is between Router 2 and Router 3. This is a typical deployment in “hub and spoke” scenario to minimize virtual circuit cost!
Tasks to perform:
1. Configure your WAN links with encapsulation frame-relay and with proper DLCIs
2. Map 10.1.1.1 (Router1) to 10.1.1.3 (Router3) with Broadcast keyword so that you can
Ping 10.1.1.3 from Router1 or can ping 10.1.1.1 from Router3
3. Configure OSPF for full connectivity between all hosts connected to Routers (you may face Non-Broadcast N/W Type issue so config ospf broadcast n/w type or you need to config Manual Neighbor-ship)
No need to config Frame Relay Cloud & All IP address on hosts and Routers are preconfigured
Use only 2 DLCIs: Router 1 to Router 2, and Router 2 to Router 3; and use OSPF only to complete full connectivity.
Key to the problem is “Non-Broadcast Network Type”. We must “disable” it on Routers Frame Relay interface “ip ospf network broadcast” or manual neighborship using “neighbor 10.1.1.X” under OSPF process
The access to Frame Relay configuration is not difficult at all for you. All you have to do is to change serial encapsulation to “frame-relay”. Here is the sample configuration for Router 1:
ip address 10.1.1.1 255.255.255.248
After you configure all three interfaces on three routers, please wait a moment! Cisco IOS’s Inverse ARP feature would automatically setup the correct IP addresses mapping to DLCIs. We can examine this on Router 2:
R2#show frame-relay map
Serial0/0/0 (up): ip 10.1.1.1 dlci 201, dynamic, broadcast, CISCO, status defined, active
Serial0/0/0 (up): ip 10.1.1.3 dlci 203, dynamic, broadcast, CISCO, status defined, active
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/50/60 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/54/91 ms
The frame relay access portion is actually done! Now we look closer at the OSPF problem.
After we start OSPF on all routers with default setting, we will immediately see a serious problem: Router 1 does not receive Router 3′s OSPF routes, and vice versa.
The problem is “Non-Broadcast OSPF Network Type”. We must “disable” it on Routers Frame Relay interface Using “ip ospf network broadcast” Command or manual neighborship using “neighbor 10.1.1.X” under OSPF process.
After applying this you will realize that you have full mesh connectivity over all devices.
Once you have completed the entire task, you can try the same scenario with EIGRP for better understanding.
After we start EIGRP on all routers with default setting, we will immediately see a serious problem: Router 1 does not receive Router 3′s EIGRP routes, and vice versa.
If you investigate, then you will understand that the problem lies with Router2. We have only two virtual circuits available in this case. Therefore, only Router 2 will receive Router 3′s EIGRP updates. Router 1 will never receive them unless Router 2 re-sends those EIGRP updates for Router 1.
Recall the default behaviour of “split horizon”: both Router 1 and Router 3 are addressed in the same subnet, so any EIGRP updates received in Router 2′s Serial0/0/0 interface connecting to this subnet will not be re-sent out through the same interface Serial0/0/0 by Router 2!
That is why Router 1 will not receive Router 3′s updates, because Router 2 won’t re-send them!
To eliminate this problem, we have to disable the “split horizon” function on Router 2′s Serial0/0/0, like this:
ip address 10.1.1.2 255.255.255.0
no ip split-horizon eigrp 10 /* not supported by packet tracer but supported with GNS
Then EIGRP goes well with such Frame Relay deployment and addressing!
A solution file is also attached to help you. Now put your fingers on your keyboard and write about the challenges you faced during implementation, and also give me your valuable suggestion/Feedback. Thanks for your time and consideration, see you soon.
Latest posts by Afazuddin Ahamed (see all)
- Internet of Things (IoT)—How an ICT Engineer Can Change the Community - November 24, 2014
- Smart Building Technology- How ICT Engineers Can Change the Community - October 31, 2014
- CCNA Prep: Introduction to WAN - November 27, 2013