Managing Cisco Devices with ASDM and SDM



	Managing Cisco Devices with ASDM and SDM

	Peter J. Welcher

Introduction

Hello again! I've been working on a course development project, with some rather long hours due to a very tight deadline. Part of the course goes into the Cisco Router and Security Device Manager (SDM), and another part looks at Adaptive Security Device Manager (ASDM). Of course, that means these look like good topics for an article.

I wrote about those about 18 months ago. It does seem timely to do a quick update on them.

I've been working with the latest versions, which show some solid improvements. One of the things I've been noticing is that the NAT, VPN, and Firewall Wizards do some safety checking. Don't you just hate it when you don't think of something and end up cutting off your VPN access into a remote router? Well, they've made it harder to "shoot yourself in the foot" with these tools.

SDM 2.1.2 is the latest version of SDM. I wrote about SDM 1.1 in March 2004, see also http://www.netcraftsmen.net/welcher/papers/sdm.html. SDM, is available now for the router series 850, 870, 1800, 2800, 3800 (Integrated Services Routers -- ISR's). It is also available and usable in some of the other models. It is orderable as a factory-installed option.

ASDM 5.0(2) is the successor to PIX Device Manager (PDM). I wrote about PDM in February 2004, see also http://www.netcraftsmen.net/welcher/papers/pdm.html. ASDM is for some of the PIX models, and for the new integrated ASA devices.

There are now some substantial user interface similarities between the two tools. For screen shots and so on, we will focus on ASDM here.

There are a nice set of tutorial graphical documents ("technical references") online showing various uses of SDM. The main URL for this: http://www.cisco.com/en/US/products/sw/secursw/ps5318/prod_technical_reference_list.html. This is a great place to look if you want screen captures of SDM, or some idea of what it can do and how to use it in various settings. This is also why I'm not going to post a PDF of a wide variety of SDM or ASDM screen captures this time around. It has already been done for us!

Versions and Pre-Requisites

Rather than reproduce the lengthy information about platforms and Cisco IOS versions, I'll refer you to the authoritative data.

Document	URL
SDM main page	http://www.cisco.com/en/US/products/sw/secursw/ps5318/
SDM data sheet	http://www.cisco.com/en/US/products/sw/secursw/ps5318/products_data_sheet0900aecd800fd118.html
ASDM main page	http://www.cisco.com/en/US/products/ps6121/index.html
ASDM data sheet	http://www.cisco.com/en/US/products/ps6121/products_data_sheet09186a008014871d.html

Do note that ASDM 5.0 requires PIX OS 7.0 or later, which is a significant (but useful) transition. We're not going to go into PIX 7.0 here, but realize there are many new features and changes in 7.0.

Installing and Enabling ASDM

If you already have a PIX or ASA running 7.0, but lack ASDM, installation is fairly easy. Download the code, copy to flash. You will then need to briefly RTFM (Read The Fine Manual) for the configuration commands. These amount to turning on the ASDM web server in the PIX, and allowing HTTPS access to specific address(es). You may need to identify the binary file name for ASDM in flash as well.

Suppose your management group is on subnet 10.10.10.0 /24. Command syntax:

http server enable
http 10.10.10.0 255.255.255.0 inside
asdm image flash:asdm502.bin

If the PIX or ASA is configured, you will then need routing and network connectivity from your PC in the 10.10.10.0 /24 subnet to the PIX

So Show Me ASDM Already!

When you launch ASDM, you'll need to point your browser at the inside of the PIX or ASA device, using HTTPS. You should then see the following screen:

ASDM opening screen

When you then click, accept certificates, and log in, you will arrive at the Home page. It shows current state of the security device. You can click on the License tab to check the licensing information for the device. (No, you can't see mine!) The Home page is intended as a dashboard for keeping an eye on basic operation of the device.

ASDM home page

You may have noticed the nifty graphs at the bottom showing CPU, RAM memory, connections per second, and selected interface I/O in Kbps. When syslog is enabled, messages show up in the bottom area of this window. The "built" and "teardown" messages show the stateful firewall activity.

Click on the Configuration button to switch to configuration mode. The icons or buttons down the left side are the various major things you can configure. Our next screen capture shows the Interfaces configuration screen.

You may click on any interface and configure it via the Edit button at the right. (I suspect you can figure out for yourself what Add and Delete do.)

ASDM's Security Policy configuration allows you to view, enable or disable the default policy, allowing traffic from more to less secure interfaces. You can also add, edit, or delete your own ACL rules via a colorful and informative GUI screen. The highlighted rule is an example of such.

I found this tool quite usable. I do have to mention two minor surprises. The first was that the ACL rule name is not visible, but sequence numbers are. The reason is that the rule names default, e.g. outside_access_out. The second one is also a CLI gotcha I just had not run into. If you create an ACL rule, then uncheck it to disable it, you still have an access list, with an entry flagged as inactive. Well, if you think about it, that ACL must end with the default deny any. And that's what bit me briefly in some testing. I was thinking "gee, I disabled the rule, so why is my traffic getting blocked". Displaying the implicit deny any might have been something the programmers could have done as a reminder of this. With all the CLI typing, I'd never used the inactive option in a PIX ACL rule. With the GUI, this option is much easier to use.

You should note the Apply button at the bottom. Until you apply changes, nothing is done to the security device. One of the preference options is to let you preview the configuration changes, and Send or Cancel. You may want to stay away from the Alt key. While doing screen captures, I noticed that doing Fn+Alt+ScreenCap was apparently interpreted as the same as clicking on Send.

One more configuration mode screen. When you click on Routing, you see the routing options with PIX 7.0. Static routes, RIP, and quite a bit of OSPF, including redistribution and summary addresses. So ASDM gives a lot of routing configuration assistance in its GUI. SDM is a bit more basic than that in the routing arena. But once it catches up, most of the more routine and even moderately advanced routing features will be configurable via GUI.

ASDM routing configuration

The real power of ASDM lies in the areas of NAT, also VPN. There is also a VPN Wizard, accessible through the menus at the top. Just to give the flavor of the VPN screens:

ASDM VPN screen

This lets you configure all the VPN policies via GUI. Much less work than typing. The VPN Wizard makes VPN tunnel setup much easier and less confusing for beginners.

In case you were wondering, ASDM also provides two screens for more routine administration of the PIX or ASA device. Device Administration is the fairly obvious place to start. The next frame over shows all of the items that may be configured through ASDM. I had clicked on Telnet, to allow telnet access from 10.20.3.0 /24. The ASDM/HTTPS and Secure Shell screens serve a similar purpose.

The Properties button allows you to set up more of the security device configuration (AAA servers, anti-spoofing, DHCP services, DNS client, IP audit, logging, and many other features).

The final major mode in ASDM is the Monitoring mode. Click the Monitoring button to enter this mode. Down the left side of the screen (below) you will see the various areas you can monitor. You get a mix of screens showing status, and graphs. We clicked on CPU under System Graphs. We then clicked the one visible item, and Add, then Show Graphs.

That brought up the following graph. SImilar graphs are available for many things, ranging from interface utilization to VPN connections.

ASDM, sample graph

That's all we have room to show. I do hope you've found this useful and informative. My reaction after driving SDM in particular was that it was much improved. In particular, I had found VPN setup a bit of a twisty little maze of passages before. Confusing. The most recent version of SDM makes it much more of a breeze, with good built-in defaults. Easy VPN Server or Easy VPN Remote setup makes it even easier. Put in the address to connect to, shared key, identify outside interface, and that's pretty much it!

Folks that know me have heard me saying to use CiscoWorks, because it is a power tool. I still feel that's true for networks with more than 5-10 devices. But SDM and ASDM are a different kind of power tool. They are directed at, and quite useful for, configuring a single device. With the built-in VPN test and troubleshooting in SDM, there's good advice and a fair degree of intelligence behind the pretty GUI.

I see a real shift happening here. These tools do significantly lower the training and knowledge threshold. With them, you may be able to get a Cisco device up and running a lot more easily. But it's more than that. The tools are quite easy to use. When I used the tools 18 months ago, I found myself fighting them a bit. Now the workflow seems natural. With all the Wizards in SDM (more than ASDM), and with the built-in troubleshooting, these tools have grown up and are showing some real potential. They already dramatically lower the barriers to getting started in the Cisco world. Now you need some idea what you're doing in terms of routing, NAT, VPN, etc. But you only need minimal CLI knowledge if you work with SDM or ASDM, and that is quite a big change!

Would I only use the GUI? Well, I know the Cisco CLI quite well. So maybe I tend to lean that way. For multi-site VPN deployment, I'd probably build a template, then edit it to configure new sites. The difference now is, I might use ASDM or SDM to configure the central site and one remote site, and then take my template from them. Even though I know IPsec from the CLI, it is faster and more likely to be right the first time using the GUI.

Reader Participation Item

Last month I opened a reader participation thread, one I'd appreciate your (brief!) thoughts and email on. I'm looking for ideas that fit the title "Surprise: Top 10 (or 20) Things That Defeat or Disable CEF". This might also be described as "How to Make a Catalyst 6500/7600 Unhappy". Thanks to those that responded.

For example:

Using a packet or QoS classification ACL with "log" in it
Large packets sent out a GRE tunnel needing fragmentation and being process switched because of that
Had to disable CEF due to bug with WCCP (the surprise was the bug, not that CEF was off)
QoS NBAR configuration causing process switching (at least Cisco IOS apparently put out a syslog message warning about this)

What other things disable CEF? I'm particularly interested in those that most surprised you. Gotcha! Bragging rights go to the "best" entry.

To encourage participation, I've got another Gotcha topic this month. "Things that configure via GUI and don't show up in the running config." (That certainly violates my expectations that EVERYTHING running in the router shows up in the running config.) There are two cases of this I know of to date:

If you configurate SAA (now IP SLA) via CiscoWorks IPM, the rtr commands don't show up in the running config. They do show up when you do "show rtr" commands.
SDM supports IOS-based IPS in the ISR routers. The IPS component documentation specifically states that the documented IPS CLI commands are quietly ignored, and that all configuration must be done via the GUI.

By the way, the motivation for the first and possibly the second of these is apparently so that NOC or Security staff can enable or change a feature without tipping off the Change Control Police. On the other hand, if my router is running high CPU, the first thing I want to do is compare the running config to see what might have changed, not play guessing games with show commands or GUI. Am I right that this is a Really, Really Bad Idea(TM) and that the Cisco engineers need to stop doing it? Or add a "show run" variant that shows such commands too? What are your thoughts? Any more examples of this?

Anyway, please do email me if you have ideas on these. I'll collect answers for a month or two, then publish any new ideas. Thanks!

Summary

Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has ten CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net (formatted this way to fool email harvesting software).