CCNA – Dynagen and Frame Relay Switch [[FRSW]]
Currently studying for the Cisco Certified Network Associate (CCNA) exam and working thru lab after lab to learn the material. Discovered the wonderful Dynamips/Dynagen site that allows you to emulate Cisco routers. But one problem: some of the labs have you emulate multiple routers. So the question becomes how you can link those routers together (the logical equivalent of running physical cables between the emulated routers). In the real world, these routers could be connected using serial cables via a Frame Relay Switch. Read on below for information on how I got this working in my lab!
The Dynagen Frame-Relay Switch (FRSW)
The Dynagen solution is to define a virtual “Frame Relay Switch” (FRSW) that can be used to connect the emulated Cisco routers within a Dynamips environment. However, although the excellent Dynamips/Dynagen tutorial discusses the FRSW it does so only from the view of the “.net” file read by Dynagen and used to construct an emulated network topology. However, that “.net” file – while critically important – is only half the story. The other half? The specific configuration commands necessary for the emulated Cisco router itself.
The Dynagen Frame-Relay Switch and a “.net” File
Let’s start with a simple .net file. I’ve named it Chap06 - FRSW as I’m using the CCNA Study Guide and Chapter 6 in that guide has quite a bit of information on configuring and connecting serial cables between Cisco routers. (Serial cables are commonly used to connect from a PC to a router for entering configuration commands; multiple routers would be connected via serial cables to permit “out-of-band” management of all of the routers from a single PC.) Let’s take a quick look at the initial setup:
Dynagen “.net” File for using a Frame-Relay Switch
# Chap06 - FRSW
[localhost:7200]
autostart = false
workingdir = C:\tools\dynamips\labs\Chap06 - FRSW
udp = 50200
# 3640 section
[[3640]]
image = C:\Program Files\Dynamips\images\c3640-ik9o3s-mz124-13.image
ram = 128
disk0 = 0
disk1 = 0
mmap = True
ghostios = True
sparsemem = True
#idlepc = 0x60290f00
# first router
[[ROUTER R1]]
model = 3640
console = 50201
# serial port connected to frame relay switch, DLCI 101
s0/0 = F1 1
# ethernet connectivity
slot1 = NM-1FE-TX
f1/0 = E1 1
[[ROUTER R2]]
model = 3640
console = 50202
# serial port connected to frame relay switch, DLCI 201
s0/0 = F1 2
[[FRSW F1]]
1:102 = 2:201
[[ETHSW E1]]
# example of connecting ethernet switch to VMNet2
1 = access 1 NIO_gen_eth:\Device\NPF_{CAD18D6C-599D-4E0E-BEA5-0C567E2B955A}
There is a lot going on with this file – almost all of it well covered by the standard Dynamips/Dynagen tutorial referenced above. For this article, let’s focus on just a couple of key issues that initially had me stumped:
- Router
R1needs to be connected to RouterR2. - Both
R1andR2are connected via a Dynagen Frame-Relay Switch (FRSW).
Now let’s take a look at the Router R2: it has a line s0/0 = F1 1 which needs to be interpreted. It means “serial port 0/0 is connected to a device named F1 which has an element named 1. For Router R2 we have a similar setting: s0/0 = F1 2 which is interpreted the same except that the device named F1 must have an element named 2.
So – what is this F1 device? It is defined below under the section labeled [[FRSW F1]]. And this section, while documented in the Dynamips/Dynagen tutorial, really threw me for a loop when I first saw it. First, the label [[FRSW F1]] simply tells Dynagen to create an emulated Frame-Relay Switch that is named F1. Plus, the actual understanding of the line 1:102 = 2:201 is not so hard. Let’s start with the 1:102, which is read as “identifier named 1 uses a Data-Link Connection Identifiers (DLCI – pronounced “del-see”) of 102“. The second part of this line is the = 2:201 which means “identifer named 1 is connected directly to the identifier named 2 – plus, identifier 2 has a DLCI of 201″.
But I Digress – Some Bits on DLCI
The DLCI code above is quite interesting. In many ways it most closely resembles a Layer 2 Machine Address Code (MAC) address in that it is used to create a “virtual circuit” (connection) between endpoints on a serial backbone. The DLCI code can be both locally-significant as well as globally-significant; the difference is the fact that although most serial connections show a simple device-to-device connection, in the real world that connection could be thousands of miles apart with numerous providers in between. For our purposes in this article, we’ll leave the DLCI as “locally-significant” only. For more information on DLCI, please see this blog on CCNA and DLCI which covers the material quickly and nicely as well as DLCI clarification entry which is where I got the Layer 2 analogy from.
Specifically back to this article: The significance of the DLCI numbers 102 and 201 is somewhat arbitrary; I used 102 to indicate that “DLCI number 1 is connecting to DLCI number 2” and 201 to indicate that “DLCI number 2 is connecting to DLCI number 1”. However, the numbers themselves are meaningful *only* insofar as they match to DLCI values configured within the emulated Cisco routers. And that leads to the next section!
Configuring an Emulated Cisco Router to use the Dynagen Frame-Relay Switch
However, although we can intuitively see that we are somehow connecting the Routers R1 and R2 together via this [[FRSW]] frame-relay switch, there is still more to do within the actual router configurations. In the Dynamips/Dynagen model, you first start the Dynamips hypervisor and then you run Dynagen against a “.net” file such as we have above. Then you start the emulated routers (R1 and R2 in this case) and configure them more-or-less as you would a physical “real” Cisco router. And that is where the second part of this article comes into play. Take a look at this actual router configuration for our running R1 router.
Emulated Router R1 Configuration
This configuration is abridged just to focus on the settings required for the frame-relay switch support:
hostname R1 ! interface Serial0/0 ip address 192.168.0.1 255.255.255.0 encapsulation frame-relay serial restart-delay 0 clock rate 2016000 frame-relay interface-dlci 102 !
This abridged configuration file can be looked at line by line:
hostname R1- Sets the router name to be
R1; included here just for completeness. interface Serial0/0- Begins the serial interface configuration section. There are four serial interfaces provided for a Dynagen emulated Cisco 3640 router. We are configuring the *first* interface with this line.
ip address 192.168.0.1 255.255.255.0- Assigns the Internet Protocol (IP) address
192.168.0.1to this interface. This is the IP address that is used by other routers to communicate over the serial link. encapsulation frame-relay- Required to enable frame-relay on the interface. See this Cisco blog article for more details.
serial restart-delay 0- The router resets the hardware each time the serial restart timer expires. This command is often used with the dial backup feature and with the pulse-time command, which sets the amount of time to wait before redialing when a DTR dialed device fails to connect. When the count value is set to the default of 0, the hardware is not reset when it goes down. In this way, if the interface is used to answer a call, it does not cause DTR to drop, which can cause a communications device to disconnect.
clock rate 2016000- This one is a little trickier and leads to discussions of
DCE(Data Communications Equipment) andDTE(Data Terminal Equipment) – none of which I want to go into here. Suffice it to say that, in the emulated Dynamips/Dynagen world, all emulated routers are DCE and provide clocking. Although that is not much of an explanation, please see this Cisco article on Serial Cable connections and let’s keep going here 🙂 frame-relay interface-dlci 102- This is the money shot here! Notice that we are associating DLCI code
102with this serial interface – and that this maps to the DLCI code specified on the emulated frame-relay switch.
Emulated Router R2 Configuration
Now let’s see the other emulated router so we can see how to connect the two routers together using the serial line, the frame-relay switch, and the appropriate DLCI code:
hostname R2 ! interface Serial0/0 ip address 192.168.0.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay interface-dlci 201 !
The above is almost the same as for router R1 so we will cover only the differences:
hostname R2- Sets the router name to be
R1; included here just for completeness. ip address 192.168.0.2 255.255.255.0- Assigns the IP address
192.168.0.2to this interface. RouterR1uses this IP address to communicate with RouterR2. frame-relay interface-dlci 201- As with Router
R1, this is the line that ensures proper frame-relay processing. The DLCI code must match the corresponding code from the Dynagen “.net” file (go back and look and you’ll see it).
One interesting point is what is *missing* from the above…note that Router R2 does no specify the clock rate 2016000 line. Beyond referencing you back to the whole DCE-vs.-DTE thing, let’s take it as read that Router R2 doesn’t need this (even in the “real” world of physical routers).
Does it All Work?
To answer that, let’s log into the Dynagen control panel and then each router to take a look at some status commands:
Dynagen Control Panel
Reading configuration file... *** Warning: Starting R1 with no idle-pc value *** Warning: Starting R2 with no idle-pc value Network successfully loaded Dynagen management console for Dynamips and Pemuwrapper 0.11.0 Copyright (c) 2005-2007 Greg Anuzelli, contributions Pavel Skovajsa => console R1 => console R2 => list /all Name Type State Server Console R1 3640 running localhost:7200 50201 R2 3640 running localhost:7200 50202 F1 FRSW always on localhost:7200 n/a E1 ETHSW always on localhost:7200 n/a
The above shows that both routers are running and that the frame-relay switch F1 is running. Disregard the Ethernet switch E1 as that is part of my network lab but is not germane to this article.
Router R1 Status
R1#show ip interface serial 0/0 Serial0/0 is up, line protocol is up Internet address is 192.168.0.1/24 [...output cut...] R1#ping 192.168.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/40 ms
Router R2 Status
R2#show ip interface serial 0/0 Serial0/0 is up, line protocol is up Internet address is 192.168.0.2/24 [...output cut...] R2#ping 192.168.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/36 ms
The above shows that the serial interface is up and running between both routers and that simple ping commands succeed.
Gettin’ Busy: Why use a Frame-Relay Switch Anyway?
One valid question is why we are using a frame-relay switch between the two emulated routers. After all, we could directly connect them using Dynagen (the Dynamips/Dynagen tutorial covers a direct connection as a first example). The answer lies in scalability. For the emulated Cisco 3640, there are a total of four serial ports; this severely limits the number of physical routers that can be connected. Let’s extend our topology to use *four* routers!
The 4-Router Frame-Relay Switch Dynagen “.net” File
Let’s quickly look at the Dynagen “.net” file for our setup:
###############################################################
# the four routers - these are easy
[[ROUTER R1]]
model = 3640
console = 50201
# serial port connected to frame relay switch
s0/0 = F1 1
# ethernet connectivity
slot1 = NM-1FE-TX
f1/0 = E1 1
[[ROUTER R2]]
model = 3640
console = 50202
# serial port connected to frame relay switch
s0/0 = F1 2
[[ROUTER R3]]
model = 3640
console = 50203
# serial port connected to frame relay switch
s0/0 = F1 3
[[ROUTER R4]]
model = 3640
console = 50204
# serial port connected to frame relay switch
s0/0 = F1 4
###############################################################
# The frame-relay switch with a "mesh"
[[FRSW F1]]
# Interconnect each router to each of the other routers
1:102 = 2:201
1:103 = 3:301
1:104 = 4:401
2:203 = 3:302
2:204 = 4:402
3:304 = 4:403
So…what is different here? Obviously we have more routers – and each router has a serial port named s0/0 that connects to the frame-relay switch named F1. For convenience, the circuit ID chosen for each router matches the router name…thus F1 1 for Router R1 thru F1 4 for Router R4.
It’s on the frame-relay switch named F1 that we see a big difference. We are creating a “mesh” of point-to-point connections between each router. (There are 4 routers total, a mesh network is (n * (n-1))/2, and as you can see we do end up with (4 * (4-1))/2 = 6 virtual circuits defined.) So all we need to do is look at the router configs to see how we use this…be prepared for a shock 🙂
Router R1 Configuration – Subinterfaces!
hostname R1 ! interface Serial0/0 no ip address encapsulation frame-relay clock rate 2016000 ! interface Serial0/0.102 point-to-point ip address 192.168.0.5 255.255.255.252 frame-relay interface-dlci 102 ! interface Serial0/0.103 point-to-point ip address 192.168.0.9 255.255.255.252 frame-relay interface-dlci 103 ! interface Serial0/0.104 point-to-point ip address 192.168.0.13 255.255.255.252 frame-relay interface-dlci 104 !
Wow! That’s different, isn’t it? We no longer assign an IP address or a DLCI interface ID to our Serial0/0 interface. This is because, each point-to-point network must have its own subnet. So…we get clever here and subdivide the Serial0/0 interface into “subinterfaces”. Router R1 must connect to Routers R2, R3, and R4. You will see in the above that we create three subinterfaces to handle this. Interface Serial0/0.102 is used to connect Router R1 to Router R2 over the “master” Serial0/0 serial interface cable. We give that subinterface its own IP on a /30 subnet (which allows only two addressable hosts) and assign it the DLCI circuit identifier 102. Then we do the same thing for the other two serial subinterfaces to connect to the other routers.
Router R2, R3, and R4 Configurations
Because this article is gettin’ kinda long, let’s combine the other three router configurations into this section:
First, Router R2:
hostname R2 ! interface Serial0/0 no ip address encapsulation frame-relay clock rate 2016000 ! interface Serial0/0.201 point-to-point ip address 192.168.0.6 255.255.255.252 frame-relay interface-dlci 201 ! interface Serial0/0.203 point-to-point ip address 192.168.0.17 255.255.255.252 frame-relay interface-dlci 203 ! interface Serial0/0.204 point-to-point ip address 192.168.0.21 255.255.255.252 frame-relay interface-dlci 204 !
Next, Router R3:
hostname R3 ! interface Serial0/0 no ip address encapsulation frame-relay serial restart-delay 0 clock rate 2016000 frame-relay lmi-type ansi ! interface Serial0/0.301 point-to-point ip address 192.168.0.10 255.255.255.252 frame-relay interface-dlci 301 ! interface Serial0/0.302 point-to-point ip address 192.168.0.18 255.255.255.252 frame-relay interface-dlci 302 ! interface Serial0/0.304 point-to-point ip address 192.168.0.25 255.255.255.252 frame-relay interface-dlci 304 !
Finally, Router R4:
hostname R4 ! interface Serial0/0 no ip address encapsulation frame-relay serial restart-delay 0 clock rate 2016000 frame-relay lmi-type ansi ! interface Serial0/0.401 point-to-point ip address 192.168.0.14 255.255.255.252 frame-relay interface-dlci 401 ! interface Serial0/0.402 point-to-point ip address 192.168.0.22 255.255.255.252 frame-relay interface-dlci 402 ! interface Serial0/0.403 point-to-point ip address 192.168.0.26 255.255.255.252 frame-relay interface-dlci 403 !
Final Thoughts
Although there is a lot more IP network configuration, this article has shown you a lot of information on how to create serial interfaces, apply DLCI, and connect routers. Hope it helped!
Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!
Leave a Reply