Continuous Integration Pipeline for Networking

This entry is part 3 of 3 in the series DevOps for Networking

Popular development methodologies like Continuous Integration are usually accompanied by some kind of automated workflow, where a developer checks in some source code, which kicks off automated review, testing, and deployment jobs. I believe the same workflows can be adopted by network engineers.

Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out. Let’s say you want to offload the creation/deletion of DHCP reservations to these junior engineers, but you still want to be able to approve all changes, just as a last line of defense, and a sanity check.

For this, I’m gong to show you how I’m managing my own home DHCP server (ISC) with Gerrit, Jenkins, and Ansible.

 

Config Review and Versioning with Git and Gerrit

I mentioned in a previous post that version control is an important component of efficiently managing network infrastructure. I’m going to take it a step further than what most are doing with RANCID, which is traditionally used at the end of a Continue reading

On Losing

When I got off the phone, I knew I’d blown it. I’d gotten so wrapped up in the discussion on eVPNs that I might have crossed over that magical line between, “this is a really neat technology,” to, “this technology will solve world hunger.” It brought back to mind my first “real fight” in the world of technology, a long ago argument between two network operating systems (Novell Netware and Banyan Vines).

At the time, I was a buck sergeant in the USAF assigned to the Small Computer Support Office. We were building a new base backbone, and trying to decide what network operating system to standardize on as an organization (as a base). The decision had come down to two options — Novell Netware and Banyan Vines. I was in the camp that wanted Vines. In fact, I’d written two papers (long’ish, on the order of 80 pages each), going through the positives and negatives in each direction. I’d been to a number of meetings, and we had small networks set up running both in our lab. In the end, though, I lost. The technology I was advocating for wasn’t chosen by “the powers that be,” and so Continue reading

CheckPoint, Watchguard earn top spots in UTM shootout

When it comes to unified threat management appliances aimed at the SMB market, vendors are finding a way to fit additional security features into smaller and more powerful appliances. In 2013, we looked at nine UTMs. This time around we reviewed six products: the Calyptix AccessEnforcer AE800, Check Point Software’s 620, Dell/Sonicwall’s NSA 220 Wireless-N, Fortinet’s FortiWiFi-92D, Sophos’ UTM SG125 and Watchguard Technologies’ Firebox T10-W. (Cisco, Juniper and Netgear declined to participate.) We observed several megatrends across all the units that we tested:To read this article in full or to leave a comment, please click here(Insider Story)

BGPSEC: Signatures and Performance

BGPSEC is a set of BGP extensions being developed by the SIDR working group of the IETF to improve the security of the Internet’s routing infrastructure. So far in this series, we’ve looked at the basic operation of BGPSEC, the protections offered, and then the first set of performance issues — how do we prevent […]

Author information

Russ White

Principal Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about — or don't really care about. You can find Russ at 'net Work, the Internet Protocol Journal, and his author page on Amazon.
TwitterGoogle+LinkedIn

The post BGPSEC: Signatures and Performance appeared first on Packet Pushers Podcast and was written by Russ White.

BGP Deaggregation with Conditional Route Injection

Whenever there’s a weird request to do something totally illogical with BGP, there’s a knob in Cisco IOS to get it done (and increase the heartburn of CCIE candidates). Conditional Route Injection (the ability to insert more specific prefixes into BGP without having them in the IP routing table) is one of them.

Keep in mind: being a MacGyver is not a long-term strategy. Just because you can doesn’t mean that you should.

Read more ...

Software-Defined Cloud Networking Reflections

Every year I reflect upon how my predictions compare to actual outcomes. Once again, that time has come, so let’s take a walk together down 2014’s memory lane, while also looking forward to exciting industry developments in 2015. Clearly innovation in networking is returning as we are seeing venture capitalists once again investing in networking innovation!

Prediction #1: The rise in server virtualization is driving network virtualization deployments.

Evaluation #1: Half True.

One can transcend network boundaries at both L2 and L3, building seamless virtual and physical networks with VXLAN as the key L2 over L3 foundation. The VXLAN specification co-authored by Arista and VMware, and in a similar vein the NVGRE specification co-authored by Arista and Microsoft, were key turning points for network virtualization. Arista’s strategic partnership announced in August 2014 with VMware (NSX, vSphere and vCloud Director) and multivendor interoperability with other controllers from Nuage Networks, OpenStack and the OpenFlow community were key milestones in 2014. New protocols take time to be adopted – usually 3-5 years. VXLAN is at that tipping point for broader implementations in place of the proprietary, vendor-specific options we have seen.

Prediction #2: “SDN” is no more “Still Don’t Know”.

Evaluation #2: Continue reading

Continuous Integration Pipeline for Networking

Popular development methodologies like Continuous Integration are usually accompanied by some kind of automated workflow, where a developer checks in some source code, which kicks off automated review, testing, and deployment jobs. I believe the same workflows can be adopted by network engineers. Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out.

Continuous Integration Pipeline for Networking

Popular development methodologies like Continuous Integration are usually accompanied by some kind of automated workflow, where a developer checks in some source code, which kicks off automated review, testing, and deployment jobs. I believe the same workflows can be adopted by network engineers. Let’s say you are the Senior Network Engineer for your entire company, which boasts a huge network. You don’t have time to touch every device, so you have a team of junior-level network engineers that help you out.

Blog Migration Complete

The blog migration is finally complete! It’s taken quite a while, but I’ve finally managed to migrate the over 1,600 posts from my original WordPress installation over to Jekyll hosted on GitHub Pages. I’ll have another post later that goes into more detail on the process that I followed (and why) as well as some of the tools that I used in the migration.

As of right now, there are 2 outstanding issues:

  1. While all the content is here, what’s not here is the comments (yet). I’m still working through some issues with Disqus, but I hope to have the issues resolved soon.

  2. Also, depending on when you read this, my original domain (“blog.scottlowe.org”) may or may not be working with the new content.

I appreciate your patience as I work through these issues.

I’d also appreciate it if you could let me know if you find anything that’s not working, such as links to other blog posts, code listings, images, etc. Because this entire site is a GitHub repo, if you’re so inclined you’re welcome to clone the repo, fix the problems, and submit a pull request. If you don’t feel like doing that, just drop me Continue reading

13 reasons why your newsletter sucks

Newsletters are a crucial tool of online marketing; get yours right and your audience will pay attention to you and whatever you’re trying to promote. Get it wrong and if you’re lucky people will just route your newsletter straight to the trash. If you really goof up, you’ll be swamped with abuse and unsubscribe requests. So, to help keep you on the path of digital righteousness here's a selection of the best ways for you to screw up your newsletter:

#1. Be boring. This is the simplest path to a failed newsletter. To really be boring ensure that your newsletter is in plain text, short, minimally formatted, and contains absolutely no graphics.

To read this article in full or to leave a comment, please click here

Hybrid OpenFlow ECMP testbed


SDN fabric controller for commodity data center switches describes how the real-time visibility and hybrid control capabilities of commodity data center switches can be used to automatically adapt the network to changing traffic patterns and optimize performance. The article identifies hybrid OpenFlow as a critical component of the solution, allowing SDN to be combined with proven distributed routing protocols (e.g. BGP, ISIS, OSPF, etc) to deliver scaleable, production ready solutions that fully leverage the capabilities of commodity hardware.

This article will take the example of large flow marking that has been demonstrated using physical switches and show how Mininet can be used to emulate hybrid control of data center networks and deliver realistic results.
The article Elephant Detection in Virtual Switches & Mitigation in Hardware describes a demonstration by VMware and Cumulus Networks that shows how real-time detection and marking of large "Elephant" flows can dramatically improve application response time for small latency sensitive "Mouse" flows without impacting the throughput of the Elephants - see Marking large flows for additional background.
Performance optimizing hybrid OpenFlow controller demonstrated how hybrid OpenFlow can be used to mark Elephant flows on a top of rack switch. However, building test networks with physical Continue reading

Show 219 – Open vSwitch Obtains Ludicrous Speed

Ben Pfaff, Justin Pettit, and Ethan Jackson are core contributors to the Open vSwitch (OVS) project. What’s OVS? OVS is a virtual switch that’s growing in popularity as an open source vSwitch. The more you dig into open source networking projects, the more you see OVS showing up. One of the OVS gotchas in the past has […]

Author information

Ethan Banks

Co-host at Packet Pushers

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
TwitterGoogle+LinkedIn

The post Show 219 – Open vSwitch Obtains Ludicrous Speed appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Manually calculating MST digests

Switches sharing an MST region must agree on three things:
  • The region name
  • The region revision level
  • The region's mapping of VLANs to STP instances
The first two are exchanged directly inside BPDUs, so they are easy to validate. The third item is about 6KB of data at a minimum. It doesn't fit in a BPDU.

Rather than exchange the table directly, MST switches calculate a 128-bit hash of the table and exchange that instead. If the hashes match, the VLAN-to-stp-instance mapping database is assumed to match.

Most platforms will show you the calculated digest.

Catalyst:
 lab-catalyst#show spanning-tree mst configuration  
 Name   [lab]  
 Revision 3   Instances configured 4  
 Instance Vlans mapped  
 -------- ---------------------------------------------------------------------  
 0     4-9,40-99,101-199,201-299,301-4094  
 1     1,10-19,100  
 2     2,20-29,200  
 3     3,30-39,300  
 -------------------------------------------------------------------------------  
 lab-catalyst#show spanning-tree mst configuration digest  
 Name   [lab]  
 Revision 3   Instances configured 4  
 Digest     0x37D94E0098E3418C046F217A71077FB1  
 Pre-std Digest 0xFC2190275BBB19CD9A6F1BB116DB10E7  
 lab-catalyst#

Procurve: 
 lab-procurve# show spanning-tree mst-config  
  MST Configuration Identifier Information  
  MST Configuration Name : different              
  MST Configuration Revision : 4    
  MST Configuration Digest : 0x37D94E0098E3418C046F217A71077FB1  
  IST Mapped VLANs : 4-9,40-99,101-199,201-299,301-4094  
  Instance ID Mapped VLANs  
  ----------- ---------------------------------------------------------  
  1      1,10-19,100  
  2      2,20-29,200  
  3      3,30-39,300  
 lab-procurve#

Because their VLAN-to-instance mapping is the same, both switches arrived at the same digest value. Note that Continue reading

My Network Toolkit

A while back, Chris Marget of Fragmentation Needed posted a run-down of his comprehensive and extremely clever network toolkit. Because I'm something of a weight weenie, mine is a lot more slimmed down. I thought I'd post it here:




The contents:

  1. Two random USB drives (in case I need to leave one with somebody).
  2. Single-mode and multi-mode LC fiber loopback plugs.
  3. Rack PDU plug adapter.
  4. Awesome PicQuic compact screwdriver (thanks to Chris's post).
  5. T1 loopback plug (red) (because we still have T1s out here in the boonies).
  6. Cat-6 pass-through plug (white).
  7. Crossover adapter (orange).
  8. Sharpie.
  9. Console setup:
  1. USB-to-DB9 adapter.
  2. DB9-to-RJ45 adapter.
  3. Flat Cat-6 cable.
  4. Rollover adapter.
  5. Velcro tie
  6. Flat Cat-6 cable with velcro tie.
The console setup could probably be improved by adding a DB9 null-modem adapter. The coolest thing (IMO) that I'm missing from Chris's setup is the Bluetooth console adapter -- maybe one day.

The Fenix AA light and Leatherman Skeletool CX almost always live in a pocket rather than the kit and go with me everywhere. The kit all fits into a small zippered case that used to hold a Dell laptop power supply.

My main goal here was to have all the hard-to-find professional stuff in Continue reading

My Network Toolkit

A while back, Chris Marget of Fragmentation Needed posted a run-down of his comprehensive and extremely clever network toolkit. Because I'm something of a weight weenie, mine is a lot more slimmed down. I thought I'd post it here:




The contents:

  1. Two random USB drives (in case I need to leave one with somebody).
  2. Single-mode and multi-mode LC fiber loopback plugs.
  3. Rack PDU plug adapter.
  4. Awesome PicQuic compact screwdriver (thanks to Chris's post).
  5. T1 loopback plug (red) (because we still have T1s out here in the boonies).
  6. Cat-6 pass-through plug (white).
  7. Crossover adapter (orange).
  8. Sharpie.
  9. Console setup:
  1. USB-to-DB9 adapter.
  2. DB9-to-RJ45 adapter.
  3. Flat Cat-6 cable.
  4. Rollover adapter.
  5. Velcro tie
  6. Flat Cat-6 cable with velcro tie.
The console setup could probably be improved by adding a DB9 null-modem adapter. The coolest thing (IMO) that I'm missing from Chris's setup is the Bluetooth console adapter -- maybe one day.

The Fenix AA light and Leatherman Skeletool CX almost always live in a pocket rather than the kit and go with me everywhere. The kit all fits into a small zippered case that used to hold a Dell laptop power supply.

My main goal here was to have all the hard-to-find professional stuff in Continue reading

Using the Junos Space REST API

Automation is going to be fundamental in all networking products. I’ve been working a lot on integrating Juniper products in existing and standard software. There are many different ways to automate something on a network running Junos. Using REST (or RESTful) APIs is one way of doing this. The reason I’m using REST is that it’s fairly easy to understand, but the best thing is that a large amount of existing products supports REST to integrate with it.

The goal of this blog is to explain how Junos products support REST, compatibility with older versions and how it scales.

What is REST?

REST (REpresentational State Transfer) is a simple stateless architecture that generally runs over HTTP. There are 4 commonly supported commands. When you issue a command your input data consists of a URL, HTTP headers and a body holding the data.

HTTP Headers are used for things like Authentication and a Content Type to let the application know what data format the body will contain.
The URL specifies which data you want to receive from the application or you want to change.
The body is empty in a request for data, when you want to change some data this Continue reading

1 … 3,655 3,656 3,657 3,658 3,659 … 3,841