You might have seen, in the recent pandemic, advertisements for masks where “one size fits all.” You might see the same sort of thing for gloves, or maybe even flip-flops—but what you will rarely find, in the networking world, is anything that fits all. It is, in fact, challenging to explain the plethora of protocols designed and deployed by the networking community to solve any possible problem.
Everyone is aware that it always takes longer to find a problem in a network than it should. Moving through the troubleshooting process often feels like swimming in molasses—you’re pulling hard, and progress is being made, but never fast enough or far enough to get the application back up and running before that crucial deadline. The “swimming in molasses effect” doesn’t end when the problem is found either—repairing the problem requires juggling a thousand variables, most of which are unknown, combined with the wit and sagacity of a soothsayer to work with vendors, code releases, and unintended consequences.
Hosts Roopa Prabhu and Pete Lumbis are joined by a special guest to the podcast, Russ White! The group come together virtually to discuss what we should think about when it comes to routing protocols in the datcenter. What are the tradeoffs when using traditional protocols like OSPF or BGP? What about new protocols like RIFT or a hybrid approach with things like BGP-link state? Spoiler alert: it depends.
With the massive move to working from home—a trend that probably will not be totally reversed even once things return to “semi-normal” (whatever that eventually looks like), security postures need to be thought and rethought to make certain they are the right thing—like disabling split tunneling for users connected through a VPN.
There is never enough. Whatever you name in the world of networking, there is simply not enough. There are not enough ports. There is not enough speed. There is not enough bandwidth. Many times, the problem of “not enough” manifests itself as “too much”—there is too much buffering and there are too many packets being dropped.
It is not unusual in the life of a network engineer to go entire weeks, perhaps even months, without “getting anything done.” This might seem odd for those who do not work in and around the odd combination of layer 1, layer 3, layer 7, and layer 9 problems network engineers must span and understand, but it’s normal for those in the field. —LighTALK @ECI
While those working in the network engineering world are quite familiar with the expression “it is always something!,” defining this (often exasperated) declaration is a little trickier. The wise folks in the IETF, however, have provided a definition in RFC1925. Rule 7, “it is always something,” is quickly followed with a corollary, rule 7a, which says: “Good, Fast, Cheap: Pick any two (you can’t have all three).”