We (Unilogic Networks) are running a Foundry BigIron 4000 as a layer 3 device only in our network. However there are some issues I see people running into that are not that good documented or presented to these people. We ourselves are quite happy with our Foundry as it does the job it handles, but there are some things you should have in mind when deploying them. Here is a short list of problems that may arise when using a Foundry BigIron 4000.

These problems are based on a Foundry BigIron 4000 running a M4 engine and JetCore blades on software version 07.7.01bT53 :

• Foundry's running in route-only will sometimes still switch data to other ports. To avoid this we suggest you put every port in a single vlan so it will not disturb other ports
• Foundry uses some pre-configured defaults for several system values used to calculate how much CAM space it should reserve for certain tasks. Unfortunately the max system routes is only 128000 (140000 in some versions) which is way to low for routers doing full BGP4. Add the following to your configuration to fix this problem: 'system-max ip-route 200000'
• Virtual Interfaces (ve's) on a Foundry will do a lot of work over the CPU! ACL's for example and also some routing. Rate-limits are not supported on VE devices.
• When using as a pure layer3 device always use the 'route-only'  syntax in your config as it will disable almost all layer2 functions (including STP)
• Remember that although the configuration style may look A lot like Cisco IOS, there are some subtile differences, especially when concerning ACL's, BGP, and route-maps. For example Foundry allows the use of CIDR everywhere while IOS only allows quad dot netmasks.

These are probably the most issues people run into when using a Foundry. If you are using a Foundry and are doing BGP on them and have some issues, don't hesitate to contact me.

Another thing about Foundry BigIron series is that these are 100% compatible with HP's 9300 series. This includes Software releases, blades and power supplies. The only real difference is a big s/Foundry Networks/Hewlett Packard/ and the change of OIDs to represent the HP enterprise OID, also HP's EP blades are JetCore blades. We are using Mixed Foundry/HP setups without any troubles.

Your Areca Driver reporter has just seen that Andrew Morton released a new patch which includes Areca Linux driver 1.20.00.07.
It features some bugfixes when the driver is being loaded when no card is present, and has some fixes concerning stack usage. It should be overall more stable thus.

Ofcourse the driver can be found on the Linux Kernel.org archive in Andrew Morton's directory.
I've not yet tested this driver myself as I'm currently at home where I have no Areca controller lying around. But at the office we have one in use and I will test the patch on this controller. Hopefully it also makes the management interface of the driver more stable so the cli will report consistently instead of failing sometimes, causing our nagios monitoring to go critical.

Oh, I bought myself a new digital camera. It's an Canon EOS 350D Digital SLR camera. It will probably be delivered next thursday. So more info then when I have it!

Andrew Morton released Linux 2.6.11-mm4 today and it again includes an Areca driver after it's absence in 2.6.11-mm3. It is based on 1.20.00.06 another release that is nowhere to be found on the Areca FTP site. It looks like Andrew's kernel tree is the way to go if you want the latest and greatest Areca driver release for Linux.

There seem to be little changes in the driver which should make it more to adhere to Linux 2.6 codingstyle and implementations, using some comments provided by leading kernel developers. It's good to know that Areca is continually to improve their Linux driver and opening it up to the world to be included in the Linux Kernel. It is nice to know that still some commercial hardware vendors are providing GPLed drivers to the public.

Stefan just noticed that since 2.6.11-mm2 (that would be 1.20.00.05) the default load of 1 that the Areca driver generates also has vanished. So this is surely an improvement over the stock 1.20.00.04 driver that Areca supplies on their FTP server.

UPDATE: If you wish to run this Areca driver on a stock Linux 2.6.11 kernel just apply this patch.

Go Areca!

Last week we ran into some probably NFS related issues on our mailserver setup. It seemed that some messages where locked/ not locked when trying to read them which resultated in some messages needing about 30+ seconds to get displayed using squirrelmail.

The problem was fixed by switching from mailutils-imap4d to dovecot-imapd. It seems dovecot locks more intelligently or does not lock at all, resulting in no delays for the IMAP client.

I was just searching for some articles related to NFS issues mainly regarding locking and found this huge NFS patch for Linux 2.6.11. This is something I'm gonna test on our NFS server (which is 2.6.11) and my workstation (also 2.6.11). Some folks at InterLink always had NFS locking issues between Linux and FreeBSD, but they fixed this by switching to FreeBSD completely. Our NFS locking issues also have vanished after switching to dovecot for our IMAP service.

Today I saw that there was a new update of the -mm tree resulting in 2.6.11-mm3. Looking at the Changelog I discovered that Areca support was dropped from this release due to it being 'busted' as the upstream maintainer (Areca) had released a new version (of which nothing can be found on their FTP site).

So if you want drivers for an Areca controller on Linux run 2.6.11-mm2 or patch the kernel tree yourself. I have generated a diff file for kernel 2.6.10 (and 2.6.11), it's available here. It's based on the 1.20.00.02 driver as present in the Fedora Core 3 directory of the Areca FTP.

Here is a patch to get Areca version 1.20.00.05 inside Linux 2.6.11 (NOTE: This patch is UNTESTED, the above 1.20.00.02 patch IS tested)

I'll keep you updated concerning Areca driver updates!

Areca always provided Linux drivers for there PCI-X/PCI-Xpress RAID cards. However I just noticed Andrew Morton implemented these drivers in his -mm tree, which makes implementation in the default Linux tree a lot closer. The first release of Andrew's -mm tree with the Areca driver inside is 2.6.11-rc3-mm1

It looks like the drivers are based on 1.20.00.05, which is peculair as these are not yet released (last version 10.20.00.04) by Areca (atleast the Areca FTP site hasn't got them). The changelog of 2.6.11-mm2 also indicates some fixes and that their is a lot of work needed to fix up these driver to 2.6 standards. 2.6.11-rc3-mm1 still has the 1.20.00.04 version of the Areca driver.

There is a little patch by Andrew Morton to make the Areca driver compile everywhere (kernel source does not have to be in /usr/src/linux). However this one is present in 2.6.11-mm2.
Also present in 2.6.11-mm2 is an patch from Adrian Bunk which does some general clean-ups to the Areca driver.

The main differences between the 1.20.00.04 and 1.20.00.05 seem to be big cleanups off the code to make it work better on 2.6 and rely less on own code to do things but to offhand this to code already present in the kernel. This already reduces the source code of the driver with a whopping 40 kbyte. In practice it would result in a more stable driver. But that's something we still have to find out.

Tomorrow I'll test run 2.6.11-mm2 on Stefan's box which has an Areca ARC-1110. I'll test basic performance and the workings of the Areca CLI tool.

UPDATE: The driver works without hassle on the box, however the CLI unreliability has not been fixed. Sometimes the Areca CLI refuses to work, but if you invoke it again it will work. This behaviour is not deadly, but very irritating if you are using the CLI for automated purposes (like nagios monitoring). However I would everybody recommend using the -mm tree if you are using an Areca RAID controller as positive feedback on this driver will speed up it's default implementation in the 2.6 kernel tree.

And ofcourse the referer spammee's are still busy trying to spam my weblog full. Yes I know Kennedy (more) from Cumfiesta is hot, but still I don't really like it refering to my site.

Luckily we have Pivot-Blacklist  that is helping me along blocking these nice referers. Still eventually something slips trough :(

And for the second time in 1 year we moved our office trough the building. The move was easier then the last one, because we switched to IP Phones so we hadn't have to do any recabling of phone lines :)

Main advantages:

• 2 Office rooms instead of 1
• Bigger rooms
  
• New interior
• Shorter distance to walk to colo room (same for cabling)
• Own infrastructure (not relying on 3rd party)
  
• AND NEW WORKSTATIONS :) (Read my post about Radeon 9250 about this)
• New wallpaper (Jennifer Garner)
  

Main disadvantages:

• No more windows outside (only towards hallways)
• No airconditioning (but that doesn't matter as this side of the building doesn't get that warm in the summer)
  

Before Pictures (with some colo pictures)

After Pictures

Today I got my new workstation at work, a nice P4 3Ghz in a Shuttle X-PC barebone with 1G of ram, 160GB SATA disk and a Asus A9250/TD (ATI Radeon 9250/9200PRO) to drive the 2 17" IIyama ProLite E435S TFT Screens. One screen is connected with DVI and the other screen with normal HD15 VGA cabling.

However I only got cloning the two screens to work on Linux. Running Windows XP with two independent screens worked flawlessly. So I ofcourse went out investigating how to get this working:

I got it working with a single screen using the stock radeon driver that's with XFree86 4.3 and with the ATI Catalyst Drivers for Linux. However dualhead cloning is something I only got working with the radeon drivers. But no xinerame or independent dualhead :(

(more)