I didn't see if you mentioned this, but are you at least getting link lights on the switch port and on the server's NIC?

If you are getting link lights, then I would go back and re-address the possibility of it being a VLAN issue, since from what you've described it sounds like you are using VLANS on this switch.

Sorry that didn't work, Karen; this just keeps getting better and better...

That's troubling; they should be getting applied right then and there. "route" won't create what it sees as an impossible route, so if the right interface(s) aren't up, they're not gonna happen.

This doesn't sound so much like a security issue, though it could be; it could just as easily be a bad cable, bad port, or something like that, too... I think that was sort of where alienux was heading with this too; you're absolutely certain that you've got a physical connection, and that this isn't a VLAN issue?

If this were me, I think I would put another computer that I knew worked on that same port; assuming that it worked, I would go through and change its settings to the ones you're planning on using, and see what happens...

Please, as you discover what's going on, post what you're finding out back up here; this is a good one...

- Larry

Yes, I am getting link lights and the MAC address shows up on the switch.

Where does the rc.local get executed in the startup? Does it not apply the static routes if the network isn't available when it tries to do it? I didn't think that would matter, so I would expect to see the static routes in the netstat -rn.

Hi, Karen -

rc.local is started by rc.sysinit, which runs it (rc.local) after it's done with everything else. rc.sysinit is started by inittab, which is read by init and used as the system changes runlevels.

The two other files that come into play a lot are /etc/profile and /etc/bashrc; when bash is started as a login shell, /etc/profile runs your bash profile (~/.bash_profile) and your bashrc (~/.bashrc), then /etc/profile. There may also be files (names and contents vary) in /etc/profile.d that are executed as the shell's environment is initializing. csh (tcsh) has its own, similar, way of doing the same thing.

As far as the routes go, and as to why you're not seeing them in the netstat you did - basically, you'll see the routes in netstat if the system can create them; if what they depend upon doesn't exist, and route determines that they're impossible, then their creation will fail. If they had been created and were there, you would see them.

I still think it's got something to do - directly or indirectly - with the fact that you've got a class A address (10.b.c.d) and a class C subnet mask; I think you're ultimately going to find there's a class C address that's supposed to be getting created - somewhere - which is your ticket onto your router / switch. I could be wrong, though.

Since you have a link, and at least some communication (if the switch can read your MAC address, you have two-way communication, right? Maybe simplifying things a little might help; try something like configure that part of the router / switch / etc. you're using so it's not using VLAN, etc. (so that it's just a basic gateway), then bring up an interface, configure it, verify that you have connectivity... then, go back and add in whatever you had to comment out?

I don't really know what else to suggest that you try... I'll certainly keep my fingers crossed, for whatever good that'll do.

- Larry

Well, after all the head banging and grief, the problem was that it was in the wrong VLAN on the switch. Now, as far as I was concerned, the VLAN was correct, but I found out that I was given the wrong VLAN. After changing the port, the machine was properly accessible.

Thank you all for your suggestions and support. I learned a lot more about Linux from the experience.

Hi, Karen -

For whatever it's worth, I had faith that you would ultimately figure out. I'm glad you did; it was certainly a real gem of a problem. There aren't many things I can think of that are worse than being given bad info, relying on it, and, as a result, watching your own deliverables slip.

Just my opinion, but I think the way you thought the whole thing through, and stuck with it, was commendable.

Ah; isn't that always the case? It certainly seems like things never progress "the easy way", and that it's only through late night and weekend "this darn thing should've worked by now", uh, "study sessions", that I've ended up learning much of anything that's been worth learning. I think that's in part because no sane person would have bothered to delve into some of the more arcane aspects of the O/S unless they had some sort of pressing need to...

At any rate, I'm glad you're up and running, and wish you all the best in both this and in your future endeavors.

- Larry