Complexity vs Security

Many of the ‘security’ measures in our networks add complexity. That may be an acceptable tradeoff, if we make a meaningful difference to security. But often it feels like we just add complexity for no real benefit.

Here’s some examples of what I’m talking about:

• Multiple Firewall Layers: Many networks use multiple layers of firewalls. If you have a strong policy that says all traffic must go via a server within a DMZ, this makes sense. But often we end up with the same connections going through multiple firewalls. We end up configuring the same rules in multiple places. No security benefit, but increased chance of making mistakes, and added troubleshooting complexity.
• Chained proxies: It’s pretty common to use a proxy server, to enforce HR and security controls on what users browse. But some organisations have chained proxies, where an internal proxy server connects to an upstream proxy server to get Internet access. The upstream proxy doesn’t add anything from a policy or control perspective. It’s just another point to configure and troubleshoot.
• NAT/Routing: First let me be clear: NAT is not complete security in itself, but it can form a valid part of your overall network security policy. That Continue reading

State of the State for Open vSwitch

This week, VMware will be hosting the Open vSwitch 2014 Fall Conference, with more than 200 attendees and nearly two dozen talks on a variety of subjects from a key participants.  The full schedule is available here, and we’ll be doing a wrap up of some of the takeaways from the conference a bit later.

For the uninitiated, Open vSwitch is a production quality, multilayer virtual switch licensed under the open source Apache 2.0 license.  It is designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g. NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag).  In addition, it is designed to support distribution across multiple physical servers similar to VMware’s vDS or Cisco’s Nexus 1000V. See full feature list here

For more information on OVS, I encourage you to check out the OVS website.

In the mean time, take a read about latest Open vSwitch developments in this post on Network Heresy by OVS core contributors Justin Pettit, Ben Pfaff, and Ethan Jackson.

Accelerating Open vSwitch to “Ludicrous Speed”

Roger

But I’ve got an ‘Excellent Signal’!!?

The Degree or the Certification: You are Not a Widget

One of the things that bothers me the most about the Internet of Things (IOT) is how blithely we slip from talking about objects as things to people as things. Among all the things I do not want to be, a “thing,” attached to the “Internet of Things,” is not one of them. What does this have to do with the question of whether you should get a degree or a certification? Simply this: You shouldn’t treat yourself as a widget, either.

Let me explain.

I can’t count the number of times I’ve heard people say, “You should get a certification because it provides more bang for the buck.” In fact, in one rather amusing line of reasoning on the subject, Peter Thiel (who started the Thiel Foundation to encourage smart young people to quit college and take up a career instead), said in a recent interview:

Educational institutions are far too often interested in churning out graduates (i.e., getting their money) without imparting the ability to think rather than just work the system.

To paraphrase, you should opt out of college because colleges are just in the game to make money off you, and you’ll make Continue reading

ESXi whitebox server

Just Published: Overlay Virtual Networks in Software Defined Data Centers

Overlay virtual networks are one of my favorite topics – it seems I wrote over a hundred blog posts describing various aspects of this emerging (or is it reinvented) technology since Cisco launched VXLAN in 2011.

During the summer of 2014 I organized my blog posts on overlay networks and SDDC into a digital book. I want to make this information as useful and as widely distributed as possible – for a limited time you can download the PDF free of charge.

Learn more about the book

Networking’s UX victims

Our perception of nirvana is impacted mightily by current conditions. For people who live in third world countries, for example, merely having running water or reliable electricity can be a life-altering boon. Meanwhile, those of us who are more accustomed to the creature comforts of life consider slow internet or a poorly seasoned meal worthy of public scorn (even if we add the hashtag #firstworldproblems).

So how is the current state of networking impacting its user base?

A new normal

Perhaps the most insidious effect of poor conditions is that prolonged exposure can actually cause us to reset our baseline for normal. When we are subjected to extended periods of great or even long periods of suck, we adjust our expectations.

In networking, this means that our current normal has been forged through diligent neglect of actual user experience for decades. It’s not so much purposeful behavior by the incumbent networking players so much as placing focus elsewhere. For at least the last few decades, the future of networking has always been defined by the next protocol or knob. That is to say that the focus for product development has always been about bolstering device capability.

With the focus Continue reading

BGPSEC: Basic Operation

I’m going to take a little break from my other two series to inject a short series on BGPSEC. I’ll return to HTIRW and RFCs you need to know shortly. BGPSEC is a set of standards currently under consideration in the IETF to secure BGP beyond the origin AS – in other words, to secure […]

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 want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. He recently published The Art of Network Architecture, is currently working on a new book in the area of network complexity with Addison Wesley, a book on innovation from Continue reading

Custom Python Packages With PyPi For Networking Peoples

Quite frequently I write and build code to control and harvest data from network infrastructure. Whether it’s writing modules for a stack automation tool like Ansible or writing modules for run to completion scripts, code is often spawned to meet requirements. Sometimes this code is more than a little complex with many dependencies. In addition, sometimes code is written to extend an existing module, like the Python NetConf library NCClient. This happened recently for example when the NCClient library failed to meet expectations.

Two options exist for complicated projects from an arbitrary point of view:

1. Include all of the dependencies in a directory and provide everything including the kitchen sink to allow your code to function as per design.
2. Create an installable which takes care of all dependencies.

With Python, option 2. is an interesting one that I’ve never previously thought about doing.

Information for this post and my initial requirement came from these two sources which were most helpful:

http://www.scotttorborg.com/python-packaging/minimal.html
http://peterdowns.com/posts/first-time-with-pypi.html

PyPi Introduction

How many times have you installed a module using something like

sudo pip install 'blah'

War Stories: Cursed VLANs

I’ve written before about switch ports being permanently disabled. This time it’s something new to me: VLANs that refuse to forward frames.

A Simple Network

The network was pretty straightforward. A pair of firewalls connecting through a pair of switches to a pair of routers:

Sub-interfaces were used on the routers and firewalls, with trunks to the switches. VLAN 100 was used for 100.100.100.0/24, and VLAN 200 was used for 200.200.200.0/24. The switches were configured to pass VLANs 100 & 200.

All was working as expected. All devices could see each other on all VLANs.

Until it stopped

We received reports that we’d lost reachability to Router A’s VLAN 200 sub-interface. After doing some investigation, we could see that Firewall-A could no longer see Router A’s MAC address on G0.200. But everything else was fine – the VLAN 100 interface worked perfectly. So we knew it couldn’t be a physical interface issue.

Hmmm. What’s going on? First instinct: check the switch port configuration. Has anything changed? Nope. VLAN 200 still there, configured as expected. The router & firewall were still tagging frames with VLAN 200. But they couldn’t see each other, and the Continue reading

Secret Sunday – Greg Ferro

Just over a month ago I accepted Etherealmind’s “30 Blogs in 30 Days Challenge”, and this Friday I ‘m pleased to say that I completed the challenge without missing a day. It seems appropriate then that I should use today’s Secret Sunday to give a shout out to the man behind the mission, Greg Ferro (aka Etherealmind).

In some ways it feels like cheating to include Greg because he’s unlikely to be a new discovery for anybody reading my blog, but credit is due where it’s due; you can’t argue that Greg does not give back to the networking community. His Etherealmind website has a huge following and a wealth of content written over a number of years. He’s a co-host of the PacketPushers podcasts, generating hundreds of podcasts dedicated to the networking industry. He has written three books that he has published on LeanPub and has a fourth on the way, co-authored with the venerable Brent Salisbury.

Greg is never short of an opinion, and I suspect that one of the reasons for his large following is that he isn’t afraid to go out there and let you know what he thinks, even if “you” are a vendor, and what Continue reading

Secret Sunday – Greg Ferro

Just over a month ago I accepted Etherealmind’s “30 Blogs in 30 Days Challenge”, and this Friday I ‘m pleased to say that I completed the challenge without missing a day. It seems appropriate then that I should use today’s Secret Sunday … Continue reading →

If you liked this post, please do click through to the source at Secret Sunday – Greg Ferro and give me a share/like. Thank you!

Ops Work vs Project Work

There’s a constant tension between delivering new services, and running the existing services well. How do you figure out how to prioritise work between Operations tasks and Project work? Skewing too far either way leads to problems. Maybe the answer is in how we structure Operations tasks?

Definitions

• Operations work: Dealing with outages, trouble tickets, support requests, etc. System monitoring – reviewing data for capacity planning, and identifying new areas to monitor. Automated repetitive tasks. Patches, upgrades, minor changes to existing services. Accountants would call this work OpEx.
• Project work: Design, test and deployment of new services. Major upgrades or enhancements to existing services. This is usually classified as CapEx. For some businesses, this work is customer-billable.

What happens when you’re imbalanced?

• Too much Project work: If you’re flat out deploying new systems (and dealing with the fallout), it’s easy to let Operations work slip. Maybe you don’t get around to automating that log rotation script, or paying attention to the slope of that consumption graph. It’s OK for a while too…things seem to be trucking along. But then you start having outages due to simple things like logs filling directories, or you hit a capacity limit, and there’s a 6-week Continue reading

Network Break 21

IT Talent Shortage and Whiny CIOs, Podcasts Make Money, ACI vs NSX wobbles and Dell busts some moves at its conference.

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 21 appeared first on Packet Pushers Podcast and was written by Greg Ferro.

Facebook Altoona Network Diagram in 2-D

Infuriating Inconsistent Interfaces; F5 on the stand.

Ok, it’s another f5 post and if you’re not using f5 you might think this is irrelevant to you. However, I beg you to read on because the issue I’m describing today has a relationship to SDN and network automation, and why they are such a pain to do in so many cases.

f5 SSL Profiles

The day began simply enough: news had broken about the “Poodle” SSLv3 vulnerability, and like the majority of network and server nerds we needed to disable or block SSLv3 as quickly as possible in order to remove that particular attack vector. My job was to look at the f5 load balancers, and to do so I realized that I needed to understand what SSL we had out there, and I’d also need to determine the exact change I would be making.

I wrote a couple of scripts to analyze our f5 configurations, and soon enough I had a spreadsheet showing all the SSL client profiles that were in use on each load balancer. It’s important, at this point, to understand how the f5 configures SSL profiles. Fundamentally, a custom profile inherits all of its settings from a “parent” profile, unless you specifically choose to Continue reading

Infuriating Inconsistent Interfaces; F5 on the stand.

Ok, it’s another f5 post and if you’re not using f5 you might think this is irrelevant to you. However, I beg you to read on because the issue I’m describing today has a relationship to SDN and network automation, … Continue reading →

If you liked this post, please do click through to the source at Infuriating Inconsistent Interfaces; F5 on the stand. and give me a share/like. Thank you!

Reinventing the wheel (or RFC 1925 sect 2.11)

Simon Wardley is another old-timer with low tolerance for people reinventing the broken wheels. I couldn’t resist sharing part of his blog post because it applies equally well to what we’re seeing in the SDN world:

No, I haven't read Gartner's recent research on this subject (I'm not a subscriber) and it seems weird to be reading "research" about stuff you've done in practice a decade ago (sounds familiar). Maybe they've found some magic juice? Experience however dictates that it'll be snake oil […]. I feel like the old car mechanic listening to the kid saying that his magic pill turns water into gas. I'm sure it doesn't ... maybe this time it will ... duh, suckered again.

Meanwhile the academics already talk about SDN 2.0.

Meeting Rules

Years ago a wise engineer gave me these rules for meetings:

1. Never go into a meeting unless you know what the outcome will be.
2. Plan to leave the meeting with less work than when you went in.

Stick to those rules, and you’ll do well.

OK, so maybe the second rule’s not so serious, but the first one has a grain of truth. You don’t need to know exactly what the decision should be, but you should be clear about what you want to get decided. If it’s particularly important, you should have already discussed it with the key attendees, and you should know what they’re thinking. You don’t want any surprises.

Too many meetings have no clear purpose, or they can only agree that ‘a decision needs to be made…pending further research.’ Avoid those sorts of meetings. Otherwise it ends up like…well….Every Meeting Ever:

Facebook Altoona Network Diagram in 2-D

Facebook recently wrote about the network architecture they are using in their new Altoona data center facility. If you haven’t read through their article yet, it’s definitely worth the read.

They have a few diagrams that outline the architecture. One of them is in 3-D. 3-D diagrams are always more difficult for my brain to conceptualize (maybe it’s just me), so I re-drew it in a more typical 2-D fashion.
There aren’t details on quantity and speeds of ports for the spine and edge switches, so I represented them similar to how they have them in their diagram. For every downward facing port a spine switch has (across the plane), 2300 servers can be added. That’s the amount of servers per pod. 48 servers per rack * 48 racks per pod = 2300 servers. Based on the switch types being used, this number could be more, but I’m using the characteristics of 48 x 10G ports for host facing ports + 4 x 40G ports for uplinks.

My diagram depicts 8 racks in the POD and 8 switches per plane. These numbers would be 48 in a fully built out network/diagram.

Feel free to comment and correct anything I may Continue reading