Category: workshop

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).

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.

Last November I was delighted to read the announcement describing how a module in CRS-1 was going to support CGN, NAT444, NAT64 and DS-Lite. It looked like a major vendor has finally decided it’s time to solve the IPv4-to-IPv6 transition problem.

However, I was not able to find anything beyond a few fancy videos, a white paper and a brochure. Can anyone shed more light on CGv6? Have you seen it running outside of PowerPoint? When can an IPv6-embracing Service Provider expect to see it on an ASR 1000?

And before you ask ... no, CGv6 is not described in my webinars; I only talk about features (not futures) that I was able to get my hands on.

I was invited to present my thoughts on NAT64 and DNS64 in the upcoming 3rd Slovenian IPv6 Summit (well, they still haven’t managed to create a bilingual site, so here's the same page from the perspective of Google Translate). While preparing for the presentation, I’ve greatly enjoyed reading the Framework for IPv4/IPv6 Translation IETF draft. I would highly recommend it; it’s rare to find such a concise and instructive document and it’s a mandatory reading if you want to understand the role of NAT in the IPv4-to-IPv6 transition.

The role of NAT64 in enterprise networks is described in the Enterprise IPv6 Deployment workshop.

Ever since I’ve figured out how to explain complex topics to bright engineers, I wanted to develop content (books, courses, documents) that explained (in this order):

• The Big Picture and WIIFM (What will the student gain by understanding and deploying something based on what I’m describing).
• How the technology we’re using actually works (remember: knowledge, not recipes) and finally
• How to configure, monitor and troubleshoot the actual boxes used to build the solution.

I’m positive you agree this approach makes perfect sense, and every now and then I’ve managed to get it right (for example, in the MPLS VPN books). Unfortunately, you’re often facing an uphill battle, as people want to focus on hands-on topics and hate to learn why things work the way they do instead of memorizing recipes like “Thou shalt not have more than 3 OSPF areas per router”.

The Wednesday's Building IPv6 Service Provider Core was a huge success (compared to the previous one); I had three times as many attendees from all over the world (map below) even though the topic was highly technical and pretty limited in scope. I can’t tell you how delighted I am that it went so well and I would like to thank (again) everyone who chimed in with improvement ideas.

Once you’ve spent a few hours trying to understand the implications of IPv6, you quickly realize that the only significant change is the increase in the address length. All the other goals that some people had been talking about were either forgotten or failed due to huge mismatch between idealistic view of the Internet IPv6 developers had 15 years ago and today’s reality. However, you still find mythical properties of IPv6 propagated across the Internet. Here are a few I’ve found; add your favorites in the comments.

IPv6 provides service/location separation. Total nonsense. The only mechanism used to find services is still DNS and it’s still used from the wrong position in the protocol stack.

Shivlu left an interesting comment to my IPv6 is not ready for residential deployment post. He wrote: “Still no customer is ready for IPv6. How do I convince them?” The unfortunate answer to this problem is: you can't, but they'll only hurt themselves. If they persist long enough, they’ll become obsolete.

The migration 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.

The web content providers have long realized that their customers have too many choices. Zvezdan Martič, one of the participants in the last year’s Slovenian IPv6 summit roundtable succinctly explained this phenomenon: “nobody cares whether my web site can be viewed in Internet Explorer or Firefox; if I don’t support the major browsers, the customers will find one of my competitors that does.”

Daniel Miessler described an interesting application of the Workstation-as-a-Service (now you know what WAAS stands for ;) cloud service (formerly known as virtual desktop): enterprise network will have to protect their workstations against browser-based attacks and the best approach is to virtualize the browsers and isolate them in a sandbox behind a firewall.

Virtualization, virtual desktops and other security-related cloud services are described in my Next-generation IP Services workshop.

Jared Valentine found an interesting bug in the EEM’s SNMP event detector: if you’re triggering your EEM applet when the increment of an SNMP variable exceeds the threshold, you cannot re-arm the applet; the exit-type increment does not work. He fixed the problem with a somewhat more convoluted approach:

• The first EEM applet reads the SNMP variable, waits a second, does a second read and stores the difference in a counter.
• The second EEM applet is triggered based on the counter values.

I’m collecting tips like this one 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.

Here’s the source code for the first applet (he had to execute CLI show commands to work around the CB-QoS MIB limitations).

Greg Ferro has republished an older post in which he compares Cloud Computing with public transport (and notes that nothing has changed in more than a year since he wrote the original article). His analogy is more than fitting; a perfect example is Google’s new Google Docs offering, where Stephen Foskett did a nice cost analysis of the unsupported service as compared to supported one.

I’m describing aspects of cloud computing in its various incarnations in my Next-generation IP Services workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.

Translated into public transport terms: if you want to fly cheap, choose Ryan Air (in Google’s case, you pay 25 cents per gigabyte per year); if you want reasonable support and flexibility, use Lufthansa ($3.50 per gigabyte per year for Google Apps Premier Edition customers or 14 times more than the unsupported capacity).

If you’re unhappy with my choice of airlines, insert your own selection in the above paragraph ;)

When the current variant of IPv6 was selected 15 years ago, seamless integration with IPv4 was a big deal, resulting in NAT-PT architecture. NAT-PT tried to solve too many problems and (as I pointed out in my IPv6 Deployment workshop), while the 6to4 NAT is manageable, the 4to6 NAT is horrific (NAT64 and DNS64 are more reasonable; more about them in an upcoming post).

NAT between IPv4 and IPv6 hosts is 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.

To make matters worse, the NAT-PT implemented in Cisco IOS is totally broken due to removal of fast switching support in IOS release 12.4(20)T and numerous other releases. As I wrote a year and a half ago, removing fast switching will bite us eventually … and so it does when you try to use NAT-PT.

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.