1. Enter the command:

ifconfig

2. In the output of the "ifconfig" command, look at the “inet” setting for each NIC (if there is one) and see if any have a value other than 128.171.*.* (e.g., 128.171.38.164) or 166.122.3.* (e.g., 166.122.3.3) or 127.0.0.1 (the standard internal loopback interface). Any value other than those subnets indicate the NIC does have a private network IP associated with it. If no "inet addr" setting is listed for a NIC, it means that the NIC is connected but has not been configured with an IPv4 IP address yet, and ITS CS will need to verify if the NIC is connected to a private network or not (step 4 below).
    
3. If a NIC on your virtual server does have a private network IP associated with it, please skip to step 17 below (verify DNS resolves .pvt and .mgt). Otherwise, continue with the next step below.

4. Contact ITS Managed Services (itscs@hawaii.edu) and ask that your virtual server be assigned to and connected to an ITS private network. As part of your request, please provide the following info:

* The reason you want to add an ITS private network connection to your virtual server

* Your virtual server’s fully qualified domain name (FQDN) (e.g., leeddash.its.hawaii.edu)

* Your virtual server’s public network IP address (128.171.x.x or 166.122.3.x)

5. ITS Managed Services will verify that your virtual server does not have a connection to an ITS private network, and if so they will assign your virtual server an IP within an ITS private network, attach a new NIC on your virtual server that connects to that network, and provide you with the private network IP, gateway, and subnet mask information.
    
6. Once you have the private network IP, gateway, and subnet mask information from ITS CS, do an “ifconfig” command and make note of the newly added NIC’s name (e.g., “ens224”), as well as the NIC name of the existing primary NIC for the public network (e.g., “eno16780032”).
    
7. Back up the existing /etc/sysconfig/network file (e.g., “cp /etc/sysconfig/network /etc/sysconfig/network.2017-07-06”) and then edit the /etc/sysconfig/network file and ensure it contains only the following lines (substitute the bracketed items with appropriate values):

8. Create a /etc/sysconfig/network-scripts/ifcfg-<NIC-name> file (where <NIC-name> is the name of the new NIC as determined in step 6; e.g., /etc/sysconfig/network-scripts/ifcfg-ens224). You can do so with “vi” or "nano" any basic text editor of your choice (or perhaps just copying the primary non-private NIC’s config file and just editing it—e.g., “cp /etc/sysconfig/network-scripts/ifcfg-eno16780032 /etc/sysconfig/network-scripts/ifcfg-ens224”).
    
9. Edit the new ifcfg-<NIC-name> file created in the previous step so that it contains the following minimal entries:

10. Create and edit a new /etc/sysconfig/network-scripts/route-<NIC-name> file (where <NIC-name> is the name of the new NIC; e.g., /etc/sysconfig/network-scripts/route-ens224) that contains the following lines:

11. Schedule a reboot the virtual server to incorporate all the changes you’ve made so far (just restarting the network service doesn't seem to be enough). E.g., when ready, as user root, enter the following command to reboot:

12. Log back into the server and switch user to the "root" user (if you cannot access the server after rebooting, you may need to log in via the virtual console to troubleshoot if you have access [see Virtual Server: How to Access Your Virtual Server via VMware Console Access] or contact ITS CS at itscs@hawaii.edu to help you); one there, print out the current network routing table using the command:

13. Examine the results of the “ip route show” command and ensure that among the entries shown are ones similar to those given in step 10 above and also a “default” entry that specifies the primary (public) NIC’s gateway and NIC name. E.g.:

14. Verify that you can ping google.com okay:

15. Back up the existing /etc/resolv.conf file (e.g., “cp /etc/resolv.conf /etc/resolv.conf.2017-07-06”) and then edit the /etc/resolv.conf file and ensure it consists of only the following three lines:

16. Once again, verify that you can ping google.com okay (this verifies that you can reach the private DNS servers specified in the previous step; if the ping doesn't work, then back out by restoring the original contents of your /etc/resolv.conf file so that you have DNS resolution again, and then troubleshoot):

17. Verify that you can resolve a .pvt hostname via DNS okay. E.g., using the “nslookup” command:

18. Schedule a reboot of your virtual server and, after it comes back up, do the previous two tests again (see if you can ping google.com okay, and see if you can resolve a .pvt hostname via DNS okay). This step verifies that your network configuration changes and private network connectivity will survive intact upon system reboot.