Aaron’s Worthless Words

A lot of IOS commands give you a lot of information. Most of the time, though, it’s way too much information, and it sure would be nice to do some grep-like stuff on the output, right? Well, just like on Linux, you can use the pipe (|) to do such. That’s not a butt cheek, by the way.

The most useful function is the include directive. This is the equivalent of just plain grep on Linux, and will show you only lines that match a string that you give it. Say that you want to find what ports on your switch are down, but don’t want to grind through all the lines of a show ip interface brief. If you just pipe it to the include command followed by the word “down”, you’ll see something like this.

Switch#show ip interface brief | include down
GigabitEthernet0/4 unassigned YES unset down down
GigabitEthernet0/7 unassigned YES unset down down
GigabitEthernet0/17 unassigned YES unset down down
GigabitEthernet0/18 unassigned YES unset down down
GigabitEthernet0/19 unassigned YES unset down down
GigabitEthernet0/20 unassigned YES unset down down

You can also use the exclude directive, which is the same as a grep -v on Linux. I hope you figured out that this gives you all lines that don’t match the word, so, let’s use the exclude directive to found out what ports are down. How about we just ignore the lines that are up.

Switch#show ip interface brief | exclude up
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/4 unassigned YES unset down down
GigabitEthernet0/7 unassigned YES unset down down
GigabitEthernet0/17 unassigned YES unset down down
GigabitEthernet0/18 unassigned YES unset down down
GigabitEthernet0/19 unassigned YES unset down down
GigabitEthernet0/20 unassigned YES unset down down

Well, this won’t exactly give you all the ports that are down. What if the port is up/down?

What else can you use with the pipe? What if you want to look at the configurations of all the ports or interfaces on a box but don’t want to go through the config hitting the spacebar over and over. If you use the begin command, you’ll see the output beginning from the first match, so, using the string interface will show you the config starting at the first interface.

Switch#show running-config | begin interface
interface GigabitEthernet0/1
description Server
switchport access vlan 4
switchport mode access
spanning-tree portfast

…

Another good one is the section command. It’s usually used on the output of show running-config and shows you sections of the config that match your string. Huh? If you want to see the BGP section of the configuration, you can do something like thing just to see that part of the configuration.

Router#show running-config | section bgp
router bgp 1
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 version 4

There are a few other commands for use with the pipe, so explore on your own. You might also want to check out regular expressions on the Cisco IOS if you want to match more than just simple text.

• Leave a comment... (6)

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

Let’s set up a scenario. You have a router with two Ethernet ports. E0/0 goes to your webservers on 192.168.1.0/24, while E0/1 goes to SysAdmins’ PCs on 192.168.2.0/24. We want to restrict all SSH access from 192.168.2.0/24 to 192.168.1.0/24 to 8k of bandwidth. That’s right, you don’t like your admins and want them to struggle with their daily tasks. Let’s set it up.

Remember the steps? ACL, class-map, policy-map, interface. First, create an ACL that matches the traffic you want to police.

ip access-list extended SQUASHSSH
permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 22

Next, create a class-map that matches that traffic.

class-map SQUASHSSH-CMAP
match access-group name SQUASHSSH

Create your policy-map. This is where you actually set the bandwidth restrictions.

policy-map SQUASHSSH-PMAP
class SQUASHSSH-CMAP
police 8000 conform-action transmit exceed-action drop

Last time, we just did a set dscp af43, but this time we actually take action on a packet instead of just marking it. The long lines does three things — it sets the ceiling to 8000 bits per second, transmits if the rate is below that number, and drops if its exceeded. So, if one of the admins tries to SCP a file over, he’s gonna be in for a surprise with only an 8k window to use. If he goes over 8k, the packets are just dropped, and it’s up to TCP to retransmit. It’ll take a while. Remember, too, that this policy applies to anything matching the ACL, so, if two admins are SCPing files at the same time, they have to share that 8k. Wow, you’re mean!

Setting it up on the interface is pretty straightforward. It’s just like we did before.

interface E0/0
service-policy output SQUASHSSH-PMAP

I set this up in a dynagen lab to test it, but, instead of SSH traffic, I policed ICMP. If I did a normal, 5-packet ping, it worked great. If I sent a 100-packet set, drop, drop, drop. Or if I increased the size of the packets. Just to be sure it was the service-policy doing the dropping, I sent a 100-packet set and removed the policy from the interface; it missed a few at first, but, when the policy was removed, it zoomed right along without a single miss or hesitation.

NOTE: I do not condone policing traffic from your coworkers machines to 8k, but it would be funny.

• Leave a comment... (4)

I’ve been trying to get some experience on Cisco VOIP, and, as you probably know, Quality of Service (QoS) is quite important in that realm. Since VOIP is very time-sensitive, you have to be sure your gear delivers the voice packets first. A packet in an HTTP transaction can wait another 200ms without any problems. A voice packet with another 200ms on it means static and digital artifact on the line. Not good. There are lots of things you can do in the world of QoS, but I’ll talk about tagging this time (I may get to some of the other topics later, though).

What is tagging, though? There is a header in an IP packet that, paraphrased from the standard, set the importance and drop-sensitivity of the packet in regard to the flow/application/data stream. A ping packet is quite unimportant in the grand scheme of things, and dropping the packet will have very little impact on the stuff going on in the network. Voice, however, needs every packet to arrive in order, so each packet’s importance is high and a drop hurts. To differentiate between these two, we set the Differentiated Service Code Point (DSCP) value in the pakcet. This is just the packet header thing I was talking about earlier.

Let me pause for a second to discuss something, though. Just tagging the packet does nothing to prioritize the packet. I can tag a packet with whatever I want, but, if a router or switch isn’t configured to use the tag, my packet just goes into the FIFO queue like everything else. Actually doing something different to a tagged packet is one of the many other parts of QoS that I may get to later.

Time to configure? Of course. Like everything in the Cisco world, it always usually starts with an access-list to define interesting traffic. You then create a class-map that defines what traffic you want to tag (usually with the ACL you created), then you create a policy-map that defines what to do with that traffic. Finally, you apply the policy-map to the interface.

Let’s try one. Let’s say we just put in a new VOIP system and want to tag the packets appropriately. The IP of the system is 10.0.0.10, and you want the gateway on that network to tag the packets as AF41 as they come into it (Google up DSCP if you want to learn about the AF41 thing). What comes first? The ACL…duh!. I like named ACLs, so we’ll create one called VOIP.

ip access-list extended VOIP
permit ip host 10.0.0.10 any

Time for the class-map. All that a class-map is used for is to create a list of values that are interesting to you, but a list can have an or or an and associated it. Basically, do you want to match all the items or just any of them. In our case, we just want to match the ACL we created (a single item), so it’s no big deal, but keep in mind that you can use the match-all or match-any keywords if you want. Here’s the class-map to match our ACL.

class-map match-any MYCLASSMAP
match access-group name VOIP

Next is what we want to do to the traffic, which is tag it to AF41. In the policy-map, you actually reference the class-map you made, so keep that in mind when you’re configuring.

policy-map MYPOLMAP
class MYCLASSMAP
set dscp af41

That says that anything that matches the class-map MYCLASSMAP gets tagged to AF41. Now we have to apply it to the gateway. Assuming that’s F0/0 of your router, give this a shot.

interface F0/0
service-policy input MYPOLMAP

That’s pretty much it. Now, when a packet lands on F0/0 that matches the ACL, it will be tagged as AF41 and sent on. I say again that this just tags packets. If you want to actually prioritize those packets, you have to do more, but I’m too sleepy to get into that right now.

• Leave a comment... (5)