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:

Greg Ferro’s “Layer-3 routing” post successfully kicked my huge sore spot: the numerous ways technical terminology is abused by product marketing gurus.

Twenty years ago, before networking became a multi-billion dollar industry, things were clear, simple and consistent: layer-2 (data-link layer) frame forwarding was bridging and layer-3 (network layer) packet forwarding was routing. Everything was crystal clear until some overly smart people tried to turn bridges into something they were not: WAN extension devices. A few large WAN networks were built with bridges … and failed spectacularly. Router vendors quickly used the opportunity to push the “routing is good, bridging is bad” mantra.

My good friend Stretch wrote an interesting article about the usability of certifications in the hiring process. I can’t agree more with everything he wrote about certifications, it nicely summarizes the various topics Greg Ferro and myself wrote about during the last year (please note: I’m not claiming Stretch was in any way influenced by our thoughts, anyone seriously considering the current certification processes has to come to the same conclusions).

Regrettably, I have to disagree with most of his alternative approach (although some of the ideas are great). It would work in an ideal world, but faces too many real-life obstacles in this one.

Greg Ferro asked a very valid question in his blog: “Why does iSCSI use TCP as the underlying transport protocol”? It’s possible to design storage-focused protocol that uses connectionless lower layers (NFS comes to mind), but the storage industry has been too focused on their past to see past the artificial obstacles they’ve set up themselves.

Cisco has recently published two excellent design guides: Deploying IPv6 in Campus Networks and Deploying IPv6 in Branch Networks. As expected from the engineers writing Cisco’s design documents, these guides contain tons of useful information and good recommendations; they’re a highly recommended reading if you’ve started considering IPv6 deployment in your enterprise network. These design guides are part of Design Zone for Branch and Design Zone for Campus.

IPv6 deployment issues are just one of the topics covered in the Enterprise IPv6 Deployment workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.

Continuing my tests of the Hierarchical Queuing Framework, I’ve tested whether the fair queuing works similarly to the previous IOS implementations, where the high-precedence sessions got proportionally more bandwidth.

Summary: Fair queuing within HQF ignores IP precedence.

Finally there's a short explanation of Twitter that I can relate to:

A while ago a senior Service Provider network designer told me that they have serious issues with IPv6 deployment as IPv6 requires a separate PPPoE session from the CPE devices which significantly increases their licensing costs. The statement really surprised me; PPP was designed to be a multi-protocol environment and it’s very easy to configure IPv4 and IPv6 over a single PPP session in Cisco IOS. I think I might have tracked down the source of this “information” to the 6deploy IPv6 and DSL presentation which states on Page 11 that “Separate PPP sessions are established between the Subscriber’s systems (or CPE) and the BBRAS for IPv6 and IPv4 traffic”.

A while ago, I wrote about the problems caused by MTU mismatch between OSPF neighbors and warned that the ip ospf mtu-ignore interface configuration command that supposedly solves the problem could cause significant headaches.

These are the router configurations I’ve used to generate the problem described in this blog post.