I had to update the software of a new Cisco Catalyst 4948 yesterday.
As usual I did:
copy tftp://<hostname>/<filename> bootflash:
boot system flash bootflash:<filename>
But the switch ignored the new software image.
During boot it said:
Booting first image from bootflash
Solution: The config-register was set to 0x2101 right out of the box. I had to change this to 0x2102. With this value the switch honors the bootvar and boots into the configured system image.
The config-register has different meanings on different cisco plattforms.
For the Catalyst 4948 the config-register contains a bit field explained at:
Problem: Windows 7 clients wait 5 seconds to send simple HTTP requests to a web server behind a cisco CSS content switch. But there is no delay when the client connects directly to a web server behind the CSS.
Description: I found one difference between CSS and non-CSS connects: the TCP WSCALE option.
When the CSS is in layer 7 HTTP switching mode (e.g. url “/*”), it does the tcp handshake and the http-request parsing on it’s own, and afterwards it decides which service is receiving the request. For this initial connect the CSS uses WSCALE=0. Which means window scaling is welcome, but the css sets it’s inbound scaling to 1 (2^0). After the request is sent from the client to the css, the css connects to the server, which negotiates WSCALE=8 (scale 256, seams to be the Windows 2008 R2 standard value).
Now the client believes WSCALE=0 for outgoing data and the server believes WSCALE=8 for incoming data.
After the first HTTP request (Keep-alive: active) the Windows server sets it’s window to 256, which is 256*256 byte for the server and 256*1 byte for the client. When the client
requests a second url it has to send the new request in 256 byte pieces and waits for the ack from the server for each packet. And both Linux and Window clients do exactly that. This is a performance penalty of course, but still it should work, but windows sends this 256 byte data pieces after a timeout of 5 seconds. I don’t know why the windows client waits, but it does. Perhaps MS thinks the window will raise magically in the meantime.
Solution: We have 2 bugs here. CSS is doing the WSCALE wrong in layer 7 switching mode, and windows waits 5 seconds before it sends > 256 byte data into a connection with a 256 byte window. For the first bug I have two work arounds:
- Use only layer 3/4 switching, if the url or header based switching is not necessary
- Apply the following setting on your css: flow tcp-window-scale disabled
The second work around disables wscale at all. The CSS sends no wscale option, which disables wscale in both directions (RFC 1323). Without the TCP WScale option the maximum window size is 64k, which should be enough. (except for huge file downloads, over far network distances perhaps)
Vienna: 10. August 2011
Problem: A network of some Cisco Access Points AIR-AP1142N-E-K9 connected to an small router works good as expected but when the user tries to connect to en PPTP VPN the connection fails with a time-out.
Solution: it was no NAT problem in this case (I fixed this before). Cisco IOS 12.4(21)?? has officially a bug not sending GRE (Proto:47) packets from the network to the client. IOS Version 12.4(25d)JA fixed this bug.
Strange! An access point in bridging mode filters depending on protocol numbers. So I guess it’s not really a bridge that Cisco implemented in this IOS device.