Blog Posts in October 2015
Content providers were using centralized traffic flow optimization together with MPLS TE for at least 15 years (some of them immediately after Cisco launched the early MPLS-TE implementation in their 12.0(5)T release), but it was always hard to push the results into the network devices.
PCEP and BGP-LS all changed that – they give you a standard mechanism to extract network topology and install end-to-end paths across the network, as Julian Lucek of Juniper Networks explained in Episode 43 of Software Gone Wild.
Time for another fill-in-the-blanks survey: how many vendors support NETCONF and/or REST API in their data center switches, routers, firewalls and load balancers?
Please help me complete the tables by writing a comment – and do keep in mind that it only counts if it’s documented in a public configuration guide on vendor’s web site.
Also, I’m not aware of any vendor using standard NETMOD YANG models. If someone does, please let me know.
I had fun times participating in a discussion focused on whether it makes sense to deploy OTV+LISP in a new data center deployment. Someone quickly pointed out the elephant in the room:
How many LISP VM mobility installs has anyone on this list been involved with or heard of being successfully deployed? How many VM mobility installs in general, where the VMs go at least 1,000 miles? I'm curious as to what the success rate for that stuff is.
I think we got one semi-qualifying response, so I made it even simpler ;)
Many vendors talk about network automation these days, and almost all of them gloss over an important detail: automation works best when you manage to simplify things to the bare minimum needed to get the job done.
One of the vendors that focus on simplifying the network device configuration is Cumulus Linux.
One of my readers sent me this question after listening to the podcast with Douglas Comer:
Professor Comer mentioned that IP choose a network attachment address model over an endpoint model because of scalability. He said if you did endpoint addressing it wouldn’t scale. I remember reading a bunch of your blog posts about CNLP (I hope I’m remembering the right acronym) and I believe you liked endpoint addressing better than network attachment point addressing.
As always, the answer is “it depends” (aka “we’re both right” ;).
During my recent SDN workshops I encountered several networking engineers who use Nexus 1000V in their data center environment, and some of them claimed their organization decided to do so to ensure the separation of responsibilities between networking and virtualization teams.
There are many good reasons one would use Nexus 1000V, but the one above is definitely not one of them.
One of my regular subscribers wondered whether it makes sense to attend a live workshop instead of listening to my webinars:
I am following your blog posts quite regularly, I’ve been a yearly subscriber for more than 3 years now and I’m even trying to attend as many webinars as I can in real time. Is there a real benefit to participate in this classroom event if we are almost aware of all your slide decks and videos?
Absolutely. Here’s what one of the attendees of a recent SDN workshop wrote when asking me whether I would be willing to do an on-site event for his company:
Whenever a vendor approaches me touting the benefits of their new gizmo, they want to give me a product demo, or offer me access to online labs… and I always tell them I’m not interested until I see their design and configuration guides.
Here’s why I think you should take the same approach:
Found an interesting article on High Scalability blog (another must-read web site) on how PostgreSQL improves locking behavior in high-volume transaction environment.
Needless to say, the feature is
totally proprietary and not available in other database products. Improved locking behavior ⇒ improved lock-in.
Moral of the story: Stop yammering. Networking is no different from any other field of IT.
Update: Yep, I goofed up on the proprietary bit (it was one of those “I don’t think this word means what you think it means” gotchas). However, if you think open source product can't have proprietary features or you can’t get locked into an open-source product, I congratulate you on your rosy perspective. Reality smudged mine years ago.
You might remember the great idea David Barroso had last autumn – turn an Arista switch into an Internet edge router (SDN Internet Router – SIR). In the meantime, he implemented that solution in production environment serving high-speed links at multiple Internet exchange points. It was obviously time for another podcast on the same topic.
Every time I’m explaining the intricacies of new technologies to networking engineers, I try to use analogies with older well-known technologies, trying to make it simpler to grasp the architectural constraints of the shiny new stuff.
Unfortunately, most engineers younger than ~35 years have no idea what I’m talking about – all they know are Ethernet, IP and MPLS.
Just to give you an example – here’s a slide from my SDN workshop.
Another week, another ExpertExpress session, as is often the case focusing on two data centers with stretched VLANs spanning both of them. However, this one was particularly irksome, as the customer ran a firewall cluster stretched across two locations.
I gave the customer engineers my usual recommendations:
SD-WAN is all the rage these days (at least according to software-defined pundits), but networking engineers still build DMVPN networks, even though they are supposedly impossibly-hard-to-configure Rube Goldberg machinery.
To be honest, DMVPN is not the easiest technology Cisco ever developed, and there are plenty of gotchas, including the problem of default routing in Phase 2/3 DMVPN networks.
While researching for another blog post, I stumbled upon this speech by Winston Churchill:
When the situation was manageable it was neglected, and now that it is thoroughly out of hand we apply too late the remedies which then might have effected a cure. There is nothing new in the story. It is as old as the Sibylline Books. It falls into that long, dismal catalogue of the fruitlessness of experience and the confirmed unteachability of mankind. Want of foresight, unwillingness to act when action would be simple and effective, lack of clear thinking, confusion of counsel until the emergency comes, until self-preservation strikes its jarring gong -these are the features which constitute the endless repetition of history.
Obviously mr. Churchill wasn't talking about IPv6 but about way more serious matters… but it's also obvious he was right abut the unteachability of mankind.
After ARIN ran out of IPv4 address space (in a totally uncontrolled “let’s party till it’s over” way) US enterprise IT shops (RFC 6919) OUGHT TO learn how to spell IPv6 (US service providers are already ahead of the pack).
You may also decide to ignore IPv6 indefinitely, but do keep in mind that consultants love panicking clients.
Jim Small asked me what I thought about the Future of Networking Packet Pushers podcast with Douglas Comer. I decided to listen to it while driving toward one of my recent hikes, and it was a great decision– it was the best Packet Pushers podcast I listened to in a long while.
All you have to do to qualify is (A) download and fill in the registration form, (B) send it to Reiss Romoli and (C) pay before attending the webinar.
Yeah, I know the PDF form says “fax it back” – everyone has to use the tools that work best in their environment.
Hope we'll meet in warm and sunny Rome in a few weeks!
During my recent SDN workshop one of the attendees asked me “How do you build carrier-grade (5 nines) cloud infrastructure with VMware NSX?”
Short answer: You don’t… and it’s a wrong question anyway.
A while ago I started discussing the intricate technical details of fibbing (an ingenious way of implementing traffic engineering with traditional OSPF) with Laurent Vanbever and other members of his group, and we decided to record a podcast on this topic.
A year ago I was a firm believer in the unlimited powers of Software-Defined Data Centers and their ability to simplify workload migrations. After all, if you can use an API to create any data center object, what’s stopping you from moving the workload running in a data center to another location.
As always, there’s a huge difference between theory and reality.
I got into an interesting discussion with a fellow networking engineer trying to understand the impact of a switch failure in a L2/L3 data center fabric (anything from Avaya’s fabric or Brocade’s VCS Fabric to Cisco’s FabricPath, ACI or Juniper’s QFabric) on MAC and ARP tables.
Here’s my take on the problem – have I missed anything?