Category: Internet

You did read my blog post on ThousandEyes, didn’t you? What I forgot to mention was that they have this cool API that allows you to extract measurement data (including BGP topology) from their system. Can we do something cool with that?

A group of researches presented an “interesting” result @ IETF 87: migrating from IBGP full mesh to IBGP reflectors can introduce temporary forwarding loops. OMG, really?

Don’t panic, the world is not about to become a Vogon hyperspace bypass. Let’s put their results in perspective.

Andrew sent me the following question: “I'm pushing to start a conversation about IPv6 in my organization, but meanwhile I've no RFC 1918 space left. What's your take on 100.64.0.0/10 - it's seems like this is available for RFC 1918 purposes, even if not intentionally?”

Short answer: Don’t even think about that!

In the TCP, HTTP and SPDY webinar I described the web application performance roadblocks caused by TCP and HTTP and HTTP improvements that remove most of them. Google went a step further and created SPDY, a totally redesigned HTTP. What is SPDY? Is it really the final solution? How much does it help? Hopefully you’ll find answers to some of these questions in the last part of the webinar.

The SDN industry probably considers me an old and grumpy naysayer (and I’m positive Mrs Y has a special place in their hearts after her recent blog post), so I tried really hard to find a real-life example where OpenFlow could be used to solve mid-market innovator’s dilemma to balance my usual OpenFlow and SDN presentation.

More than four years ago one of my friends wrote about uselessness of UMTS connections (the page has decayed into digital wasteland in the meantime) for inter-router backup links and although I got numerous comments trying to explain the issues I never found a good explanation that a simplistic networking engineer like me could understand.

Ilya Grigorik fixed that. His Breaking the 1000 msec Time-to-Glass Mobile Barrier talk has some real-world statistics, and a fantastic description of how 3G/4G networks work and what causes the enormous latencies. His High Performance Browser Networking book has even more details. Enjoy!

In the first part of the TCP, HTTP and SPDY webinar I explained why TCP and HTTP impact the end-to-end web application performance. In the second section of the webinar, we did a deep dive into the actual TCP and HTTP mechanisms that increase end-to-end latency (3-way handshake, initial congestion window, request/response nature of HTTP).

The responses to my What did you do to get rid of manual VLAN provisioning post were easy to predict: a few people sharing their best practices (thank you!), few musings on the future of SDN/networking, and the ubiquitous anonymous rant against stubbornness and stupidity of networking engineers and their OPEX.

I know one should never feed anonymous trolls, but this morsel is simply too juicy to pass, so here it is – let’s see what makes networking so complex.

It seems that most people not having a vested interest in status quo agree the socket API is broken. After all, why should every single application ever written have to deal with the idiosyncrasies of two address families?

Not surprisingly, the browser vendors got sick and tired of waiting for a fixed API or a standardized session layer (nothing happened in the last two decades) and decided to implement happy eyeballs – a simple mechanism that creates two TCP sessions (one over IPv4, another one over IPv6) and uses whichever one works better.

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

A while ago I got an interesting question:

Let's say that due to circumstances outside of your control, you must have stretched data center subnets... What is the best method to get these subnets into OSPF? Should they share a common area at each data center or should each data center utilize a separate area for the same subnet?

Assuming someone hasn’t sprinkled the application willy-nilly across the two data centers, it’s best if the data center edge routers advertise subnets used by the applications as type-2 external routes, ensuring one data center is always the primary entry point for a specific subnet. Getting the same results with BGP routing in Internet is a much tougher challenge.

Matthew Stone encountered another unintended consequence of full Internet routing in a VRF design: the TCAM on his 6500 was 80% utilized even though he has the new Sup modules with one million IPv4 routes.

A closer look revealed the first clue: L3 forwarding resources on a Cat6500 are shared between IPv4 routes and MPLS labels (I don’t know about you, but I was not aware of that), and half the entries were consumed by MPLS labels:

Yesterday I described the roadblocks you might encounter when faced with a seemingly simple challenge:

In a network with two data centers (connected with a DCI link), ensure the applications in a data center stay reachable even if its Internet links fail.

In the Solutions Corner (a brand new part of my web site) you’ll find a short high-level design document describing the overall solution and listing the technologies you could use to implement it (you might want to watch the video before reading the document).

I’m exposed to an incredible variety of topics in my ExpertExpress engagements, but there are always a few recurring themes, one of them being “we’re experiencing long convergence times and high packet loss after our primary Internet link fails.” Almost always the root cause turns out to be full Internet routing table being received on inadequate hardware.

Thomas wanted to check whether the IP traffic is actually delivered to a remote site and sent me the following question:

I would like to know whether the packets I sent from site A to site B have been received. I don't want to create test traffic using ip sla, I would like to know that the production traffic has been delivered. I could use ACL counters but I'm running a full mesh of tens of sites. Ipanema does this very well, but I'm surprised that this doesn’t exist on Cisco IOS.

Short answer: that’s not how Internet works.