Archive for the ‘Cisco’ Category
Cisco Express Forwarding – CEF
In my last post about unicast Reverse Path Forwarding, I made quite a few references to CEF. CEF (known as Cisco Express Forwarding) is a feature built into every Cisco router and is enabled by default it’s really the feature that makes Cisco well Cisco. I figured I would take a little time and discuss CEF in a little detail.
From a 500 foot view CEF is a method the router uses to forward packets, without utilizing any CPU cycles. CEF builds 2 cached tables in memory, these 2 cached tables are built from every entry in the routing table. So when the next packet arrives the router simply looks up the CEF entry found within memory to forward the packet, compared to sending the packet to the packet to the CPU for a route lookup and then forwarding the packet on.
CEF works by creating two tables:
- The Adjacency table maintains the layer 2 forwarding information for each FIB entry eliminating the need for the router to send out ARP requests.
- The FIB (Forwarding Information Base, also known as the CEF table) contains information from the routing tables and tracks the next-hop for all routes. So where the adjancency table manages layer 2 information the CEF table manages the layer 3 forwarding information
Now that we know the components of CEF, lets talk a little about how CEF interacts with packets as they enter the router.
- Once the packets arrives at the router the layer 2 information is stripped off. (This is normal and happens whenever a frame is accepted to a layer 3 device)
- Next the router looks up the destination using the CEF table.
- Then the router finds the corresponding adjacency table entry.
- The router then adds the corresponding layer 2 information (found in the adjacency table) back to the packet and forwards the packet on. All from memory.
You can view the CEF table by issuing the command sh ip cef:
Now remember the CEF table is layer 3 information so we have destination prefixes and what the next hop address is along with the outgoing interface.
You can view layer 2 adjacencies by issuing the sh adjacency %Interface% detail:
Since the adjancency table pertains to layer 2 information we’ll see some MAC addresses here, one thing I want to point is that long hexidecimal number in the fifth line that line consists of the destination MAC address of 10.1.1.2, the source MAC address of this routers fa0/0 interface and the ethertype of 0800 (Meaning it’s an ethernet interface)
Now this was only the tip of the iceberg for CEF, and this post was only supposed to bring it to light on a real high level so more CEF related posts will mostly surface as time goes on.
Scheduling router jobs utilizing Kron policies.
Another very nifty feature that is part of every router (along with Unix system) is the ability to run and schedule Kron jobs. The next question is what can you use these kron jobs for, well you can use them to run privileged level commands on a scheduled basis.
A few examples:
- Let’s say you want the router to automatically send it’s config to a TFTP or SCP server, create a kron job that will do just that on a weekly basis.
- Create a kron job that will write the running-config to memory so you don’t have to run the risk of losing your current configuration in the event of a power failure or router reboot.
- Set a kron job to run on a nightly basis and issue the undebug all command to prevent someone from letting a debug run rampant.
- The possibilities are almost endless.
Something to keep in mind however is the fact kron jobs cannot be used to make configuration changes, kron cli commands are submitted at the privilege level individually and because they are submitted individually you cannot nest commands to issue commands in global config mode. (You will want to look for a macro for something like that)
Now lets look at what we need to do to create and schedule a kron policy for a Cisco device:
- Create the kron policy.
- set the commands that are to be issued by the kron policy.
- Create the kron occurrence policy.
- Specify the re-occurrence schedule.
- Specify which kron policy to run under the occurrence schedule.
Setting up a kron policy
Setting the kron policy schedule.
The router will also tell you if the clock is not configured, as you could guess if the date/time on the router is not configured correctly scheduling the kron job could be difficult.
You can view the kron schedule by issuing the following command: sh kron schedule
Viewing the kron schedule
I’ve created a second schedule to run every 2 minutes to the sake of my own time.
You can also debug the kron job to verify it is running successfully: debug kron all
Kron debug output.
From the debug output you can see the router call the kron job, issue the command in the kron policy, delay the kron job another 2 minutes, and in this case you can see the router write config to memory.
Working with Cisco Macros.
As I was going some switch configuration guides I stumbled upon something that caught my attention macros. These macros allow you to create a set of commands that are issued to the device anytime you apply the macro.
Now these macros are very open ended, and have a host of potential uses. For example if you needed to change the management address of switch in a remote location simply create a macro that will do it for you. This way even though you will lose connectivity to the switch the macro still runs because the commands are being issued by the switch not by you from your computer, thus the new IP address is applied allowing you to connect back in using the new IP address. You can also use these to configure ports. Simply create a macro that will enable various features like portfast, port-security, rootguard, storm control, etc then head into interface config or interface range config mode and apply the macro, its an even quicker way to apply the same configuration to multiple ports this can also assist you with enforcing a uniform configuration to these ports leaving out human error (in case you configure ports manually one by one or continually configure small groups of ports using the interface range command).
You can also set variables in your macros, variables are assigned using the $ followed by the variable name. So let’s just say you created a macro that will reset a port that has been disable due to a port security violation you can set the interface as variable within the macro, now when you apply the macro simply specify the value of the variable.
See the below macro:
macro name psecrst do clear port-security stick int $int int $int shut no shut end sh int | include err-dis @
Note: Macros are created from configuration mode.
The key points with defining the above macro are the following, the name of the macro in this case the name is psecrst (short for port security reset, but you can name macro’s whatever you want), then you input the commands in the format and order needed to accomplish what you want successfully. Something to keep in mind is the commands will be issued from configuration mode (config) so if some commands needs to be issued in different modes you will need to account for that. You can also see I specified the variable at $int so I am able to specify whatever interface I need to in order for this macro to work correctly. When you are finished putting the commands in your macro you finish the macro by inputting the @ symbol.
To apply a macro we can issue the following command:
macro global apply psecrst $int fa0/2
As you can see after I specify the macro name I then start calling the variables (and you can have more then one variable in a macro) followed by the desired value of the variable. So in this case I specified fa0/2 as the variable so when the macro runs it resets port fa0/2.
Now if you run a macro and you are not getting the results you were expecting you apply the macro using this command
macro global trace psecrst $int fa0/2
Here we specified the keyword trace instead of apply this tells the switch to show you the commands as they are being issued.
I’ve attached the below screen captures:
Creating a macro within the CLI of a catalyst switch
Starting a macro with a variable assigned.
Tracing a macro with a variable assigned.
Using the CLI to install and IOS in .tar format.
Recently I tried updating the IOS of a Catalyst 2960 using it’s web interface (Why I don’t know), but like everything Cisco GUI related (SDM) I had trouble getting it to actually work. The page would just sit their and cycle. So I found myself unable to update the IOS using the GUI. So I extracted the files within the .tar file to flash, told to the switch to boot using the newer IOS then issued the reload command.
Start off by putting the .tar file on your tftp server like any normal IOS upgrade, the key difference here is you want to use the following command:
archive tar /xtract tftp://192.168.1.5/c2960-lanbasek9-tar.122-58.SE1.tar flash:
The variables here are the IP Address of the TFTP server and the IOS image file name.
Next you will see the switch extract the files within the .tar file
Extract tar file in flash
The last thing you can see is the .bin IOS file. Now I issue the boot system command:
boot system flash:/c2960-lanbasek9-mz.122-58.SE1/c2960-lanbasek9-mz.122-58.SE1.bin
Note: The contents on the .tar file are extracted into a folder
This tells the switch to boot this particular IOS file. Then after you issue the reload command and the switch boots up you will see the switch loads with the new IOS version.
IOS Version loaded by switch
Cisco IOS DHCP Server with Option 43 for LWAP’s
Cisco routers (and switches) have the ability to hand out DHCP addresses, so if you have a relatively small branch office & you don’t want to set up a full DHCP server you can simply add that functionality to your Cisco device.
It does take quite a few lines to get this going but I wouldn’t consider it to be a complicated configuration, each parameter is pretty self-explanatory. Let’s look at a typically IOS DHCP configuration.
Now the first thing you want to do is define the DHCP pool with the ip dhcp pool poolname command this puts us into (dhcp-config)# mode where we can configure addition parameters for this pool. Next you see the network 192.168.20.0 255.255.255.0 command which defines our DHCP range followed the default gateway, DHCP lease duration (3 days in this case), the DNS Server the for the DHCP clients, and finally the domain name.
The next thing we are going to do is configure some DHCP exclusions, these are simply addresses we tell the DHCP service not to hand out. We are also going to change the amount of times the router pings an address before it declares the address available.
Now the exclusions are done from (config)# mode (but as you can see they can be entered from (dhcp-config)# mode) along with the ip dhcp ping packets 4. The Cisco device will ping an IP address within the pool to see if it available, by default the device will send 2 pings if they both time out it assumes the address is available, here you can see I changed it to send 4 pings.
You can view any DHCP leases by issuing the Sh ip dhcp binding command. (Yes I know the time is a bit off but this my lab switch)
Now for some bonus content, I was going to split this up into multiple posts but figured I would just roll it in.
We are going to configure Option 43 in our DHCP scope. Option 43 is vendor specific, and is used by Cisco LWAPs to find and join WLC controllers. It’s all done in the following line:
As you can see this is also done within the DHCP Pool at the (dhcp-config)# configuration mode. The tough part here is figuring out the hex value however the hex value consists of 3 parts. The first part is the type which is always 0xF1, followed by the length which is the number of controller management IP address times 4 (So if you have 2 controllers for redundancy it would be 2 x 4 = 0×08), the third part consists of the ip addresses of controllers management interface in hex. (Now seriously did you ever seeing yourself converting IP’s to hex, or did you use a hex calculator?). For this example I used 2 management IP addresses 192.168.2.5 which is C0A80205 in hex and 192.168.3.5 which is C0A80305 in hex. Now all that together gives us the f108C0A80205C0A80305 hex string seen the above configuration.
Now here’s a DHCP packet with the Option 43 field:
Now packet analysis can be a bit daunting at first, but if you go line by line, you can easily make out everything that was configured, you see the option number and the hex value we entered, now your LWAPs in branch offices will be able receive a DHCP address and still find your WLC’s.
For more information on setting up a Cisco device as a DHCP click here. (This guide goes much more in depth then my post)
For more information on DHCP Option 43 and Cisco LWAP click here.
Automatically recover err-disabled ports.
Cisco switches have a feature built-in so ports in an err-disabled state automatically reset themselves saving you the time of having to connect to the switch and manually shut and no shut these interfaces. Only two parameters need to be considered when configuring this feature.
The first parameter concerns which errors you want the switch port to automatically recover from. For example you may not want a port with a security violation to come back up without administrative intervention, but a port downed due to a flapping host you might want automatically turned back on after a few minutes. You can issue the errdisable recovery cause ? command to see a list of switch port errors that the switch can automatically recovery from.
The second option you can configure is the time interval in which the switch waits before it re-enables the err-disabled port. The default recovery interval is 300 seconds.
As you can see, this is all down from global config mode.
While this err-disable recovery feature can be a great time saver it is still important to investigate and correct the real issue that is causing the switch ports to fail into an err-disabled state.
