Network Extension High Level Topology Diagrams

These topology diagrams have been updated in similar fashion to the Network Extension Availability diagrams I shared in an earlier post. This one is a 7-page PDF deck that emphasizes shared vs dedicated and multi-site HCX Network Extension topology variations. Each diagram is fairly self-explanatory (there’s a box with highlights in every diagram).

Some additional (Bonus 🥸) info below.


Note1: There are MON elements in this deck, planning that for my next post. Everything described is in the context of the traditional Network Extension functionality.
Note2: The depicted L / daisy chain topology (extension of an extension) assumes the original network and gateway is VLAN based or overlay with traditional edge gateways. Extending source networks with a distributed routing function (on NSXv or NSX-T) requires a traffic filter for delivering packets to the gateway. The L topology is not supported in this case.

  • Page 1 is depicts a basic set of network extension appliance (NE) peers extending one network as the baseline. Here are key takeaways:
    • HCX can extend source Distributed Switch and NSX networks.
    • In the destination HCX works with NSX to create (or connect to) an NSX Overlay Segment.
    • During the operation, the user specifies the subnet info and tier-1 router at the destination.
    • At the end of the operation the basic extension’s segment will be in a disabled state. Think of it as a stub configuration. When the network is ultimately unextended with HCX, you have the option to keep the segment disabled (isolated), or to enable the gateway (routed).

      HCX uses these to perform several checks and produces certain outcomes:
      • If the network does not exist on the tier 1, HCX will create it. The basic requirement is for the destination NSX Tier-1 to be present, and for a deployed NE appliance on its overlay TZ.
      • If there’s an inexact overlap with a network on the tier-1, the operation fails (it’s possible the subnet was entered wrong, or the subnet was not expected to exist on the tier 1.
      • If the network exists, and the subnet matches exactly, HCX will connect the extension to the existing segment, and disable the network.
        Some users will take advantage of this behavior to pre-create networks with custom naming conventions.
  • Page 2 depicts sharing single NE pair for multiple networks
    • This is the most condensed deployment model for up to eight networks.
    • It is probably true in any migration project, but especially in this mode, special attention should be taken to move “top-talker pairs” (chatty workload buddies in the same subnet) to reduce the shared load.
  • Page 3 describes dedicating an NE appliance per network.
    • The image describes pros/cons: best scale/smallest vm network failure domain but highest deployment resource cost.

      There’s no CON in complexity in the sense that increasing scale is just changing a service mesh number. The additional appliance auto-deploy and configure themselves.
  • Pages 4-7 depict multi-site extension topologies
    • In addition to what is already mentioned within these diagrams. I would also say the emphasis for these should be to show what is possible, not necessarily what will make sense to do in every deployment. The flexibility in these multi-site extensions can be instrumental for achieving portability, but they carry additional design decisions.
    • Lets use a “V” topology as an example (this is depicted in page 4):
      • In a project where the source data center is being evacuated, at some point it may no longer make sense to keep the primary routing at the source. When that time arrives one of the two clouds may be selected as the new primary and the network extension legs may need to be reconfigured.
      • If the networks are unextended and migrated to both clouds, you will have duplicate dicontiguous routed networks. This is like having two different cities with identical zip codes & street names. This doesn’t work, but is a possible outcome if HCX is used without design.

That’s all for this. Hopefully these are useful to you.

Friends (and strangers), I hope ye be blessed in everything you do!


Gabe 🖖🏼🤨

One comment

  1. Hi Gabe. Do you know if is possible to configure a Bridge in a extended segment? The case is for the physical Workloads on the destination site to use the extended network.

    Like

Leave a comment