Reaction: Devops and Dumpster Fires

Networking is often a “best effort” type of configuration. We monkey around with something until it works, then roll it into production and hope it holds. As we keep building more patches on to of patches or try to implement new features that require something to be disabled or bypassed, that creates a house of cards that is only as strong as the first stiff wind. It’s far too easy to cause a network to fall over because of a change in a routing table or a series of bad decisions that aren’t enough to cause chaos unless done together. —Networking Nerd

Precisely.

But what are we to do about it. Tom’s Take is that we need to push back on applications. This, also, I completely agree with. But this only brings us to another problem—how do we make the case that applications need to be rewritten to work on a simpler network? The simple answer is—let’s teach coders how networks really work, so they can figure out how to better code to the environment in which their applications live. Let me be helpful here—I’ve been working on networks since somewhere around 1986, and on computers and electronics since Continue reading

Worth Reading: Your comfort zone may destroy the world

Journalism has been on life support since the advent of social media, but this past year we have witnessed the quick, painful death of truth, and it may be gone forever. Put a comfortable lie in an echo chamber, and nobody will challenge it. It will reverberate until it is accepted as actually true. Then, the willfully ignorant will shout it as loudly as they can. It may be their truth, but that does not make it true. —Shelly Palmer

The post Worth Reading: Your comfort zone may destroy the world appeared first on 'net work.

Wroth Reading: Exascale might prove difficult

The supercomputing industry is accustomed to 1,000X performance strides, and that is because people like to think in big round numbers and bold concepts. Every leap in performance is exciting not just because of the engineering challenges in bringing systems with kilo, mega, tera, peta, and exa scales into being, but because of the science that is enabled by such increasingly massive machines. But every leap is getting a bit more difficult as imagination meets up with the constraints of budgets and the laws of physics. The exascale leap is proving to be particularly difficult, and not just because it is the one we are looking across the chasm at. —The Next Platform

The post Wroth Reading: Exascale might prove difficult appeared first on 'net work.

Spiral Windows

The post Spiral Windows appeared first on 'net work.

Worth Reading: Joining forces against mass collection

Some of the world’s biggest companies and organizations joined forces with Microsoft to fend off the U.S. government’s habitual practice of demanding access to customers’ personal information. Microsoft filed a lawsuit against the U.S. Department of Justice (DOJ) in April, arguing it is unconstitutional to seize computer data from third parties and subsequently issue gag orders so companies cannot notify customers. Now a motley crew of institutions, organizations, and businesses — like Apple, Google, Delta Air Lines, Mozilla, The Washington Post, Fox News, the American Civil Liberties Union, the U.S. Chamber of Commerce — have joined the cause by signing and submitting an amicus brief. —The Stream

The post Worth Reading: Joining forces against mass collection appeared first on 'net work.

Worth Reading: IPv6 versus v4 performance map

This is a world map showing the average value of the relative performance of observed connections in IPv6 compared to IPv4. The values are in units of milliseconds. For each observed dual stack end device, the TCP SYN exchange connection times are recorded and the best IPv6 and IPv4 Round Trip Times (RTT) are retained. …. Where IPv6 is faster, the IPv6 RTT is smaller than the IPv4 RTT and the result of the subtraction is a negative number, displayed as a shade of green in the above map. Where IPv4 is faster the result of the subtraction is a positive number, displayed as a shade of red in the map. —APNIC

The post Worth Reading: IPv6 versus v4 performance map appeared first on 'net work.

Nenshou Fire: Recoil

My daughter has started a new fiction series on her blog; I’ll just link to it here for anyone who’s interested.

A cold circular object is pressed to my head, a hand reaching around to cover my mouth before I can make a sound. My eyes squeeze shut reflexively. Is this it? Is this how I’m going to die? After so much time of hiding, running, escaping the war around me, am I finally reaching the end of my life? My heart explodes inside me, waiting for the explosion of powder, marking the final moments of my life…but nothing comes. I open my eyes, surprised. What is this? Why hasn’t he made that one little motion that would end my life? —Nenshou Fire

The post Nenshou Fire: Recoil appeared first on 'net work.

Worth Reading: Big buffers and reality

This whole big buffer nonsense has gotten out of hand (kinda like Trump and his H-yuge Border Wall or Clinton and her lack of ethics) and it’s time for this issue to be put to rest. For the last few years, the main messaging from Arista has been that you need big buffers for everything, especially for big data applications. I’m not saying it doesn’t make for a good marketing soundbite… —Packet Pushers

The post Worth Reading: Big buffers and reality appeared first on 'net work.

Worth Reading: Binding to an IPv6 subnet

In the original framework of the IP architecture, hosts had network interfaces, and network interfaces had single IP addresses. The list of active network interfaces, and the manner in which they acquire IP addresses, either by a static configuration or by some dynamic mechanism via a query to the local network, is specified in a boot time configuration file. —Potaroo

The post Worth Reading: Binding to an IPv6 subnet appeared first on 'net work.

Enough with “firewalls”

A mythical conversation on firewalls, and some observations

“Let’s put the firewall here, so it can protect the servers in this part of the network.”
“How would you define a firewall?”
“You know, the appliance that, well, protects servers and other machines from outside threats…”
“And how does it do this?”
“By filtering the traffic using some sort of stateful mechanism, and network address translation, and deep packet inspection, and blocking certain ports, and…”
“In other words, it’s a bunch of services on a single device?”
“Yes…”
“Then maybe we should think in terms of services instead of appliances.”

I’ve never actually had this conversation, but I’ve had many similar ones across my times as a network engineer. I’ll admit, in fact, that it took a lot of conversations like this (with me on the receiving end) to grock the difference between a service and an appliance, and to see that my constant thinking in terms of appliances (or even devices) was actually hindering my ability to design networks. Let me give you two specific reasons you should think of security services, instead of security appliances.

First, When you disaggregate the “things a firewall Continue reading

Worth Reading: HPE trims back

The trouble that Dell and HPE found themselves in is that they did not build platforms fast enough as the market shifted away from selling or reselling licensed software and putting platforms together piecemeal for customers and towards companies using a public cloud as a platform or companies using a set of open source components figuring it out on their own. Frankly, companies like IBM, HPE, and Dell charge too much for such integration services, they take too long, and companies are always dependent on others to make changes to that platform because they lack expertise. —The NExt Platform

The post Worth Reading: HPE trims back appeared first on 'net work.

Worth Reading: Ditch the pitfalls of layer 2 in the data center

If you’re operating on the IT side, you’re likely all too familiar with troubleshooting an unexpected outage caused by what should be a simple upgrade to a switch, or bringing a new server onto the network. While modern data center design for private and public clouds has been rapidly evolving from traditional Layer 2 networks to Layer 3 centric leaf-spine architecture, too many of us are still dealing with the headaches that come from L2 technologies such as Multichassis Link Aggregation (MLAG), First Hop Redundancy Protocol (FHRP), and Spanning Tree Protocol (STP). —The New Stack

The post Worth Reading: Ditch the pitfalls of layer 2 in the data center appeared first on 'net work.

Grow Up

The post Grow Up appeared first on 'net work.

Worth Reading: Ransomware and backups

Read through the recent Wall Street Journal ransomware article and you’ll find some great stats on the growing threat and cost. One thing you won’t find: the word “backup.” We’re happy to see ransomware finally getting the attention it deserves, but why discuss the problem and leave out the obvious, simple antidote? It’s like an article on a bike theft epidemic that fails to mention that none of the bikes were locked up. —Cloud Security Alliance

The post Worth Reading: Ransomware and backups appeared first on 'net work.

Worth Reading: Hardware slaves to the master algorithm

Over the long course of IT history, the burden has been on the software side to keep pace with rapid hardware advances—to exploit new capabilities and boldly go where no benchmarks have gone before. However, as we swiftly ride into a new age where machine learning and deep learning take the place of more static applications and software advances are far faster than chipmakers can tick and tock to, hardware device makers are scrambling. —The Next Platform

The post Worth Reading: Hardware slaves to the master algorithm appeared first on 'net work.

snaproute Go BGP Code Dive (10): Moving to Established

In the last post on this topic, we traced how snaproute’s BGP code moved to the open state. At the end of that post, the speaker encodes an open message using packet, _ := bgpOpenMsg.Encode(), and then sends it. What we should be expecting next is for an open message from the new peer to be received and processed. Receiving this open message will be an event, so what we’re going to need to look for is someplace in the code that processes the receipt of an open message. All the way back in the fifth post of this series, we actually unraveled this chain, and found this is the call chain we’re looking for—

• func (st *OpenSentState) processEvent()
• st.fsm.StopConnectRetryTimer()
• bgpMsg := data.(*packet.BGPMessage)
• if st.fsm.ProcessOpenMessage(bgpMsg) {
  • st.fsm.sendKeepAliveMessage()
  • st.fsm.StartHoldTimer()
  • st.fsm.ChangeState(NewOpenConfirmState(st.fsm)) }

I don’t want to retrace all those steps here, but the call to func (st *OpenSentState) processEvent() (around line 444 in fsm.go) looks correct. The call in question must be a call to a function that processes an event while the peer is in the open state. This call seems to satisfy both Continue reading

Worth Reading: gRPC

HTTP’s convenience comes with a huge performance trade-off, which takes us back to the issue of finding the most optimal communication framework for microservices. Enter gRPC, the modern, lightweight communication protocol from Google. It’s a high-performance, open-source universal remote procedure call (RPC) framework that works across a dozen languages running in any OS. Within the first year of its launch, gRPC was adopted by CoreOS, Netflix, Square, and Cockroach Labs among others. —New Stack

The post Worth Reading: gRPC appeared first on 'net work.

Worth Reading: On decomposing systems

Flexibility (we tend to call it agility) and faster development times remain top of mind today. Comprehensibility less so, but perhaps we should be paying more attention there? Say you’re all bought into cloud native microservices based architectures, is splitting your system up into multiple independent services going to help you achieve your goals? —The Morning Paper

The post Worth Reading: On decomposing systems appeared first on 'net work.

Bridge to the Ocean

The post Bridge to the Ocean appeared first on 'net work.

Worth Reading: Do we still need OSPF areas?

When OSPF was created it used areas to minimize the size of the topology graph (and the time it took to run Dijkstra algorithm). In the meantime, the CPU speeds increased by orders of magnitude, and graph computation algorithms got a few optimization boosts (incremental SPF for example). —IPspace

The post Worth Reading: Do we still need OSPF areas? appeared first on 'net work.