Featured Video & White Paper: Cisco’s GBP to OpenStack
Cisco highlights its group-based policy (GBP) abstractions for OpenStack, a declarative policy model that simplifies application-oriented interfaces.
Public Key Authentication on Cisco IOS
Have you ever been in that situation that you needed to apply the same configuration quickly on multiple Cisco routers? If yes, youPublic Key Authentication on Cisco IOS
Have you ever been in that situation that you needed to apply the same configuration quickly on multiple Cisco routers? If yes, you probably wrote a script that connected to routers and sent appropriate IOS commands. One problem that you certainly had to solved was forcing your script to enter login credentials such as username and password. Moreover if you secure an access to privileged user mode of routers with an enable secret command you had to tell the script how to enter that password as well.
All the issues I have mentioned above can be easily solved with Expect scripting language. Expect sends commands via telnet or ssh session as the human would. However encapsulating IOS commands to syntax recognized by Expect language every time you need to change routers' configuration seems to be not very comfortable. That is why public key authentication for Cisco routers can be handy.
Public key authentication allows you to log in to your routers using RSA key instead of a password. But firstly key-pair - public and private key must be generated and a public key copied into a config file of the router. Then you can connect to the router with your private key. A private key is the key that should 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: 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