Vendors will be battling it out in the networking industry as SDN and NFV catch on. Here's who to watch.
The second part of this blog series examines the IEEE standards and government regulations that impact channel bonding.
A long time ago in a podcast far, far away one of the hosts saddled his pony unicorn and started explaining how stateful firewalls work:
Stateful firewall is a way to imply trust… because it’s possible to hijack somebody’s flows […] and if the application changes its port numbers… my source port changes when I’m communicating with my web server - even though I’m connected to port 80, my source port might change from X to Y. Once I let the first one through, I need to track those port changes […]
WAIT, WHAT? Was that guy really trying to say “someone can change a source port number of an established TCP session”?
Read more ...Saying ‘open networking’ is a little like saying ‘SDN’. Without context, it can mean almost anything. Some argue it’s more around options on platforms while others believe it’s more to do with software. When I think about open networking, I think about these main points…
Generic Platforms – White box switches are all the rage these days and for good reason. A white box switch gives you the option to run a variety of different software platforms on generic hardware. This means you don’t need to buy a piece of proprietary hardware to run your proprietary software on. The net result here is that vendor lock in goes away. It also means that you don’t need to wait years and years to buy new hardware to get new software.
Linux – Linux is used EVERYWHERE. As it turns out, it’s already used quite extensively in networking platforms, but not how you might imagine. Most networking vendors use a highly customized version of Linux and the Linux kernel. The reason for this is simple – Linux wasn’t built for networking. Long story short, traditional network vendors had to modify the Continue reading
One of the things I struggled with when starting at a vendor was dealing with project codenames. There is no secret decoder ring – you have to learn the names the hard way. I couldn’t understand why descriptive names weren’t used. It took a while, but I’ve come to understand the reasoning behind the obscure names now. It’s still a stretch to say I ‘love’ them, but I can at least understand them now.
When I started my professional career, it was common to name servers using things like Greek & Roman Gods, or Star Wars characters. Billing might run on Apollo, while Medusa was used for third-party connections.
This is fine for 5-10 servers, but clearly doesn’t scale. I’ve wasted many long and pointless hours in server naming “bikeshedding” discussions. Grumpy old sysadmins would argue that it was far easier to remember names like Bert & Ernie than web01/web02. The Young Turks saw that as a way of hoarding knowledge. It seemed to deliberately make it more difficult for newcomers/outsiders. They preferred descriptive names that gave some indication of what the system was doing, where it was located, etc.
Arguments went back and forth, then virtualisation came Continue reading
At the recent Network Field Day 11, there were several discussions at the Cisco offices after the Cisco folks left the room. One of these discussions, led by Terry Slattery, was centered around SDN, and I think it’s worth a listen/watch (only about 20 minutes):
In this video, I made the argument that SDN should be limited to a very specific definition, which eliminates the management plane from the conversation entirely (around 5:40).
I am in full agreement that the term SDN, or “software-defined __ “ is at this point totally meaningless. It means so many things to so many different people, and predictably, this conversation ended with just as much confusion about SDN as when we started. So, to try to “define” SDN seems pointless, and smells of hair-splitting, but I do this for a very specific reason.
To me, SDN and network automation are two totally different things, yet they almost always get lumped together in conversations. Normally I wouldn’t try to remedy this, but since one of these things is a practical thing to do for many organizations, I want to offer up a different way of thinking about this.
First off, you Continue reading
Below BGP design case study is taken from the Orhan Ergun’s CCDE Practical Workbook.In the new version of the workbook there are more than 50 case studies are shared for many technologies. If you are in the network design field or want to learn about it,don’t miss the book. Scenario : Network A is a customer […]
The post BGP Design Case Study appeared first on Orhanergun.
Below BGP design case study is taken from the Orhan Ergun’s CCDE Practical Workbook.In the new version of the workbook there are more than 50 case studies are shared for many technologies. If you are in the network design field or want to learn about it,don’t miss the book. Scenario : Network A is a customer […]
The post BGP Design Case Study appeared first on Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net.
We manage a distributed system of autonomous elements where the operation, performance and stability is determined by external factors that are out of our operational control.
The post Response: Anomaly Detection For Monitoring appeared first on EtherealMind.