Deterministic peering sounds very complicated, doesn’t it? It is also sometimes called deterministic steering.
In short, within NSX it is used as ‘being able to determine which BGP neighbor to peer with’, or ‘being able to determine which path the traffic should take’. Even shorter: ‘does this packet take uplink A or B?’
Why?
The reason for using this pathing method in NSX is to be more in control of failure scenarios and to be able to predict what will happen when a certain component fails, rather than leaving it up to the algorithm gods.
It depends on the requirements of your project or company whether or not you must be able to accurately describe everything in case of an incident. For example; financial institutions typically need to be able to go into extreme detail of each scenario, whereas an SMB can get away with a more flexible approach.
From a deployment perspective this relates to the different Availability Zones in your infrastructure or design.
Being able to predict what happens in case of a failure can also help you troubleshoot issues later on, when trying to figure out the root cause of the problem. If you can trace the failure back by way of which path remained up and which ones didn’t, it can help point you in the right direction.
In the VCF Design Guide it relates to design decision VCF-NSX-BGP-REQD-CFG-002.
What?
Looking back at my previous post about the Tier-0 and Edge Node uplinks, we can use the same image to expand upon it.
Here we see Uplink VLAN A and Uplink VLAN B, the same as in the previous post. I’ve expanded the image to also show the ESXi host underneath.
The point of the deterministic part is that you can determine which path each packet should take at any given time. So in the example above, we want to make sure that packets tagged with VLAN A only exit through pNIC0 on the physical ESXi host. Same for VLAN B, with with pNIC1.
This can occur when you have two different top of rack switches, to create two availability zones for example. In this case pNIC0 would connect to ToR A with VLAN A, and pNIC1 would connect to ToR B with VLAN B.
If both VLANs are available on both pNICs, any of this doesn’t apply, since it doesn’t matter through which uplink the packets egress the ESXi host.
How?
In NSX this determinism is achieved through named uplink teaming policies configured at a couple of profiles.
Uplink profile
The first point to apply the named uplink teaming policies is at the uplink profile level. This applies to Edge Nodes for the T0 uplinks described in this post, but can also apply to ESXi hosts/Transport Nodes for VLANs segments made available for VM traffic.
Simply add two teamings when creating the Uplink Profile and designate them a single uplink each. See below for a 2-uplink profile.
Recall that the ‘Uplink-1’ and ‘Uplink-2’ are applied to the uplink portgroup (or segment) when creating the Edge Node itself, as depicted below.
In the portgroups I have defined which VLAN are trunked – in this case VLAN 100 for Overlay/GENEVE, and the two uplink VLANS – A is 120 and B is 121.
Transport Zone
The second point to configure the named uplink policies is at the VLAN Transport Zone level. If you have a separate Edge Node Transport Zone and a VM VLAN Transport Zone (as design recommendation VCF-NSX-OVERLAY-REQD-CFG-005 specifies) and you want steer the traffic for both, then you need to apply the named policies to both Transport Zones.
When creating the Transport Zone, or editing it, add the uplink teaming policy names to the list. Note that the uplink teaming policy names must match with the named uplinks defined in the uplink policy exactly.
Uplink segments
With the named uplink policies made available in NSX, we are now able to create segments and steer the traffic over a specific uplink. When creating a segment select the named policy you want the traffic to egress through at the ‘Uplink Teaming Policy’ drop down menu.
If no named policies are showing up, make sure you have the correct Transport Zone selected.
Make sure you add the VLAN that is available on the respective uplink!
Do the same for uplink 2.
Then finally we can connect those segments to the Tier-0 Gateway to use them as uplinks. Select the respective uplinks when creating the interfaces for the Tier-0.
Now the first Tier-0 uplink, named T0-Uplink01, with VLAN 120 tagged, will only egress through uplink-1, which is bound to a portgroup with VLAN 120 as part of the trunk. Whereas T0-Uplink02 will only egress through uplink-2, which has VLAN 121.
Summary
Deterministic peering, deterministic path steering, whatever you want to call it, allows you to determine the path that a (VLAN) packet is going to take. This is achieved by defining uplink policies that bind a physical uplink port to an NSX logical segment.
If you want to read more about this topic, I can highly recommend this blog from Harikrishnan over at VxPlanet, or this one from Shank at Lab2Prod.
The original article was posted on: significant-bit.com
