SDN and legacy companies: laggards or pragmatists?

There was an interesting Twitter thread over the weekend initiated by Ethan Banks (@ecbanks). He commented that there was too much technique churn in SDN and NetOps (the networking equivalent of DevOps). His point was that in the face of all the change in how to do things, it left users in an impossible spot. How can up pick up a new technology if the frameworks around how to use it are consistently changing?

His conclusion was that we cannot herd these cats. But what is really going on?

No consensus on operating models

The most basic truth here is that there is no real consensus on operating models around any of the new technology. While there are rough agreements on a few architectural principles (and even there, far more is in the air than well grounded), there is really not a lot of best practices to which companies can pin their operations.

Sure, it might be obvious to people that SDN is here to stay. But what exactly does that mean? And which SDN do I evaluate, purchase, and eventually deploy? Do I go with OpenFlow because ONF has convinced me that openness is the primary tenet? Do I Continue reading

The Degree, or the Certification: First Thoughts

Having just come off doing a presentation on “being a great engineer,” I can tell you what the number one question people asked was: Should I get a degree, or a certification? In fact, several people were irritated that Denise and I were even talking about anything else, because it’s the only question that counts.

Let me counter that thought. If you’re asking whether you should get a degree or a certification, you’re asking the wrong question.

It’s not that I don’t have anything invested in certifications. I hold a CCIE (2635), CCDE (2007:001), and CCAr. I’ve written questions for the CCIE. I was on the original SME team that invented the CCDE and CCAr certifications. I’ve taught certification classes, written certification books, and generally been involved in the certification world for a long time.

It’s not that I don’t have anything invested in college, either. I have one four year degree, two Master’s degrees, and I’m currently working like crazy to gain acceptance into an PhD program (Philosophy, in Apologetics and Culture, if you’re curious). I’ve taught as an adjunct in the NC State MS program, and I’m on Capella University’s advisory council. I teach on a regular basis Continue reading

Android Bugs

I have a little Samsung Galaxy S2 which is a perfectly adequate phone. I use the Google Apps on it to keep some semblance of order in my life. However, I run into some occasional bugs which require a bit of work to solve. So I’m putting in the fixes here so they’re easily available.

1. Weather widget displays an incorrect location. Documentation date 03.11.2014
This is fixed by going to Settings->Application Manager and performing a forced stop on the TouchWiz Home application.

2. Lockscreen displaying an incorrect location. Documentation date 03.11.2014
First I thought this was related to the first problem. However, this can be fixed by going to Applications->Security and changing the location detection to refresh automatically. It looks like adding a new city in the weather widget updates the location in the lockscreen, but removing it doesn’t force an update to the lockscreen.

More bugs will be documented here as they’re found.


Learning NSX, Part 18: Routing Without Network Address Translation

This is part 18 of the Learning NSX blog series, in which I talk about using layer 3 (L3) routing with VMware NSX but without network address translation (NAT). This post describes a configuration that offers yet another connectivity option for OpenStack cloud administrators and operators.

In part 6, I showed you how to add a gateway appliance to your NSX installation. Part 9 leveraged the gateway appliances to create a L3 gateway service, which—as I explained in part 15—provides the functionality for logical routers in OpenStack. (Logical routing was covered in part 14.) Part 16 expanded the routing configuration to support multiple external networks. This post expands the options again by showing you how to do logical routing without using network address translation (NAT). Of course, it would probably be helpful to read the entire series; links to all posts can be found on the Learning NVP/NSX page.

As I mentioned, so far you’ve seen three different external connectivity options:

  • Routing (layer 3 connectivity) to a single external network

  • Routing (layer 3 connectivity) to multiple external networks using VLANs

  • Bridging (layer 2 connectivity) between a logical network and a physical broadcast domain

Both of the routed Continue reading

HTIRW: Provider Peering and Revenue Streams (Part 2)

This is a continuation from last week’s post on provider peering streams. Second Example: Customer to Noncustomer Assume traffic is coming in from A and is destined to M. How can AS64501 maximize revenue stream in this situation? There is only place to make money (the [A,C] link), and there is one place where its […]

Author information

Russ White

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

Use a Disaster Recovery Project to Build Your New Cloud

It doesn’t make sense to build a new data center network to support legacy bare-metal server infrastructure. You’ll have to use relatively expensive 1G/10G ports to be able to connect the current and future servers, and once the server and virtualization engineers wake up and do hardware refresh you’ll end up with way too many ports (oh, and you do know that transceivers could cost more than the switching hardware, right?).

Read more ...

BYOD: Just another money-grab?

BYOD policies sound alluring. No more forced use of a crappy old corporate laptop – “hey look, we’ll let you choose whatever you want!” But I think it is a way to shift the cost burden over to employees. It will be done slowly, over several years, and we’ll welcome it. But it will lead to employees carrying more costs. I guess we should be careful with what we wish for.

In my teens I spent many years working in the produce & butchery departments at a local supermarket. When I started out, the contracts still had the last vestiges of union-dominated times. So we got paid allowances for laundry, extra allowances if we’d passed some school exams, higher rates for overtime, meal allowances, etc. During the years I was there, these were eroded. Each year they gave us pay rises that were nominally higher than inflation, and yet another allowance was ‘incorporated’ into my wages. Sometimes allowances would remain for older employees. When I left, I was being paid significantly more than new employees, in part because I still had several extra allowances.

I think we’ll see the same thing with BYOD programs. I think it will go like this:

  1. Announce BYOD Continue reading

Helpful Concepts for the Fresh New Geek

Someone recently asked me to be a professional mentor, an occurrence that becomes more surreal the longer I consider it in its implications and entirety.  So far the recipient of my educational transgressions appears content, but the experience has reminded me of several ranty moments I’ve had over the years regarding what new network geeks […]

Author information

Keith Tokash

Keith Tokash

Keith Tokash, CCIE (R&S) #21236, began his career in 1999, and has spent the last decade running around large content and small ISP networks. He spends his spare time with his newborn son, on the mat at the local Jiu-Jitsu gym, and trying to keep his fat yap shut.

The post Helpful Concepts for the Fresh New Geek appeared first on Packet Pushers Podcast and was written by Keith Tokash.

Positioning an IT Conversation

About a  week ago, I took my wife’s van to the shop. The main issue was it was making a popping noise in the front end. I only observed the noise when steering sharply and the vehicle was in motion. Typically this occurred when parking. Although I was nearly certain this was an issue with a CV joint, I only told the mechanic about the symptoms we had observed.

The reason I didn’t lead the conversation to the CV joint is that I wanted the mechanic to look at the problem objectively. I knew he was the expert and I wanted him to solve the problem instead of replacing a part. In order to shift the responsibility, I needed the mechanic to diagnose the problem and create a plan of action.

Positioning IT Conversations to Solve Problems

At this point in my career, I have worked in various areas of technology. Over the years, I’ve had customers that tell me exactly what they think they need. In some cases, they’re correct. However, there are times that their solution does not fully solve the problem they are observing. On the other hand, some customers take a smarter approach and explain the problem they are trying to solve.

When Continue reading

In Praise of Support Lifecycles

If you’re just starting out working with ‘Enterprise’ products, you may not have come across Support Lifecycles. It’s important to know what these are, and how it affects you. They can have both a positive & a negative impact on when and why you choose to upgrade systems.

What Are Support Lifecycles?

Developers would like to only support the latest version. But customers can’t/won’t always run the latest version. They need to know that they can expect a certain level of support for the version they’re running. As a compromise, software vendors will publish a support lifecycle policy. This will outline the levels of support a product gets, from new product introduction, through to being superceded, and finally moved to end of support. Typical phases include:

  • General Support: Product is in General Availability phase, and is fully supported. You can log support cases, search KB articles, and expect both functionality enhancement and bugfix patches. The current product version will always be in this phase, and typically 1-2 major versions behind will also be included.
  • Limited Support: You can log a support case, and we’ll try to help, but we’re not planning any new patches, and you’ll probably get a suggestion Continue reading

Adding protocols to masscan

The unique feature of Masscan is that it has it’s own TCP/IP stack, bypassing the kernel’s stack. This has interesting benefits, such as being able to maintain a TCP connection with all 30 million HTTPS servers on the Internet simultaneously. However, it means that (at the moment) it’s difficult to write your own protocols. At some point I’m going to add LUA scripting to the system and this technical detail won’t matter, but in the meanwhile, if you want to write your own protocols, you’ll have to know the tricks.

Scalability

The issue Masscan solves is scalability, such as maintaining 30 million concurrent TCP connections. In a standard Linux environment, the system requires about 40 kilobytes per TCP connection, meaning a system would need 1.2 terabytes of RAM to hold all the connections. This is beyond what you can get for standard servers.

Masscan reduces this. At the moment, it uses only 442 bytes per TCP connection – including the memory for difficult protocols like SSL. That’s less than 16-gigabytes of RAM for 30 million concurrent connections.

This is a little excessive, because connections are quick. Even a fast scan of the Internet takes long enough that at any Continue reading

Network Break 19

Continuing our regular look at the news in Networking and Cloud.

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+

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

Shellshock: One Month On

Shellshock was released a little over a month ago, to wide predictions of doom & gloom. But somehow the Internet survived, and we lurch on towards the next crisis. I recently gave a talk about Shellshock, the fallout, and some thoughts on wider implications and the future. The talk wasn’t recorded, so here’s a summary of what was discussed.

Background: NZ ISIG: Keeping it Local

The New Zealand Information Security Interest Group (ISIG) runs monthly meetings in Auckland and Wellington. They’re open to all, and are fairly informal affairs. There’s usually a presentation, with a wide-ranging discussion about security topics of the day. No, we don’t normally discuss “picking padlocks, debating whose beard or ponytail is better or which martial art/fitness program is cooler.”

Attend enough meetings, and sooner or later you’ll be called upon to present. I was ‘volunteered’ to speak on Shellshock, about a month after the exploit was made public. I didn’t talk about the technical aspects of the exploit itself – instead I explored some of the wider implications, and industry trends. I felt the talk went well, mainly because it wasn’t just me talking: everyone got involved and contributed to the discussion. It would be a bit Continue reading

The Etymology of Elephant and Mice Flows

Over the past 3-4 years, the term elephant flows has been used to refer to east-west (machine-to-machine) traffic, such as vMotion, Migration, Backup, and Replication. The term mice flows is used to refer to north-south (user-to-machine) traffic. Why are we using these terms all of a sudden and did they come from? Wikipedia states “It is not clear who … Continue reading The Etymology of Elephant and Mice Flows →

White Box switch readiness for prime time

Matthew Stone runs Cumulus Networks switches in his production network. He came on the Software Gone Wild podcast recently to talk about his experiences. Cumulus, Pica8, and Big Switch are the three biggest proponents of white box switching. While Pica8 focuses on the Linux abstractions for L2/L3, Pica8 focuses more on the OpenFlow implementation, and Big … Continue reading White Box switch readiness for prime time →

Appropriate Halloween costumes

There has been some debate over Halloween costumes, whether ISIS terrorist garb or hazmat suites are appropriate. Of course they are. Culture responds to current events; everything is fair game.

An example of this are Afghan "war rugs", as pictured below. The one on the left is in response to the old Soviet invasion, and the one on the right is in response to the post-9/11 invasion by the U.S. Rug weavers incorporated things from their environment into the rugs. In particular, the design of the rug on the right comes from leaflets we carpet bombed the country with before invading them.



Indeed, the entire "Halloween" theme is about death. It's just that it got incorporated in our culture long before the Internet enabled wimpy nitpickers from debating what was, or wasn't, appropriate. I'm not sure if the holiday would've survived in the modern politically correct climate.


1 … 3,684 3,685 3,686 3,687 3,688 … 3,841