Unextend network

Jump to solution

Dear Team,

 

We are migrating a workload from VCF3.x to VCF4.x using HCX, Generally, when we  unextend the network it takes 1-3 minutes) to switch the gateway from the old to the new environment but sometimes it takes a long time to switch the gateway from the old to a new environment (4-6mins), what could be the reason for the same? Is it something related to HCX, NSX-T, or upstream, could someone please assist how to TShoot the same.

 

Thank you in advance

0 Kudos
1 Solution

Accepted Solutions
grosas
Community Manager
Community Manager

To see the details of what is happening in the management plane during the operation, you  can tail -f /common/log/admin/app.log on the HCX Connector and HCX Cloud Managers. 

1. Across both sites you will see the NE bridge become disabled 

2a. The destination T1's gateway become connected. 

2b. In parallel at the source, the original gateway/SVI etc should be manually disabled.  
      (this is a coordination with your network team, if you don't control the first hop gateways)

3a. The routing configuration in the new VCF should be able to advertise the newly connected subnet very quickly. 

3b. The original route also needs to age out of be removed. 

Mileage varies depending on the coordination of the activities and the overall routing configuration.  Recommendation is to run through the process end to end with a test network so you can understand route propagation/age out timings in your environment.

 

_____________________________________
Gabe Rosas (VMware HCX team at VMware)
Blog: hcx.design
LinkedIn: /in/gaberosas
Twitter: gabe_rosas

View solution in original post

5 Replies
JS408
VMware Employee
VMware Employee

Are you referring to the time it takes the unextend task to complete? Or the time it takes the datapath to change

0 Kudos
 
yes , it's related to both.
0 Kudos
grosas
Community Manager
Community Manager

To see the details of what is happening in the management plane during the operation, you  can tail -f /common/log/admin/app.log on the HCX Connector and HCX Cloud Managers. 

1. Across both sites you will see the NE bridge become disabled 

2a. The destination T1's gateway become connected. 

2b. In parallel at the source, the original gateway/SVI etc should be manually disabled.  
      (this is a coordination with your network team, if you don't control the first hop gateways)

3a. The routing configuration in the new VCF should be able to advertise the newly connected subnet very quickly. 

3b. The original route also needs to age out of be removed. 

Mileage varies depending on the coordination of the activities and the overall routing configuration.  Recommendation is to run through the process end to end with a test network so you can understand route propagation/age out timings in your environment.

 

_____________________________________
Gabe Rosas (VMware HCX team at VMware)
Blog: hcx.design
LinkedIn: /in/gaberosas
Twitter: gabe_rosas

Thank you Gabe, appreciate your help and support.

0 Kudos
belky
Contributor
Contributor

Good info, thanks for sharing!

Tags (1)
0 Kudos