Vendor Marketectures in Real Life
Remember my rants about VMware and firewall vendors promoting crazy solutions that work best in PowerPoint and cause more headaches than anything else (excluding increased vendor margins and sales team bonuses, of course)?
Here’s another we-don’t-need-all-that-complexity real-life story coming from one of my long-term subscribers:
My client runs VMware NSX on top of a Nexus BGP EVPN with VXLAN network. We manage the physical network and a 3rd party manages the NSX. The 3rd party come from a VMware background and are not as strong on networking. They are using NSX-V and are about to deploy pockets of NSX-T, but NSX-V will be around for a while.
The problem I have is they have deployed NSX-V in an active active DC design which was causing all sorts of asymmetrical routing horribleness that was upsetting the firewalls, whilst pushing all this complexity down to the physical network to resolve.
Long story short I armed myself with the facts thanks to your webinars, called a meeting and now all the stakeholders agree we need to migrate to an active/standby design, simplifying it greatly. I’m not taking all the credit for it as the 3rd party eventually came to the same conclusion as me, but it helped me build more credibility with my customer. Thanks again for making me look good ;)
Here are some ipSpace.net resources he might have used in the process:
- Designing Active-Active and Disaster Recovery Data Centers
- NSX Technical Deep Dive
- Disaster recovery-related blog posts
"Do You still need this ipspace subscription?" is the question I hear every year. "Do we even do or use things the guy teaches?" My answer is always: "Yes, sure, but what's more important, we know what not to do" Cheers.
It is all about a proper design, with any product. The best product will not scale well and behave as it should with a bad design. By the way, you dont need to be worried about NSX-V/T dfw and asymmetric flows contrary to a perimeter FW. With dfw, there is only a single interface for ingress and egress...the vNIC of the VM.