BGPsec and Reality

From time to time, someone publishes a new blog post lauding the wonderfulness of BGPsec, such as this one over at the Internet Society. In return, I sometimes feel like I am a broken record discussing the problems with the basic idea of BGPsec—while it can solve some problems, it creates a lot of new ones. Overall, BGPsec, as defined by the IETF Secure Interdomain (SIDR) working group is a “bad idea,” a classic study in the power of unintended consequences, and the fond hope that more processing power can solve everything. To begin, a quick review of the operation of BGPsec might be in order. Essentially, each AS in the AS Path signs the “BGP update” as it passes through the internetwork, as shown below.

In this diagram, assume AS65000 is originating some route at A, and advertising it to AS65001 and AS65002 at B and C. At B, the route is advertised with a cryptographic signature “covering” the first two hops in the AS Path, AS65000 and AS65001. At C, the route is advertised with a cryptogrphic signature “covering” the first two hops in the AS Path, AS65000 and AS65002. When F advertises this route to H, at Continue reading

One model at a time: Integrating and running Deep Learning models in production at EyeEm

This is a guest by Michele Palmia, now @EyeEm, good times @IBM, @UniPd and @UCC.

We’ve now been running computer vision models in production at EyeEm for more than three years - on literally billions of images. As an engineer involved in building the infrastructure behind it from scratch, I both enjoyed and suffered the many technical challenges this task raised. This journey has also taught me a lot about managing processes and relationships with different teams, tasks of an especially challenging nature in a dynamic startup environment.

What follows is an attempt to consolidate the computer vision pipeline history at EyeEm, some of the challenges we had to face, some of the learning we’ve gained, and a glimpse into its future.

Index the world’s photos

New Book: Explain the Cloud Like I’m 10

What is the cloud? Why is it called a cloud? How does the cloud work? What does it mean when something is 'in the cloud'?

I wrote a new book: Explain the Cloud Like I'm 10, answering those questions for the complete beginner. It makes the perfect gift for Halloween. And Thanksgiving. And Christmas. Oh, and birthdays too!

The irony is, if you read HighScalability, you're not the target audience :-) Explain the Cloud Like I'm 10 is for people who hear about the cloud everyday and have wondered what it is.

Talking with people outside the tech bubble I've found the cloud is still a mystery. I think that's because almost every explanation of the cloud I could find was a rewording of the same unhelpful technobabble.

In Explain the Cloud Like I'm 10 I've used a lot of pictures and a lot of examples. I go slow and easy. I try really hard to build up an intuitive understanding of what the cloud is and how it works.

If you know of anyone who might benefit from a book like this, I'd appreciate it if you'd pass it on.

thanks! 

 

History of computers, part 2 — TCP/IP owes a lot to Xerox PUP

To understand where we are going, we first must understand where we have been. This applies equally well to the history of nations across the globe as it does to computers and computer networking.With that in mind, we’re taking a slow (somewhat meandering) stroll through the history of how computers talk to each other. Last time, we talked a bit about dial-up Bulletin Board Systems (BBSs) – popular through the 1980s and the bulk of the 1990s.Also on Network World: The hidden cause of slow Internet and how to fix it Today, I’d like to talk about one of the most influential, but rarely discussed, networking protocol suites: PARC Universal Packet (PUP).To read this article in full or to leave a comment, please click here

History of computers, part 2 — TCP/IP owes a lot to Xerox PUP

To understand where we are going, we first must understand where we have been. This applies equally well to the history of nations across the globe as it does to computers and computer networking.With that in mind, we’re taking a slow (somewhat meandering) stroll through the history of how computers talk to each other. Last time, we talked a bit about dial-up Bulletin Board Systems (BBSs) – popular through the 1980s and the bulk of the 1990s.Also on Network World: The hidden cause of slow Internet and how to fix it Today, I’d like to talk about one of the most influential, but rarely discussed, networking protocol suites: PARC Universal Packet (PUP).To read this article in full or to leave a comment, please click here

IBM casts Watson as the brains behind IoT

IBM is trying to be the brains behind the increasingly brawny presence of IoT in all corners of the business world, using its AI expertise to offer insight into piles of new data, provision new implementations, and help drive decision-making.The company thinks that its Watson AI is the ideal back-end for IoT, which is an area that few companies are addressing so directly. There’s a great deal of uptake around technology that connects new devices to the network, but comparatively little that actually does meaningful work on the floods of new data provided as a consequence.+ALSO ON NETWORK WORLD: REVIEW: Turbonomic, VMware virtualization management tools + Cisco snaps up streaming-data startup PerspicaTo read this article in full or to leave a comment, please click here

Worth Reading: The Economics of DDoS

These days, there are typically three parties to a distributed denial of service attack. You probably know about two of them: the perpetrator and the target. Less well known is the vast and growing number of third-party providers of DDoS attacks as a service. Brazenly advertising their wares online, these providers will perform an attack on the customer’s behalf and provide detailed reports of their accomplishments. Their fees are shrinking due to rapidly expanding competition and the abundant supply of readily available attack resources, such as botnets. As a result, the DDoS attack business is very much a buyer’s market. —Kevin Whalen @Arbor

The post Worth Reading: The Economics of DDoS appeared first on rule 11 reader.

Why network operations should care about AppDynamics

Earlier this year, Cisco surprised many industry watchers when it forked out a cool $3.7 billion to acquire AppDynamics, which was about 2x the valuation it had going into its IPO. Most people know Cisco as the de facto standard and market leader in networking. AppDynamics lives higher up the stack and provides a view into how applications are performing by collecting data from users, applications, databases and servers.One might surmise that Cisco will use AppDynamics to go after a different buyer, and that assumption is correct. AppDynamics paves the way for Cisco to have a meaningful discussion with lines of business, application developers and company leaders. However, thinking AppDynamics isn’t for Cisco’s current core customers, network engineers, is wrong. AppDynamics can provide an equal amount of value to that audience.To read this article in full or to leave a comment, please click here

Why network operations should care about AppDynamics

Earlier this year, Cisco surprised many industry watchers when it forked out a cool $3.7 billion to acquire AppDynamics, which was about 2x the valuation it had going into its IPO. Most people know Cisco as the de facto standard and market leader in networking. AppDynamics lives higher up the stack and provides a view into how applications are performing by collecting data from users, applications, databases and servers.One might surmise that Cisco will use AppDynamics to go after a different buyer, and that assumption is correct. AppDynamics paves the way for Cisco to have a meaningful discussion with lines of business, application developers and company leaders. However, thinking AppDynamics isn’t for Cisco’s current core customers, network engineers, is wrong. AppDynamics can provide an equal amount of value to that audience.To read this article in full or to leave a comment, please click here

Today, $50 off Sennheiser’s HD1 In-Ear Wireless Headphones – Deal Alert

The HD1 In-Ear Wireless headphones from industry veteran Sennheiser combines immaculate sound quality with take-anywhere mobility. Utilizing a sleek ergonomic design and crafted with high-quality materials, this premium headset exudes luxury. Exceptional wireless hi-fi sound is assured thanks to Bluetooth 4.1 with ACC and Qualcomm apt-X technologies. Featuring NFC for simple one touch pairing, an integrated microphone and ten-hour battery life, the HD1 In-Ear Wireless is a perfect companion to mobile devices. The typical list price of the HD1's is discounted 25% for today only, so you can get them for $149.95. See this deal now on Amazon.To read this article in full or to leave a comment, please click here

Why does one NGINX worker take all the load?

Why does one NGINX worker take all the load?

Scaling up TCP servers is usually straightforward. Most deployments start by using a single process setup. When the need arises more worker processes are added. This is a scalability model for many applications, including HTTP servers like Apache, NGINX or Lighttpd.

Why does one NGINX worker take all the load?CC BY-SA 2.0 image by Paul Townsend

Increasing the number of worker processes is a great way to overcome a single CPU core bottleneck, but opens a whole new set of problems.

There are generally three ways of designing a TCP server with regard to performance:

(a) Single listen socket, single worker process.

(b) Single listen socket, multiple worker processes.

(c) Multiple worker processes, each with separate listen socket.

Why does one NGINX worker take all the load?

(a) Single listen socket, single worker process This is the simplest model, where processing is limited to a single CPU. A single worker process is doing both accept() calls to receive the new connections and processing of the requests themselves. This model is the preferred Lighttpd setup.

Why does one NGINX worker take all the load?

(b) Single listen socket, multiple worker process The new connections sit in a single kernel data structure (the listen socket). Multiple worker processes are doing both the accept() calls and processing of the requests. This model enables some spreading of the inbound Continue reading

A Sample Makefile for Publishing Blog Articles

As some readers may already know, this site has been running on a static site generator since late 2014/early 2015, when I migrated from WordPress to Jekyll on GitHub Pages. I’ve since migrated again, this time to Hugo on S3/CloudFront. Along the way, I’ve taken an interest in using make and a Makefile to help automate certain tasks at the CLI. In this post, I’ll share how I’m using a Makefile to help with publishing blog articles.

If you’re not familiar with make or its use of a Makefile, have a look at this article I wrote on using a Makefile with Markdown documents, then come back here.

In general, the process for publishing a blog post using Hugo and S3/CloudFront basically looks like this:

  1. Write the blog post. (I haven’t found a tool to automate this yet!)
  2. Put the blog post into the right section of the Hugo directory tree. (In my setup, it’s in the content/post directory.)
  3. Build the static site using hugo.
  4. Upload the resulting HTML files to the appropriate S3 bucket.
  5. Invalidate the appropriate URLs (paths) in AWS CloudFront so that the CDN picks up the new files/pages.

Some of these steps Continue reading

Automated Testing & Intent Verification for Network Operations

The most important part of writing quality software is testing. Writing unit tests provide assurance the changes you’re making aren’t going to break anything in your software application. Sounds pretty great, right? Why is it that in networking operations we’re still mainly using ping, traceroute, and human verification for network validation and testing?

The Network is the Application

I’ve written in the past that deploying configurations faster, or more generally, configuration management, is just one small piece of what network automation is. A major component much less talked about is automated testing. Automated testing starts with data collection and quickly evolves to include verification. It’s quite a simple idea and one that we recommend as the best place to start with automation as it’s much more risk adverse to deploying configurations faster.

In our example, the network is the application, and unit tests need to be written to verify our application (as network operators) has valid configurations before each change is implemented, but also integrations tests are needed to ensure our application is operating as expected after each change.

DIY Testing

If you choose to go down the DIY path for network automation, which could involve using an open source Continue reading

1 … 1,847 1,848 1,849 1,850 1,851 … 3,833