Archive for February 2014
Using regular expressions to make troubleshooting easier.
I’ve mentioned regular expressions throughout a few my articles over the last few years, usually as part of a configuration. However something I wanted to throw out there, is the fact you can use regular expressions with show commands. This can save quite a bit of time when bouncing between devices all day.
A few examples that I commonly use:
Let’s say you want to easily to pick out and view individual routes in the routing table or BGP table, here I used the underscore “_” regular expression to pick out only the route I wanted. This also works quite well to quickly see the default route.
Something I got tired of real quick, was checking interface errors since we all know issuing “show int” displays an awful lot of information, here I used the pipe “|” to look for multiple strings.
Let’s also say you need to quickly see the status of multiple interfaces on a chassis or stackable switch, we can use the brackets “[” “]” to look at a range of numbers, so you can easily view a particular interface across the stack or chassis, and/or even to see a range of interfaces across the stack/chassis. (I don’t have a functional stack in my lab yet but that RegEx would work across the first 2 stack members)
Now regular expressions are very powerful and there are quite a few I did not mention here. I highly recommend taking some time to go over them and see you can come up with. Feel free leave those findings in the comments below!
You can read more about the RegEx’s here.
A look at Flexible Packet Matching and a possible use case?
Flexible packet matching, definitely an extremely powerful tool and a complicated one at that, not only because of it’s configuration but also because you need to be familiar with the different protocol structures as well as regular expressions if you want perform some fancy matching criteria.
In a nutshell, Flexible packet matching allows routers to look deep into a particular type of packets, & into the various fields contained within the packet to perform specific actions based on the contents of those fields.
Before you can configure flexible packet matching, you will first need load a PHDF, Protocol Header Definition File. The PHDF is an XML file that outlines the format of the protocol header, the name of the fields, the length of the fields, and where the fields start within the packet. Below is sample of the XML text with the icmp.phdf:
To dwell on the PHDF for a bit longer:
- The field name matches a particular field within the header for the most case.
- The offset, denotes where the field starts in the packet header. The offset is always from the start of the header.
- The length, defines how long the field is.
- Notice the length and the offset can either be in bits or bytes
- The total length of the header at the bottom of the PHDF is also a requirement.
- This is all good to know since you can create your own PHDF files.
Here is a quick outline of an ICMP packet so you can correlate the PHDF to the to the actual packet.
To load the PHDF file itself, you’ll want to issue the following command:
After the PHDF is loaded you can issue the following command to see the specifics of the PHDF file itself. Similar to what is listed in the PHDF file itself.
Next, we are going create an ‘access-control’ class-map to match our traffic. I will keep the example to ICMP for simplicity:
Notice, we have multiple match statements, making sure we only look ICMP Echo packets, that have have a number with the first 256 byes of its payload. Now remember you can get pretty creative with regular expression, (If you’ve done any real work with BGP routing policies you know what I mean) for the sake of this post I wanted to keep it simple.
Now we need to create a ‘stack’ class-map, this particular type of class-map allows the router to narrow down its matching criteria by matching particular protocol headers in a particular order. If you do not specify a ‘stack’ class-map the the ‘IP’ header will be assumed. The example below matches ICMP over IP. Check out the INE link at the end of this post to see an advanced ‘stack’ involving ICMP within an IP-IP tunnel.
Since we have the ‘stack’ and ‘access-control’ class-maps defined it is now time we tie this together within a policy-map. Before we do that, we need to create an ‘access-control’ policy-map to match our ‘access-control’ class-map, and define our action when matching traffic is seen. There are only a few different options with ‘access-control’ policy-maps. (All of the pretty much listed below)
To tie together, the ‘stack’ & the ‘access-control’ class-map we will need to create another ‘access-control’ policy-map referencing the ‘stack’ class-map as a class, and then referencing the class-map containing our action as a service-policy.
With all the pieces tied together now, we can apply this to an interface:
So now, any ICMP Echo packets with a digit from 0-9 in the payload will get dropped, we can verify this by issuing the following show command:
Not an easy process, and quite a tedious one in fact. So what could you possibly use this feature for? Well this feature could be used as a psuedo-IPS to block a specific set of malicious traffic, or even to block ICMP Covert channels without the use of an IPS.
Here are some other resources for Flexible Packet Matching:
INE FPM Article – Great resource for showing off the power of FPM, by matching ICMP packets within an IP-IP tunnel
I highly recommend the Wireshark WCNA book for learning about the different protocols headers (and much more)
Use your router to perform packet captures.
For quite some time now Cisco routers have had a feature known as EPC embedded packet capture, this feature allows you to perform packet captures directly on the interfaces making this one of the most useful features Cisco could implement (in my own opinion of course), a few things you can do with this feature:
- Listen to VoIP calls to verify quality
- Verify packet markings
- Troubleshooting connectivity issues
- and so on.
The best part of this, is the fact the configuration is fairly simple and you can begin capturing packets with just a few simple commands.
Here is a quick outline of the process:
- Create a buffer point
- Create a capture point
- Tie the buffer point & the capture together
- Start the capture
- Stop the capture
Now to dive a little deeper!
The buffer point is memory used to hold the packets captured and as we all know Cisco devices have a finite amount of memory on them and we would not want a packet capture to completely utilize all the space and cause other issues. So this where we limit what gets put in the buffer. On top of that we can also set filters based off an access-list in order to limit the packets we will capture, since in many cases we would not want to capture all the data traversing the router.
Buffer Point Options
Next we need to specify the capture point, this is where we specify the interface we want to capture on and in which direction we want to capture in. One thing you will need to specify is if you want to capture CEF or process switched traffic, this option in itself I think I just awesome (Of course most of the time you will capture CEF switched packets) but it’s nice to have the option. One thing I want to throw out there is yes you can capture on sub-interfaces.
You have the option to capture both IPv4 & IPv6 traffic
Now that we have created the capture point and the buffer point, we need to tie them together, this done with the following command:
All we need to do now is start then stop the capture, with the following command:
You can either manually stop the capture, or use one of the various options in the buffer point to trigger the capture to automatically stop.
Once the capture is complete you will most likely want to export the capture off the router and to your own workstation for deeper analysis in Wireshark or Omnipeek. You can export the capture off box by using protocols like TFTP or FTP, or even export the file directly to flash and come back to it later.
Buffer export options
Just think about the doors this opens for troubleshooting those odd random issues where you only wish you could capture the traffic for further analysis now you can!
Also think about the other cool things you can do with EPC:
- Utilize EPC on multiple interfaces at the same time, with multiple capture & buffer points. (Check out this page from Cisco)
- Use EPC in conjunction with kron jobs or EEM applets to perform on-demand packet captures.
- Much more
CCIE or Null! 