• Home
  • Who Am I ?
    • Contact
    • What does Ethereal Mind mean ?
  • Disclosure
    • Disclaimer
    • Comment Policy
    • Privacy Policy
  • Just Three
  • Archive

EtherealMind

Software Defined & Intent Based Networking

You are here: Home / 2014 / Archives for April 2014

Archives for April 2014

The Hardware Inside Your Network Device

30th April 2014 By Greg Ferro Filed Under: Blog

I’ve spent a lot of time researching the hardware and technology that goes inside switches and routers. In part this is because I’m in the early stages of a book on White Box Networking where I needed to be able to put together information about the technology but really because software can only deliver what hardware can offer.

As part of the research I started a podcast series and roped in John Harrington aka The Network Sherpa and Simon Chatterjee who does the design of this hardware as a day job. We have published two shows and there is another one to come. I’ve received a lot of positive feedback from listeners the first show, far more than normal and this will be a topic for future shows.

You should head over to Packet Pushers to give them a listen:

Show 186 – The Silicon Inside Your Network Device – Part 1 – Packet Pushers Podcast
Show–186-The Silicon Inside Your Network Device – Part 2 – Packet Pushers Podcast

As always, finding people who have permission to speak and knowledgeable remains a challenge. If you would like to talk about an aspect of networking silicon, please get in touch so we get more content out to the audience.

the-silicon-inside-your-network

<

p>I haven’t progressed the book as far as I’d like due to heavy consulting and advisory commitments with my clients but there is a big update shortly.

The Cost of Software Licensing in Networking – Is the Price Worth It ?

28th April 2014 By Greg Ferro Filed Under: Blog

I’ve been evaluating Cisco Nexus products for a customer. So far, its taken more than 10 hours to check which product licenses are required for each platform. And I’m still not confident that I’ve got it correct and accurate. The licenses are convoluted and I’m really worried that I’ll pick a license and miss the features that I need.

So I checked with the reseller engineer and he doesn’t know either, “that is more of a sales thing” he said. The inside sales person said “I’ll need to the engineer to advise me on that”.

FACEPALM

I once worked on a project with staff from Cisco Professional Services where it took 3 days to build and validate the bill of materials – specifically on the software licensing required for some Nexus switches. At the standard rate of USD$3000 per day for Cisco PS plus my agency day rate at $1500/day, that bill of materials cost the client $13,500. Total vendor purchase was approx. $200,000.

Some time ago, I met with a company that has networking licensing team. These people have a full-time position managing the licensing of network software. Not hardware, just software, feature licenses, maintenance programs. So operating a network means we will soon have licensing professionals ? Microsoft has a certification for “Volume Licensing Specialist” to manage the complexity of administration. That’s ridiculous.

I last ranted about Cisco licensing in September 2012 Rant: Cisco claims “We’re Listening” to Simplifying Cisco Software Licensing – EtherealMind. Two years later and not much has changed.

While I’m wasting time reading manuals about licensing, I’m not working on an SDN Strategy or adding value to the network. That expensive network equipment with a shedload of useful features isn’t returning the investment I promised.

The CIO and project managers complain about long lead times, knows that this isn’t getting value from the investment. We all feel helpless in the face of vendor business models because we just wants to get the job done and improve the network.

There is no right answer here. But the cost of selecting  software licenses is getting to be more than the licenses. That’s ridiculous.

 

software-licensing-lover-1-595-opt

Blessay: We Need To Buy Infrastructure Dolls Not Babies For The Private Cloud

25th April 2014 By Greg Ferro Filed Under: Blessay, Blog

The future of private infrastructure ownership is moving to a new model combines the old with the new that I describe as “dolls and babies” where the major transformation in infrastructure ownership is the transition from having babies to owning dolls.

Infrastructure as Babies

Enterprises buy infrastructure like people have babies. It takes months to make a baby, creates a great deal of disruption during their delivery and it wasn’t easy to change work practices when the baby arrived.

And, like a real baby, it involves large capital investments and enormous amounts of ongoing feeding and care. Preparing the space, learning how the handle the baby and what it needs are all challenging things for the ‘new parents’.

In the last five years, we have have seen many structural changes in manufacturing of hardware through commoditisation. Indeed, its become so cheap to make new hardware, or extend the life of existing hardware that large companies like EMC & Cisco can produce multiple product families with major overlap. Comparisons show that EMC’s VNC and VMAX or Cisco’s Nexus 6000/7000 products in the data centre have so much overlap that it buyers find it hard to pick out the obvious differences. Logically, the profit margins must be able to sustain entire business units to produce and develop the platforms.

Infrastructure as Dollsinfrasructure-dolls-not-babies-opt

The alternative option is to consider asset purchases as dolls. Something to be bought cheaply, used for a short period and then tossed aside after a year or two. A doll asset might live on for a while on the toyshelf before being tossed as rubbish.

Infrastructure as dolls uses a concept of replacement and rotation. This requires change in business process and technology section to enable rapid change, faster deployment and so on. Buy doll clothes instead of baby clothes.

We have all heard those concepts before as “private cloud” which enables “doll” concept. See Cattle vs Kittens for more detail.

Transition – Are Customers Are Becoming Wiser ?

Vendors are reluctant to adopt the “doll” business model. Firstly, they are often deeply attached to their babies and reluctant to change.

Secondly, delivering babies is very good business for vendors. High priced goods that require large upfront investments make for good cash flow and trailing revenue.
Customers are becoming better parents and realising that they have too many babies. Having fewer babies is about family planning and careful career choices.

Conclusion

Creating and raising babies is the way that IT Infrastructure has developed over the last 20 years. As our babies grow up and become teenagers, many are realising that our ‘teenagers’ are not exactly right for the nest generation. If only we have chosen dolls instead of babies, we could put the old dolls away and get new ones without causing any damage.

We need Dolls not Babies in IT Infrastructure.

PS: Pets & Cattle

I’ve talked before about the cattle vs Kittens but feel that this metaphor is more suited to operating systems or virtual machines where systems need less maintenance, low capital and have limited physical presence. In the physical infrastructure, the device configuration is largely unchanged for most of it’s life. For both storage arrays and network switches in the data centre, configuring a few LUNs or adding a few ports to a VLAN constitutes a trivial delta in terms of overall functionality. All of the big decisions are made during the design phase where selection, features, location and implementation are all fixed before the roll out. Servers are already priced as consumable items and easily replaced in many use cases.

 

Blessay: Overlay Networking, BFD And Integration with Physical Network

25th April 2014 By Greg Ferro Filed Under: Blessay, Design, OpenFlow

In discussions with a stealthy networking startup today, we were discussing how their overlay network technology for an SDN-enabled WAN was able to to detect network blackouts and brownouts in the physical network. Their answer was to run Bi-directional Forwarding Detection (BFD) in the overlay tunnels. At each end of the overlay, the BFD agent (in both hardware and software) monitors the state of the underlying network through hello messages and it able to determine not only up/down status but also latency, jitter and loss by monitoring timestamps and counters.

You might want to reference Introduction to How Overlay Networking and Tunnel Fabrics Work and Overlay Networking is More and Better while Ditching the Toxic Sludge and even So You Dont Like Overlay Networking before you dive in here. These are part of a six post series on Overlay Networking1

Two Strategies

There are two basal strategies to handle overlay/underlay service detection. Out of band or in band signalling.

Out of band Signalling

implies that the external networks is somehow aware of the tunnel state and is able to support some sort of guarantee about the overlay itself. A network controller that owns every part of the physical networks will have the ability to program the end-to-end path. Of course, the controller will need to tightly manage all elements of the end-to-end and have complex interaction to maintain the controller integrity. Alternately, the controller would reduce its complexity by pushing the device configuration into the network device (this seems to be the purpose of the promise theory as promoted by Cisco and purpose of OpFlex).

Secondly, networks device must be able to monitor each flow and detect a performance issue and signal the controller of

The negative impact of the promise theory approach is that the device is more complex to manage itself. Managing a large volume of flows will require custom silicon and extensive new software exchange to signal the out-of-band stats back to the controller.

This would seem more complex, less reliable and potentially more expensive overall. The proof is yet to be seen. We have been using Out of Band signalling in networking through QoS tagging for a long time but with mixed results.

In Band Signalling

This method uses the tunnel endpoints to send messages through the tunnel and look for service information. Sending a regular hello and detecting loss would signal a blackout. Put a timestamp onto the hello and match that on receipt and it’s possible for the endpoint to measure jitter and delay.
For most networks, this is the practical case since the an external network is typically uncontrollable.

When I say “most” I’m pointing to the WAN where the nature of the underlying physical nature is completely unpredictable and unreliable. The use of MPLS to provision oversubscribed circuits on shared services means that most provider guarantee are observed for some portion of the time, say 95%, 97% or to a maximum of 99%. There are very few times when paying for 1:1 bandwidth allocation is possible or practical.

The use of BFD is particularly exciting approach since it s already exists in many network processors and Ethernet PHY chips and could be readily implemented in software. I understand that code is already widely available. Avoiding new protocols will reduce customer resistance.

The Value Of Detection

On the assumption that detection shows that a specific tunnel is failing, what are can be done to rectify the problem ?

In a physical network today, you can only mark the frame/packets using Ethernet COS or IP DSCP and hope that every device in the network will honour the implicit contract to prioritise according to some sort of rule base. If you are lucky, you will be able to configure every device and if you are very lucky each hardware interface will respond the QoS configuration the way that you expect.

In a small physical network of 50 to 100 devices this is possible if somewhat impractical due to the hardware variation. QOS handling is dependent on the Ethernet PHY cha. But if you add 500 or 1000 virtual devices then this be

Alternately, you can mark packet/frames with MPLS tags and use the “circuit emulation” capability of MPLS tunnels segregate different traffic flows into MPLS paths that have different physical properties.
The answer is to divert flows into another overlay tunnel. This works for both data centres and WANs where are, or should be, many paths between two end points. A WAN design today does not use both WAN circuits because existing routing protocols can only select one best path from the possible paths. A network controller and flow based network devices can choose paths for flows at a granular level.

The level of granularity will be determined by the hardware or software in the edge device (whether virtual or physical )

Overlay to Underlay Visibility

How does the overlay know what paths the underlay took ? One possibility is to listen to the routing protocol in the underlay and get the OSPF state database or the BGP announcements and calculate the network layout. Then map the overlay tunnels by matching the IP address of the end points against the routing table data.

Strategic Landscape

I’ve been waiting to hear how new companies would deliver the SDN WAN . Both in-band and out-of-band signalling strategies can, of course, be made to work but the whether one is better than the other is not known. In the following diagram, I shows that a network flow moves through many hops but the end-to-end connection state that has the feedback loop between endpoints. Feedback loops are critical to the design of all complex systems and the only feedback loop in network flows is performed at TCP layer.

Network feedback loops 1

The addition of SDN controllers creates a more comprehensive set of feedback capabilities, far more than has ever been possible because of the distributed nature of networking. The use of BFD will provide an in band feedback loop:

Network feedback loops 2

The use of in-band control methods are is how I understand the value of the Cisco ACI strategy. Each device in the network has some functions that is able to monitor the flow performance and report status back to the controller. This function is delivered by custom silicon inserted into the forwarding path in each and every network device. This creates a significant dependency on hardware and software in each and every network device and seems to contradict the fundamental design of networking (complex at the edge, simple at the core).

Network feedback loops 3

The EtherealMind View

Here are some thoughts about the technology and approaches to the problem:

  • The IP protocol is designed to complex at the edge and simple in the middle. Adding “intelligence in the network” provides, at best, a short-term gain and has alway proved to be wasted over the last 20 years. The best case study here is the Internet, dumb at the core and smart at the edge.
  • The TCP protocol uses in-band signalling to notify congestion and loss. The TCP algorithm is the heart of the Internet scalability (perhaps making BGP the brain) and SDN doesn’t change this, nor can it. It is my understanding that in-band signalling scales better than out-of-band at a fundamental level.
  • Simpler network devices will lower cost and complexity. I can see that “fat and feature rich” network devices (promoted by many network vendors) will be a good fit for many customers but I remain .
  • In the event of path loss or degradation, there is a clear line of action for fault resolution from the controller. I prefer this directness or imperative style of operation.

I’m genuinely excited to hear about the SDN WAN over the next 3 months.

Footnote

As I said earlier, this post in one in a series of posts on Overlay / Underlay networking. Click [here to read the others]2and feel free to engage in the comments.


  1. http://etherealmind.com/series/overlay-networking/ ↩
  2. http://etherealmind.com/series/overlay-networking/ ↩

Internets of Interest for 24th April 2014

25th April 2014 By bookmarks Filed Under: Bookmarks

Bookmarks of Good Places to Visit

 

Collection of useful, relevant or just fun places on the Internets for 24th April 2014 and a bit commentary about what I’ve found interesting about them:

Why I quit writing internet standards — Tech News and Analysis – Vidya Narayanan writes at GigaOm about the dysfunction and problems of the IETF. I have similar views and am not participating in the IETF for similar reasons. Compare this piece to one from Russ White and David Meyer at Packet Pushers for a different perspective:

After contributing to standards organizations for more than seven years, engineer Vidya Narayanan decided it was time to move on. Although she still believes that these organizations make the Internet a better place, she wonders about the pace of change versus the pace of organizations.


Oh… man – All this – Aweome tip for Mac OS X. from Dr Drang at LeanCrew:

The other day, though, I ran across this page by Russell Harris, explaining a feature of Terminal I never knew existed:Just right-click (or Control-click) on the command you want to look up. The word will highlight, and the context menu that pops up will have Open man Page as its top item.


Why Internet Standards are Still Important – Packet Pushers Podcast – Russ White writing at Packet Pushers talks about the need for IETF –

What we need here is balance. Unfortunately, the networking industry tends to get “shiny thing syndrome,” running off after new and “better” stuff every time something new and shiny turns up with any sort of early success. And another part of the networking industry sits around waiting for the new shiny thing to be able to solve world hunger before even thinking about it. But these are human level problems; a new organization can solve them for a short period of time, but reality has to set in at some point.


Tooled-up Ryobi girl takes nine-inch grinder to Asus beach babe • The Register – I wish I could write a headline this good and accurate.

Fair play to Ryobi for demonstrating that promotional blondes have moved on a bit from hitting the sand to check their Facebook accounts, and can now lay a patio with stylish aplomb.


Why “Trying Too Hard” in Sports (or Life) Can Sabotage Your Success | The Wheelhouse | Big Think – Good advice from Big Think. Be smart not zealous.

People think that the harder they try, the better the results. But effort versus success is not a straightforward upward graph but rather a curve. Once a player goes beyond a certain “effort” threshold, it actually begins to hurt their performance.


Don’t Forget about the ASA’s “show conn” Command – PacketU – My most favourite troubleshooting command on the ASA firewall CLI too. Paul Stewart at PacketU reminds us.

I often find myself troubleshooting connections through an ASA. As a firewall, the ASA is often blamed for network connectivity issues. Therefore, we often just want to determine if the issue is upstream or downstream from the firewall. One of the first things that comes to mind is the packet capture capability. However, there is a simpler tool that may quickly answer these types of questions. That tool is the “show conn” command.

My problem is that always forget the filtering syntax since I don’t work on ASA firewalls all that often.


Choosing the Best Product for the Client or the Best for Me? | LINDSAY HILL – Lindsay Hill picks on a key problem in making cheaper networks, namely that customers get twitchy about paying for relatively expensive professional services on low cost designs. Cognitive Dissonance at its finest.

Am I right in this thinking? Cheaper/free products can definitely do the job, and in the case of Open Source projects, they’re often the only way for really large companies to get the flexibility and power they need. That’s great if I want to work directly for those companies, or as a medium to long-term contractor. But it’s very tough as a consultant. There’s a lot of products I’d like to work with, but I just don’t/won’t get a chance. Maybe it’s time for me to change jobs?

I’ve recently been through this scenario. The customer id come back to me and I was able to cut more than $6 million out of the datacenter design from “BigNameCompany” in the first pass. Now they don’t have any problem paying my fee. It is n’t a reliable business though.


RFC 7203 – An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information – Golf claps for security industry for discovering ways to share meta-data about notifications.

The number of incidents in cyber society is growing day by day.
Incident information needs to be reported, exchanged, and shared
among organizations in order to cope with the situation. IODEF is
one of the tools already in use that enables such an exchange.


Get Ansible to Work on Mac OS X Mavericks | IPyandy – Much needed piece since there seems to be a lot of interest in Ansible for auomation at the moment.

If you’re trying to run an ansible-playbook or just testing around using a Mac running OS X Mavericks. There’s a good possibility that you’ll hit a little snag. Let’s try a simple ping ansible command.


The Goldilocks Zone: Security In The Software-Defined Data Center Era | The Network Virtualization Blog – VMware Blogs – Martin Casado from VMware highlights that security might be the “killer app” for software defined data centres. I agree strongly that SDDC offers a better system for ongoing security improvement but I’ve found that it takes quite a few hours of whiteboarding before people understand why. A sales cycle of that complexity doesn’t scale or allow for rapid growth but it is very sticky. EMC appears to be demanding large profits from NSX division and I doubt this will be a strong marketing message which is truly a los for the industry.

To our thinking, the Goldilocks Zone must simultaneously provide context and isolation for security controls. We can place controls in the endpoint, or in the network, and trade off between these properties, but without both simultaneously, we simply don’t have the right conditions to create a fundamentally secure data center infrastructure. Furthermore, we lack any sort of consistent approach across – and even within – the different infrastructure siloes. We lack ubiquity of control.

The next generation of security is about metadata and SDDC is a primary source for metadata.


  • 1
  • 2
  • 3
  • 4
  • Next Page »

Network Break Podcast

Network Break is round table podcast on news, views and industry events. Join Ethan, Drew and myself as we talk about what happened this week in networking. In the time it takes to have a coffee.

Packet Pushers Weekly

A podcast on Data Networking where we talk nerdy about technology, recent events, conduct interviews and more. We look at technology, the industry and our daily work lives every week.

Our motto: Too Much Networking Would Never Be Enough!

Find Me on Social Media

  • Facebook
  • Instagram
  • Linkedin
  • RSS
  • Twitter
  • YouTube

Return to top of page

Copyright Greg Ferro 2008-2017 - Thanks for reading my site, it's been good to have you here.

Opinions, Views and Ideas expressed here are my own and do not represent any employer, vendor or sponsor.Full disclosure