Lengthy questions regarding administering a small-office network, including a Cisco PIX Firewall and Cisco Catalyst switch.

August 9, 2006 11:33 AM

Lengthy questions regarding administering a small-office network, including a Cisco PIX Firewall and Cisco Catalyst switch.

We're making some modifications to a small office network. I do not do this for a living, by any means, and I realize that I am a little over my head, but I am willing to give it a go.

Essentially, what we are doing is chucking the old server and replacing it with a NAS. Now, no one here likes the old network-- the best thing I ever did was set all the workstations to print via IP rather than using the server. Nowadays, no print jobs get lost, and everything usually works. The server sees virtually no use, as nearly everything here (our website, our exchange server, etc) is outsourced.

What I need to do is to tell the routing hardware to give the new printers and NAS static IP addresses.

So, I went about the internet, looking around, and I still haven't figured out how to tell the hardware what I want it to know. I can get to the firewall via my browser at 192.168.1.1. I can get to the switch only by hyperterminal through the DB9 console, and despite some competence with command-line instructions, I can't see any routing information. I can't figure out how to get to the switch via a browser GUI, and I can't tell anything about the current IP routing scheme.

My questions:
1. How do I get to the switch's GUI?
2. Does the firewall somehow make getting to the switch less important?
3. Given your answers in 1 and 2, what do I need to figure out to assign static addresses to the new hardware?

I realize that these questions may be basic, but I am totally flummoxed that I can't get to the switch, and I am wondering if my failure is due to stupidity or design.

posted by trharlan to computers & internet (16 comments total)

Why on earth are you printing directly to printers via IP? That is a really bad idea.

I would question your use of a NAS as well. Usuaully people implement a NAS because it is the cheapest way to get a shared harddrive. Not knowing how big your office is, I would recommend a NAS for a home office. Over 5 users, get a server (linux or Windows SBS).


Question 1
Back to your questions->The catalyst's web interface might be disabled.

telnet (or db9) in and check the running config for:

ip http server

If you do not have that like, add it.

Question 2
Depends on if you want to manage anything on the switch. I would imagine that given your basic networking knowledge, you don't need to be touching the switch at all.

Question 3
Static IP's, or static dhcp leases? The prior, just enter the IP into the device. The latter, setup leases with static ip's in the firewall (if that is doing your DHCP) or on your server (if that is doing DHCP).
posted by SirStan at 12:00 PM on August 9, 2006

The Catalyst web interface doesn't really let you configure much, you are better off (this goes for the PIX as well) to use the Telnet/SSH interface.
posted by SirStan at 12:01 PM on August 9, 2006

Yeah, Catalysts aren't all that smart.

But as long as you know a) what's handing out DHCP addresses on your network and b) how to find out what addresses it is *not* handing out, then you can decide on static addresses for your new filer, et al. You then simply set those on the devices themselves, howmever those devices want you to.

It's possible you should find a local geek, and pay them to do it for you...
posted by baylink at 12:07 PM on August 9, 2006

SirStan--

First, thank you.

Printing over IP has been 100% reliable for months. Printing via the server has not. Now, that may be a good reason to get a better server, but the switch so far has been good. Why is printing over IP such a bad idea?

I already tried your answer to Q1 (should have mentioned that), and I have the like.

As far as Q2, you bring up a fine point. Maybe I don't need to be in there at all, but I still want to know.

For Q3, for the dhcp leases, I suppose I need to poke around some more on the firewall.
posted by trharlan at 12:10 PM on August 9, 2006

baylink-- nice summary, thank you. Paying a local geek is a fine idea, but part of this is a learning experience for me, and part of it is bad experiences with local geeks.
posted by trharlan at 12:11 PM on August 9, 2006

Pedagogy is a good thing, as long as you understand the constraints imposed on you by OJT. :-)

As for IP printing; I rather suspect Stan's complaining that you switched from centrally spooling the jobs to having each workstation spool its own, which does have some drawbacks... *how* the jobs move is likely less important than where they spool.
posted by baylink at 12:24 PM on August 9, 2006

IP Printing -> Well, indeed it does "work", however you have no access control, no way to update client drivers, no way to monitor usage. While it does "work", it is an extremely basic setup. It works if you dont know how to do it through a server.

Q2-> Use telnet if you want to configure anything on your switch (vlans, diags, etc). The web interface is nearly useless.

Go to a Windows desktop (I say that because I know where to find the info on a Windows desktop), start->run->cmd /k ipconfig /all

Look for this line:
DHCP Server . . . . . . . . . . . : 192.168.116.10

That is where you are going to want to set the static lease.

Shoot me an email (see my profile) if you want further assistance with this, or things in general.
posted by SirStan at 12:29 PM on August 9, 2006

Some extra info:

*most likely, in an environment as simple as yours, the switch contains no routing information. The Pix may do all the routing, and even then, there may be very little "visible" info because you only have two or three interfaces (just a guess there). One is a default route to the internet, and the rest of the routing is determined purely by the IP address/subnet mask on your Pix interface(s).

for example, the inside interface may look something like this:

ip address inside 10.1.1.2 255.255.255.0

the Pix already knows to forward any traffic for that network to that network because it has this info defined in the command above.

Run a 'show ip route' (or some minor variation on this), to see the routes.

*to accomplish what you asked above, as SirStan said: assign a new IP address to the new device. This should be an address within the space defined on that interface on the Pix. Then also give that device a default route back to that interface on the Pix. So using the example above you might give that new device an IP on the 10.1.1.x network, it will have a subnet mask of 255.255.255.0, and a gateway of 10.1.1.2

hope some of this helped
posted by poppo at 12:36 PM on August 9, 2006

Firefox ate my first response.

1. As far as gui's go, you may want this. True, the web interfaces are next to useless. Even with that, you're better off learning the CLI, as there are some rather important features either strangely implemented in that, or just flat-out missing. Advice: stay away from their macros, use it to learn by looking at the config after you change stuff, and really, truly, do not rely on it.

2. Depends. I don't know enough about how you have things set up to give any reasonable advice.

3. Assign static leases in your DHCP server to those two devices. That's probably the simplest way.

Now, to get routing info, go into the enabled shell and type "show ip route."

System config, in its entirety: show run

DHCP will either be on the PIX or another server. If you see an ip helper entry, that's your DHCP server. Go set it up. Easiest way is by mac address. If not, happy reading.

I'd argue the "NAS for smaller businesses" and "ip-based printing is bad" statements vehemently.
posted by onedarkride at 2:04 PM on August 9, 2006

Thanks, poppo and onedarkride.

Care to elaborate further on I'd argue the "NAS for smaller businesses" and "ip-based printing is bad" statements vehemently.?
posted by trharlan at 2:12 PM on August 9, 2006

IP-based printing essentially makes every single workstation into a print server. So long as all the print servers play nice together, the configuration works. The disadvantages crop up when something goes wrong. For example, if someone decides to print a 300 page document before going to lunch, you're going to have trouble because there's no central mechanism for pausing or delaying the print job. Without a print server, you can't even (easily) tell who printed it! Furthermore, if someone happens to install the wrong driver, and locks the printer up as a result, all the other servers can't print. Tracking down that one bad driver is a pain. Finally, should you ever want to collect detailed info about your print expenses, you'll really be in trouble. Toner and paper expenses can really add up and it can help with reasonable bugdeting to know what departments are gobbling up the supplies.
posted by elderling at 2:42 PM on August 9, 2006

You've already gotten good answers, but I'll try to rephrase what they're saying... I had a hard time reading some of it. It was correct, but a little confusing.

First, it's unlikely your Catalyst knows anything about IPs except for its own. Switches usually work 'underneath' IP addresses; they are physical Ethernet devices. So you can plug in a Mac and run Appletalk, or a Netware server and run IPX. It all works, because the switch moves data from one computer to another based on their network card addresses, NOT their IPs.

On a local network, if machine A wants to talk to machine B, it first sends out an ARP request "who has 192.168.0.12?" Machine B replies with, "that's me, at MAC address yadayada." Then machine A builds and sends packets directly to machine B over the wire, addressed to the MAC address, not to the IP. The switch sees the initial ARP request and sends it to all ports. When the answer comes back, the switch remembers that MAC address yadayada is on port 12. When machine A starts sending packets, the switch sends them only to machine B's port.

IP is a layer on top of MAC addresses... switches work at Layer 2, where IP is Layer 3. There are 7 layers in the transport model, but generally speaking, only 2 and 3 are actually ever talked about or used.. the higher layers are abstract ideas that aren't clearly implemented anywhere. Layer 2 and Layer 3 are the only things you'll ever care about. Switches work at Layer 2, underneath IP. Dumb switches (ones that can't be network-managed) don't know anything about IP at all, in fact, and they work just fine.

IP matters when you're routing between separate networks. Switches generally do not do that. You CAN get 'Layer 3 switches', which do route, but they're not that common, and a lot more expensive.

So basically, the upshot is that the switch won't care about the IPs at all. Not in the least.

The PIX firewall is a layer 3 device, and may care about the IP, but it's probably set up to just pass through internal traffic and block outside traffic. If you're not trying to reach the NAS from outside, the PIX probably won't care about it at all. As long as the PIX isn't between the NAS and any devices you want to attach, you can pretty much ignore it.

The machines on the network now are getting their IP addresses from somewhere. Either they are statically configured, or you have a DHCP server on your network. Chances are pretty good that the server you hate so much is your DHCP server, and if you pull it out, your network is gonna break. You can find out by going to any Windows machine, opening a command prompt, and typing ipconfig /all at the prompt. Look for a line that says DHCP server. If you see one, figure out which machine has that IP address. If it's the server you want to replace, you're going to need another DHCP server. If it's the PIX, you're fine.

Once you know what range your DHCP server is giving out, give your NAS device a static IP that's outside that range and not taken by anyone else. I like to use the numbers between 10 and 20 for servers. I usually put the router at 1, infrastructure (DNS and DHCP servers) in the 2-10 range, servers at 11+, and put clients at 50+. You just have to be REALLY SURE you're not giving the NAS box the same IP as anyone else. Two machines with the same IP on the network is Bad. You assign the NAS box an IP that's never going to be given out by the DHCP server. Some DHCP servers are smart enough to figure out the conflict, but not all of them are. You can't count on that... put your NAS on an IP you KNOW is safe.

If you don't have a DHCP server, then you'll have to figure out what addresses everyone is using, which is a pain. One way is to visit every computer in the building with a notepad, and make a list. Choose something else for your NAS, add it to the list, and save it for the next person.

If you have access to a Linux box, the network utility nmap makes this very fast:

nmap -sP 192.168.10.0/24

That is a 'ping scan', and it will search the network 192.168.10.0 for up to 255 hosts. (substitute your own network numbers... most likely, leave the /24 on the end, that means to search that whole Class C IP block. [in this case, 192.168.10.1 to 192.168.10.255]).

Look at which numbers are taken, and don't use those. :) Make sure you run the scan when everyone is online.

Elderling summarized the multiple-print-server problem very nicely... if you need to stop a big job, good luck figuring out where it came from. If you're printing through one server, there's just one place to look.
posted by Malor at 4:40 PM on August 9, 2006

IP Printing -> Well, indeed it does "work", however you have no access control, no way to update client drivers, no way to monitor usage. While it does "work", it is an extremely basic setup. It works if you dont know how to do it through a server.

I was correct.

SirStan: you're conflating raw-IP transport to the printer with *where the jobs spool at*. This is confusing; you should probably work to be clearer.

Whether the jobs transport to the printer using TCP/514 (lpr), TCP/9100 ('JetDirect'), or SMB (usually over TCP as well these days, but it *could* be over NetBEUI) is less important than *whether they spool on a centralized print server first*, which, tr, is what SirStan is really on about.

Yes, if you have more than about 4 offices off one hallway, you really do want to be using a centralized print server, so that there's one place to pause and kill jobs going to any given physical printer. What network transport mechanism the jobs use to get from there to the printer is immaterial, really, though if your workstations are running windows, your print server ought to speak to *them* with SMB, so that the status displays and pause controls work.

Samba on Linux will do all of these things for you; what, exactly, *is* your filer; I don't think you've said.
posted by baylink at 6:03 PM on August 9, 2006

IP printing: I've never seen a large network that didn't have a network-attached printer, or more accurately, printers. Printer pools are pretty necessary to avoid the 300 page document hangup.

NAS: Samba shares fall under NAS, but so does this. The solution you implement will be in direct relation to your load and size requirements, but it's almost entirely necessary. I guess you could put shared documents in a wiki, but after trying that, the users at large likes their hive of word documents.

Back to the point, though.. How's your router config going? If you want to either email the configs or post them here, i'm sure that we can all bicker until you have a working set of configs.
posted by onedarkride at 7:35 AM on August 10, 2006

Everyone is awesome. Thanks to all.

The DHCP settings are indeed administered by the PIX, and I found them via the PIX GUI. So, as many of you said, there was no need to get to the switch. I went ahead and made a static range, and I was able to configure to static IPs what needed to be configured.

The server on the network does nothing. As far as the printing via IP, there are approximately 4 users per printer, no one ever prints much of anything, and supply costs are not a concern in this office.

As far as the NAS goes, I opted for the Infrant ReadyNas 600. It seemed to be the most user-friendly machine out there, it has enough storage, it can keep a hot spare, and it can run RAID 5. Because we don't really need enterprise-level stuff, because our old server was unreliable, because printing via IP works fine, because we have our really important stuff backed up on hard copy elsewhere, and because the ReadyNas appears to be a breeze to operate, I think (despite all of the protestations) that the way that we're going makes a lot of sense from a cost/benefit perspective. Of course, keeping the hot spare and running RAID 5 cuts 2TB down to 1TB, but that's totally fine, and more than we need.

Now, I realize that it takes nerve for a novice to walk in here and tell all the network guys that he is ignoring them because he's so sure of himself. But, in the end, none of the benefits that were listed here of using a print server were compelling. I can understand why they would be important in a larger office. Anyway, the ReadyNas has a print server, so maybe I'll implement it if I can see any value in doing so. Of course, if that's a totally stupid idea, I'm sure someone will tell me so.

Thanks again so much, everyone.
posted by trharlan at 8:57 AM on August 10, 2006

Oh, Malor, I used AngryZiber to do the task you mention on our windows network.
posted by trharlan at 8:58 AM on August 10, 2006