Weirdness solved; A dumb request.

Solved the networking weirdness that had befallen some of our servers since upgrading our networking infrastructure. We'd implemented HP's LACP solution,understanding that it would work with the HP server NIC teaming thing to give us a really high-speed, fully teamed solution. Apparently not, for some reason. The 802.whatever that the NICs would have been picking up automatically - the team type being set to auto - just doesn't seem to work reliably.

So I broke the teams on the problem boxes, then set the trunk type on the switch to "trunk" instead of LACP - you can trunk two different ports on two different cards within the chassis, giving you redundancy - then recreated the teams to NLB with Fault Tolerance, then unchecked the TCP onloading box, which seems, from reading around, to be giving loads of people shit. It's apparently corrected in the latest NIC drivers, but just to be sure, you know. Problem gone, performance not quite as good, theoretically, but there's so many other throttles right now I can't tell. So that's good.

What's not good, however, is a reputable database provider asking us to add an entire class B network to our firewall ACL, then another class C network. That's right. Dear gullible fool, please open 65000+ addresses to your ACL list. The reply was neccesarily short and to the point, as you'd expect...

Fun and games, Google and Novell's different Wednesdays.

Trying to sort the routing this morning for the new exchange server, with the help of our friendly local firewall guy. I've never learned any PIX, and on the evidence of this morning I think I probably got the good end of the deal there. It's a bit of fun, eh? Anyway, the upshot is it's sorted now, and I've learned a valuable lesson: When you make a change to your firewall - TAKE OUT THE REDUNDANT ENTRIES. This will then save the time and sanity of your replacement as he tries to reverse engineer the inner machinations of your DMZ (tell me you have one of those) via IP addresses which may or may not either be: a) still be in use b) assigned to a different machine or best of all and my personal favourite; c) assigned to a machine of the same name which has since been rebuilt and now has a completely different function. And you can add comments on PIX entries too, so take a second and put 'em in. The lifespan of networking equipment is considerably longer than the tenure of the average IT worker, so I'm sure karma will come into this somewhere down the track.

Google, I see, are writing off $768 million, due to the decline, fall, and plummet from space of AOL. They want out completely, and I think the only thing they can be blamed for there is taking too long to bite the bullet. The sooner the excresence that was America Online gets wiped from the face of the earth, the better.

Novell would probably like to be able to afford to write off something else other than another tranche of workers, but they can't. Be nice if the job losses could stop now, please.

A weird one...

I've got one of those weird ones today. We've installed a new network infrastructure - all shiny new HP Procurve stuff. Yesterday morning, one of our servers didn't back up, with BackupExec reporting that it couldn't see it. RDP'd to the server fine, and I could ping the backup server, and ping the errant server from the backup server. I could also, from either server, open an UNC share on ANOTHER server but not on each other. They're both on the same subnet, plugged directly into the new core switch, the ports on which are effectively, at the moment, wide open.

This morning, another server had the same problem, despite backing up yesterday. The error logs on the servers which can't connect have the odd DCOM error which, on closer investigation, could mean one of about forty different things, none of which look like an easy fix. It's all too easy to go off on some wild goose chase here. The core switch is new, so there's a cloud hanging over that, but I had something similar before it was replaced, which I didn't investigate too deeply as it was only a day before the new switch went in. One things for sure - something out there is screwing up my NetBIOS traffic, and I want to know what it is.

A day of deep joy...

How I love sysadmining while surrounded by morons. Today's a prime example. We have an accountancy application which is, like most of these things, just about OK when used in the environment which it was designed for. Local domain, fat client, normal, networked printer. Even then, it's needed a fair bit of tweaking to get it right - it prints from an environment variable, for example, because thats the way it does it. It's one of them.

Someone tried to put it on citrix and we had a nightmare with it. We couldn't get it to print properly at all, despite the application vendor's being on site for a couple of days and dialling in god knows how many times. So I made sure that the people who needed to use it got full-fat clients, quick sharp. Everyone happy.

Except some genius has decided that it would be just too great for someone at a related institute across town to be able to dial into our accounting application through citrix. And our interface to the outside world, I might add, is rubbish. Not in terms of speed, but reliability of service of certain things. We have other people who connect through citrix, for example. Sometimes their printer auto-creation works, sometimes it doesn't. Depends on the wind. Sometimes it takes five minutes to log into NFuse (that's how far behind we are); sometimes, seconds. Reboot router, phone up ISP and complain. Right now, those are our options. So it's not going to work. In a month of Sundays. Even if it did work in the first place, which it doesn't.

Obviously, someone's ego's going to be bruised when it becomes apparent that this is going to have be er, altered. No guesse for who's going to end up wearing it, though. Be nice if I got asked at the start, for once.