Archive

Category Archives for "Russ White"

DC Fabric Segment Routing Use Case (5)

In this, the last post on DC fabrics as a Segment Routing use case, I mostly want to tie up some final loose ends. I will probably return to SR in the future to discuss other ideas and technical details.

Anycast

Anyone who keeps up with LinkedIn knows anycast plays a major role in many parts of the infrastructure. This isn’t unique to LinkedIn, though; most DNS implementations and/or providers, as well as just about every large scale public facing web application, also uses anycast. Which leads to an obvious question—how would SR work with anycast? The answer turns out to be much simpler than it might appear. The small diagram below might be helpful—

anycast-01

Assume A and B have two copies of a single service running on them, and we want hosts behind F to use one service or the other, just depending on which the routing system happens to route towards first. This isn’t quite the classical case for anycast, as anycast normally involves choosing the closest service, and both of the services in this example are equal distance from the hosts—but this is going to be the case more often than not in a data center. In Continue reading

On Definitions: Whatever is Forwarding Information?

After last week’s, a reader left a comment noting “I2RS doesn’t manipulate forwarding data.” If I2RS isn’t “manipulating forwarding data,” then what, precisely, is it doing? I thought it’s worth a post to try and help folks understand the definitions in this space—except, as you’ll soon discover, there are no definitions here. In fact, it’s almost impossible to create a single set of definitions that will clarify the issues involved in understanding the various sorts of state in a network device. The following illustration might be helpful in trying to understand the vagaries of the various kinds of state, and the confusion that results from the various names used in different places.

device-model-definitions

It would be “nice” to say something like: information held in the forwarding table, that’s actually used to forward traffic through the router, is the only real “forwarding data.” This makes for a nice clean definition that clearly separates, say, what the RIB does and what the FIB does in most of the hardware based switching devices produced today. There are two problems with this clean definition, however.

First, there are, and always will be, devices produced that simply don’t have a forwarding table. Instead of Continue reading

Docker Forks the Open Source Bubble

The magic of open source.

If I’ve heard this once, I’ve heard it a thousand times.

Put the software “out there,” and someone, somewhere, will add features because they need or want them, fix bugs because they’ve run into them, and generally just add value to the software you’ve created for free.

This is why, I’m told, open source is so much better than open standards—isn’t open standards just another name for a bogged down, broken process where vendors try to run in fourteen different directions at once? Where customers really aren’t heard for the din of careers being made, and technical solutions far too often take a back seat to political considerations? Open source is going to ride in and save the day, I’m told, making all complex software free and better.

reaction-02Unicorns. No, seriously. Or maybe you prefer frogs on stilts. It doesn’t work this way in the real world. If any project, whether it be an open source project or an open standard, gains enough community buy-in, it will succeed. If any project, whether it be an open source project or an open standard, doesn’t gain community buy-in, it is dead—no matter which company supports it, Continue reading

An I2RS Overview

What is the Interface to the Routing System (I2RS), and why do we need it? To get a good I2RS overview, consider the following illustration for a moment—

rib-fib

What does the interface between, say, BGP and the routing table (RIB) actually look like? What sort of information is carried over this interface, and why? A short (and probably incomplete) list might be—

  • Routes being installed by the routing protocol into the RIB—this is the most obvious bit of information, allowing the device to actually build a forwarding table
  • Routes being overwritten—this isn’t as obvious as installed routes, but BGP (for instance), can only advertise what is installed in the local table; hence if a route it has installed is overwritten, the process needs to know to stop advertising the route
  • Routes being removed from the routing table—perhaps even less obvious, but some routing protocols (BGP is one) allow for multihop routes; when the next hop is removed, any routes using that next hop need to be removed as well
  • Connected interfaces removed—this is often handled as a route removal, but it impacts more than just multihop routes; removing a connected route implies loss of reachability to a specific set of Continue reading