Thursday, November 28, 2013

How to configure a Cisco router to be a frame relay switch

If you are studying for the TSHOOT exam, it is a good idea to familiarize yourself with the topology. I've been working on creating a lab that mocks the TSHOOT topology, and it has forced me to recall how to setup a Cisco router to act like a Frame Relay switch. 
Here is the topology that I've built. As you can see, it closely resembles the topology that Cisco has provided on their site. Since their doc doesn't provide specific DLCIs, I've used the most logical numbers I could think of.
tshoot-wan
The first step in configuring a Cisco router to act like a frame relay switch is to enable frame relay switching:
FR(config)#frame-relay switching
Once enabled, you then configure the serial interfaces connected to the other routers.
interface Serial0/0
 description Link to R4
 no ip address
 encapsulation frame-relay
 clock rate 64000
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 403 interface Serial0/1 304
!
interface Serial0/1
 description Link to R3
 no ip address
 encapsulation frame-relay
 clock rate 64000
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 302 interface Serial0/2 203
 frame-relay route 304 interface Serial0/0 403
!
interface Serial0/2
 description Link to R2
 no ip address
 encapsulation frame-relay
 clock rate 64000
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 201 interface Serial0/3 102
 frame-relay route 203 interface Serial0/1 302
!
interface Serial0/3
 description Link to R1
 no ip address
 encapsulation frame-relay
 clock rate 64000
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 102 interface Serial0/2 201
Then all you need to do is configure the other routers and connect them to your "switch". Here are the configs for the other router serial interfaces for reference:
!R1
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
!
interface Serial0/0.12 point-to-point
 ip address 10.1.1.1 255.255.255.252
 frame-relay interface-dlci 102 

!R2
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
!
interface Serial0/0.12 point-to-point
 ip address 10.1.1.2 255.255.255.252
 frame-relay interface-dlci 201   
!
interface Serial0/0.23 point-to-point
 ip address 10.1.1.5 255.255.255.252
 frame-relay interface-dlci 203   

!R3
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
!
interface Serial0/0.23 point-to-point
 ip address 10.1.1.6 255.255.255.252
 frame-relay interface-dlci 302   
!
interface Serial0/0.34 point-to-point
 ip address 10.1.1.9 255.255.255.252
 frame-relay interface-dlci 304 

!R4
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
 frame-relay lmi-type ansi
!
interface Serial0/0.34 point-to-point
 ip address 10.1.1.10 255.255.255.252
 frame-relay interface-dlci 403
References used for this configuration are as follows:
Posted by at No comments:

Clock rate versus bandwidth

If you have ever setup a lab of Cisco routers, you likely have configured a clock rate on one or more serial interfaces. You might have also configured the bandwidth setting on an interface as well. Is one required and not the other? Do they both need to be configured? That's what many people have wondered, including myself when I first started configuring Cisco routers over a decade ago. So I figured I'd create a quick explanation to help people better understand the bandwidth and clock rate commands.

Bandwidth

The bandwidth command administratively sets the bandwidth of an interface. When a router boots up, it sets a default bandwidth on an interface which can be seen with the show interface command.
R1#show int s0/0
Serial0/1 is administratively down, line protocol is down 
  Hardware is M4T
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

[output omitted]
The following example shows the bandwidth command syntax as well as the show interface output after the bandwidth has been changed:
R1#config t
R1(config)#int s0/0
R1(config-if)#bandwidth ?
  <1-10000000>  Bandwidth in kilobits
  inherit       Specify that bandwidth is inherited
  receive       Specify receive-side bandwidth

R1(config-if)#bandwidth 256
R1(config-if)#do show int s0/0
Serial0/0 is up, line protocol is up 
  Hardware is M4T
  Internet address is 192.168.1.1/30
  MTU 1500 bytes, BW 256 Kbit/sec, DLY 20000 usec,
If the bandwidth is configured to 256Kbps, it doesn't mean that the interface only sends data at that rate. The router will still use 1.544Mbps (assuming a point to point T1). The bandwidth command is used for higher level protocols such as routing protocols and Quality of Service. If you configure EIGRP or OSPF, they will use the default bandwidth that is on an interface. If you manually configure the bandwidth on an interface the routing protocol would use that instead. 
It is common to use this command on interfaces connected to leased lines or connections provided by a service provider. For example, if you have a Metropolitan Ethernet connection that comes in on a Gigabit Ethernet interface, but the service provider has only provisioned it to 50Mbps, then using the bandwidth command to set it to 50,000 kbps would allow the router to accurately calculate the bandwidth on that link.

Clock Rate

The clock rate command is used to configure the rate at which bits of data will traverse the actual hardware interface. This command does impact the speed at which data traverses an interface.
The syntax for this command is as follows: 
R1(config-if)#clock rate ?
  With the exception of the following standard values not subject to rounding,

          1200 2400 4800 9600 14400 19200 28800 38400 
          56000 64000 128000 2015232 

  accepted clockrates will be bestfitted (rounded) to the nearest value
  supportable by the hardware.

  <246-8064000>    DCE clock rate (bits per second)
Typically when dealing with leased lines such as T1's from a service provider, you don't need to configure a clock rate because you are on the DTE side of the link. However, this command is frequently used in lab environments since one side of the serial connection is the DCE. 
For additional information information on the syntax of these commands, here is a link to the command reference at cisco.com

(http://www.tekcert.com)
Posted by at No comments:

How to configure DHCP Snooping on a Cisco Catalyst switch

Everything in this post has been tested in a lab environment with a Cisco 3550, Infoblox DHCP servers, a Netgear router as a "rogue" dhcp server, and a MacBook Pro as a client. The 3550 is configured with ip routing and a layer 3 interface on the subnet where the DHCP servers are located (10.0.10.0/24). VLAN 20 has been created on the 3550 with an interface ip address of 10.0.20.254/24. All the DHCP server configuration and helper addresses were tested and working prior to implementing DHCP snooping to eliminate any doubt as to whether the DHCP snooping configuration is working or not. So, let's get started.
For DHCP snooping to work, you have to enable it globally. That is done with the following global configuration command:
Switch(config)#ip dhcp snooping
You also have to tell the switch which VLANs to monitor. In a production environment, this would be the client VLANs, not a transit VLAN that leads to the rest of the network. This is done with the following command:
Switch(config)#ip dhcp snooping vlan 20
At this point DHCP snooping is configured and enabled. There are several default settings that can be modified later, but that can be delt with after we verify things are working. Here is the basic show command to verify DHCP snooping is working (specifically the top few lines):
Switch#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:

20
DHCP snooping is operational on following VLANs:

20
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled
   circuit-id format: vlan-mod-port
    remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
Once you verify DHCP snooping is working, you can verify DHCP lease information starts to populate the DHCP snooping binding table on the switch with the following command:
Switch#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
AA:2C:DD:09:D1:CD   10.0.20.28       28781       dhcp-snooping   20    FastEthernet0/13
Total number of bindings: 1
If you have a DHCP server plugged into a switch with DHCP snooping enabled, or if you have a layer 2 LAN port connected to an upstream switch where the DHCP server resides, you'll have to trust that port. To do this, enter the following command in interface configuration mode:
Switch(config-if)#ip dhcp snooping trust
Any DHCP responses that come from an untrusted port (all the other ports) will simply be dropped without any notification. To test this out, after this was all configured and working, I connected a Netgear router with DHCP enabled into another VLAN 20 access port on the 3550. I forced a DHCP request to be sent out by the client and nothing happened. No log messages or warnings, nothing. Just to be sure the rogue DHCP server was working, I disabled snooping and unplugged the 3550 uplink to the production network. The client received a 192.168.1.2 ip address immediately. I released the IP, reconfigured snooping and tested again. The client received an IP from the authorized DHCP server and nothing happened with the fake DHCP server port.
I wish the switch was smart enough to put the switch-port connected to the rogue DHCP server into err-disable mode, but at least it stops the unauthorized DHCP server from actually handing out IP leases.
This concludes the basic DHCP snooping configuration. For additional information regarding DHCP snooping configuration options, check out these links:
Also, for reference, here are the relevant parts of my 3550 lab configuration:
interface FastEthernet0/1

 description Layer 3 uplink to production network

 no switchport
 ip address 10.0.10.253 255.255.255.0
 speed 100
 duplex full
!
interface FastEthernet0/12

 description Rogue DHCP server

 switchport access vlan 20
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/13

 description Client

 switchport access vlan 20
 switchport mode access
 spanning-tree portfast
!
interface Vlan20
 ip address 10.0.20.254 255.255.255.0
 ip helper-address 10.0.10.106
 ip helper-address 10.0.10.107
One final thought. If you are rolling this out into production, be sure to do so during a change window and test a client DHCP request with ipconfig /release and ipconfig /renew to be sure it can get an IP address and it shows up in the binding table.
Disclaimer: This configuration was tested in a lab environment. If you use this configuration to modify a production environment, you do so at your own risk. The information in this post is provided as an example so you can custom tailor it to your own network. Don't blame me if this information is misused and causes an outage to production systems.
Posted by at No comments:

How to configure DHCP Snooping on a Cisco Catalyst switch

Everything in this post has been tested in a lab environment with a Cisco 3550, Infoblox DHCP servers, a Netgear router as a "rogue" dhcp server, and a MacBook Pro as a client. The 3550 is configured with ip routing and a layer 3 interface on the subnet where the DHCP servers are located (10.0.10.0/24). VLAN 20 has been created on the 3550 with an interface ip address of 10.0.20.254/24. All the DHCP server configuration and helper addresses were tested and working prior to implementing DHCP snooping to eliminate any doubt as to whether the DHCP snooping configuration is working or not. So, let's get started.
For DHCP snooping to work, you have to enable it globally. That is done with the following global configuration command:
Switch(config)#ip dhcp snooping
You also have to tell the switch which VLANs to monitor. In a production environment, this would be the client VLANs, not a transit VLAN that leads to the rest of the network. This is done with the following command:
Switch(config)#ip dhcp snooping vlan 20
At this point DHCP snooping is configured and enabled. There are several default settings that can be modified later, but that can be delt with after we verify things are working. Here is the basic show command to verify DHCP snooping is working (specifically the top few lines):
Switch#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:

20
DHCP snooping is operational on following VLANs:

20
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled
   circuit-id format: vlan-mod-port
    remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
Once you verify DHCP snooping is working, you can verify DHCP lease information starts to populate the DHCP snooping binding table on the switch with the following command:
Switch#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
AA:2C:DD:09:D1:CD   10.0.20.28       28781       dhcp-snooping   20    FastEthernet0/13
Total number of bindings: 1
If you have a DHCP server plugged into a switch with DHCP snooping enabled, or if you have a layer 2 LAN port connected to an upstream switch where the DHCP server resides, you'll have to trust that port. To do this, enter the following command in interface configuration mode:
Switch(config-if)#ip dhcp snooping trust
Any DHCP responses that come from an untrusted port (all the other ports) will simply be dropped without any notification. To test this out, after this was all configured and working, I connected a Netgear router with DHCP enabled into another VLAN 20 access port on the 3550. I forced a DHCP request to be sent out by the client and nothing happened. No log messages or warnings, nothing. Just to be sure the rogue DHCP server was working, I disabled snooping and unplugged the 3550 uplink to the production network. The client received a 192.168.1.2 ip address immediately. I released the IP, reconfigured snooping and tested again. The client received an IP from the authorized DHCP server and nothing happened with the fake DHCP server port.
I wish the switch was smart enough to put the switch-port connected to the rogue DHCP server into err-disable mode, but at least it stops the unauthorized DHCP server from actually handing out IP leases.
This concludes the basic DHCP snooping configuration. For additional information regarding DHCP snooping configuration options, check out these links:
Also, for reference, here are the relevant parts of my 3550 lab configuration:
interface FastEthernet0/1

 description Layer 3 uplink to production network

 no switchport
 ip address 10.0.10.253 255.255.255.0
 speed 100
 duplex full
!
interface FastEthernet0/12

 description Rogue DHCP server

 switchport access vlan 20
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/13

 description Client

 switchport access vlan 20
 switchport mode access
 spanning-tree portfast
!
interface Vlan20
 ip address 10.0.20.254 255.255.255.0
 ip helper-address 10.0.10.106
 ip helper-address 10.0.10.107
One final thought. If you are rolling this out into production, be sure to do so during a change window and test a client DHCP request with ipconfig /release and ipconfig /renew to be sure it can get an IP address and it shows up in the binding table.
Disclaimer: This configuration was tested in a lab environment. If you use this configuration to modify a production environment, you do so at your own risk. The information in this post is provided as an example so you can custom tailor it to your own network. Don't blame me if this information is misused and causes an outage to production systems.
Posted by at No comments:

Using Windows Server 2008 as a RADIUS Server for a Cisco ASA

http://fixingitpro.com/2009/09/08/using-windows-server-2008-as-a-radius-server-for-a-cisco-asa/
Posted by at No comments:

Configuring NTP on a Linux client

To install ntpd, you can do it a couple different ways (such as downloading it from ntp.org and installing it manually) or you can use your favorite installer (I use apt-get):
sudo apt-get install ntp
Then you need to edit the /etc/ntp.conf file to point to the server you want to grab the time from. Since the installation started the process for me, I wanted to stop it before editing the conf file:
service ntp stop
Also, you might need to chmod the file first to allow writing to the file:
cd /etc
chmod 777 ntp.conf
vi ntp.conf
Add a line with your server to the config, I added mine above the defaults in they had listed:
server 10.2.1.4
Save your changes with :wq
Now undo the chmod command to put it back to rw-r-r:
sudo chmod 644 ntp.conf
Now start the ntp service back up:
service ntp start
That's all there was to it. Type "date" to see the current time and date on your box. It should be current after the service starts.



http://www.tekcert.com
Posted by at No comments:

Password Recovery on a Cisco 2500 Series Router

If you have built a home lab (or are running really ancient hardware in production), you may find yourself in need of resetting the password configured on a 2500 series router. Depending on the router platform, the syntax is different. Here's how to do it on a 2500:
1. Reboot the router and send a break sequence to enter ROMMON mode. Break sequences can be sent using a Ctrl+Break key combination, or if you are on a system that doesn't have a break sequence, try using your terminal software to send a break sequence.
2. (optional) Type the letter O and hit enter. Record the existing setting, it's most likely 0x2102.
3. To reset the configuration register and have the router bypass the startup-config, type the following:
o/r 0x2142
To boot the router, type the letter i and hit enter.
>i

System Bootstrap, Version 11.0(10c), SOFTWARE
Copyright (c) 1986-1996 by cisco Systems
2500 processor with 14336 Kbytes of main memory
The router should load and ask you to enter the initial configuration bla bla bla. Skip it and go into config terminal and change the configuration register back to 0x2102 (or whatever it was in step 2 if different). The command to change the configuration register in global config mode is as follows:
router(config)#config-register 0x2102
You can also copy startup-config to running-config to load the config file, or you can just reboot.
Posted by at No comments:

Juniper Certification Exam Study Guides [PDF]

I thought these may be useful for people studying for Juniper certifications:
Juniper posts a lot of stuff on their site for certification and technical reference . Everything from free study guides like these to training videos.
Posted by at 2 comments:

Verify Cisco IOS Before Upgrading

If you have ever upgraded the IOS on a Cisco Switch or Router, you may have just copied the new IOS file from a tftp server and then rebooted without thinking twice about it. This generally works and I've done my fair share of upgrades without checking the file integrity in the past. However, there is a safer way to upgrade: the Verify command.
After copying your file from whatever source (ftp, tftp, scp, etc), you simply type verify and the filename and it does the rest. Here's what it looks like:
Router#verify flash:c1841-ipbasek9-mz.124-24.T.bin
Verifying file integrity of flash:c1841-ipbasek9-mz.124-24.T.bin.............

.............................................................................

........................................... several thousand dots truncated
.............................................................................

.............................................................................

...............................................Done!
Embedded Hash   MD5 : A51F5C72743BAB116E72E58F4A8D2BB2
Computed Hash   MD5 : A51F5C72743CFC116E72E58F4A8D2BB2
CCO Hash        MD5 : 8F8DED53AF421719DB699DF5ADC891E0

Embedded hash verification successful.
Router#
As you can see from the output, the MD5 hash value is calculated and then compared to an embedded hash in the file. Obviously if the file were modified or corrupted during transport, it would show up here.
Another way to verify the file is to include the /verify option when copying a file. It does the same function as the example above, however it performs it immediately after the copy is complete. Here's the syntax:
Router#copy ?                                                              
  /erase          Erase destination file system.
  /error          Allow to copy error file.
  /noverify       Don't verify image signature before reload.
  /verify         Verify image signature before reload.

Router# copy /verify ftp:/filename.bin flash:
I haven't seen an MD5 hash come back labeled as "bad" yet, but I have seen a corrupt file simply not work with the verify command:
Router#verify example.bin
File example.bin does not support verification.
That's all there is to it. So, be sure to check your files when you're upgrading IOS.. before you reboot.

http://www.tekcert.com
Posted by at No comments:

Determine Public IP Via Telent

Many people use sites like http://www.whatismyip.com or http://www.ipchicken.com to identify the public IP address of an unfamiliar network.
Telnet to v4address.com or v6address.com if you do not have a web browser (router, switch, linux).
[josh@webserver ~]$ telnet v4address.com
Trying 184.105.238.114…
Connected to v4address.com.
Escape character is ‘^]’.
This is the telnet autoresponder at v6address.com.
You have connected over IPv4.
Your IP address is 12.34.56.78
Connection closed by foreign host.
Posted by at No comments:
Subscribe to: Posts (Atom)