Worth Reading: Open Flow Controller Performance

OpenFlow’s architecture is inefficient, and caps performance while sucking unnecessary power. That’s the conclusion of a bunch of Comp. Sci boffins from researchers at Australian brain box Data61 and Sydney University, who assessed four major OpenFlow controllers – NOX, Maestro, Floodlight and Beacon. Their paper is at Arxiv. Poor old OpenDaylight was also tested but not reported: “the performance [was] too low to provide any insightful comparison”. To cut to the chase: none of the controllers tested got anywhere close to line speed, whether running on a network processor (based on Tilera chips), or on a Xeon E5-2450-based server (more on the configurations later). —The Register

The post Worth Reading: Open Flow Controller Performance appeared first on 'net work.

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—

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

Worth Reading: The Internet of Poorly Working Things

Of course, not all connected devices are so easily mocked; some devices are dead serious: home security, HVAC, almost any kitchen appliance — even our very smart toaster. And it’s not that the IoT doesn’t work. The situation is actually worse than that: The IoT randomly works. Devices stop and restart, they require visit to unsupportive customer support pages and helpless Your Call Is Important To US help lines (and now we have chatbots). If you think I exaggerate, google “Nest trouble” or “smart bulbs trouble”. We don’t have to look around much to find the culprit: with its razor-thin margins, the Consumer Electronics (CE) culture offers a big fat target for our inquisition. —Monday Note

The post Worth Reading: The Internet of Poorly Working Things appeared first on 'net work.

Worth Reading: Disregarding Security Warnings

Software developers listen up: if you want people to pay attention to your security warnings on their computers or mobile devices, you need to make them pop up at better times. A new study from BYU, in collaboration with Google Chrome engineers, finds the status quo of warning messages appearing haphazardly—while people are typing, watching a video, uploading files, etc.—results in up to 90 percent of users disregarding them. Researchers found these times are less effective because of “dual task interference,” a neural limitation where even simple tasks can’t be simultaneously performed without significant performance loss. Or, in human terms, multitasking. —Brigham Young University

The post Worth Reading: Disregarding Security Warnings appeared first on 'net work.

On the ‘net: BGP—the most successful virus

This Weekly Show episode was recorded live at IETF 96 in Berlin in July 2016. Greg Ferro and several guests discuss the state of routing protocols such as BGP, and explore different approaches to routing, like Facebook’s Open/R initiative. They also debate issues around telemetry, network disaggregation, and whether enterprises should participate in the IETF to influence vendor product development.

Listen to the podcast over at Packet Pushers

The post On the ‘net: BGP—the most successful virus appeared first on 'net work.

Worth Reading: Intel’s Snap

Scale is creating the demand for new enterprise tooling to better understand and manage ever disparate workloads across devices, cars, buildings, etc. There were examples of this trend in almost all of the IDF keynotes and sessions we attended as well as additional discussions that focused on how Snap, Grafana, and platforms such as Kubernetes serve as ways to manage workloads and lots of data. —The New Stack

The post Worth Reading: Intel’s Snap appeared first on 'net work.

Worth Reading: Cloud Key and Key Escrow

The problem Apple wanted to solve is this. Suppose that you have some sort of iToy — an iPhone, an iPad, etc. — or Mac. These systems allow you to back up your keychain to Apple’s iCloud service, where they’re protected by your AppleID (an email address) and password. If you buy a new device from Apple, your keychain can be downloaded to it once you log on to iCloud. (Note: uploading keys to iCloud is optional and disabled by default, though you are prompted about enabling it during device setup.) —CircleID

The post Worth Reading: Cloud Key and Key Escrow appeared first on 'net work.

snaproute Go BGP Code Dive (9): Moving to Open

a href=”http://ntwrk.guru/bgp-code-dive-8/”>In the last session of snaproute BGP code dive—number 8, in fact— I started looking at how snaproute’s BGP moves from connect to open. This is the chain of calls from that post—

• st.fsm.StopConnectRetryTimer()
• st.fsm.SetPeerConn(data)
• st.fsm.sendOpenMessage()
• st.fsm.SetHoldTime(st.fsm.neighborConf.RunningConf.HoldTime, st.fsm.neighborConf.RunningConf.KeepaliveTime)
• st.fsm.StartHoldTimer()
• st.BaseState.fsm.ChangeState(NewOpenSentState(st.BaseState.fsm))

The past post covered the first two steps in this process, so this post will begin with the third step, st.fsm.sendOpenMessage(). Note the function call has st.fm... in the front, so this is a call by reference. Each FSM that is spun up (think of them as threads, or even processes, if you must, to get this concept in your head, even though they’re not) can have its own copy of this function, with its own state. When reading the code to sort out how it works, this doesn’t have much practical impact, other than telling us the sendOpenMessage function we’re looking for is going to be in the FSM file. The function is located around line 1233 in fsm.go:

func (fsm *FSM) sendOpenMessage() {
  optParams := packet.ConstructOptParams(uint32(fsm. Continue reading

Worth Reading: Stream Processing’s Hard Problems

Before we dive into why data access is a hard problem in stream processing, here is some background information. At LinkedIn, we develop and use Apache Samza as our stream processing framework, Apache Kafka as our durable pub-sub messaging pipe, and Databus (and its next generation replacement) for capturing change events from our databases. Our streams infrastructure team gets feedback from application developers across the company (and from the open source community) on scalability, reliability, usability, and other problems that they encounter in their production applications. —LinkedIn Engineering Blog

The post Worth Reading: Stream Processing’s Hard Problems appeared first on 'net work.

Worth Reading: Is Openstack becoming Trumpstack?

Tired of hearing about Pets vs. Cattle? Most of us are. The underlying concept is important. While OpenStack, and most private and public cloud platforms, is geared towards workloads that have resiliency build into the application, many of the folks in the industry just aren’t there yet. The question comes to OpenStack advocates now: Should we push away potential adopters of the platform because they may have workloads that aren’t entirely appropriate for a typical “cloud” infrastructure? —DiscoPosse

The post Worth Reading: Is Openstack becoming Trumpstack? appeared first on 'net work.

Agile

The post Agile appeared first on 'net work.

Worth Reading: Go versus Python performance

It may be that I’m doing something in Python that’s an obvious don’t do or that I’m simply using a very computationally expensive way to achieve my goal, and any experienced Python programmer would suggest I did it a different way. However, for something so simple to see an order of magnitude difference between the two languages either makes Python look very slow, or Go look very fast, or maybe a bit of each, at least for this particular calculation. —Moving Packets

The post Worth Reading: Go versus Python performance appeared first on 'net work.

Worth Reading: Remember the lead time

Disaster recovery is one of those important things that seldom seems to get the attention it deserves. My experience is that most large organizations, and some smaller organizations, have disaster recovery plans that at least get partial testing. —Netcraftsmen

The post Worth Reading: Remember the lead time appeared first on 'net work.

Reaction: Forced Updates

The controversy over Microsoft forcing upgrades on users is in the news again, as the EFF has posted an article once again about the forced upgrades to Windows 10, and the various data collection schemes Microsoft has put in place. I understand the concern, but… A couple of points to consider, starting with forced upgrades—

When I worked in customer support I sometimes wished we had forced upgrades (rather than paid ones, in fact). There are so many times someone doesn’t upgrade past an obvious bug. We would spend hours working around the bug because they didn’t want to upgrade. It probably cost the company I worked for millions of dollars in support a year so we could refrain from saying, “take two upgrades and call me in the morning.”

As an operator, I see the other side of this story—if I don’t need the upgrade, or I’m not hitting the bug, I shouldn’t need to upgrade.

The world of IoT—in fact, the world in which we live, where millions of machines are used as botnets without the knowledge of their owners—is pretty frightening without forced upgrades. I wonder how many millions of dollars a year machines with Continue reading

Worth Reading: Apcera NATS messaging service

With the ever-increasing amounts of data sent and received by today’s applications, developers are turning to tried-and-true technologies to help them address message brokering across different applications, or between different microservices within an application. Stripping the complexity from message brokering at scale is something which Apcera aims to accomplish with its Go-based message broker service NATS. —The New Stack

The post Worth Reading: Apcera NATS messaging service appeared first on 'net work.

Worth Reading: One old guy’s advice

Having grown in my career since college, I have learned many lessons. I started out in computers back in 1986, at the precipice of the “Clone” era. I cut my teeth and my hands by installing chips on memory cards and motherboards, replacing 5.25” floppy discs, and dealing with the jumble of cables on Dual 5MB Winchester hard drives that cost and weighed an arm and a leg. —virtually tied to my desktop

The post Worth Reading: One old guy’s advice appeared first on 'net work.

Worth Reading: IPv6 performance (again)

Every so often I hear the claim that some service or other has deliberately chosen not to support IPv6, and the reason cited is not because of some technical issue, or some cost or business issue, but simply because the service operator is of the view that IPv6 offers an inferior level service as compared to IPv4, and by offering the service over IPv6 they would be exposing their clients to an inferior level of performance of the service. But is this really the case? Is IPv6 an inferior cousin of IPv4 in terms of service performance? —CircleID

The post Worth Reading: IPv6 performance (again) appeared first on 'net work.

On the ‘net: I2RS on Packet Pushers

While Greg was at the IETF in Berlin, Sue Hares and I—the two current co-chairs of the I2RS working group—had a general discussion around what the big idea is and where the working group is headed. You can listen to the recording at Packet Pushers.

The post On the ‘net: I2RS on Packet Pushers appeared first on 'net work.

VIRL on Packet Cloud—Some thoughts

For the last couple of days I’ve been messing with Cisco’s VIRL on Packet’s bare metal service. I don’t do enough labbing now to spend multiple thousands of dollars building a lab in my house, and I want something that I can use from anywhere without opening a lot of holes in my home network when I’m on the road, so the Packet service seems like something useful to get running.

Forthwith, some observations and hints for those who might be thinking about doing this. Some of this might be obvious to other folks, I know, but—maybe me writing them down here will be somehow helpful, and save other folks some time.

An observation—this all feels a little (okay, maybe a lot) clunky’ish. There’s a lot of steps, it takes a long time to set up, etc. There are a lot of moving parts, and they interconnect in interesting ways. Maybe this will all get better over time, but for now, if you’re going to do this, plan on spending at least a half a day, probably more, just getting all the pieces to work.

Some places I ran into trouble, and things I needed to configure that I had Continue reading

Worth Reading: Photographing the Internet

Shuli Hallak photographs the Internet. And when we say she photographs it, we’re not just talking about cool pictures of wires (although those are in her portfolio) but entire worlds that are up and running right under our noses but remain invisible. Her work is helping to demystify the sometimes complicated language surrounding the open Internet and is building a new understanding of how important the open Internet is for people everywhere. —Internet Society

The post Worth Reading: Photographing the Internet appeared first on 'net work.