Phase III: Configure
Now for the fun part of the project: configuring it for actual operation. The “real” configuration tasks will be reserved for lab exercises, but some initial setup helps things run more smoothly. The tasks involved are as follows:
Step 1: Frame-Relay Switch Configuration
I have used a variety of different devices over the years for this function, from a Cisco 7010 (huge power-sucking heat generator) to the NM-8A/S module in my current lab environment. The module is a much better approach because it accomplishes the same thing while using existing hardware real estate. The only drawback is that the interfaces are lower speed (128K typically), but in a lab environment that is not problematic.
Remember for the interface naming conventions on Cisco routers, namely slot/port, and with modules the slot is usually going to be 1/X. Assuming use of the module in the parts list, the interfaces are as follows:
- Serial 1/0
- Serial 1/1
- Serial 1/2
- Serial 1/3
Configuration is fairly straightforward. You have to supply frame-relay Data Link Connection Identifiers (DLCI, the Layer 2 addresses in frame-relay) and a few other settings. For the sake of simplicity assume that Router 1 is connected to S1/0, Router 2 is connected to S1/1, and so forth.
The first step is to enable the router to perform frame-relay switching, which is configured in global configuration mode using the frame-relay switching command. The configuration for the first port would be as follows, with annotations explaining the significance of the commands:
|interface Serial 1/0||Physical interface being configured|
|encapsulation frame-relay||Layer 2 encapsulation type|
|clock-rate 128000||Port speed (use top speed available)|
|frame-relay intf-type dce||Designates DCE switch interface|
|frame-relay route 102 interface serial 1/1 201||Describes the DLCI of frames coming into the interface, and then the destination DLCI and interface|
|frame-relay route 103 interface serial 1/3 301|
|frame-relay route 104 interface serial 1/1 401|
The concept here is simple: the router on the other end of the cable (DTE side) sends traffic tagged with one of the DLCI values (e.g., 102, 103, 104), then sends it out the interface with a new DLCI number (e.g., 201, 301, 401), and it arrives on the DTE port of the destination router. This is basically the same logic used by service providers with enormous switches. You can do the same type of thing with ATM or MPLS configured ports, but for ATM you need specific interface types. Following this, you need to configure the rest of the ports to perform the same type of switching tasks.
Step 2: Create Basic Template Configurations
I recommend one final task just to make things easier when you want to erase configurations and start over when you start a new set of lab tasks. Create a set of basic parameters that you will use at the start of most every lab and that will remain constant. Here are the ones that I recommend:
- Hostname — I prefer to use a single letter which describes the device: R for router, S for switch, F for firewall, etc.. Following that is a numerical value that just describes where the device sits in the topology. Sometimes I include a model number so I know the capabilities of the device. For instance, if the first router in the lab pod is a 2620, I would make the hostname R1-2620.
- Device access — The device access ports probably will not change substantially, so setting the parameters is a good idea. Usually you only need console or telnet/SSH access but setting the AUX settings for routers is a good idea as well. Basic settings for each are suggested as follows:
line con 0 Console Port privilege level 15 Enters privileged mode right away password xxxxx Specifies a password when needed No login Logs you in directly without intervention line aux 0 Auxiliary (modem) Port password xxxxx Specifies a password to access the system transport input all Allows any protocol for access (telnet, etc.) login Requires a login process for access line vty 0 Virtual Terminal Port (remote access) password xxxxx Specifies a password to access the system transport input all Allows any protocol for access (telnet, etc.) login Requires a login process for access
- LAN Settings — Most routers that you use in a lab have the capability of supporting VLAN trunking on LAN interfaces. That being the case, set the encapsulation type on the switch(es) to trunking encapsulation right off the bat, and don’t change it.
- WAN Settings — Serial interfaces on Cisco routers default to HDLC encapsulation, so make certain that you set the ports to frame-relay encapsulation. That way, the interfaces will be up/up when you start off, and you will not have to waste time troubleshooting issues that really are not issues
- Device Defaults — A few settings are helpful on routers and switches simply so you do not have to deal with ongoing irritating issues. A big help is to disable DNS lookups when you mistype a command, which is the no ip domain-lookup command in global configuration mode. Setting the time zone helps also.
To keep your template configurations readily available, copy them to flash memory using the copy running-config flash: command. When you are done with a lab exercise, you can issue the write erase command and reboot. Once the device completed the boot process, issue the copy flash:<filename> running-config command and then reload the configuration.
There are many other tips and tricks to creating great lab environments which I hope to share in the future!