October 28, 2021 By Saju Mathew
Rei Odaira
Weiming Gu
3 min read

In the second part of this three-part blog series, we will demonstrate adding custom routing rules to accomplish the separation and then test the reachability.

This is one of the simplest methods to achieve reachability in an existing virtual machine without having to understand the concepts of routing tables or namespaces. This is part of the series of blogs to explain how to use multiple network interfaces in IBM Cloud VPC.

Custom Routes

This figure shows our multi-zone controller/worker scenario, as explained in Part 1:

From Worker1 we can see that ping to Control Subnet1 and Subnet2 are working by default using the default route. Therefore, we need to add routing rules for the data subnet to ping Worker2 on Interface D from Worker1 using Interface B.

Generally, a simple approach can be to simply add the rules via an ip route add command. Specifically, in this case, one would use the command on Worker1:

ip route add 172.16.102.0/24 via 172.16.101.1 dev ens4 metric 0  

Similarly, here is the command to execute on Worker2:

ip route add 172.16.101.0/24 via 172.16.102.1 dev ens4 metric 0

Once the rules have been established, one can check routes via ip route command. Ping the respective IP addresses from Worker1 to Worker2 to validate that reachability is achieved:

ping -c 3 -I 172.16.1.5 172.16.2.5
ping -c 3 -I 172.16.101.5 172.16.102.5

Additionally, to be sure that communication is NOT occurring from the control interfaces to data network and vice versa, we can validate that the following pings will NOT be successful:

ping -c 3 -I 172.16.1.5 172.16.102.5
ping -c 3 -I 172.16.101.5 172.16.2.5

In this case, the correct isolation has been achieved by the combination of the routing rules and anti-spoofing. More generally, one should enforce the isolation by security group rules. Readers are referred to our online manual.

One additional item to note is the default routing within the virtual machine. Since we have properly added routes based on the destination, even the default ping command without specifying a source interface will work properly. Therefore, the following commands will be successful:

ping -c 3 172.16.2.5
ping -c 3 172.16.102.5

Persistent Custom Routes

Now that we have successfully tested the Custom Routes we added, we can make it persistent by adding the following on Ubuntu distributions to the netplan. First, move the existing /etc/netplan/50-cloud-init.yaml to /etc/netplan/99-netcfg.yaml and then add a route to the destination network via the local interface’s gateway.

New /etc/netplan/99-netcfg.yaml:

network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: 02:00:02:06:b3:a3
            set-name: ens3
        ens4:
            dhcp4: true
            routes:
                - to: 172.16.102.0/24
                  via: 172.16.101.1
                  metric: 0

Once this is done, /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg can be created, according to the following text:

network: {config: disabled}

Now, issue the netplan apply command and proceed to test the reachability by ping. 

On Red Hat Enterprise Linux, kindly refer to the Red Hat documentation on configuring the custom/static routes.

Summary

In this post, we explained how to configure Custom Routes to accomplish reachability in our use case of multiple network interfaces. Custom Routes are the simplest method to enable communication and separation among virtual server instances with multiple network interfaces. In the next (and final) post, we will present two more approaches that are more advanced and flexible, namely Source Interface Based Routing Tables and Network Namespaces.

Was this article helpful?
YesNo

More from Cloud

A clear path to value: Overcome challenges on your FinOps journey 

3 min read - In recent years, cloud adoption services have accelerated, with companies increasingly moving from traditional on-premises hosting to public cloud solutions. However, the rise of hybrid and multi-cloud patterns has led to challenges in optimizing value and controlling cloud expenditure, resulting in a shift from capital to operational expenses.   According to a Gartner report, cloud operational expenses are expected to surpass traditional IT spending, reflecting the ongoing transformation in expenditure patterns by 2025. FinOps is an evolving cloud financial management discipline…

IBM Power8 end of service: What are my options?

3 min read - IBM Power8® generation of IBM Power Systems was introduced ten years ago and it is now time to retire that generation. The end-of-service (EoS) support for the entire IBM Power8 server line is scheduled for this year, commencing in March 2024 and concluding in October 2024. EoS dates vary by model: 31 March 2024: maintenance expires for Power Systems S812LC, S822, S822L, 822LC, 824 and 824L. 31 May 2024: maintenance expires for Power Systems S812L, S814 and 822LC. 31 October…

24 IBM offerings winning TrustRadius 2024 Top Rated Awards

2 min read - TrustRadius is a buyer intelligence platform for business technology. Comprehensive product information, in-depth customer insights and peer conversations enable buyers to make confident decisions. “Earning a Top Rated Award means the vendor has excellent customer satisfaction and proven credibility. It’s based entirely on reviews and customer sentiment,” said Becky Susko, TrustRadius, Marketing Program Manager of Awards. Top Rated Awards have to be earned: Gain 10+ new reviews in the past 12 months Earn a trScore of 7.5 or higher from…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters