So, I’ve been rationalising a small remote site’s network infrastructure and thought I would use some existing spare kit to try to “improve” the network  architecture. So, there was a Cisco 2800 series router and some little switch with a couple of servers plugged into it. Not much but important enough. I figured I would deploy a second 2800 and add a HWIC-D-9ESW to both 2811s. Join them with Etherchannel and set-up GLBP between the routers before the traffic headed onwards.

So a couple of obvious caveats – The Cisco 2800 (and 1800 and 3800 series too) is nearing end of supported life. This is on a budget and new kit is not an option currently.  A shiny new pair of layer three switches would have worked too – simple dual network links with some dynamic routing. Many ways to skin this fish 🙂 Anyhoo. I came across a few limitations of my plan

1) The HWIC-D-9ESW has a hard limit 0f 15 VLANs (which needs to include the VLANs 1002/1003/1004/1005, so 11 usable VLANs). Not very many if you plan on joining the ESW modules to an existing VTP domain with a few segments.

2) The HWIC ESW modules can’t do Etherchannel. So bonding a pair of links between two ESWs or between an ESW and another switch is not possible

3) Cisco do not support GLBP on SVIs with ESWs. Hmm, HSRP and VRRP are supported however. (I did setup GLBP between an SVI on each device and GLBP appeared to work. I didn’t do thorough testing though, so there are likely to be some gotchas- even though it seems to work).

Some of these limits are described in “Switch Virtual Interface for Cisco Integrated Services Routers” (PDF), “Cisco HWIC-4ESW and HWIC-D-9ESW EtherSwitch Interface Cards“, “Cisco 2800 Integrated Services Routers“.

So, long story short, two routers using HSRP with a single link between them (could use two links and have STP block one) each connected to the upstream connection. At least now the remote office has some level of network resilience.

The point of this post – in case you missed it!! – was that some “simple” features one takes for granted on “normal” Cisco kit can be lacking or missing entirely one lower end devices. Once again, it pays to completely check the vendor support matrices and feature sets. In this instance, it was quite tricky to find a definitive list of available (or disabled) features.


Just a quick note to remind folks who upgrade to FTTC Broadband that using an MTU of 1500 bytes (Ethernet standard size) is possible if your PPPoE router supports RFC4638 and supports “baby jumbo frames”.

In short – PPPoE needs 8 bytes of each Ethernet frame resulting in an effective MTU of 1492 for the IP layer between your modem/router and the DSL endpoint at your provider. These 8 bytes can be “reclaimed” if your router has the ability to transmit baby jumbo frames up to 1508 bytes excluding Ethernet headers. Andrews and Arnold has a good write up available describing this in further detail along with a specific PPPoE/FTTC page.

If you are using a Cisco router with appropriate hardware you can add something like the following to a working FTTC/PPPoE configuration.

conf t
bba-group pppoe global
tag ppp-max-payload minimum 1492 maximum 1500
int fa 0
mtu 1508
int dialer 0
mtu 1508

The ppp-max-payload min and max defaults are 1492 and 1500 respectively, so all you actually need to do is configure the MTU to 1508 on the FastEthernet 0 (assuming this is your PPPoE interface) and dialer 0 interfaces. Note that even though the Fa0 interface is used to connect to the FTTC modem, you do not appear to need to change its configured MTU size. You can check that it can support frames larger than 1500 by checking the maximum using “mtu ?” in the config mode.

Once these changes are made, you can do “debug ppp negotiation” to track the negotiated options, including the negotiation of a MRU of 1500 bytes. Once this is working correctly you will not need to do any fiddling to get pMTUd working or messing with client MTUs to avoid the inevitable odd browser hangs.


UPDATE: Just an FYI, you can check which BT cabinet serves your telephone/postcode along with expected FTTC speed uplift at or at

UPDATE2: You do in fact need to set the Fa0 (or what ever your PPPoE interface is) MTU to 1508!



For lab scenarios (or when you are just being cheap) some switches can be convinced to allow non-Cisco SFPs to work using the following IOS commands:

service unsupported-transceiver
no errdisable detect cause gbic-invalid
errdisable recovery cause gbic-invalid

As usual, your mileage may vary.

Recently I needed to do some tests on some Cisco lab kit I have access to. The tests were with full BGP feeds – which cannot be handled by the lab routers due to minimal memory specifications. I set about investigating the memory upgrades and was shocked (again!) at the price of real Cisco RAM. More worryingly, some of the on-line shops I looked at did not convince me they were selling genuine Cisco RAM rather than “compatible”.

Anyway, I decided to look into getting “compatible” memory since these are lab routers, out of warranty and are not under SmartNet contract. Your mileage may vary with this information and you may invalidate your SmartNet or warranty status. That said…

I needed to upgrade Cisco 1801, Cisco 1841, Cisco 2801 and Cisco 2811 routers.

The 1801 went simply from 128MB to 384MB with a Crucial memory SO-DIMM part CT3264X335. The 1801 takes a 200pin SO-DIMM DDR 2700, CL2.5, Unbuffered, Non-ECC, DDR333 memory module. A slower DDR DIMM module may work, but this DDR2700 one worked for me.

The Cisco 1841 took 144pin SDRAM SO-DIMM, PC133, non-ECC, unbuffered. This is the same as the 2801.

The Cisco 2801 takes 144 pin SDRAM SO-DIMM, Unbuffered, non-ECC, PC133. A list of compatible parts should be: KVR133X64SC3/256, MT8LSDT3264LHG-133, THLY25N01C75, CT32M64S8W7E, HYS64V32220GDL-7, MH32S64PFJ6L, EBS26UC6APS-75, HYM72V32M636BT-6, THLY25N01B75, NT256S64VH8A0GM-75, MT8LSDT3264HG-133

The 2811 can be upgraded from 256MB to 512MB or 768MB. The router takes 184-pin unbuffered, ECC, DDR PC2700 ram. I initially tried a Crucial part (CT6472Z335 which was a module MT9VDDT6472AY-335F1) which did not work. The MT9VDDT6472AY is a single rank 512MB module. I then tried a dual rank 512MB module (KVR266X72C2/512) which worked. I would expect MT18VDDT6472AG or similar (with 18 modules rather than 9 modules) dual rank 512MB module to work.

During this investigation and upgrade, it would appear that the 2500, 2600, 3600 take the same flash modules too. They do support different flash module sizes, but realising that the modules are compatible makes troubleshooting or replacing parts simpler. Of course, you have to re-flash the appropriate IOS!

Hopefully this will help someone out there! Of course, using non-Cisco memory may get you into hot water if you ever ring Cisco for support! You have been warned.