Networking Field Day 7 – Here We Go Again!

I’m pleased to be invited back for the 7th installment of Networking Field Day in San Jose, CA from February 19th - 21st. This event is part of a series of independent IT community-powered events that give the vendors an opportunity to talk about the products and ideas they’ve been working on, and receive honest and direct feedback from the delegates. The results of this dynamic vary quite greatly - sometimes a vendor doesn’t quite bring their A-game and we let them know.

A New Year, A New Job and New Challenges

Well by the time I get around to clicking “Publish” on this post it will no longer be a secret, and you don’t know how hard its been for me not to talk about this in overly public forums.

As some of you may have heard, after five months of interviews and immigration paperwork, I have accepted a new role with Juniper Networks as a Sr Data Center* Technical Marketing Engineer. This role will see me move to the San Francisco Bay Area in the next week or so, and be based directly out of the Sunnyvale office for at least the next two years.

The Role

This new role is actually quite exciting to me (and a little bit scary) because it takes all of the knowledge and skills I have gained over the last 15 years as a consultant and then makes use them in a different way. Instead of building solutions to individual customer requirements, I will be working with the Solutions Team to help promote solutions that are universal and can scale with user need. I will be working on creating white papers, design guides and helping position Juniper Data Center their solutions.

Having spent Continue reading

Please Fill Out Our 2014 Audience Survey

Packet Pushers is a big part of Greg’s & Ethan’s lives and the show is continuing to grow in 2014. We learn a lot, laugh a lot, and work hard to bring you the show every week and fresh content on the blog site. Despite enjoying editing and writing along with producing the podcast, the […]

Author information

Ethan Banks

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

The post Please Fill Out Our 2014 Audience Survey appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Install Open vSwitch Networking on Red Hat Fedora 20

The following tutorial will bootstrap you in installing and configuring Open vSwitch on Red Hat Fedora 20. It also has some extras that are just general Fedora configuration tasks such as setting up networking along with Wireshark over an X11 ssh session. This is the first of lots of integration posts over the next year as we develop network virtualization ...

...

BGP Path Hunting/Exploration

 Only one change or link flap can cause one hour or more traffic drop.  It is weird, right? But this is true. In this article BGP Path Hunting/ Path Exploration behavior will be shown, BGP route flap dampening and its variants will be explained and how only one interface flap can cause very long down […]

Author information

Orhan Ergun

Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security.

He has more than 10 years in IT, and has worked on many network design and deployment projects.

In addition, Orhan is a:

Blogger at Network Computing.
Blogger and podcaster at Packet Pushers.
Manager of Google CCDE Group.
On Twitter @OrhanErgunCCDE

The post BGP Path Hunting/Exploration appeared first on Packet Pushers Podcast and was written by Orhan Ergun.

Show 176 – Intro to Python & Automation for Network Engineers

Network engineers keep hearing about Software Defined Networking (SDN) and wonder, “Will I have to become a programmer to keep my job?” The answer is, “Probably not.” However, there’s still an awful lot to be said for network engineers becoming familiar with the tools of network automation. There’s a gain in productivity to be had […]

Author information

Ethan Banks

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

The post Show 176 – Intro to Python & Automation for Network Engineers appeared first on Packet Pushers Podcast and was written by Ethan Banks.

[Storage Flow Control] Part 2 – Implementation and Troubleshooting

This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are: IP Storage - uses TCP windowing to provide feedback to client on how much data to send Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks.

OpenDaylight Summit 2014

I will be at the OpenDaylight Summit in Santa Clara on February 4th and 5th. To me, OpenDaylight represents a platform on which we can test SDN ideas today, right here, and right now. In my day job I may never be called upon to help deploy OpenDaylight (here’s hoping!) but nonetheless, it’s projects like this where the best and the brightest come together to share ideas and help to form the technology that the industry will be using for the next few decades.

SDN 2014 – Make Our Garden Grow – Part 1

Let dreamers dream what worlds they please Those Edens can’t be found The sweetest flowers The fairest trees Are grown in solid ground We’re neither pure nor wise nor good We’ll do the best we know We’ll build our house and chop our wood And make our garden grow And make our garden grow These […]

Author information

Steven Iveson

Steven Iveson

Steven Iveson, the last of four children of the seventies, was born in London and has never been too far from a shooting, bombing or riot. He's now grateful to live in a small town in East Yorkshire in the north east of England with his wife Sam and their four children.

He's worked in the IT industry for over 15 years in a variety of roles, predominantly in data centre environments. Working with switches and routers pretty much from the start he now also has a thirst for application delivery, SDN, virtualisation and related products and technologies. He's published a number of F5 Networks related books and is a regular contributor at DevCentral.

The post SDN 2014 – Make Our Garden Grow – Part 1 appeared first on Packet Pushers Podcast and was written by Steven Iveson.

Why Network Engineers Should Learn Programming

Because Microsoft Excel is not a text editor. Seriously.

This is a followup to the previous post, inspired by Ethan Banks of Packet Pushers. If you do operational networking at all, you deal with text files all the time: logs, debug output, configuration files, command line diagnostics, and more. I'm constantly amazed when I see people open Word or Excel to do their text editing, often one keystroke at a time.

The number one reason to learn basic programming is to automate that stuff. Personally, I use a combination of traditional Unix shell tools and Python to get the job done, but you could probably do it all with one or the other.

There are lots of other reasons to learn programming too, many of which will be discussed on an upcoming Packet Pushers episode. But if you don't believe any of those, this one alone makes it worth the effort.

Step away from the spreadsheet. Do it now.

Why Network Engineers Should Learn Programming

Because Microsoft Excel is not a text editor. Seriously.

This is a followup to the previous post, inspired by Ethan Banks of Packet Pushers. If you do operational networking at all, you deal with text files all the time: logs, debug output, configuration files, command line diagnostics, and more. I'm constantly amazed when I see people open Word or Excel to do their text editing, often one keystroke at a time.

The number one reason to learn basic programming is to automate that stuff. Personally, I use a combination of traditional Unix shell tools and Python to get the job done, but you could probably do it all with one or the other.

There are lots of other reasons to learn programming too, many of which will be discussed on an upcoming Packet Pushers episode. But if you don't believe any of those, this one alone makes it worth the effort.

Step away from the spreadsheet. Do it now.

“VIF down” Issues with UCSM 2.2(1b)

Sadly, this will be another post regarding issues I’ve had with UCSM firmware release 2.2(1b). During the upgrade process, I experienced a lot of issues with data plane connectivity - after I activated (and subsequently rebooted) a Fabric Interconnect, and it came up with the new NXOS version, a slew of blades would have persistent errors regarding virtual interfaces (VIFs) that wouldn’t come back online. Here is the error report for a single blade where I was seeing these errors:

Cisco UCS – “Unable to Communicate With UCSM Controller”

When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this: 6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.

Farewell to Networking

Almost twenty years ago, I began my career in networking.  HP hubs and routers, no VLANs, one router PHY port per subnet.  From there I installed an ATM backbone using LANE in the venerable Catalyst 5500 platform, then moved on to GigE in 3750 stacks and finally to 10G Nexuses (Nexa, Nexi?).  I’ve seen WiFi […]

Author information

Matthew Mengel

Matthew was a Senior Network Engineer for a regional educational institution in Australia for over 15 years, working with Cisco equipment across many different product areas. However, in April 2011 he resigned, took seven months of long service leave to de-stress and re-boot before becoming a network engineer for a medium sized non-profit organisation. At the end of 2013, he left full-time networking behind after winning a scholarship to study for a PhD in astrophysics. He is on twitter infrequently as @mengelm.

The post Farewell to Networking appeared first on Packet Pushers Podcast and was written by Matthew Mengel.

Cisco UCS Error – “Process Failed”

One of the (sadly numerous) issues I’ve run into while upgrading to Cisco UCSM version 2.2(1b) is this little error message indicating that a service failed to start: This gives us an error code of F0867 and it’s letting us know that the UCSM process httpd_cimc.sh failed on one of our Fabric Interconnects. For those that don’t know, you can get a list of processes within UCSM by connecting to local management and running “show pmon state”.

Quick Thoughts on Learning Python

I was scheduled to be a guest on an upcoming episode of the Packet Pushers podcast, on the topic of Python for network engineers. Unfortunately due to bad luck I'm not going to be able to make the recording. Here are some quick thoughts on learning Python. If you're already an expert programmer you already know how to learn languages, so this post isn't for you.

Scenario 1: You've coded in another language, but you're not an expert.
I would start with the basic Python class at Google Code. It's targeted specifically at people who know basic programming skills in some other language. It was perfect for me; I went through the exercises and was able to quickly start writing simple, useful Python scripts.

Scenario 2: You don't know how to write code at all.
Start with the Udacity CS101 class if you like guided learning, or Learn Python the Hard Way if you prefer books. Be prepared to spend a lot of time on either. It's not easy the first time around.

After you've gotten through one of those two scenarios, do the following:


  1. Spend time browsing the documentation for the Python Standard Library. Python is a large language, Continue reading

Quick Thoughts on Learning Python

I was scheduled to be a guest on an upcoming episode of the Packet Pushers podcast, on the topic of Python for network engineers. Unfortunately due to bad luck I'm not going to be able to make the recording. Here are some quick thoughts on learning Python. If you're already an expert programmer you already know how to learn languages, so this post isn't for you.

Scenario 1: You've coded in another language, but you're not an expert.
I would start with the basic Python class at Google Code. It's targeted specifically at people who know basic programming skills in some other language. It was perfect for me; I went through the exercises and was able to quickly start writing simple, useful Python scripts.

Scenario 2: You don't know how to write code at all.
Start with the Udacity CS101 class if you like guided learning, or Learn Python the Hard Way if you prefer books. Be prepared to spend a lot of time on either. It's not easy the first time around.

After you've gotten through one of those two scenarios, do the following:


  1. Spend time browsing the documentation for the Python Standard Library. Python is a large language, Continue reading

Healthy Paranoia Show 21: Windows Forensics with Andrew Case

That’s right, it’s time for another surveillance-free, EFF-approved episode of Healthy Paranoia! Where the passwords are salted and the packets are always encrypted. This episode is hosted by the infamous Mrs. Y, queen of metadata and official privacy advocate for Healthy Paranoia, and recorded in the NSA-proofed SCIF with Grecs, of Novainfosec.com and Shmoocon Firetalks. […]

Author information

Mrs. Y

Snarkitecht at Island of Misfit Toys

Mrs. Y is a recovering Unix engineer working in network security. Also the host of Healthy Paranoia and official nerd hunter. She likes long walks in hubsites, traveling to security conferences and spending time in the Bat Cave. Sincerely believes that every problem can be solved with a "for" loop. When not blogging or podcasting, can be found using up her 15 minutes in the Twittersphere or Google+ as @MrsYisWhy.

The post Healthy Paranoia Show 21: Windows Forensics with Andrew Case appeared first on Packet Pushers Podcast and was written by Mrs. Y.

[Storage Flow Control] Part 1- Introduction

When making the leap to adopting FCoE as a storage medium, there are a few things to consider in order to be successful. Many of these concepts are foreign to the storage administrator who has been operating a native Fibre Channel SAN for the better part of the last decade or more - this is because while Fibre Channel networks are costly, they are purpose-built. There is no concept of a loop in Fibre Channel - with Ethernet we deal with these all the time.