This is not a mundane detail, Michael.

https://secure.restek.wwu.edu/config/

Have random config UI’s there. First one that comes to mind is a dns one. You can tweak the expires variables for all the zones, turn wpad on or off, etc.

Tune the DHCP lease times, DNS servers, etc.

We should also move sluice config there, and clean that up. Half the variables in there are unused now.

Each different config would be it’s own directory, so we could fine tune who has permissions to each. Could also be called ResTek control panel, but that sounds a little cheesy to me. I’m really gonna be out of a job after we code all of this up…

Mike :: Jun.15.2004 :: General :: Comments Off

We dropped our bandwidth from 16mbit to 1.5mbit today. I also cleared Packeteer’s class tree and recreated it from scripts.

Packeteer is so fast.

It’s insane. I never thought I’d say that. With all the improvements they’ve made over the last year, and the fact that we have about 1/1000th the network load we did a week ago it only makes sense that it would be zippy.

Here are some ping stats from my house (qwest DSL):

• restek main server (66.165.0.24): 84ms
• campus DNS server (140.160.242.13): 90ms
• office machine (140.160.214.91): 89ms
• yahoo.com (216.109.127.28): 336ms
• fibercloud (216.57.204.2): 83ms

Those are all averages, and I did about 5 pings to each.

Summary:

• We’re slightly beating the academic network.
• We’re less that 5ms slower that fibercloud, meaning Packeteer is adding way less lag to the connection.

We must protect Packeteer from the evil flow monsters on campus next fall. We must have 2 firewalls.

Mike :: Jun.15.2004 :: General :: Comments Off

Read a sweet paper on DNS high availability using some router hacks. See ISC-TN-2004-1 here. Basically the F root server for the whole internet has the IP address 192.5.5.241, but there are servers distributed all over the world answering queries for that address. It’s similar to a load balancing device, except it is implemented by having multiple routers and switches pointing to your server cluster. There’s no cheesy load balancing device that is a single point of failure.

Apparently you could use this setup for other traffic types also, but it works really well for DNS because there is a single UDP request, and a single UDP answer.

Mike :: Jun.14.2004 :: General :: Comments Off

This old FAQ has some info:

Some hardware is also known to cause problems. This includes:

3Com 3c905 cards

Some work, some don’t. Try disabling busmastering if your system is unstable.

So I may just be out of luck. I’ll try using a different NIC.

Mike :: Jun.09.2004 :: General :: Comments Off

Went through the list of the top 25 IP’s sorted by number of connections in packeteer. Discovered that the top 6 people had over 1000 new flows created per minute. A tcpdump of their internet bound traffic showed that all their connections were either ICMP pings to random hosts, or port 445 connections to random hosts. Sounds like a virus to me, so I blocked all of them.

I also put a special 20kbit/sec limit on someone in fairhaven that was having trouble controlling their massive uploads.

Mike :: Jun.09.2004 :: General :: Comments Off

I finally updated the switch crawling code to retry on failures. The scripts used to email me with a few timeouts on occasion. It will now retry up to 3 times.

I also realized that the code was making a SNMP connection to the switch and fetching the in and out records for each port. This part gets looped over for every port on the switch. It would be much better to connect once, then loop over the ports and query the in and out records.

And the pair of scripts that do this (for octet and packet counts) could really be combined.

Mike :: Jun.09.2004 :: General :: Comments Off