I managed to tweak that HP into submission so it worked pretty well on XP Pro; but when a new opportunity came up for an Intel Dual Core 2 processor HP 6910p laptop I jumped at it. A little more weight, but the full size/speed hard drive, the bigger screen, and opportunity to run 64 bit OS’s were more than enough to motivate me.

 The laptop came with Vista, of course. There was a choice between 64 and 32 bit versions. Normally, I wipe all of that off the laptop, repartition and install everything myself from scratch, just the way I want it. But in this case, we don’t have Vista 64, or a volume license - and there are all these little features on the laptop I decided to go ahead and give it a go. Time to jump in and get the feet wet and all of that. What the hell, Vista x64 here we come.

As I expected, I ran into a lot of walls. I’ve spent the past 72 hours fussing about and figured out the following. I may not have it all quite exactly right, but I believe you will find solutions to most Vista issues can be solved by researching around the issues mentioned below.

Most of my issues involve networking and permissions which are fairly different from anything prior. In many ways it seems they have tried to incorporate linux or Mac-like features; but it is such a hybrid atmosphere that it becomes totally non intuitive. I’m constantly second guessing: could this be a Mac type solution, could this be a Linux type solution, is this plain old Windows, or is this some new Vista ‘feature’.

A few things I’ve come across:

1. UAC - user account control: similar to linux or Mac, the logged on user (even one with administrative rights) operates with reduced rights. Access to any settings, features, and many applications must be confirmed by clicking ‘OK’. A great idea in theory, but presents ALL kinds of issues since older management tools were not designed with this in mind. Example: this feature seemed to cause issues opening management tools in an mmc console. I ended up turning it off, which solved a lot of issues. In linux you run as root, and everything underneath (any processes run) runs as root automatically. It works quite well - but this has been a ‘feature’ of Unix/linux forever and so my theory is that it just doesn’t really work in Vista. Not if you’re in a mixed  environment, and who isn’t?

2. Authentication - Vista forces the highest level of authentication which is NTLM v.2 - unfortunately many non Microsoft systems, older Microsoft systems, and XP based shares (even on a domain) do not support it. The result is you can’t access shares or printers on many linux/samba systems or Microsoft workstations. The solution is to edit the local system policy on Vista to fail back to the older authentication methods. This will likely come up as an issue in some of our field offices.

3. Accessing shares on an XP Pro domain workstation required creating a local user on the workstation with the same username - userxyz - as the username I am logged onto my Vista workstation with. This is common in peer to peer environments but not domain environments where you would be prompted for a username and password. Accessing my Windows servers does result in a prompt to authenticate.

4. Exchange 2007 and 2003 management tools are not supported on Vista

5. Cisco does not have a VPN client for Vista x64 and does not plan to release one.

6. Adding Vista to a domain that has GPO’s enabled can result in issues not seen on XP or 2000 workstations. This primarily centers around the LOCAL SERVICE and NETWORK SERVICE accounts on the Vista workstation. If security rights like “adjust memory quotas” or anything related to “process level tokens” are set in GPO, they will defeat the local rights of service accounts on the workstation. The fix is to add these two accounts into your domain group policy objects so they get applied (and there are a number of new entries for Vista)

All in all, I’m not seeing the WHY of Vista, except that it is kind of pretty… One guy described it as a “pig with lipstick” but I won’t go so far. The potential exists for some real security improvements, but mostly I’ve had to defeat all of them to be compatible in my existing environments.

As for x64 - most of my 32bit apps work, with the exception of apps that involve any direct type of hardware/network involvement (here it is 50/50). More apps work on XP-64 than work on Vista-64. There are a number of 64bit solutions for many applications, but it is very spotty. I find the lack of management tools for Microsoft’s flagship Exchange 2007 to be quite puzzling.

Problem: When connected to my internal LAN via VPN client, or through IPSec tunnel I can’t upload FTP files to my internal FTP server. Additionally, when trying to access external FTP servers through my ISA 2006 server, I can not upload.

I scoured my FTP server looking for an issue, when it occured to me I ought to try access from inside the firewall. It worked. Then I searched every access list, cache setting, rule, and property I could think of in ISA 2006.

Finally I found the problem on Tom’s Blog at Lanlogic - Find the rule that applies between your client and the server. This might be the second to last rule, or it might be “allow outbound access to the Internet”. It will be the same rule that sits between you and the FTP server. It probably says “allow all outbound access”. Guess what? It lies.

Right click the rule and LOOK at the drop down, past properties… You will see this. Click the “configure FTP” option. You will see a checked check box that says “Read Only”. Un check it. FTP problem with ISA 2006 solved.

These are the things I love about Microsoft.

Resolution: After some creative Googling,  I find out this is a short-coming (I won’t call it a bug) in a network service called Avahi, which maintains it’s own domain for registering network services: .local - therefore, attempts to resolve host.local never make it to the intended DNS server because the Avahi service is maintaining this local DNS-like zone.

I turned off the Avahi service in Gutsy via System/Administration/Services - disabling “Multicast DNS service Discovery”.

I love simple fixes. http://avahi.org/wiki/AvahiAndUnicastDotLocal

I like to maintain good security practices in my personal as well as my work computing environments. I also enjoy being able to provide myself and the networks I manage with enough security that we are well covered from any reasonable threat, yet not to the point that things become overly complicated to manage or impact the usability of the environment.

I don’t consider myself a security expert. I would not feel comfortable designing a security policy or architecture for a major financial institution doing on line trading and banking. I do feel pretty comfortable with my ability to protect my personal data and networks, and very comfortable that I am part of a team that is focused on increasing security AND usability where I work.

On my personal and work laptops I’ve been running a combination of a popular free software firewall, AVG (free version), and Microsoft Windows Defender. This combination has worked extremely well on my IBM Thinkpad X31, which is not going into it’s fourth year of life with a 1.6 GHz Pentium M and 2 GB of RAM. The combination has provided excellent protection, even though I rarely use my laptops where they aren’t behind some type of hardware firewall already.

On my Intel Core-Duo HP Compaq nc2400, this combination of software - in particular the software firewall - has caused me a bunch of headaches. The issue I’ve had is constant freezing, having to reboot this laptop multiple times per day. The freezes happen whenever anything changes in the status of a network interface. For instance, if I open a vpn connection to my home network. The connection opens, routing table is correct - but there will be a few seconds where my local network applications like Outlook seem to get “confused” and not know where to go. If I wait a few seconds after making the vpn connection, sometimes everything is fine and the traffic for the vpn goes over the vpn and the local traffic goes local. However, more often than not, if there were any network applications open at the time—add or change an interface like this and the laptop freezes and must be hard re-booted.

I want my laptop firewalled at work. Knowing I’m not exposing any ports unintentionally is comforting. Knowing someone who happened to get local admin access can’t remotely browse my computer, connect via DameWare, etc, is a good feeling. Knowing that should some new worm come along and start probing the network, I’ll be immune lightens the load.

I discovered that my software firewall was probably the root of these network issues and freezes by trial and error. I don’t really blame the software firewall since it has worked brilliantly on my personal ThinkPad, and I use VPN connections frequently there too… But when I removed the software, a lot of my issues seemed to resolve themselves. No more holding my breath every-time I had to connect via VPN… I have a hunch part of it might lie in the IDS/Application scanning portion of the firewall software. Disabling those features might make a difference.

This is when the Yoggie caught my eye. It is a Linux based hardware firewall on a USB stick, for Windows only. One of the big marketing points for the device is that you offload the security duties to this Linux USB host computer. The only thing is that whatever you gain in getting rid of your software firewall application, you lose because now you have reduced your full duplex gigabit Ethernet connection down to a half duplex 480Mbps through this USB device. In addition the Yoggie must run a network RNDIS driver on your computer to setup a virtual network interface of sorts which becomes your computer’s firewalled address. This driver also diverts the traffic at layer two from the Ethernet or WiFi into the USB device before it reaches the operating system. It is a significant hit in network speed if you are using Gigabit Ethernet now. You’ll notice it if you do large file transfers, video, etc. The Yoggie GUI and driver aren’t exactly lightweights in cpu and memory usage either.

I first installed the Yoggie at home on my ThinkPad. The install went smoothly. I had done a lot of reading ahead of time and knew exactly what to expect. I allowed all traffic on my home firewall to pass to the laptop and the Yoggie logged and filter several port scan attempts. It seemed to work very well and I was quite pleased. Then I tried to check my mail. I use SSL encryption for IMAP and SMTP connections to my ISP. Yoggie wouldn’t let the SMTP traffic out. I disabled SMTP from the application scanning parts of Yoggie and it began working again. Ok, no big deal. Note that I uninstalled my software firewall prior to installing Yoggie.

The next day I installed it on my work laptop. This is where several days, yes days, of frustration and lost productivity began. The first thing that happened was that I could not connect to the Yoggie’s web console. This is the only way to connect with and configure the Yoggie. There is no telnet or ssh. If the web console isn’t working, you are pretty much out of luck. Yoggie has a tray icon that is green if the Yoggie is connected, Blue if the protection is disabled, and Red if the Yoggie is not connected. The Yoggie driver will disable all network connections if it is not connected.

I had a theory that the issue not connecting to the web console might have something to do with a local vlan we have with the exact same subnet the Yoggie was configured for. It shouldn’t have mattered, but trace routes to the Yoggie’s address were going to the default network gateway, not to the Yoggie device.

I unplugged from the Ethernet and rebooted. I was able to connect to the Yoggie this time around, so I changed Yoggie’s address to a very little used and highly unknown reserved IP segment of 1.0.0.0/29 - this is a perfectly valid address in the networking world, just a little unconventional. I immediately lost contact with the Yoggie after setting it’s address to 1.0.0.1.

I installed the beta driver, and the icon turned green again - showing that the driver and the Yoggie were again seeing each other. The Yoggie driver/network interface that it installs on the PC must have an IP address in the same subnet as the Yoggie. It would not configure itself with an address in the 1.0.0.0/29 subnet.

Once I figured out what was happening, I manually assigned a 1.0.0.2 address to the NDIS Network driver/interface. After rebooting I was able gain access to the console on the 1.0.0.1 address and change it back to a more conventional 172.x.x.x network subnet. I changed the NDIS driver/adapter back to DHCP and rebooted. The adapter picked up a new address in the same subnet as the Yoggie and everything *seemed* back to normal.

I tried opening our help desk ticketing system, it wouldn’t open. I tried opening our sharepoint site, it wouldn’t open. Disabling the HTTP scanning in Yoggie fixed those issues.

One of the most annoying things about Yoggie is the interface. Half the time, it comes up “page not found” for as yet unknown reasons. The interface itself is abstracted and obscures the true operation of the device - presumably to make it an ‘easy’ console for non-IT types. It makes it tremendously difficult to troubleshoot. Unlike other firewall configurations, there is no set of access-lists and hard defined configuration to check, dump, save, restore, etc… You have the ability to open ports to individual IP addresses, but not to a range or an entire subnet. You have very little control over anything else. The Yoggie has it’s own internal rules it follows, making ‘adaptive’ changes as it sees fit. The problem is there is no way to tell what these changes are, or how they might affect your legitimate operations. The firewall rules, which include a white list and blacklist in addition to individual ports are particularly confusing on the first time through.

It is very hard to know if the Yoggie is actually working. You can try a test download of the EICAR test antivirus file. Yoggie will pop up a webpage and say it was blocked. This is the only proof you have, unless you want to set up another machine and port scan yourself to see if Yoggie does anything.

I’m hoping that one more reinstall with the standard driver will get Yoggie working the way it is supposed to.

In theory it is a really handy device and lets me lighten the load on my machine considerably. In reality it has been really buggy and non-intuitive to get running past a default install.

Support has been responsive on one occasion. Of couse they are located in the UK and Israel, and Saturday is the sabbath so I don’t expect to hear anything until Monday.

One thing I’ve found very strange is that: A. their drivers are unsigned, and B. their support website has been overrun with pornographic spam in several places! - and it is several weeks old already. This reflects poorly on a security company.

They also make a Gatekeeper pro, which is a USB hub sized firewall that connects via Ethernet like a standard firewall. It gets power from the USB. You can use it with any OS, as Yoggie Pico is limited to Windows because of the RNDIS driver. The drawback is that it only works on your Ethernet connection.

My advice at this point - don’t bother. I’m a geek. I don’t mind playing around with this or that and usually pick up a little knowledge in the process. But as a solution, it just isn’t quite there yet.

I may end up going back to some version of my software security. We’ll see

- LATEST update: Yoggie came through and I got a brand new Pico PRO in the mail today. Downloaded the latest software and it seeems to be working like a charm. Many thanks to Gil and Ilan at Yoggie support.

- Another update. I have been in almost daily contact with Yoggie support. They’ve decided my unit is defective and given me a local address to return it to. Upon receipt, I’ll be sent a working unit. I’ll update on the new device. For now, my free Comodo firewall is providing ample protection and the extra load on my system has not been noticeable.

Update: I did hear back from Yoggie support on the web console issue. They told me I should be using the beta driver and not the standard driver. They suggested I try physically disconnecting and then reconnecting the Yoggie before I reboot the laptop. I tried that and it didn’t work. I’m still having issues accessing that web console. The AV aspects of Yoggie are pretty much disabled because of the issues mentioned previously - so EICAR simply downloads at which point AVG picks it up. I’ve tested Yoggie pretty extensively port scanning it from external machines on the same subnet. It has been a solid performer in that regard. This is kind of cool, especially on a public wi-fi network. I wish that dang web console wasn’t so buggy - I can’t view the logs or make any changes. I also wish there were some alternate interface like telnet or ssh from the client pc. I also wish there were more options for configuration. As far as the file scanning goes, and disabling those features - no external device is going to give you any virus scanning on an ssl connection anyway. The content is encrypted - so you need a software AV software running that is going to scan that sucker after it gets decrypted and before it gets executed in RAM. Oh yeah - I think the driver is signed now; and I contacted Yoggie support about the porn in their comments fields. It seems to be gone

–Charles Socci

1. Enumerates (or singles out) each drive on the server

2. Determines the free space on those drives

3. Returns the result

This was fairly easy. All it took then was putting in some logic to only show a popup if the space was below a certain level.

Then, it had to be scheduled in Windows Scheduled Tasks to run as me when I am logged on only. (otherwise you won’t see it… and it will require you enter you password.

I have mine scheduled to run every four hours and targets our main database drives, and Exchange for free disk space. If the space is less than 1 GB, the script pops up a Message Box telling me how much free space is left on which drive.

This script currently only works against Windows 2003 servers. When that is ironed out I will post a revision.

Here it is:



‘BEGIN SCRIPT

On Error Resume Next

minfreespace=1000

If WScript.Arguments.Count = 0 Then

Wscript.Echo “Usage: freediskspace.vbs <servername>”

WScript.Quit

End If

For Each strComputer In WScript.Arguments

Set objWMIService = GetObject(”winmgmts:” _

& “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)

Set colDiskDrives = objWMIService.ExecQuery _

(”Select * from Win32_PerfFormattedData_PerfDisk_LogicalDisk where ” _

& “Name <> ‘_Total’”)

For Each objDiskDrive in colDiskDrives

IF objDiskDrive.FreeMegabytes < minfreespace THEN

Wscript.Echo strComputer & ” Drive ” & objDiskDrive.Name & ” Free Space - ” & objDiskDrive.FreeMegabytes & ” MB”

Else ‘ Wscript.Echo objDiskDrive.Name & ” has over 1000 MB free…”

End If

Next

Next

‘END SCRIPT

Enjoy

Charles Socci

This initiative got a little bit of needed push this past summer when a 100 year old steam pipe burst in front of our office building forcing us out, with no access whatsoever to our data center, for two weeks.

DR has always been one of those things that always been emotionally charged, mysterious and frightening to me. It can seem like an unsolvable problem. There are so many challenges. Management and user communities often don’t understand the massive scope of providing a ‘turn-key’, and ’seamless’ ‘fail-over’ solution. A favorite saying of one former boss was that we could ’send men to the moon in 1969, so why can’t we (you) do this…?’

The answer to that question is that, yes we can do this - but how much money and resources would you like to dedicate?

Chances are, that counter question (use tact always) will put things back in perspective. If you are really lucky, the answer will be that this is a major priority and will be supported and funded as well or better than any other technology or business initiative. If not, you will be put in a position of how best to use your budget and resources to accomplish as much of a plan as possible.

I’ve always worked in medium-sized businesses, or nonprofit. In these situations IT staff is typically small, and sysadmin/network admin types tend to become pretty versatile.

You are IT manager or director, have high expectations from users and managements, have not so high funding and resources, and are expected to put together a workable IT disaster plan. Where do you start?

There are essentially two approaches I’ve seen so far. The first involves a great deal of planning, meeting, analysis, consulting and takes a very long time. In the end there may be more questions than answers. The second approach involves starting where you are, with what you have and going from there. The advantage of the second approach is that should something actually happen tomorrow, you at least have something in place. It also gives you the opportunity to actually show management what is and is not capable with your given resources. Planning and analysis aren’t bad things - its just that from a technical standpoint, few people outside IT are going to understand the basic technical challenges. I think starting simple is a great strategy.

Where you will need to do your analysis and planning will be in which services you are going make available during an emergency. Learning to communicate effectively with non-IT management is a big key to success.

Our emergency back in July answered some of these questions for us. When our data center went dark, it became immediately evident what our priorities were. It wasn’t what we necessarily would have thought. Some of the need came up from the field to IT while the senior management had other needs that were coming down from above. Our role became to present these needs and establish a priority. This can be a delicate position for IT since there may be conflicting demands. Our job was to look at the needs, evaluate the requirements needed to fulfill them and present a proposal back to senior management.

We were fortunate that we already had a ‘back-up’ email solution in place. Our email solution is a company that essentially spools our email and then forwards it. In the event we go down, our users can log onto a web site and retrieve their email. It is a little more complex than that, but that is basically how it works.

What we ended up with this summer, was a basic, scalable platform to provide and restore services to our users. It took about a week, but in that time we contracted a co-location facility, purchased some servers, and began providing our users with the most essential services.

A lot of immediate issues came to light. One was that we didn’t have the most current backup tapes, since the pick-up had been missed prior to the emergency. We started with what we had.

We provided access via Citrix. We began with the evaluation licenses, working the other details out later.

The resources were on the light side. But, the point is that we got something going in an extremely short period of time. Something is always better than nothing in a situation like this. You can always add on, add space, and expand.

Since this summer, we have moved forward and will be adding an ESX environment as well as replication to our co-lo facility. We are already doing daily SQL dumps off-site.

The primary technical challenge will always be bandwidth. Unless you have a massive pipe between your primary and co-location facilities you will have to make some decisions as to what you can effectively replicate on a real-time basis. The other consideration is that your emergency resources need to be powered, cooled, and secured just like your production resources.

Vendors will try and sell you products, many of which work very well, to do data replication and/or fail-over. The issue is that you simply can not pass more data over your pipe in a given period than data that changes during that given period. If you are using a T1 at your primary and co-lo sites, that T1 not only must provide your normal daily bandwidth requirement, you are now attempting to squeeze all your daily data deltas (or differences/differentials/incrementals) over the pipe. A T1 translates to about 1.5 million bits per second. In actuality, after the overhead of TCP/IP and latency you will be doing well to see 900-1000 Kbps of actual real-time bandwidth. These are BITS not BYTES. We typically measure our data sizes in BYTES. So in the best case, our 1000 Kilobits per second, at eight bits per byte, is 125 Kilobytes per second, 450 MB per hour or about 11 GB per day.

If you have 100 users, that is about 110MB of total data per user per day. This does not include your current bandwidth usage such as email, internet surfing, or anything else you use your Internet connection for. Replication software typically provides some compression, or the ability to replicate data blocks instead of entire files, but you can see the challenges. Most of us will find our connectivity will be the ultimate deciding factor in what we can and can not replicate in real time off site. If the vendor tells you that you can queue your replication for less busy times of day, or ‘drip’ the data, or whatever - just remember this simple math. You can not put more data over the wire per day than it will accept.

One of the things that makes IP based SAN so compelling is the ability to mirror data at block level, and support technologies like virtual computing that make our lives so much better. But, it is expensive.

That’s about it. Don’t be overwhelmed. Start with what you’ve got. Don’t forget that your emergency resources need to be powered, cooled, and secured just like your production resources do. Do the best you can with it and present the results with pride and an attitude of how much more could be done if you had that fat pipe and big SAN.

Photo by Charles Socci - Crews repair steam pipe rupture at 41st Street and Lexington Avenue, New York City July 2007

I joined the company in May ‘06, my boss had been there a few months, and the CTO had been there about a year. Neither of them are still with the company and as the network administrator, the ESX infrastructure has fallen into my hands - as my boss had more or less taken the lion’s share of responsibility and planning during the procurement and configuration phases. I’m quite familiar with the day to day tasks of deploying a VM, etc… But the bigger picture has been a little fuzzy.

My new boss and the new CTO have been pretty great to work with; and supported my desire to attend VMWare sponsored training on ESX this past week downtown at the MicroTek facility on Broad Street in the Financial District.

The training was pretty good. Each student (there were about fifteen or twenty) had their own pc, and we used Citrix to access VMWare’s educational environment where teams of two shared one remote ESX server (DL380). When we got to the Clustering/VMotion/HA part we combined into teams of four with two students managing each ESX host. We covered everything from installing to troubleshooting. Quite a bit of material for four eight hour days. The tough thing is that truly understanding everything about ESX means you already have a grasp of Windows administration, Active Directory, SAN architectures, networking, etc… So for instance, if you’ve never touched a SAN, the whole concept of VMotion or presenting LUNS to a host isn’t going to make much sense - neither are iSCSI software vs hardware based initiators, or HBA’s, vLans, etc, etc… The weakest link for me is understanding our SAN architecture. I’m getting a handle on it; and we are hoping to get Dell in to give us a technical overview of managing it, creating and presenting LUNS to hosts. We’ve got two additional matching Dell 2950’s we want to add to the existing two ESX hosts. We need additional licenses for the ports on the fiber switch. Once the proper LUNS have been made available to the new hosts I’ll be able to set them up into the existing cluster with no problem.

I’ve been doing a lot of experimenting with the free version of VMWare Server at home. This has been alot of fun. We had a very simple network at home, cable internet, a wi-fi cable/dsl router, and that was it. I built an internal LAN and made the wi-fi LAN a DMZ that is isolated from our internal LAN. My vpn device is simply an old Dell Dimension T500 with some extra RAM and dual NICs, running Win2K3 server and RRAS… on the inside sits my workstation, my wife’s workstation, and my single server/dc running Win2k3. This is an old AMD Athlon 1.2 GHz maxed out with 1.5 GB of RAM.

I bought an old Compaq SDLT drive on EBay for $165, put a SCSI card in and installed backup software. I installed VMWare server for Windows and put two VMWare guests (two Windows XP workstations and a Linux workstation) and was running my server/dc/dns and backup on the host. It kept occurring to me that maybe there was a better way to do this - so I cloned the server to a VM, installed Ubuntu Linux server with minimal options, installed VMWare server for Linux, and then ran my guests, plus the original server in VM’s on the Linux host.

I was able to map the SCSI interface and tape drive through to the VM guest server. Everything worked ok, but for some reason I could not get the same performance out of this arrangement that I had gotten out of the Windows based host which totally suprised me. Even disabling the server and trying various combinations of RAM and reservations for the host, there just didn’t seem to be enough CPU cycles to go around and everything ran at a snail’s pace. When I went back to Windows again, everything just seemed to work better. This was a disappointment because managing the Linux server felt so much more like managing an ESX environment. Its also really cool to use a tool like Putty to go in and some basic sysadmin stuff instead of waiting for an RDP session, open multiple windows, waiting, clicking, waiting, etc, etc, etc…

My wife’s workstation is actually an old Compaq notebook that was originally NT 4, upgraded to 2000 Pro. Its been acting a little funky lately, but she has all our banking software on it and some other stuff. (yes, we back it up). So I made a VM out of it, thus taking any hardware issues completely out of the picture. I was able to give the VM a lot more free disk space, and upgrade it to XP. So now my wife can use the VM instead of the notebook which has more resources and isn’t dependent on an old piece of hardware, slow drive and memory, etc… Such a powerful tool.

Maybe I’ll see if my wife will let me pick up some supported hardware off EBay to build an ESX server at home

Let’s assume that you already know how to log into the device and have the necessary passwords to get you into Enable mode to configure your Cisco IOS device.

 Perhaps the first and most basic command is simply: show run - which will display the running configuration on the device.

Backup Your Cisco Device

To backup your configuration before you start, download and start-up a free tftp software on your workstation (solarwinds is great). Install and run. Note the default directory. 

On your Cisco device type the following command:

copy startup-config tftp:<ip address of your workstation running tftp software>

Editing Extended Access Lists

Here is one that really threw me for a loop when I started digging into a very lengthy firewall configuration on a Cisco device. There was a very long extended access list, which is really just a normal access-list except this one had a few hundred lines. If you tried to edit the access-list directly, it would wipe out all those lines! And, wouldn’t you know the first time I touched that firewall, I did just that! Thank goodness for not saving changes and being able to reboot the firewall to the old config. NEVER SAVE YOUR CHANGES UNTIL YOU HAVE VERIFIED THEY WORK! Once confident your changes are good, type write mem to save them. Remember to always back anything you work on up before you modify it.

To edit an extened access-list, you need to know what the line numbers are underneath it. If you have an extended access list 21, type show access-list 21. This will display all the line numbers contained in access list 21. (Note, these line numbers get re-numbered automatically by the Cisco IOS). Find the line number you want to edit. Let’s say it is 13.

From config mode type: ip access-list extended 21

(config)# ip access-list extended 21

This will bring you into a new config mode for extended access lists:

(config-ext-nacl)#

To remove a line, just type no and the line number:

(config-ext-nacl)# no 13

To add a line, type a new line number and the command for that line:

(config-ext-nacl)# 14 permit tcp any host 10.10.10.1 eq www

Modifying Interfaces

One of the most common things I’ve ever needed to modify are individual ports on a switch - usually to change the Vlan, or perhaps change the speed or duplex settings manually.

Type config terminal (or config t) to get into config mode.

Type Interface and the name of the interface (you can see the name of the interface from the show run command or show interface command. It might be something like FastEthernet 0 port 3 or GigabitEthernet 1 port 11

Type:

(config)# interface FastEthernet0/3 (or for short type Fa0/3)

This will bring you into (config-if)# mode.

If you are configuring a range of ports, you could do this from config mode:

(config)# interface range FastEthernet0/0 – 10

Other commands you can use at the (config-if)# mode prompt are:

no shutdown - this will turn the interface on, which by default is turned off.

You can also ‘reset’ or ‘bounce’ the port by using the shutdown command followed by the no shutdown command if you are having some type of issue with that port.

You can give the port an IP address:

ip address 10.10.10.1 255.255.255.0

Or you can tell it to use DHCP:

ip address dhcp

As with any Cisco command, you can type a ? after it to see all the available commands.

You can add a description, which is always helpful:

(config-if)# description This port is for the IT vlan

Or perhaps:

 (config-if)# description ISP WAN interface. For support call 800 555 1234 contract number xyz123

You can use the speed and duplex commands to configure the speed and duplex settings of the interface:

 (config-if)# speed 100

 (config-if)# duplex full

The switchport command allows you to put a port into a certain vlan:

 (config-if)# switchport access vlan 10 (this would make the port available on vlan 10 as long as trunking is configured to support vlan 10 on the switch)

Throughout my career in IT I’ve often wished for a formal account, a log book of sorts, of various problems and solutions I’ve come across.

The online blog seemed like a perfect format to document and share this information.

Thanks for coming and please return to contribute or take advantage of what I hope will be some helpful information.

Cheers -

Charles Socci 19 August, 2007