Archive for the ‘cli’ tag
ISCW Notes – Role-based Views
I’m at training for the ISCW test this week, and this topic came up yesterday. Since it came up last week at the office, I figure it was a sign from $deity that it was time for a blog entry.
An admin in another business unit was trying to set up command access for some of his techs. He was going through a couple of routers and assigning commands to privilege levels so that his techs could access them. He was having a boat load of problems, though, and couldn’t get it to work
He was trying to allow his guys to run a show ip route, but they also wanted to run show ip route x.x.x.x. He was assigning commands to privilege level 7 then giving his tech’s user accounts the same privilege.
Router(config)#privilege exec all level 7 show ip route Router(config)#username user1 privilege 7 secret his.password
For some reason, this wasn’t working, though. The user could log into the router, but they couldn’t get authorized to run the subcommands as expected. I blamed it on his non-standard 7600 running a non-standard IOS version (sorry, I can’t give any more detail without revealing too much about the company), but I came across a much easier way to do it today in class with role-based views.
A view is a set of commands that can be assigned to users, and, to give a user access to those commands, you make them a member of that view. You’ll see that in a second. You also have a superview, which is a set of views, so a user can be a member of multiple views.
There are some prerequisites to using views. First of all, you have to have the enable secret set. You should already have that on a production router, but, if you’re working in a lab or something, you may have issues. You also need to have AAA enabled. That’s beyond the scope here, but I’m sure you can figure it out.
To configure a view, you must first be in the root view. How do you do that? Just enable to it.
Router#enable view
You’ll enter the enable secret, and nothing special will happen, but now you can use the parser view command to create a new view. This takes you into the view submode which is where you list what commands you want to let users run. You also set a secret (password) so you can call up the view later.
Let’s create a view called “TechView” for my guy. We’ll give members of that view access to the “show ip route” commands to include all the subcommands. We’ll put the user “tech1″ in that view, too.
Router(config)#parser view TechView Router(config-view)#secret view.pass Router(config-view)#command exec include all show ip route Router(config)#username tech1 view TechView secret tech.pass
Every time that “tech1″ logs in, that user will have access to all the show ip route commands. If you have a user who is not in that view but wants access to it, they can run the enable view TechView command and enter the secret. On the console, you’ll see a message saying that user has switched to the view. If the user does a show parser view, they can see what view they’re in.
Router#enable view TechView Password: Router# *Mar 1 00:09:04.047: %PARSER-6-VIEW_SWITCH: successfully set to view 'TechView'. Router#sh parser view Current view is 'TechView'
Send any test vouchers questions my way.
Using SSH to Run Commands on a Router or Switch
SSH is more than just a shell. You can copy files from and to a server or piece of network gear with it. You can use it to tunnel traffic. Possibly my favorite, though, is to use SSH to run a command on a remote box without interacting with a shell.
One of my biggest pet peeves with IOS (or pretty much any Cisco OS) is the lack of complex filtering. Let’s say I want to look at all the downed ports and interfaces on modules 3 and 6 of my 6509. I can’t easily do that with command from the IOS, but, on my Linux box, I can use multiple grep commands to get exactly what I want really easily. Let’s work through the example, shall we?
To start with, let’s just do a show ip int brief without getting a shell on the switch.
ssh my.switch.com "show ip int brief"
When you run this and give your password, you see the output we’ve all learned to love, and, now that you’ve got it in STDOUT on your Linux box, you can start filtering. Now, let’s use grep to find the downed ports and interfaces on modules 3 and 6.
ssh my.switch.com "show ip int brief" | grep down | grep Ethernet[36]
How about downed ports and interfaces on modules 3 and 6 that not administratively down?
ssh my.switch.com "show ip int brief" | grep down | grep Ethernet[36] | grep -v admin
I’ll stop there, but it can go on and on. Read up on regular expression and/or grep if you don’t know what we’re doing here.
What’s really happening is that we’re taking the output of the command “ssh ….” and piping it (with |) to the command grep. We can send it to whatever command we want, though, so don’t be shy. I’ve actually written several scripts that take output of commands like show int description on a router to generate some reports. When I want to run one of those, I do something like this.
ssh my.switch.com "show int desc" | parseOutput.pl
There’s always a gotcha or two to watch for, isn’t there? I’ve found a couple.
First, your command runs at your privilege level, so, if your user is priv 1, you’re not going to be able to do a show run or reload. You could just ignore security for a bit and set your privilege to 15, but I don’t recommend doing anything like that. Before you say it, you’ll probably have a hard time with enabling as well. You can only run one command at a time, so you would just enable yourself and get kicked off. Not very helpful.
Another problem I see is the lack of public/private key pair support on Cisco devices. On a Linux box, you can copy your keys around, and those are presented in lieu of a password. Since (most) Cisco devices don’t have home directories, there’s no place to drop the keys, and we’re left with just using passwords. Support for this would be nice, but the security problems associated with keep SSH keys and user home directories are probably too much to even think about.
What else? Oh, yeah. The PIX/FWSM/ASA family supports SSH, but it acts differently from the IOS guys. When you run a command through SSH, you actually get an interactive shell with the command already on the CLI for you. This is probably by design; the only thing you can really do from a non-priv prompt is to enable.
Anyway, send any grilling tips questions my way.
Using the Pipe in IOS
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.
Common Cisco IOS Commands
Here’s a list of IOS commands that I use all the time that aren’t a part of the basics. I obviously use more than just these, and you do, too, but I hope there’s at least one eye-opener in there.
show env all: Shows the environment status, including fan, power supplies, etc. Good for making sure the environment is alright.
show history: Shows your command history since you logged onto the device. Good for remembering what command you put into get those stats the boss needs. Configuration changes don’t show up here.
show inventory: Shows a nice list of what the device has hardware-wise. It’s good for a router with a bunch of modules or a switch with a bunch of cards.
show interface trunk: Shows all the trunks on a switch along with pruning information. Good for making sure all VLANs are propagating around the network.
show interface capabilities: Shows what the interface is capable of doing — not just what’s its configured to do.
show interface counters: Shows byte and packet information for every interface. Good for quickly showing statistics without having to look at all the show interface garbage.
show mac-address-table: Shows the CAM table on a switch. Good for tracking down where a host is plugged into.
show tcp brief: Shows all TCP connections associated with the device like SSH sessions or BGP.
show users: Shows who’s logged onto the device. Good for finding a line to clear to kick everyone off the box.