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.

A month ago Stephen Foskett complained about lack of Microsoft’s support for FCoE. I agree with everything he wrote, but he missed an important point: Microsoft gains nothing by supporting FCoE and potentially a lot if they persuade people to move away from FCoE and deploy iSCSI.

FCoE and iSCSI are the two technologies that can help Fiber Channel gain its proper place somewhere between Tyrannosaurus and SNA. FCoE is a more evolutionary transition (after all, whole FCoE frames are encapsulated in Ethernet frames) and thus probably preferred by the more conservative engineers who are willing to scrap Fiber Channel infrastructure, but not the whole protocol stack. Using FCoE gives you the ability to retain most of the existing network management tools and the transition from FC to FCoE is almost seamless if you have switches that support both protocols (for example, the Nexus 5000).

You’ll find introduction to SCSI, Fiber Channel, FCoE and iSCSI in the Next Generation IP Services webinar.

Quick summary for the differently attentive: Even without the DNS processing, NAT-PT and NAT64 differ from the perspective of peer-to-peer applications. The differences don’t matter for IPv6 clients connecting to IPv4 servers.

Whenever I’m talking about NAT64, someone would say “we’re already using it”. As it turns out, they’re usually using NAT-PT, which looks a lot like NAT64 from afar (after all, they both allow IPv6-only clients to connect to IPv4-only servers). However, there are significant differences between the two, the most important one being DNS64, which handles DNS processing completely outside of the forwarding path (NAT-PT has embedded DNS Application Level Gateway, which was one of the major reasons NAT-PT was declared broken beyond hope).

Phillip Remaker provided an excellent explanation of new IOS release numbering rules in a comment on the Did you notice 15.1T is released? post. Here’s a short summary:

• 15.0(1)M was an exception which consolidated the transition from 12.x rules to 15.x rules.
• Every new 15.x epoch will start with feature releases (15.1(1)T, 15.1(2)T ...) and end with a mature mainline 15.x(y)M release, which will get bug fixes and maintenance rebuilds.
• 15.x+1(1)T will appear approximately at the same time as 15.x(y)M and the whole cycle will repeat.

In another interesting timing coincidence, the documentation for IOS-XR release 3.9.1 appeared at approximately the same time (probably a little bit later) as I started to research the viability of CGv6 during the preparation for my NAT64/DNS64 presentation.

A kind guest has provided links to configuration guide and command reference in a comment to my blog post. Thank you!

A while ago I was criticizing the network-blindness of the storage industry that decided to run 25-year old protocol (SCSI) over the most resource-intensive transport protocol (TCP) instead of fixing their stuff or choosing a more lightweight transport mechanism.

My argument (although theoretically valid) became moot a few months ago: Intel and Microsoft have demonstrated an iSCSI solution that can saturate a 10GE link and perform more than 1 million I/O operations per second. Another clear victory for the Moore’s Law.

In another great blog post, Scott Berkun lays out his thoughts on what managers of programming teams should be able to do. You should read the whole article, as most concepts apply equally well to networking teams: if you’re a team leader, you should have decent knowledge of technology and its limitations, if you’re higher up the management chain, it’s more important that you can trust your people, work with them to reach good decisions ... and figure out when they’re bullshitting you.

John shared a great idea in his comment to my “FTP: a trip down the memory lane” post: when using some FTP servers you can specify the range of passive ports, allowing you to tighten your router ACL (otherwise you’d have to allow inbound connections to all TCP ports above 1024).

A while ago I’ve bitterly complained about the FTP protocol design. I have decades-long grudge with FTP. If you’re old enough to remember configuring firewalls before stateful inspection or reflexive access lists became available, you probably know what I’m talking about; if not, here’s the story.

When enterprises started using the Internet 15+ years ago, most desktop FTP clients did not support passive mode (although it was part of the FTP standard). When configuring “firewalls” (one or two routers with long access lists), you had to allow all inbound TCP session to ports higher than 1024 just to support FTP data sessions. No problem ... unless you were using Sun workstations or NetBIOS over TCP (both of them use dynamic server ports above 1024), in which case those services were totally exposed to the Internet.