After working for ITQ for about three years, I will switch to AnyLinQ as of April 1, 2020. Although I am still very happy with ITQ, and I still saw enough perspective for myself, the offer and challenge that AnyLinQ presented me was something I could not refuse. That’s how it feels now.
The past 3 years at ITQ have been the most educational ones of my career, and ITQ has been the best employer I have had so far, I still decided to leave ITQ. It was a very difficult decision to make. My feeling says that I have to jump into it and go for this challenge. At AnyLinQ I will be working in the role of Senior Consultant/Architect, but also going to do some pre-sales and helping build and shape their internal “VMware practice”.
I keep pursuing my VCDX ambitions at AnyLinQ with the same motivation and ambition. My new employer will support my goal for the coming year, and my objective to do my defense in September 2020 will not change.
Looking back at my ITQ time, I am very grateful that I’ve been part of this amazing company with all the wonderful and knowledgeable people as colleagues. I want to thank ITQ for all the time and effort they invested in me, and the cool projects I have done. Because without them I would not have been the Senior IT Professional that I am today.
For now; I am very much looking forward to a new period, with new and different learning curves and my time at AnyLinQ.
In June 2017 I joined the company ITQ Consultancy in the Netherlands. A VMware knowledge POWERHOUSE! Back then I only held a VCP5-DCV certification which was almost expiring, and up to that point, I mainly worked with compute and storage infrastructures.
When I joined ITQ my primary goal for the first year was getting more knowledge on the networking part within IT and especially getting familiar with the Software-Defined Network solution of VMware; NSX for vSphere. My secondary goal was achieving a double VCIX status (DCV and NV) within one year after I started at ITQ.
Recently I worked on a customer engagement where I installed NSX-T into their environment. After the installation, a migration needed to be done from the VSS port groups (VLAN backed) to the NSX-T Segments (VLAN backed).
I’m working on an NSX-T 2.5 design for a customer. Since there are some changes with the load balancing options and design scenarios for Edge Node VMs and N-VDS, I first wanted to know what was changed, and how did it work.
Named Teaming Policies is a feature in that was introduced in NSX-T 2.3 and since NSX-T 2.4 a N-VDS can have multiple Named Teaming Policies attached. This section becomes now even more interesting since the NSX-T Edge Node recommended design has changed with NSX-T 2.5. See this blogpost from Rutger Blom to gain more information about this change.
In this blogpost I’m only focusing on the load balancing part itself when you make use of multiple teaming policies and not how to configure it.
I recently started investing some time into the ”cool kid stuff’; VMware Enterprise PKS, and Kubernetes. I started with reading some blogs, watching some video’s online and reading official documentation. After a while, I started deploying PKS in my lab and tried to integrate it with NSX-T. The blogs I was using were not talking about dynamic routing at all, only doing static routes. Even the Pivotal documentation set is not mentioning BGP setup in that much detail. Only for the Multi-Tenant PKS deployments. I’m not talking about other dynamic routing protocols because NSX-T only supports BGP.
Most of the times customers who are deploying PKS or considering PKS are running dynamic routing protocols in their environments. Therefore, I’m writing this blog to share how I did my BGP setup within NSX-T and PKS, and then specifically for the route redistribution part. (more…)