With VSAP, Nuage Can Read Any SDN Underlay
A network visibility tool lets Nuage users peer into any underlay network.
Cisco Still Loves ASICs, as EZchip Discovers the Hard Way
A chipmaker's stock plunges as Cisco returns to ASICs on a key platform.
VMware Says Customers Are Betting Big on NSX
A new twist on counting SDN customers: Who's really committed?
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