Packet Design CTO to Discuss SDN Management Challenges

Session to cover need for route analytics to facilitate SDN across wide area networks

SANTA CLARA, Calif. – Nov. 11, 2013 – Packet Design CTO Cengiz Alaettinoglu will conduct a technical session during the 16th annual MPLS/SDN 2013 International Conference about how route analytics can address software defined networking (SDN) management challenges. Specifically, he will introduce the need for a network access broker to verify if the wide area network (WAN) can handle the traffic demands of SDN applications without impacting other applications adversely.

Session Title: “Challenges in Operating a Software Defined Network: How Route Analytics Alleviates the Risks”

Session Description: Northbound SDN APIs allow creation of network-aware applications. Cloud and data center applications have successfully taken advantage of these APIs to provide seamless virtual machine mobility and elasticity. However, these applications are unaware of whether or not the underlying WAN can provide acceptable performance.

Technology vendors have toyed with bandwidth on demand, demand placement and rapid provisioning as SDN applications for carriers. The ability to provide performance guarantees for these applications as well as cloud applications requires deep understanding of underlying real-time network topology and traffic demands. Route analytics is the state-of-the-art-technology needed to provide this information.

In this presentation, Cengiz will Continue reading

Cisco ACI: As The Dust Settles

So, the industry is sufficiently abuzz about the Cisco ACI launch last week, and the stats on my introductory series I wrote tells me that, like it or not, this is having a pretty big impact. The focus on the application is clearly the right approach - all of this talk about SDN and network virtualization is taking place because the current network model’s complexity results in bad kluges and long provisioning times, and the applications folks are always waiting on the network to respond.

Cisco ACI: As The Dust Settles

So, the industry is sufficiently abuzz about the Cisco ACI launch last week, and the stats on my introductory series I wrote tells me that, like it or not, this is having a pretty big impact. The focus on the application is clearly the right approach - all of this talk about SDN and network virtualization is taking place because the current network model’s complexity results in bad kluges and long provisioning times, and the applications folks are always waiting on the network to respond.

Install Open vSwitch v2 from Source on Red Hat Fedora 19

This is a walk through for installing Open vSwitch v2.0+ on RedHat Fedora 19 from source. If you want to build Open vSwitch from RPM binaries please see this post There are some new OVS tables included in the latest builds that include some neat concepts. OVS is often regarded as the SDN reference data plane implementation in the early ...

...

Who Uses Google’s DNS?

Much has been said about how Google uses the services they provide, including their mail service, their office productivity tools, file storage and similar services, as a means of gathering an accurate profile of each individual user of their services. The company has made a very successful business out of measuring users, and selling those metrics to advertisers. But can we measure Google as they undertake this activity? How many users avail themselves of their services? Perhaps that's a little ambitious at this stage, so maybe a slightly smaller scale may be better, so let's just look at one Google service. Can we measure how many folk use Google's Public DNS Service?

Handy Tshark Expressions

Tshark is the CLI version of Wireshark, and it's amazing. I'm going to start collecting some of my favorite tshark one-liners here. Check back often.

Find All Unique Filenames Referenced in SMB2
tshark -r file.pcap -Tfields -e ip.src -e ip.dst -e text smb2 | grep -oP "GUID handle File: .*?," | sort | uniq | awk -F: '{print $2}' | sed 's/,//'

Notes:
You don't actually need to include the ip.src and ip.dst fields, since they're not extracted by the grep command. I include them in case I want to do an ad-hoc grep for an IP address during the analysis process. Another way to do the same thing would be to modify the display filter to look only for certain addresses, e.g.:

tshark -r file.pcap -Tfields -e text smb2 and ip.addr==1.1.1.1 | grep -oP "GUID handle File: .*?," | sort | uniq | awk -F: '{print $2}' | sed 's/,//'

IETF 88 Technical Plenary

This is a long video, but you need to watch it. I’ll have a couple of longer reports on IETF 88 in the coming weeks, as I get the chance to write stuff up. Edit: For anyone who’s interested in this topic specifically, please join the perpass IETF mailing list.

Author information

Russ White

Russ White
Principle 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. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area of network complexity with Addison Wesley, Continue reading

Show 166 – SDN Controller Strategies

We know that networking for last few months is all about SDN Unicorns and other Applications. This week we are joined by Mike Dvorkin and Brent Salisbury to talk about the science of building SDN controller application. It's not easy to decide how to build a model that allows for business policy to map onto flow management, virtual server and physical devices so we gathered in the virtual boardroom to discuss the fundamental nature of SDN Controller and basic concepts of what you want to build and why.

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.

The post Show 166 – SDN Controller Strategies appeared first on Packet Pushers Podcast and was written by Greg Ferro.

Evolving the data center network core

As complex functions that were historically shoehorned into the network core move out to the edge where they belong, data center core network operators can now focus on improving the experience for the different types of applications that share the network.  Furthermore, with fewer vertically scaled systems giving way to many horizontally scaled systems, the economics of data center bandwidth and connectivity needs to change.

I’ve jotted down some thoughts for improving the data center core network along the lines of adding bandwidth, managing congestion and keeping costs down.

Solve bandwidth problems with more bandwidth


Adding bandwidth had been a challenge for the last several years owing to the Ethernet industry not being able to maintain the historical Ethernet uplink:downlink speedup of 10:1, and at the same time not bringing down the cost of Ethernet optics fast enough.  Big web companies started to solve the uplink bandwidth speed problem in the same way they had solved the application scaling problem -- scale uplinks horizontally.  In their approach, the role of traditional bridging is limited to the edge switch (if used at all), and load-balancing to the edge is done using simple IP ECMP across a “fabric” topology.  The number Continue reading

[Insieme and Cisco ACI] Part 2 – Programmability

Introduction to Application-Centric Infrastructure In the last post, we discussed the hardware that was being announced from Cisco’s Insieme spin-in. While the hardware that is comprising the new Nexus 9000 series is certainly interesting, it wouldn’t mean nearly as much without some kind of integration on an application level. Traditionally, Cisco networking has been relatively inaccessible to developers or even infrastructure folks looking to automate provisioning or configuration tasks. It looks like the release of ACI and the Nexus 9000 switch line is aiming to change that.

[Insieme and Cisco ACI] Part 1 – Hardware

I’m pleased to kick off my 3-part blog series regarding the VERY recently announced data center networking products by Insieme, now (or very soon) part of Cisco. Nexus 9000 Overview From a hardware perspective, the Nexus 9000 series seems to be a very competitively priced 40GbE switch. As (I think) everyone expected, the basic operation of the switch is to serve up a L3 fabric, using VXLAN as a foundation for overlay networks.

[Insieme and Cisco ACI] Part 2 – Programmability

Introduction to Application-Centric Infrastructure In the last post, we discussed the hardware that was being announced from Cisco’s Insieme spin-in. While the hardware that is comprising the new Nexus 9000 series is certainly interesting, it wouldn’t mean nearly as much without some kind of integration on an application level. Traditionally, Cisco networking has been relatively inaccessible to developers or even infrastructure folks looking to automate provisioning or configuration tasks. It looks like the release of ACI and the Nexus 9000 switch line is aiming to change that.

[Insieme and Cisco ACI] Part 1 – Hardware

I’m pleased to kick off my 3-part blog series regarding the VERY recently announced data center networking products by Insieme, now (or very soon) part of Cisco. Nexus 9000 Overview From a hardware perspective, the Nexus 9000 series seems to be a very competitively priced 40GbE switch. As (I think) everyone expected, the basic operation of the switch is to serve up a L3 fabric, using VXLAN as a foundation for overlay networks.

[Insieme and Cisco ACI] Part 2 – Programmability

Introduction to Application-Centric Infrastructure In the last post, we discussed the hardware that was being announced from Cisco’s Insieme spin-in. While the hardware that is comprising the new Nexus 9000 series is certainly interesting, it wouldn’t mean nearly as much without some kind of integration on an application level. Traditionally, Cisco networking has been relatively inaccessible to developers or even infrastructure folks looking to automate provisioning or configuration tasks. It looks like the release of ACI and the Nexus 9000 switch line is aiming to change that.

[Insieme and Cisco ACI] Part 1 – Hardware

I’m pleased to kick off my 3-part blog series regarding the VERY recently announced data center networking products by Insieme, now (or very soon) part of Cisco. Nexus 9000 Overview From a hardware perspective, the Nexus 9000 series seems to be a very competitively priced 40GbE switch. As (I think) everyone expected, the basic operation of the switch is to serve up a L3 fabric, using VXLAN as a foundation for overlay networks.

Avoiding Demo Fail

How would you like to be the CEO of a company like Apple or Dropbox? Money, fame and awesomeness surround you. But as cool as that sounds, it doesn’t prevent you from living through a failed live product demo in...

VMware NSX, Convergence, and Reforming Operational Visibility for the SDDC

Note: This article was originally written for and published at the VMware Network Virtualization Blog. The following is a verbatim re-post of the original content.


Through convergence, VMware NSX will substantially reform operational visibility for the era of the software-defined data center.

Executive Summary

Since the launch at VMworld 2013, much of the discussion about VMware NSX has been focused on its core properties of agile and fully automated network provisioning; the ability to create fully functional L2-L7 virtual networks in a software container with equivalent speed and mobility of virtual machines. And while these are very important capabilities of VMware NSX, we believe there is yet another and perhaps equally significant dimension to be discovered. That is, how network virtualization and VMware NSX, through convergence and instrumentation of virtual networks, virtual compute, and the physical network, will substantially reform operational visibility for the era of the software defined data center.

With convergence comes new visibility

Convergence of network and compute is made possible by a platform ideally positioned at the first point in the architecture where these different yet closely related services can reliably coexist. A less obvious yet significant consequence of this is that convergence inherently provides more Continue reading