My favorite yellow press outlet has decided to propagate hearsay instead of writing “original contributions” (but their mastery of creating sensationalistic titles remains unchallenged). This time, they claim that “New features embedded in Cisco IOS like VoIP and Web services can present an opportunity for hackers”.

The only supporting documentation they provide is a story in SearchSecurity with a sensationalistic title (New Cisco IOS bugs pose tempting targets, says Black Hat researcher) followed by two pages of confusion including gems like “… new deployments of Internet Protocol version 6 (IPv6) and VoIP installations may make router exploitation more vulnerable to remote attackers …” supported by “… IPv6 was considered a security threat due to the many net tunnels used to connect to IPv6 …”, which, as anyone who has some basic clue about IPv6 knows, has nothing to do with router vulnerabilities.

Soon after I wrote the Designing Fast Converging BGP Networks article (you’ll find it somewhere in this list, one of my regular readers sent me an interesting problem: BGP sessions would be lost in his (IS-IS based) core network if he would use fall-over on IBGP neighbors and the BGP router would have a primary and a backup path to the IBGP neighbor.

It turned out to be an interesting side effect of aggressive route table purge following a link failure: the route to BGP neighbor was removed from the routing table before IS-IS ran SPF and installed an alternate route, and BGP decided it’s time to give up and terminate the session.

You might have noticed that your IOS release supports a ctunnel interface (hint: your image has to support CLNS) and wondered what it could do. Well, it’s a GRE tunnel between a pair of NSAPs, so you can transport IP traffic across your well-engineered CLNS network without ever exposing the core routers to the dangers of IP.

But wait, it gets better: starting with IOS releases 12.3(7)T and 12.2(33)SRA, you can transport IPv6 across the ctunnel interface. Unfortunately, they haven’t implemented MPLS over GRE over CLNS yet (the mpls ip command is present, but does not work).

Many thanks to those of you that responded with Netflix details (special thanks to Volcker for sending me the packet capture). Immediately after someone mentioned firewalls, I knew what the most sensible answer should be: to get across almost anything, use HTTP. No surprise, Netflix chose to use it. However, they’ve managed to deploy streaming video over TCP, which is not a trivial task. So, how did they do it?

Fifteen years ago, the focus of the “true” service provider was on voice traffic and data offerings based on virtual circuits, implemented with a plethora of semi-compatible technologies slowly developed within the ITU organization: X.25, ISDN, Frame Relay and the all-encompassing ATM.
In the meantime, some relatively small companies (including Cisco, Wellfleet and 3Com) were producing so-called “routers” that supported two technologies nobody took seriously: Ethernet and IP.

Thanks to my readers, I often learn something completely new about the intricacies of Cisco IOS. The “VLAN Interface Status” post resulted in a comment about the SVI autostate concept, which is (not surprisingly) a somewhat muddy topic:

• In most cases, the SVI interface tracks the state of access and trunk ports using the VLAN. The details are well explained in the Understanding SVI Autostate section of the Cisco IOS documentation.

The important part of the SVI autostate calculation is the “port is in STP forwarding state for the VLAN” requirement. If a VLAN is not carried in a trunk port (for example, due to switchport trunk allowed configuration command), the trunk port’s status does not influence the autostate.

Ying would like to have a PE-to-PE IPSec protection for traffic within a single VRF. For example, all traffic in VRF-A sent between PE-1 and PE-2 should be protected with IPSec and the PE-routers should be the endpoints of the IPSec session (CE-to-CE IPSec is trivial).

My first response was “hard to do”, then I started hallucinating about MPLS-over-GRE-over-IPSec-over-IP-over-MPLS tunnels between the PE-routers with tunnel-specific IGP and per-VRF BGP next hops. It can be done (we’ve implemented numerous large-scale MPLS/GRE/IPSec designs), but is there a simpler alternative? Please share your ideas in the comments.

Vijay sent me this question a while ago:

I have configured a L3 VLAN interface on a Cisco 3750 switch and assigned an IP address to it. I haven't assigned any ports to this VLAN. Why am I not able to ping the IP address of the VLAN interface from the switch itself?

The VLAN interface (like any other interface) has layer-1 and layer-2 state.

The layer-1 state is displayed in the Status column of the show ip interface brief command, the layer-2 state in the Protocol column.

In one of our discussions, Stretch provided an excellent graph illustrating that the ISP competition seems to reduce prices almost linearly and asked me in a later comment to justify the inverse relation between subscription charges and consumer choice.

You might consider this debate to be purely between Stretch and myself, but it’s an interesting example of what you might need to do in daily your job. If you want to be a great networking engineer, you have to be prepared to question everything, including common wisdoms, “well-known truths”, “common practices” and facts that look too good to be true. Ready? Let’s go …

I'm looking for details on how Netflix streams videos over the Internet. I've found their description of encoding and bit rates, but was not able to find lower-layer details (I can only assume they use UDP, but I would like to verify that with someone who's actually using the service).

I would also appreciate any information on whether they work with Service Providers (for example, using local direct peering) to ensure the upstream Internet connections are not clogged with streamed video.