Using Differentiated Services to Tame Elephants

This post was co-authored by Justin Pettit, Staff Engineer, Networking & Security Business Unit at VMware, and Ravi Shekhar, Distinguished Engineer, S3BU at Juniper Networks.

********************

As discussed in other blog posts and presentations, long-lived, high-bandwidth flows (elephants) can negatively affect short-lived flows (mice). Elephant flows send more data, which can lead to queuing delays for latency-sensitive mice.

VMware demonstrated the ability to use a central controller to manage all the forwarding elements in the underlay when elephant flows are detected.  In environments that do not have an SDN-controlled fabric, an alternate approach is needed.  Ideally, the edge can identify elephants in such a way that the fabric can use existing mechanisms to treat mice and elephants differently.

Differentiated services (diffserv) were introduced to bring scalable service discrimination to IP traffic. This is done using Differentiated Services Code Point (DSCP) bits in the IP header to signal different classes of service (CoS). There is wide support in network fabrics to treat traffic differently based on the DSCP value.

A modified version of Open vSwitch allows us to identify elephant flows and mark the DSCP value of the outer IP header.  The fabric is then configured to handle packets Continue reading

Fibre Channel and FCoE: Some Basics

There’s been some misconceptions and misinformation lately about FCoE. Like any technology, there are times when it makes sense and times when it doesn’t, but much of the anti-FCoE talk lately has been primarily ignorance and/or wilful misrepresentation.

In an effort to fight that ignorance, I put together a quick introduction to how FC and FCoE works. They both operate on the basic premise that you can’t drop any frames. Fibre Channel was built as a lossless protocol, and with a bit of work, Ethernet can also be lossless.

Check it out:


Just Published: SDN and OpenFlow – The Hype and the Harsh Reality

If you’re a regular reader of my blog, you know that I spent a lot of time during the last three years debunking SDN myths, explaining the limitations of OpenFlow and pointing out other technologies one could use to program the network.

During the summer of 2014 I organized my SDN- and OpenFlow-related blog posts 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

Alteon group selection by HTTP Host header using Content Rules

Using this lab setup, I will practice HTTP Host based group selection, which is a server pool in Alteon's terminology.



Fist I need to add two hosts to my /etc/hosts files, which is c:windowssystem32driversetchosts :

  • a.dans-net.com
  • b.dans-net.com

Both will point to 10.136.85.11.


10.136.85.11    a.dans-net.com
10.136.85.11    b.dans-net.com

I want a.dans-net.com to go to SRV1 and b.dan-net.com to go to SRV2

I need to add two groups with one host only. Notice that AFAIK since version 29 Alteon allows to use strings as rip, groups and virt

 /c/slb/group a_dans
        ipver v4
        add 1
 /c/slb/group b_dans
        ipver v4
        add 2

Next step is to configure the Content Class, which means to configure matching classes which will be later used by Content Rules

 /c/slb/layer7/slb/cntclss a_dans http
 /c/slb/layer7/slb/cntclss a_dans http/hostname a_dans
        hostname "a.dans-net.com"
        match equal
 /c/slb/layer7/slb/cntclss b_dans http
 /c/slb/layer7/slb/cntclss b_dans http/hostname b_dans
        hostname "b.dans"

Notice that class a_dans is Continue reading

Basic Alteon setup

Time to actually test the lab.

Click here for previous post to see the lab setup.



Here is a basic Alteon setup with very basic server loadbalancing.

The VIP is 10.136.85.10 and the Source NAT, or proxy ip in Alteon terminology is 10.136.85.200. We need the SNAT, as otherwise the Alteon will reply directly to the client. We need the reply traffic to pass through the Alteon to get it translated back to VIP from the real IP address of the selected server.

Notice that that we have a default GW for the management interface, and a different gateway for the data path, which is the traffic from the client and to the servers.

/c/sys/mmgmt
        dhcp disabled
        addr 10.136.1.100
        mask 255.255.255.0
        broad 10.136.1.255
        gw 10.136.1.254
        addr6 fc00:1:0:0:0:0:0:1
        prefix6 64
        gw6 fc00:1:0:0:0:0:0:254
        ena
/* LB1
/c/sys
        hprompt ena
/c/sys/ssnmp
        Continue reading

Only Two Weeks Left to Sign Up For The First Public Docker Training

JAMES_TEAM@CURTYPHOTOGRAPHY.COM-1

Just a quick reminder:  As of today you have only two weeks to sign up for the very first ever public Docker training class in San Francisco!  Here’s your chance to rapidly get up to speed on Docker’s container technology with plenty of first-hand attention.  The class, held in a small intimate setting in downtown San Francisco, will be led by myself and the legendary Jérôme Petazzoni.  We are both Solutions Engineers at Docker Inc. with strong backgrounds in development and operations.  The training will be held September 17th and 18th and will cover a wide range of topics from fundamentals to best practices to orchestration and beyond.

Click here to reserve your spot today!

Want to learn more and stay up-to-date?

Demo: End to end, hop by hop, physical and virtual network flow visibility with NSX

You’ve probably heard it before. The myth goes something like this: “With software based overlays, troubleshooting in real-time where a flow is going with ECMP hashing on the fabric is going to be a real problem.” The implied message being that this can only be possible with special hardware in a new proprietary fabric switch.

I’ve heard this one a number times, usually while seated comfortably in a session presented by a vendor who’s invested in the failure of software-centric network virtualization such as VMware NSX. As if this person has never heard of Netflow? Or maybe they assume you won’t bother to do the research, connect the dots, and in fact discover all that is possible.

Well, guess what? I decided to do the research :-) And I put together a short demo showing you just how simple it is to get this troubleshooting capability with generally available software, using any standard network switch, constructed in any standard fabric design (routed Leaf/Spine, L2 with MLAG, etc).

I presented this demo to the VMworld TV crew and embedded it here for your convenience:

How does it work?

It’s really simple, actually. Here’s what I explain in the video:

The Continue reading

Demo: End to end, hop by hop, physical and virtual network flow visibility with NSX

You’ve probably heard it before. The myth goes something like this: “With software based overlays, troubleshooting in real-time where a flow is going with ECMP hashing on the fabric is going to be a real problem.” The implied message being that this can only be possible with special hardware in a new proprietary fabric switch.

I’ve heard this one a number times, usually while seated comfortably in a session presented by a vendor who’s invested in the failure of software-centric network virtualization such as VMware NSX. As if this person has never heard of Netflow? Or maybe they assume you won’t bother to do the research, connect the dots, and in fact discover all that is possible.

Well, guess what? I decided to do the research :-) And I put together a short demo showing you just how simple it is to get this troubleshooting capability with generally available software, using any standard network switch, constructed in any standard fabric design (routed Leaf/Spine, L2 with MLAG, etc).

I presented this demo to the VMworld TV crew and embedded it here for your convenience:

How does it work?

It’s really simple, actually. Here’s what I explain in the video:

The Continue reading

Demo: End to end, hop by hop, physical and virtual network flow visibility with NSX

You’ve probably heard it before. The myth goes something like this: “With software based overlays, troubleshooting in real-time where a flow is going with ECMP hashing on the fabric is going to be a real problem.” The implied message being that this can only be possible with special hardware in a new proprietary fabric switch.

I’ve heard this one a number times, usually while seated comfortably in a session presented by a vendor who’s invested in the failure of software-centric network virtualization such as VMware NSX. As if this person has never heard of Netflow? Or maybe they assume you won’t bother to do the research, connect the dots, and in fact discover all that is possible.

Well, guess what? I decided to do the research :-) And I put together a short demo showing you just how simple it is to get this troubleshooting capability with generally available software, using any standard network switch, constructed in any standard fabric design (routed Leaf/Spine, L2 with MLAG, etc).

I presented this demo to the VMworld TV crew and embedded it here for your convenience:

How does it work?

It’s really simple, actually. Here’s what I explain in the video:

The Continue reading

Five Reasons To Be At Interop New York

This guest post is by Drew Conry-Murray, Director of Content & Community at Interop and a good friend of the Packet Pushers. SPECIAL NOTE: Interop is offering the Packet Pushers community a 25% discount on Total Access and Conference Passes or a FREE Expo Pass for the New York show. Register today with the code PACKETP to receive the discount. The […]

Author information

Sponsored Blog Posts

The Packet Pushers work with our vendors to present a limited number of sponsored blog posts to our community. This is one. If you're a vendor and think you have some blog content you'd like to sponsor, contact us via [email protected].

The post Five Reasons To Be At Interop New York appeared first on Packet Pushers Podcast and was written by Sponsored Blog Posts.

Basics – Docker, Containers, Hypervisors, CoreOS

Containers virtualize at the operating system level, Hypervisors virtualize at the hardware level. Hypervisors abstract the operating system from hardware, containers abstract the application from the operation system. Hypervisors consumes storage space for each instance. Containers use a single storage space plus smaller deltas for each layer and thus are much more efficient. Containers can boot and be […]

The post Basics – Docker, Containers, Hypervisors, CoreOS appeared first on EtherealMind.

SLAAC May Save Your Life

Flatline

A chance dinner conversation at Wireless Field Day 7 with George Stefanick (@WirelesssGuru) and Stewart Goumans (@WirelessStew) made me think about the implications of IPv6 in healthcare.  IPv6 adoption hasn’t been very widespread, thanks in part to the large number of embedded devices that have basic connectivity.  Basic in this case means “connected with an IPv4 address”.  But that address can lead to some complications if you aren’t careful.

In a hospital environment, the units that handle medicine dosing are connected to the network.  This allows the staff to program them to properly dispense medications to patients.  Given an IP address in a room, staff can ensure that a patient is getting just the right amount of painkillers and not an overdose.  Ensuring a device gets the same IP each time is critical to making this process work.  According to George, he has recommended that the staff stop using DHCP to automatically assign addresses and instead move to static IP configuration to ensure there isn’t a situation where a patient inadvertently receives a fatal megadose of medication, such as when an adult med unit is accidentally used in a pediatric application.

This static policy does lead Continue reading

Windows ISATAP Client, Part 3

In Part 2 we did the initial ISATAP configuration for our Cisco router. Here we’ll show the config we use on our Windows clients and server. netsh interface isatap set router 203.0.113.30 netsh interface isatap set state enabled Normally I tell system admins to never hard-code IP addresses into their application; always use DNS names! […]

Author information

Dan Massameno

Dan Massameno is the president and Chief Engineer at Leaf Point, a network engineering firm in Connecticut.

The post Windows ISATAP Client, Part 3 appeared first on Packet Pushers Podcast and was written by Dan Massameno.

Debian/Ubuntu PMTUD & uRPF

I originally started my PMTUD posts using Ubuntu 14.04. Halfway through the post I simply could not get Ubuntu to change it’s MTU on receipt of ICMP fragmentation needed messages. I then tried Debian and it worked. Windows also had no issues changing it’s MTU. Wanting to finish off the post I switched to Debian […]

Network Infrastructure as Database

A while ago I wrote about the idea of treating network infrastructure (and all other infrastructure) as code, and using the same processes application developers are using to write, test and deploy code to design and implement networks.

That approach clearly works well if you can virtualize (and clone ad infinitum) everything. We can virtualize appliances or even routers, but installed equipment and high-speed physical infrastructure remain somewhat resistant to that idea. We need a different paradigm, and the best analogy I could come up with is a database.

Read more ...

Q and A with Neela Jacques, OpenDaylight Executive Director

Q&A with Neela Jacques, OpenDaylight Executive Director

by Matt Sherrod, VP of Product Management - September 2, 2014

As OpenDaylight makes progress towards spurring adoption of SDN and NFV via an open platform, we asked Executive Director Neela Jacques his latest thoughts on the project’s current status, the state of SDN management, and what’s next.   

1. For people who may not be familiar with OpenDaylight, what is your mission?
OpenDaylight is an open source project that is creating a common, open platform for SDN and NFV. We’re a community of developers uniting competitors to work collaboratively to overcome networking’s toughest challenge -- technology fragmentation and duplication. By creating an open codebase for SDN and NFV, OpenDaylight is a vehicle for vendors to build their unique products, service and support offerings on top of a common, core set of technologies.   

2. Do you feel like the move toward open SDN has reached a critical mass? When and how do you see that happening?
In less than 15 months since we formed, OpenDaylight has grown to include 39 member companies and more than 220 developers that are working to unify the networking industry around a common, open, standard code base. Continue reading

Steve Jobs Thinks All Network Engineers Should Learn to Code

With some downtime this weekend, I was able to watch a few documentaries on NetFlix.  There were a few great ones on Mark Zuckerberg, Warren Buffet, Mark Cuban, and Steve Jobs.  Many of them came from the Bloomberg Game Changers series, but for Steve Jobs, I watched the Steve Jobs: The Lost Interview that was filmed in 1995, lost for almost two decades and then was released in 2012.  I highly recommend all of them, but for this post, I want to highlight something Jobs said nearly 20 years ago.
What does this have to do with Networking?

There have been numerous articles over the past few months, some by me, that either advocate that network engineers should learn how to program, that there is no need for them to learn how to program, or they should simply learn to think like programmers.

Now check out what Steve Jobs said in the following video back in 1995:
…I think everybody in this country should learn how to program a computer – [they] should learn a computer language, because it teaches you how to think.  It’s like going to law school.  I don’t think anybody should be Continue reading
1 … 3,723 3,724 3,725 3,726 3,727 … 3,854