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.
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
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 […]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
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
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
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 […]Log analysis GUI tools
Log analysis is important to both troubleshoot and understand network devices behaviour. Tail/less/grep are great tools that can help to filter and search hundreds or thousands lines of logs. If you prefer a GUI there are a couple of alternatives…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:
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
Let People Choose Their Own Tools
Why is it that people will pay a lot of money for a consultant’s time and expertise, but then hobble them by limiting the tools they can use?
Chris Wahl has written about learning to cope with the default tools and settings:
It’s almost a given that anything I own – personally or via my employer – will not be allowed to touch any piece of software or hardware in the average client environment. It causes too many headaches with compliance rule sets like Sarbanes-Oxley (SOX)…
This means that I’ve come to rely on whatever tools are universally available. Let’s take PowerShell for example. I have an entire library of scripts that I’ve written over the past several years. More often than not I end up using the vSphere Client or ESXi Shell instead because I can’t get to my scripts. If it’s a highly repetitious task I may just re-create a script by hand, but more often than not, it’s not worth the effort.
I’ve posted similar things to IEOC about the use of aliases on network gear:
I’m a consultant, so I work on a variety of different systems, and can’t rely on having a large list of aliases Continue reading