CCIE or Null!

My journey to CCIE!

Posts Tagged ‘Cisco Switch

Working with Cisco Macros.

with 4 comments

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
no shut
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.

Written by Stephen J. Occhiogrosso

June 13, 2011 at 8:11 AM

Layer 1 Troubleshooting with Cisco Switches.

with one comment

Apparently Cisco switches have the capability of performing TDR tests on cables to test cable length and pin-outs. This is something I stumbled upon while browsing through the Cisco Learning Network and I just had to give it a whirl. After all sooner or later you are going to run into a cable issue, it’s just a matter of time. Whether it was not crimped, punched down correctly, or someone ignored the IEEE standard and made a cable too long. The bottom line is some user somewhere will not connect to the network and then it will be up to you to troubleshoot why (and to fix it).

To test a cable simply issue the following command: test cable-diagnostics tdr int %IntefaceType/Number% from privileged mode, and include the interface in question.

After a few seconds issue the following command to see the results: Sh cable-diagnostics tdr int %IntefaceType/Number%

The results are as follows:

Pretty straight forward, it tells you the interface the cable is plugged into, the speed of the connection, the local and remote pair of the cables, cable length (notice the “+/-” of a few meters), and finally the status.

Here is a description of the results from Cisco’s website (Found here):

This command is currently available many different switch models 2900’s,  3500’s, 3700’s, and further (Including both 10/100 MB and 1 GB ports). I would also like to mention if you perform this test on a live port, communication is not interrupted at all. The Cable Length measurement is actually very accurate, don’t let the “+/-” factor confuse you, I’ve ran this on multiple cables and the length calculation is right on the mark. This is a definitely a nifty feature to keep in your when you run into those wired connectivity issues.

Written by Stephen J. Occhiogrosso

April 18, 2011 at 3:17 PM

Automatically recover err-disabled ports.

leave a comment »

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.

Written by Stephen J. Occhiogrosso

April 11, 2011 at 7:07 PM

Configuring a SPAN session.

with 2 comments

A SPAN session is a way for you to have the traffic that is transmitted and/or received from one port or VLAN and have it forwarded out another port for analysis purposes. It’s very easily configured by a few small statements and the only thing you have to decide on is which port you want to monitor, the traffic flow you want to see from that port (egress, ingress, or both) and the destination port you want the traffic sent to. (See the configuration below)

Note: For this local SPAN session both the source port and destination port must be on the same switch. RSPAN allows SPAN sessions across remote switches, but I will not be covering RSPAN in this post.

Their isn’t much to consider concerning the source port since it will not be effected at all, the destination port however is treated a bit differently. First off the destination port will be put in a “Monitor” mode, meaning traffic received on this port will be dropped. Only traffic from the source port will be transmitted out of the destination port by the switch that’s it.

You can issue the sh monitor session # command to see if their are any active SPAN sessions on the switch, or if you want to see the details of a configured SPAN session. The source port (fa0/1), traffic flow (both), destination port (fa0/2), and the encapsulation, are all shown in the command. To close down a SPAN session simply issue the no monitor session # command.

Now your next question might be, what are you going to use this for or why are you going analyze the traffic? Well, if the station at the destination port is running Wireshark, it’s a real easy way to get a glimpse at the traffic traversing your network. From their you can look through the data and see if anything sticks out. Alternatively you can have a SPAN session provide data to a IDS/IPS system so it can monitor your network for any abnormalities.

Written by Stephen J. Occhiogrosso

April 4, 2011 at 2:21 PM

%d bloggers like this: