Table of Contents
Purpose
Impact of Don't Encode Org-id Option
Solution for Analytics Reach-ability via ADC
Purpose
The purpose of this documentation is to describe the impact of enabling "don't encode org-id" option on the director's overlay addressing schema which in turn affects Analytics reachability in a multi-tenant system when ADC is enabled on the controllers towards the Analytic servers.
Impact of Don't Encode Org-id Option
When the director overlay addressing schema is enabled for “Do not encode Org Id” (as seen in the screen shot below), the same ip-address is used for the tvi’s belonging to different tenants on the branch – in other words, there is a duplication of the ip-address, assigned to the control-vr tvi (clear/secure), across the tenants in a multi-tenant setup. This is expected and is actually the use-case for enabling this knob as a means to reduce the ip-address consumption in a multi-tenant production setup
Below screen-shot shows the overlay address schema on the director with "Don't Encode Org Id" set to True.
Seen below is an example of ip-address duplication across the control-vr belonging to multiple tenants – you can see 10.148.0.2 (clear) and 10.148.0.3 (secure) being re-used across the tenants
The duplication of ip-address, across the control-vr tvi interfaces, possess a problem while using ADC on the controllers towards the analytic nodes. The ADC employs a VIP ip-address which is basically the tvi ip-address of the provider org (where the ADC is configured) as seen below
As seen, 10.0.0.3 is configured as the VAN-VIP ip-address (not too clear in the screen shot below)
This VAN-VIP ip-address is actually configured on the branches as the “lef collector” address, so the branches would initiate tcp session towards this ip-address. The controller would receive the session packets on the tenant control-vr and pass it on to the provider control-vr which has the ADC configured.
However, since the tenant’s tvi ip-address is also the same as the VAN-VIP address, it would consume the LEF session packets coming from the branch instead of passing it to the provider Org’s Control-vr – so essentially the lef session packets will never make it to the provider’s Control-vr where the ADC is configured.
You would see the below condition on the branches with respect to the LEF sessions – they would be stuck in “re-connect” because the session never makes it to the analytic servers.
Solution from Analytics Reachability via ADC
In order to resolve this condition you would need to define a unique ip-address, on the controllers, which would be used as the VAN-VIP address in the provider Org’s control-vr.
You can define this ip-address as belonging to a loopback interface which is part of the parent Org’s control-vr – this way the ip-address would get advertised to all the sites/branches as a sdwan bgp update.
It’s required to perform these steps on all the controllers which have ADC towards the analytics.
Step 1: Create a loopback interface
Step2: Associate the loopback interface with the Provider Org’s control VR
Step 3: Ensure that the loopback’s address is learnt on all the branches in their respective control-VRs
Step 4: Change the VAN-VIP ip-address to the one of the loopback
Step 5: Change the LEF collector ip-address to the new VAN-VIP address on all the branches (in all the relevant Org’s) including the controller’s (tenant Org). This is an important step which would immediately effect the change from the old VAN-VIP to the new one.
Below is a "show configuration | display set | match lef" snipped which shows the log collector configuration in a tenant org, the same configuration would need to be present in all the tenants and the provide org (if present on the branch)
Step 6: Verify if the connection to analytics is established from the branch
The above steps would have to be performed on other controllers (which would act as collector2, collector3 etc on the brances) – needless to say we need to use a different ip-address for VAN-VIP on each controller
Once this configuration is in place, the branches will be able to reach analytics via ADC on the controllers. The bottom-line is that the above configuration ensure a unique ip-address for the VAN-VIP which is different from the TVI address which are duplicated between the Orgs.