How does an intelligent network affect you? Do you care how you’re able to read this blog post as long as it is delivered efficiently and loads quickly? Let’s dive deeper. As you consume information available on the World Wide Web, use the various enterprise apps at work, and browse training videos, do you ever wonder about how the content is delivered to you? Think about the various technologies and network services that may have impacted how this blog was delivered to you and the path it took from the app server to your laptop, iPhone, Blackberry, android phone, or tablet.
The upcoming World IPv6 launch is stimulating a lot of conversation around IPv6 deployment and common deployment scenarios. People regularly ask “where’s my NAT,” which is something we have tried to address in architectural discussions in RFC 2993, RFC 4864, and RFC 6269. Margaret Wasserman and I have worried specifically about the implications of the multiplication of provider-independent addresses at the edge and the issues of multihoming, and described a model for IPv6 network prefix translation that we think addresses most of the issues and yet facilitates scalable multihoming without provider-independent addressing and the bloating of the route table it implies. Per-residential-customer multihoming is currently in use for NTT BFLETS in Japan.
My colleague Andrew Yourtchenko, whom many of you may know from IPv6 events, has a very different opinion about network address translation. If anything, he would like to get rid of it. Andrew has contributed to some 14 RFCs on the topic of transition and has much of value to say.
While I agree with Andrew on a number of issues, I don’t agree about the model in which one deploys a prefix allocated by each of one’s upstreams providers on each of the LANs in a network. I think that while we have reduced costs for ISPs in the smaller route table, we have significantly expanded the complexity faced by the edge network without giving them a benefit that they readily recognize. I agree with the end-to-end model and the ability to deploy new applications anywhere in the network, but I think that stateless prefix translation can meet those issues and help in managing the size of the route table. Andrew and I recently weighed the pros and cons of our different opinions and included our thoughts in this blog. What is your opinion on this topic? Read More »
In my previous post, I discussed 4 common Cisco IOS Software feature licenses for Cisco Catalyst 2K and 3K switches. I specifically concentrated on LAN Lite and LAN Base licenses for layer 2 networks. Today I’ll take a closer look at layer 3, IP Base and IP Services licenses. I’ll point out again that this post is not intended to represent or replace any Cisco documentation. Product information can change very quickly and use of this post is solely at the readers’ own risk.
For those of you who have used Cisco switches for a long time, do you remember the Cisco Catalyst 5500 switches with a Route Switch Module (RSM)? That was how layer 2 and layer 3 were put together within a single chassis – in a kludgy way. Those days are long gone. The Cisco Catalyst switches today feature powerful and integrated layer 3 capabilities. Layer 3 switching and routing are so close that they spark lots of fun discussions. Here, I’ll concentrate on the layer 3 switching capabilities of the Cisco Catalyst 3560-X and Catalyst 3750-X switches.
Read More »
Cisco UPOE is a hit, ramping up to more than 1 million ports annualized run rate since its introduction last year. Read what IT World Canada and CRN have to say about the opportunities afforded by Cisco UPOE.
Beyond powering a wide range of devices with 60W PoE power, Cisco UPOE really shines when it is combined with Cisco EnergyWise. EnergyWise allows you to monitor and control the power consumption of devices connected to the switches. The combined EnergyWise and UPOE demo at Interop showed how you can use the network to turn devices on and off remotely to save power when the devices are not being used. In the following video, Rich Zavala, Technical Marketing Engineer, explains to Jimmy Ray from TechWise TV how he is powering a multitude of devices over Ethernet including LED lights and personal telepresence units, and how Cisco EnergyWise automates energy management for IT and non-IT equipment connected to the switches.
As we approach the much talked about World IPv6 Launch on June 6th, 2012 it is important to help as many as possible do what is needed to prepare their own Internet Edge to not only participate in the launch but also to ensure business continuity regardless of which IP version is used. Start now so you don’t have to rush your deployment at the end.
There are important first steps to take before you ever type the first command or click the first check box on a product. Important stuff like a gap analysis on what you can and cannot support as well as what your provider supports IPv6-wise, what your address plan will look like and other considerations. Luckily Cisco has either written a document or a blog on many of these topics. Recent blogs include:
- “Integrating IPv6 Into Your Network: Five Steps for Building Your IPv6 Address Plan” – by Jim Bailey
- “Taking Advantage of World IPv6 Launch: Practical ways to add more IPv6 to your network” – by Phillip Remaker
- “Deploying IPv6 in the Internet Edge” – by yours truly, Shannon McFarland
Given that we are just shy of a month away from World IPv6 Launch, I wanted to blog on the top considerations for enabling IPv6 support on one of the most important components of any Internet Edge design, the Application Delivery Controller (ADC) or more commonly known as a Server Load Balancer (SLB).