Bidirectional Forwarding Detection (BFD) protocol has finally been published as a series of RFCs. BFD gives you quick failure detection between L3 hops (routers) regardless of the underlying technology and equipment (modems, media converters, bridges). It’s been gradually introduced in Cisco IOS during the last few years; release 15.0M and 12.2SRE contain almost everything you’ll ever need (missing: multihop BGP support and MPLS LSP support).

I wrote about BFD in Improve the Convergence of Mission-Critical Networks with Bidirectional Forwarding Detection (BFD) article (you’ll find it somewhere in this list). To learn more, read the RFCs in this order:

It’s amazing what people would try to patent ... and it’s even more amazing what gets past the examiners. IBM has managed to patent passing ipv6 or dhcp argument to indicate an IP host should network-boot over IPv6 or using DHCP. The idea is so trivial it’s almost not worth mentioning and goes along the lines of: “usually we use BOOTP and TFTP to get network boot parameters, but imagine we could pass DHCP as the argument to the boot routine and then it would use DHCP instead of BOOTP”.

A few days ago my friend Greg (also known as @etherealmind) wrote an interesting tweet (probably prompted by the change in AT&T data plans):

If a data cap doesn't affect 97% of users, why bother implementing it at all? Surely the 3% can be that significant?

A few of us immediately responded that the 3% could represent 80 (my guess) to 97% (@icemarkom) of the traffic. As I’m tracking my home Internet connection with MRTG for over a year, I was also able to get some hard facts (although the sample size is admittedly very small). We’re pretty heavy internet users (no limits on what my teenage kids are doing and I’m mostly working from home), but the average yearly utilization of my 20 Mbps pipe is only 180 Kbps or less than 1% of its capacity (still, over a year, that’s almost 700 GB of data or 350 months of AT&T’s DataPro plan).

Another article from Scott Berkun pointed me to a wonderful tool: Readability. Imagine being able to read web pages in decently-sized font on pleasant background and without all the navigational and ad clutter. It makes my reading experience infinitely more pleasurable; now I can manage to read blog posts that are several pages long without getting a headache.

IS-IS has “forever” (at least since RFC 1195) supported multiple layer-3 protocols, but always with a nasty side-effect: if a link in your network did not support one of them, you could get hard-to-diagnose black holes.

The problem is illustrated in the left-hand column of the following diagram. Due to a single IS-IS topology, the shortest path between A and B is the direct link, and since IPv6 is not enabled on that link (click on the diagram to get an enlarged version where you'll be able to see the link colors), A and B cannot exchange IPv6 traffic even though there’s an alternate path between them.

Tired of losing half of your bandwidth to spanning tree? TRILL will solve all your problems, bring the world peace and make better coffee than Starbucks (hint: the second claim is fake and the third one is not so hard to achieve).

Undoubtedly TRILL is an interesting technology that can alleviate the spanning tree limitations. Unfortunately I’ve seen a very similar technology being heavily misused in the past (resulting in some fantastic failures) and remain skeptical about the deployment of TRILL. My worst case scenario: TRILL will make it too simple to deploy plug-and-pray bridged (vendors will call them “switched”) networks with no underlying design that will grow beyond control and implode.

Andrej Kobal from Astec shared a few interesting facts during the 3rd Slovenian IPv6 summit: they were deploying a pilot IPv6 subnet in a large network and wanted to retain tight control over the IPv6 address assignment (some people don’t consider random address chasing embraced by Windows the best use of their time), so they’ve decided to use DHCPv6. Bad luck: DHCPv6 can’t tell you the IPv6 address of the default router (like DHCP does). You need ICMPv6 RA (part of IPv6 Neighbor Discovery) to figure out who the router is.

If you want to protect the integrity of your network, you need to deploy SeND or RA guard as well as DHCPv6 guard on your switches. These features are not yet available on many L2 switches ... Catalyst 4500 and Catalyst 6500 are a notable exception. Catalyst 3750 also supports IPv6 port access lists.

Every so often I get a question about the MTU metric in EIGRP and whether it’s used at all or not. It’s supposed to be used (at least it was decades ago): if your router would have to ignore some equal-cost paths to the same destination (the number of equal-cost paths exceeds the value of the maximum-paths router configuration parameter), it would ignore those with the lowest MTU metric.

After an email exchange with Carlos G Mendioroz, I retested the above behavior with Cisco IOSv release 15.6(1)T in 2023. EIGRP MTU-related behavior changed since I last looked (in 2010): it no longer considers MTU when selecting a subset of equal-cost paths; the most stable (oldest) paths stay in the IP routing table regardless of their MTU value in the EIGRP topology table.

Jan Žorž from go6.si is obviously a very successful IPv6 evangelist: not only did he manage to organize numerous IPv6 summits in Slovenia (which is probably one of the reasons Slovenia is the leading European country on the RIPEness scale); he’s also helped persuade the mobile industry to roll out pilot IPv6 services. Right now we have two mobile operators piloting IPv6; both dual-stack (with two PDP contexts) and IPv6 roaming are working flawlessly.