As shown in the diagram above, your virtual data center network topology includes two types of routers or gateways – edge and provider gateways inside a virtual data center. These gateways are logical network constructs provided by VMware NSX. The key architectural distinction between these is that edge gateway provides routing and network services inside your VDC while the provider gateway connects your VDC to external networks – such as IBM Cloud Private network and the public Internet.

Inside a virtual data center, you can deploy two types of virtual networks  – routed or isolated virtual data center networks. By its definition, a routed virtual data center network is routed through its connection to the edge gateway. This routing option provides a L3 routed access to other virtual datacenters or to other connected networks. The underlying SDN provides various capabilities for enhancing routing latency and performance, and some of these have been made available for you via the portal. For example, the distributed routing option provides fast and efficient east-west routing. But sometimes these come with some limitations, too. For example, if you want to use firewalling between virtual data center networks attached to the same edge gateway, the distributed routing option must be disabled. North-south traffic can still be firewalled with the edge gateway firewall even with the option disabled. So this leads to some decisions that you must do, mostly related to network security. Isolated virtual data center networks are logically isolated L2 domains, segments that allow you to connect two or virtual machines within the virtual data center, but they are not attached to the edge gateway, and therefore they do not have any routing, firewall or NAT services. Some customers use the isolated VDC networks when deploying their own firewall appliances within the VDC, we can discuss about this in a future blog, if there is interest.

Connectivity to and from the VDC is key, and there we have two basic options. Virtual data centers can be deployed with or without public connectivity. The latter is an option, if you want to keep all traffic 100% private, where the public option allows your workloads to be connected to the public Internet through the provider gateway. VDCs provide connectivity to IBM Cloud services and private endpoints by default. If you want to expand to other IBM Cloud IaaS platforms (Classic, VPCs or Power Virtual Servers), IBM Cloud Transit Gateways provides this interconnectivity. With on-premises connectivity needs over private WANs, IBM Cloud Direct Link is the offering for these needs, attached to the Transit Gateways. See an example topology in the following diagram.

Network address translation (NAT) is an embedded function on the provider and edge gateways and you can do NATing on either of these. When considering NATing, always design your NAT rules considering the desired traffic path and think how you see the packets at the next router. For example, if you do source NAT (SNAT) at the edge gateway to get egress Internet access from your virtual data center network. If you created a matching “destination any rule”, then the IP packets sent from the virtual machine towards the provider gateway have already been NATted. If you wanted to have a Transit Gateway connection for private connectivity, then the source IP of the packets might not be what you wanted. Alternatively, you might consider doing SNAT for public traffic at the provider gateway, where the rules would only match the traffic going to the Internet and the private traffic going to the Transit Gateway would have the original source IP address of the virtual machine. You can also do NO_NAT rules where you define the traffic not to be NATted by source and destination IPs, and then you might also need to set some priorities for the rules. Both options work, but you must select a solution that fits your needs. The new options to allow NAT rules for public traffic at the provider gateway might simplify your NAT rule design significantly.

A gateway firewall (FW) is an embedded firewall running on both provider and edge gateways. Provider gateway firewall allows all traffic by default while edge gateway firewall denies all traffic by default. You can customize these rules post initial provisioning. When considering firewalling, always design and check your firewall rules on the Gateway firewalls in the traffic path to see that you match the correct source and destination IP. Note that with the NAT rules you can select which IP you match in the firewall rules, the public (or external) or private (internal). It is recommended to select one way to match the FW rules and then follow that path for all. When it comes to firewall rules in general, so think where do you implement firewalling. Also consider simplicity and rules management aspects. You have options to create security groups and IP sets, which are key for managing the firewall rules in a logical way.  

What about the scope of the networks? Can other virtual data centers in the organization see your networks? Each virtual data center provides its own network topology and own networks. By default, the scope of the network is the virtual data center, but there is an option to expand the scope to other virtual datacenters in the VCFaaS site with Data Center Groups (DCGs). There is also an option to deploy virtual data centers without an edge, and you may wonder why? I think sharing networks between virtual data centers needs a dedicated blog, focusing just on Data Center Groups and how you can use these in your network designs.

What's next?

Now that we have introduced the basic concepts, it is time to think about external connectivity in more details. How do you access your virtual machines from the Internet, or how do your virtual machines access the Internet, IBM Cloud private networks and services? How about connections to on-premises, using VPNs, IBM Cloud Interconnectivity services and so on. What are the best practices for each and how do you configure these? As there are a lot of topics to discuss, I decided spit this into multiple blogs, and the next one will focus on public networking, and then following with topic to cover VPNs and using IBM Cloud interconnectivity options. Stay tuned…