Bad designer sent me an interesting comment: 2G and 3G networks have huge latency issues. GPRS is intolerable, UMTS is awful and HSPDA is reasonable but still not what one would hope for.

The latency does not seem to be associated with serialization delay. UMTS gives you reasonable transfer rates and significant latency and GPRS gives you an order of magnitude higher latency than ISDN with comparable transfer rate. If anyone knows enough about the mobile technologies to explain this phenomenon (or at least give me useful pointers) I’d really appreciate your comments.

My friend Stretch alerted me to an article published by BBC News, which reports that “an EU cyber security expert” told “a House of Lords committee” (wow, that’s the perfect body to deal with Internet issues) that the proposal submitted by Chinese to an ITU-T study group required “modifications to BGP” which would “threaten the stability of the entire Internet.”

Regardless of whatever the original proposal has been, the information has been distorted, twisted, adapted, abstracted, and misunderstood so many times before being published that it’s impossible to figure out what exactly has been going on. The account of an eyewitness (sitting in the Kampala talks in September) doesn’t tell much more.

The engineer who wanted to detect specific DoS attack (WAN link overload) with EEM applet asked for something more in his original question: he wanted to receive a SNMP trap on the NMS when the DoS attack is detected. Implementing this requirement with an EEM applet is simple; you just need to add the trap keyword to the event manager applet configuration command.

EEM-SNMP integration is described in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.

A while ago I’ve created a short presentation describing modern IP- and web-based services. It describes the application-layer topics I’ve been focusing on in the last few years, from cloud computing to web-based applications. I've tried to keep it simple enough that someone without the prior knowledge of the field would not get lost after two slides, but still far away from high-level marketing nonsense (you can get plenty of that anywhere else). Today I finally found some time to spend on the paperwork and wrote the description of the Next-generation IP Services tutorial.

The main driver for IPv6 deployment is the IPv4 address space exhaustion, caused primarily by fast growth of residential users.

Each residential user needs an IP address, a small company doesn’t need anything more and even a reasonably-sized company can survive with a few IP addresses.

One would expect the vendor readiness to follow this pattern, but the situation is just the opposite: while the enterprise networking devices have pretty good IPv6 support (Data Center components from some vendors are a notable exception), the vendors serving the residential market don’t care.

The Service Provider-related IPv6 challenges are covered in my Market trends in Service Provider networks workshop. You can attend a web-based tutorial version or we can organize a dedicated workshop event for your team.

After doing the initial tests of the HQF framework, I wanted to check how “hierarchical” it is. I’ve created a policy-map (as before) allocating various bandwidth percentages to individual TCP/UDP ports. One of the classes had a child service policy that allocated 70% of the bandwidth to TCP and 30% of the bandwidth to UDP (going to the same port#), with fair queuing being used in the TCP subclass.

Short summary: HQF worked brilliantly.

If you happen to be one of those “universal engineers” tasked with configuring a Cisco router just because you deployed a web site yesterday, you’re probably already searching for a book in the Dummies series. Once your desperation exceeds a certain threshold, you might consider the “Cisco Routers for the Desperate”.

The idea is great: give someone who hasn’t seen Cisco IOS CLI before enough knowledge to perform the basic tasks. The writing style is surprisingly good and the book is filled with well-explained printouts you might get from the router. Looks like a perfect book for the task … if only it wouldn’t be hopelessly outdated.

One of the few benefits of having a Facebook page is the ability to view the fan statistics (Facebook calls that Insights). I’ve just looked at the gender demographics of my fans and I was astounded; nothing has changed in the last 20 years. What are we doing wrong?

It looks like my load sharing posts did not paint the whole picture; I’m always assuming the readers have a basic level of IP routing knowledge (somewhere around BSCI/CCNP) and jump into juicy details. Let’s try to fix this error and start from the beginning. For more details, watch the How Networks Really Work webinar.

A router receives its routing information (reachability of IP prefixes) from various sources: connected IP prefixes, static routes and dynamic routing protocols. For every IP prefix, the best source (= one with the lowest administrative distance) is selected and only the route(s) from that source are included in the IP routing table.

Every so often someone tries to apply the “let all be friends and love each other” mentality to LAN networks and designs a pure layer-2 switched LAN (because it’s simpler). Jay contributed a ten-step “what happens next” description in his comment to my “Lies, damned lies and product marketing” post. The steps are so hilarious I simply had to repost them:

1. Build everything at layer 2 because "it's simpler".
2. Scale a little.
3. Things start breaking mysteriously. Run around in circles. Learn about packet sniffers and STP.
4. Learn about layer 3 features in switches you already own. Start routing.
5. Scale more.
6. Things start breaking mysteriously. Learn about TCAMs. Start wishing for NetFlow.
7. Redesign. Buy stuff.
8. Scale more.
9. VMWare jockeys start asking about bridging across the WAN.
10. Enroll in hair loss program.