Collection of useful, relevant or just fun places on the Internets for 24th May 2014 and a bit commentary about what I’ve found interesting about them:
Google: ‘EVERYTHING at Google runs in a container’ • The Register – Containers are going to add to the complexity of virtual networking. With Google saying that they run their infrastruture on containers, expect to see a lot o interested in Docker & CoreOS. xThe company is able to do this because of how the tech works: Linux containerization is a way of sharing parts of a single operating system among multiple isolated applications, as opposed to virtualization which will support multiple apps with their own OS on top of a single hypervisor.
Declarative and Procedural Programming (and How I Got It all Wrong) « ipSpace.net by @ioshints – I am also struggling with the concept of declarative programming. The lack of precision means that execution of a given policy has the potential to be flawed and inaccurate. Did I say implementation details? Isn’t that procedural programming? No, we’re still in the realm of declarative programming (we never tell the switches how to implement VLANs, do we?), but working at a lower level of abstraction and dealing with how individual devices (or vendors) expect things to be declared. So I agree with Ivan, it’s confusing.
I’m lacking conviction that the path of imprecise declaration is a smooth one.
LiveAction Introduces its Single Pane of Glass, Next-Generation, LiveAction 4.0 – LiveAction – LiveAction released Version 4 of their product. I saw a live demo at TechFieldDay and I’m hoping to spend more time with this product in the near future. The visualisation around the QoS and data path really caught my attention.
SteelHead: Troubleshooting Riverbed Steelhead W… | Riverbed Splash – Guide to troubleshooting Riverbeed Steelhead platforms from engineers on their TAC.
A group of Riverbed TAC engineers have worked on an internal troubleshooting document to kick start new TAC engineers. It describes the design of the Steelhead appliance, the working of the optimization service and the setup of optimized TCP sessions, installation and operation related issues, various latency optimization related issues, on how to use the various CLI tools to troubleshoot and how you can deal with the contents of the system dump.
Nice work. The introduction to the WAN Optimisation is very well done.
On a side note, self publishing means that vendors can and should publish more documentation like this. Why aren’t they ?
Network architect perceptions of SDN, cloud, and the future of networking — Gigaom Research – This is my latest analyst report for GigaOm Research on the adoption of SDN. Of particular note in this research is survey and the survey responses showed a number of surprising results. In January 2014 Gigaom Research conducted a survey of network architects, engineers, and managers on their experiences with the cloud and SDN in today’s market. The results from more than 250 responses covering a survey audience of large companies with multiple data centers and extensive experience provide some startling insight into the reality of SDN.
The End of Undetected BGP Route Hijacking – This PDF from Renesys talks about the use of large scale analytics to monitor public BGP routing table to detect and analyse changes. Some of the changes are accidental and some are more suspicious. Worth reading and including into your network security thinking.
Hat Tip to Wes Felter at Hack The Planet in Exile blog
RFC 7196 – Making Route Flap Damping Usable – Interesting work on route flap damping. It appears that someone seems to believe that RFD is still needed and picked up on some old research into the better default values. Since the vendors all have different defaults (as listed in the RFC) I can’t see that this is anything useful since it will another IETF RFC that get ignored.
Can’t help but wonder if this is a “vanity RFC” for the authors. The IETF should be focussing on producing something useful. The authors actually point out that they don’t expect anyone to implement the proposed changes.
Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes’ normal convergence process.