Updating the DNS Registration Model to Keep Pace with Today’s Internet.

CloudFlare is, arguably, the largest third-party DNS Authoritative operator in the world. We manage well over 1 million domains and have registrations in almost every TLD open for registrations. Our role as a DNS operator is to maintain customer information and publish their records in the global DNS.

In this blog, we’ll introduce a significant problem that DNS operators like CloudFlare face when trying to provide the best possible experience to our customers. If you are a CloudFlare customer, you’ll remember during the sign up process you were asked to login to your registrar account in order to change your nameservers (NS). The absence of an automated process for changing NS records not only makes our signup process one step longer than we’d like, it also prevents CloudFlare, and other 3rd party DNS operators, from doing a slew of other things that would benefit customers and the Internet as a whole.

Note: In this blog we’ll use the term DNS Operator mainly in the context of operators that provide Authoritative DNS service. This is sometimes called Managed DNS service.

Manual Updates

For those who are not yet CloudFlare customers, let’s run through the sign up process:

When CloudFlare customers enable Continue reading

Networking Field Day 9: Fresh Perspectives on Open Networking

The community-selected delegates of Networking Field Day 9 #NFD9 are coming to Cumulus Networks on February 11, 12:30pm-2:30pm PST, to learn more about open networking – and it’s going to be live streamed for everyone, so mark your calendar.

We’ve assembled a team of industry experts from Cumulus Networks to discuss with 13 NFD9 delegates data center evolution and what makes us different.

The topics to be presented are:

  • Overview and what makes Cumulus Linux compelling — JR Rivers, co-founder and CEO
  • Data center architectures and how we make it easier to build networks — Dinesh Dutt, Chief Scientist
  • Data center network operations and how we make it easier to manage networks — Matt Peterson, Office of the CTO
  • Real world examples, from a network admin to a cloud admin — David Sinn, Customer Solutions Engineer

Networking Field Day is not just a one-way presentation; it brings us together with independent thought leaders to share information and opinions in a presentation and discussion format. If you’re a networking technologist, this is a great opportunity for you to join the live stream and participate in the discussions on Twitter #NFD9 and @CumulusNetworks. If you’ve heard about open Continue reading

Network Break 27

Coffee, doughnuts and networking. A perfect combination.

Author information

Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus.

TwitterFacebookGoogle+LinkedIn

The post Network Break 27 appeared first on Packet Pushers Podcast and was written by Greg Ferro.

From VIRL to IOU and Back

When VIRL first came out everyone jumped on the bandwagon, including myself. Some of us have had it before it was officially released to the public...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

EIGRP SIA (Stuck-In-Active) through animations.

EIGRP SIA (Stuck-In-Active) process through animations: “Active” = Actively looking for a route to a network (Successor) Without SIA Browse in separate page With SIA Browse in separate pageFiled under: Animation, Routing protocols Tagged: EIGRP, feasible successor, sia, sia-query, sia-reply, stuck-in-active, successor

EIGRP SIA (Stuck-In-Active) through animations.

EIGRP SIA (Stuck-In-Active) process through animations: “Active” = Actively looking for a route to a network (Successor) Without SIA Browse in separate page With SIA Browse in separate pageFiled under: Animation, Routing protocols Tagged: EIGRP, feasible successor, sia, sia-query, sia-reply, stuck-in-active, successor

New CCIE RSv5 Workbook Troubleshooting & Full Scale Labs Posted

Troubleshooting Lab 3 and Full Scale Lab 3 have now been added to the CCIE RSv5 Workbook!

The new Troubleshooting Lab 3 uses the Full Scale Lab 1 logical topology, but breaks all of the protocols you’ve previously built. I suggest you take your time with each ticket so that you can fully digest why each fault occurs. Practice your time and knowledge skills by taking the Troubleshooting Lab 3 challenge!

Full Scale Lab 3 is built on a brand new logical topology, and has a strong focus in MPLS and BGP technologies. The solution guide features detailed breakdowns of each topic domain to give you a better understanding of the solutions used to solve each task. Keep in mind that there are multiple ways to solve most problems.

For discussion on these new labs visit our online community, IEOC.

Enjoy!

Cisco offers ACI alternative for Nexus 9000 switches

Cisco is adding a new control plane capability to its Nexus 9000 switches for customers not yet opting for or needing a full-blown application policy infrastructure.Cisco’s BGP Control Plane for VXLAN is designed to appeal to operators of multitenant clouds looking for familiar BGP routing protocol features with which to scale their networks and make them more flexible for the demands of cloud networking. VXLAN, which scales VLAN segmentation to 16 million endpoints, does not specify a control plane and relies on a flood-and-learn mechanism for host and endpoint discovery, which can limit scalability, Cisco says.To read this article in full or to leave a comment, please click here

Path MTU discovery in practice

Last week, a very small number of our users who are using IP tunnels (primarily tunneling IPv6 over IPv4) were unable to access our services because a networking change broke "path MTU discovery" on our servers. In this article, I'll explain what path MTU discovery is, how we broke it, how we fixed it and the open source code we used.

Tunnel

source

First there was the fragmentation

When a host on the Internet wants to send some data, it must know how to divide the data into packets. And in particular it needs to know the maximum size of packet. The maximum size of a packet a host can send is called Maximum Transmission Unit: MTU.

The longer the MTU, the better for performance, but the worse for reliability, because a lost packet means more data to be retransmitted and because many routers on the Internet can't deliver very long packets.

The fathers of the Internet assumed that this problem would be solved at the IP layer with IP fragmentation. Unfortunately IP fragmentation has serious disadvantages and it's avoided in practice.

Do-not-fragment bit

To work around fragmentation problems the IP layer contains a "Don't Fragment" bit on every IP packet. Continue reading

A Baker’s Dozen, 2014 Edition

bakersdozen-f

As is our annual tradition, this blog provides a year-end review of how the Internet providers at the top of our IP Transit Intelligence global rankings (formerly, Renesys’ Market Intelligence) fared over the previous year.  The structure and performance of the Internet remains a huge blind spot for most enterprises, even those critically dependent on it for business operations.  Whether it’s the next 3 billion people coming online, poor performance due to suboptimal routing, or security breaches of a trust-based Internet infrastructure, Dyn provides critical insight into the structure and performance of the Internet, both real-time and historical, via its Internet Intelligence products.  More importantly, our services help our customers make the changes necessary to optimize Internet availability, reliability, and reach.  This blog reviews a single very small slice of our data related to the sizes of the top global players as it pertains to the markets and customers they serve.

Back in 2008, we chose to look at the 13 providers that spent at least some time in the Top Ten that year, hence the name “Baker’s Dozen“.  We repeated that exercise in 2009, 2010, 2011, Continue reading

From VIRL to IOU and Back

When VIRL first came out everyone jumped on the bandwagon, including myself. Some of us have had it before it was officially released to the public. Cisco’s VIRL is really a good piece of software,...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

From VIRL to IOU and Back

When VIRL first came out everyone jumped on the bandwagon, including myself. Some of us have had it before it was officially released to the public. Cisco’s VIRL is really a good piece of software,...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

From VIRL to IOU and Back

When VIRL first came out everyone jumped on the bandwagon, including myself. Some of us have had it before it was officially released to the public. Cisco’s VIRL is really a good piece of software,...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

Data-Driven RESTful API Testing for Java

This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody

In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM

Data-Driven RESTful API Testing for Java

This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody

In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM

The Scenario

Lets take a very simple example REST API

GET, PUT: /v2/foo

Step 1: The Solution Components

The solution uses the following components

The parameterized runner will run run a test multiple times given a bunch of parameters. This way we can write one test, specifiy our parameters in YAML and let JUnit do the hard work!

Step 2: Writing the YAML file

Here's a sample YAML file:

---
- name: testGetAllFoo
  operation: GET
  uri Continue reading
1 … 3,616 3,617 3,618 3,619 3,620 … 3,819