SDN: Integration over Manipulation
I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.
If you’ve ever been in this situation, you likely realize this entire process probably takes some time. Either the application team doesn’t know what exactly needs to be changed, or the network team is too busy, or both. Clearly, there’s a problem. And more often than not, this discussion becomes all about the forwarding architecture.
Oh yes, with old-school ACLs we could only match on a few things - IP subnets, TCP ports, that's about it. But now with OpenFlow - we can match on **EtherType**!! We're saved!!
Don’t be misled - the value of an SDN architecture does not lie in the fact that we can do Continue reading
SDN: Integration over Manipulation
I’d like to briefly express a sentiment that I pondered after listening to another one of Ivan’s great podcasts, specifically regarding the true value of a software-defined network approach. The statement was made that ACLs are terrible representations of business policy. This is not inaccurate, but the fact remains that ACLs are currently the de facto representation of business policy on a network device. The “network team” gets a request from an application team to “fix the firewall”, and the policy that is applied to enable that application typically results in an ACL change.
If you’ve ever been in this situation, you likely realize this entire process probably takes some time. Either the application team doesn’t know what exactly needs to be changed, or the network team is too busy, or both. Clearly, there’s a problem. And more often than not, this discussion becomes all about the forwarding architecture.
Oh yes, with old-school ACLs we could only match on a few things – IP subnets, TCP ports, that’s about it. But now with OpenFlow – we can match on EtherType!! We’re saved!!
Don’t be misled – the value of an SDN architecture does not lie in the fact that we can do Continue reading
SDN Terminology from Layered Models
Even though we don’t build networks with OSI products, we still use terms from the OSI model. What terms will we end up using for SDN, once the dust settles?
The previous post introduced one document that attempts to define terms and architecture, and today’s post introduces another: the ITU-T Y.3300 document. But how do these documents fit in with our fast-changing networking landscape – and what words should we use? Today’s post looks at the Y.3300 doc, and explores a few of the terms.
Other posts in this series:
Big Picture First: ITU-T Y-Series
Most of us don’t have a reason to read docs from standards bodies unless we’re looking for a particular standard or fact. But as long as we’re talking about one doc from the ITU-T Y-series, it’s worth a minute to set the context of what these documents are.
First off, the topic area for the Y-series is broad, but it’s all networking! The title for the ITU-T’s Y-series of documents spells out the big items:
Global information infrastructure, Internet protocol aspects and next-generation networks
Great, so the topic is global network, IP, including next-generation networks. It’s networking! Continue reading
Better than best effort — reliability and the Internet.
Metcalfe’s law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system.Networks prior to the Internet were largely closed systems, and the cost of communicating was extraordinarily high. In those days, the free exchange of ideas at all levels was held back by cost. On the Internet, for a cost proportional to a desired amount of access bandwidth, one can communicate with a billion others. This has propelled human achievement forward over the last 20 years. By way of Metcalfe’s law, the Internet’s value is immeasurably larger than any private network ever will be.
So why do large private service delivery networks still exist?
The answer lies primarily in one word: reliability. What Metcalfe’s law doesn’t cover is the reliability of communication of connected users, and the implications of a lack of reliability on the value of services delivered. Although Internet reliability is improving, much like the highway system, it still faces certain challenges inherent with open and unbiased systems.
On a well run private network, bandwidth and communications are regulated to deliver an optimal experience, and network issues are addressed more rapidly as all components Continue reading
On a Journey with VMware NSX Customers
Playing a part in the transformation of the networking industry has been one of the most rewarding opportunities of 
my career. On top of that I get the privilege of leading a team that continues to amaze me in their ability to execute. You’ve heard us talk about the more than 400 VMware NSX customers we have to date, 70+ of which are in production. You can safely assume that number is even higher today. Even more impressive is the fact that customers are making significant financial commitments to the architectural changes they are embarking on. In fact, as of last quarter we counted more than 50 organizations that have invested more than $1 million in NSX.
Now, it’s never easy for IT organizations to talk publicly about technologies they’ve purchased or deployed. This is all the more reason why I’m very grateful that VMware NSX customers have made time to speak publicly about the value they are deriving from VMware NSX to the financial community, at events such as RSA Conference, Palo Alto Networks Ignite and OpenStack Summit, and of course, to the press. No other vendor can claim more customers that are publicly discussing their Continue reading
Liveblog from ONUG!
We’re going to try out a new thing today – liveblogging from the ONUG Spring 2015 presentations here in NYC. If it doesn’t work, I apologize – but it’ll be fun trying!
If you liked this post, please do click through to the source at Liveblog from ONUG! and give me a share/like. Thank you!
Vendor Neutral
And then Bilbo held the router up to the light and wondered aloud… Whatever is, vendor neutral?
Vendor neutral certainly receives a lot of play in the world of network engineering. You might have even heard the words come out of my mouth during my case study on the Telepost Greenland network at Interop a couple of weeks ago. Maybe even more than once.
But what does vendor neutral actually mean?
Does it really mean, “Can I buy my next piece of equipment from any vendor I like, and not worry about it working in my network?” Or, perhaps, “Can I buy my next piece of equipment from any vendor I like, and not worry about it disrupting my network management and operations?” The second question is the harder, in the real world — and one we’re not likely to get an answer to any time soon.
What about an open API into every piece of equipment in your network? That would be nice — but how do we get from where we are today to that nirvana? We’ve had the drive towards a MIB based interface, a common set of command line configuration constructs, several API driven Continue reading
ONUG Spring 2015 Live Blog
My live blog from the ONUG 2015 Spring event in NYC.SDN Terminology from Layered Models
Even though we don’t build networks with OSI products, we still use terms from the OSI model. What terms will we end up using for SDN, once the dust settles?
The previous post introduced one document that attempts to define terms and architecture, and today’s post introduces another: the ITU-T Y.3300 document. But how do these documents fit in with our fast-changing networking landscape – and what words should we use? Today’s post looks at the Y.3300 doc, and explores a few of the terms.
Other posts in this series:
Big Picture First: ITU-T Y-Series
Most of us don’t have a reason to read docs from standards bodies unless we’re looking for a particular standard or fact. But as long as we’re talking about one doc from the ITU-T Y-series, it’s worth a minute to set the context of what these documents are.
First off, the topic area for the Y-series is broad, but it’s all networking! The title for the ITU-T’s Y-series of documents spells out the big items:
Global information infrastructure, Internet protocol aspects and next-generation networks
Great, so the topic is global network, IP, including next-generation networks. It’s networking! Continue reading
Diving into the DNS
The turning of the DNS from a distributed database query tool into a malicious weapon in the cyber warfare arena has had profound impacts on the thinking about the DNS. I remember hearing the rallying cry some years back: “Lets all work together to find all these open resolvers and shut them down!” These days I don't hear that any more. It seems that, like SPAM in email, we’ve quietly given up on eradication, and are now focusing on how to preserve service in a toxic world. I suppose that this is yet another clear case of markets in action – there is no money in eradication, but there is money in meeting a customer’s requirement to allow their service to work under any circumstances. We’ve changed our self-perception from being the public DNS police to private mercenaries who work diligently to protect the interests of our paying customers. We are being paid to care about the victim, not to catch the attacker or even to prevent the attack.Reinventing CLNS with L3-only Forwarding
Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:
What you describe is literally intra-area routing in CLNS.
He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).
Read more ...Connecting NXOS VIRL instance to Arista vEoS
In this blog, I will cover the steps that I did to connect Cisco NXOS VIRL switch instance to Arista vEoS switch instance. We can connect any Cisco switch simulated in VIRL, I just picked the NXOS switch type. CML/VIRL supports majority of Cisco switches as VM as well as few external switches from Juniper, … Continue reading Connecting NXOS VIRL instance to Arista vEoS
Cisco NXAPI with VIRL
In this blog, I will cover the steps to get NXAPI working with NXOS image in VIRL. For more details on CML/VIRL, please refer to my earlier blog series. Running NXAPI with VIRL image makes it easy to write automation scripts without needing a physical switch. Earlier, I had installed VIRL February release(0.9.17) which included … Continue reading Cisco NXAPI with VIRL