VMware HCX

 View Only
  • 1.  HCX L2 MON and unextend - What owns the Gateway and when

    Posted Jun 23, 2023 03:30 PM

    When extending L2 networks MON can be enabled/ticked but its actually activated at a VM level from what I understand so it requires a further action per VM (Router Location), is this correct?

    Until this is done the VM will keep using HCX on-prem as Gateway for all internal/external traffic

    Once the gateway (Router Location) is changed in HCX for the VM and pointed to HCX Cloud, traffic will start flowing via HCX Cloud Appliance and then respect the MON Routing Policy so traffic either goes to HCX on-prem or to Tier 1

    Once the network is unextended, the respective Gateway IP is assumed by the NSX Tier 1 Gateway so from that moment on for destinations not within the SDDC traffic will flow via Tier1 --> Tier0 --> VTGW --> On-Prem or Cloud according to destination (and vice versa for return flow)

    Can you help correct the above where necessary and clarify the changes that happen at each phase or point me to documentation that clearly explains these steps? I would like to understand how the gateway changes between activating MON at L2 network when extending, to changing the Default Router in HCX for the VM to when you actually unextend the VLAN.

    When does traffic to other on-prem networks (not extended) and other Cloud Networks stops flowing via L2 NE towards on-prem Gateway and starts going via Tier-1 Gateway/VTGW via DX DX/BGP etc..?

    This would be a very important cutoff as all of a sudden the Routing and Security Rules move from on-prem to AWS so it's a game changer and there is lots of pre-work to do to ensure existing IN/OUT traffic keeps working for the unstretched network/VM's.

    Is there a cutover checklist available?

    andvm_0-1687609373580.png

     

    Thanks



  • 2.  RE: HCX L2 MON and unextend - What owns the Gateway and when

    Broadcom Employee
    Posted Sep 25, 2023 08:39 AM

    When you unextend a Network Extension, when you expand the network entry you have an option to select 'Connect cloud network to cloud edge gateway' after unextending to connect the remote side gateway.

    By default, the cloud segment is left disconnected from the Edge Gateway after removing the network extension. This is done to prevent an Edge Gateway from advertising a route to the cloud segment and causing a potential routing conflict with the network in the on-premises data center. Selecting this option connects the segment to the Cloud Edge Gateway after removing the network extension. If dynamic routing is activated, the network is advertised from the Cloud Edge Gateway.

    Unextending a network removes the HCX L2 bridged path without removing the NSX Segment or vSphere Port Group, or NSX interface. The NSX router interface remains disconnected when the option Connect cloud network is not used.



  • 3.  RE: HCX L2 MON and unextend - What owns the Gateway and when

    Posted Sep 27, 2023 11:32 AM

    MON is a global setting that can be enabled at the HCX service level. It doesn't require further action at a per-VM level (Router Location) during the migration process. When you enable MON in HCX, it applies to all VMs that are part of the migration and attached to the NSX segment created after extending the network.

    When you change the gateway of an extended network from the on-premises site to the cloud (referred to as "Failover" in disaster recovery scenarios), the routing of traffic will indeed shift to the cloud side, specifically through the Tier-1 (T1) and Tier-0 (T0) routers on the cloud site. This change in routing is a fundamental aspect of disaster recovery and failover processes.

    During this failover scenario, Mobility Optimized Networking (MON) may not play a significant role in determining the routing path because the primary goal during disaster recovery is to quickly switch over to the cloud environment and make it the active site for running workloads. MON is primarily designed to optimize the routing path during ongoing migrations, not necessarily for failover scenarios where the cloud site becomes the active site.