Computers can have more than one network adapter.

In this scenario, a host PC is connected to both a corporate network (via NIC #1) which allows internet access as well as a private network (via NIC #2) with several LabVIEW Real-Time targets. The corporate network is setup to assign a DHCP address in the range of 10.0.x.x with subnet mask 255.255.0.0 to NIC #1. The default gateway (router) address is 10.0.0.1.

Figure 5. In this scenario, a multi-NIC controller is connected to both a corporate network (with internet access) and a local private network.

Following the guidelines above, we can configure NIC #2, attached to the private network, with a static IP outside of the 10.0.x.x subnet range. While it might be acceptable to use an address in the 10.1.x.x range, as it is in a different subnet, it is possible that other 10.x.x.x IP addresses are used for additional corporate servers, etc. Therefore, it is safer to use the 192.168.x.x range for the private network.

Since we are working with a small number of LabVIEW Real-Time targets in the private network, we can use a subnet mask of 255.255.255.0 and assign each a static IP address in the range 192.168.0.x; this will allow for up to 255 connected interfaces in the subnet. For simplicity, the IP address of the host computer (NIC #2) will be set to 192.168.0.1.

It is important to leave the default gateway blank on the NIC #2 settings for the host machine. In this way, only the NIC #1 default gateway will be used, which is what we want in order to access the internet from the host. In addition, the default gateway can be left blank on the LabVIEW Real-Time devices, as they should only be communicating within the local subnet (there are no gateways connected).

Table 3. This table shows one possible IP address configuration for the system shown in Figure 5 above. Notice that the two NICs connect to different subnets, and that only one Default Gateway address is specified.

Case 2: Configuring an NI Real-Time Hypervisor System with Virtual Ethernet Connection (local development)

NI Real-Time Hypervisor systems run a host OS (Windows or Linux) alongside LabVIEW Real-Time simultaneously. Each physical NIC in these systems can be assigned to either the host OS or LabVIEW Real-Time, and a virtual NIC (emulated in software) is also presented to each OS to simplify inter-OS communication.

Figure 6. In this scenario, a Real-Time Hypervisor controller is running both Windows XP and LabVIEW Real-Time in parallel. Both OSs are connected to each other through a set of virtual NICs, and each OS has a physical NIC to connect to the corporate network & internet as well.

In this scenario we will work with a Real-Time Hypervisor system that has two physical NICs, and has the internal Virtual Ethernet connection enabled. One physical interface will be assigned to Windows XP, and the other to LabVIEW Real-Time. Therefore, each OS will have access to two NICs (the Virtual Ethernet connection and one physical connection). The Windows XP side of the hypervisor system will be used for LabVIEW Real-Time application development and deployment.

Assume that the physical connections are used to enable communication to the internet from either OS via a corporate network. The virtual interface will be used only for communication between LabVIEW Real-Time and Windows XP. The IP address of both physical adapters connected to the corporate network will be dictated via DHCP, and will be in the range 10.0.0.x with subnet mask 255.255.255.0. The gateway address is set to 10.0.0.1.

Following the guidelines above, we should set a static IP for each of the Virtual Ethernet adapters using a different subnet than is used with the physical adapter on each OS. Although other addresses in the 10.x.x.x range could be used, to be conservative we will set the IP addresses of the Windows XP and LabVIEW Real-Time adapters to 192.168.0.1 and 192.168.0.2 respectively. The subnet mask of each is set to 255.255.255.0.

Because we want both Windows XP and LabVIEW Real-Time to access the internet via the physical NICs, they should be the only adapters that have a default gateway set. Therefore, we will leave the default gateway entry for both Virtual Ethernet NICs empty. Note that each OS ultimately has only one default gateway specified.

Table 4. This table shows one possible IP address configuration for the system shown in Figure 6 above. Since there are two OSs running on a single hypervisor controller in this case, the important thing to note is that each OS connects to separate subnets with each NIC, and a maximum of one default gateway.

Case 3: Configuring an NI Real-Time Hypervisor System with Virtual Ethernet (remote development)

In this scenario, two physical NICs are also used in a Real-Time Hypervisor system with the Virtual Ethernet connection enabled as in Case 2 above. However, the physical NIC assigned to LabVIEW Real-Time will be used for deployment from a networked host PC rather than for internet access.

Figure 7. In this scenario, the LabVIEW Real-Time side of an NI Real-Time Hypervisor system is connected to a remote Windows PC for LabVIEW Real-Time application development.

The Windows physical adapter will still be assigned a DHCP address in the range 10.0.0.x with subnet mask 255.255.255.0. The Virtual Ethernet adapters on Windows XP and LabVIEW Real-Time will once again use static IP addresses of 192.168.0.1 and 192.168.0.2 respectively, with subnet masks of 255.255.255.0 and no default gateway.

To ensure that the physical NIC used with LabVIEW Real-Time is on a different subnet than the Virtual Ethernet NIC, we can use an IP address of the form 192.168.1.x with subnet mask 255.255.255.0. Therefore, the remote PC adapter and LabVIEW Real-Time adapter connected together can use static IP addresses of 192.168.1.1 and 192.168.1.2 respectively with subnet masks of 255.255.255.0. Once again, no default gateway is needed since neither adapter needs to access an outside network (no gateways are present on this subnet).

Table 5. With a remote LabVIEW Real-Time development machine added to this scenario, IP address settings must be chosen such that the remote PC can connect with the LabVIEW Real-Time side of the hypervisor system. 

Many other configurations are also possible, including using DHCP with the remote development PC and LabVIEW Real-Time target (to allow connection with the internet), or using additional NICs in the LabVIEW Real-Time target or remote host computer to connect to the internet.

Case 4: Connecting to Two Routed Networks (advanced)

One more advanced scenario involves configuring a computer (running only one OS this time) with two NICs that communicate with two local networks. Each network features a gateway that can be used to relay packets to additional outside networks.

Figure 8. In this advanced scenario, a multi-NIC computer connects to two routed networks. This TCP/IP configuration is more difficult to set up, especially if the outside networks are not supersets of the local network subnets.

Imagine that local network A uses IP addresses of the form 10.0.0.x with subnet mask 255.255.255.0, and local network B uses IP addresses of the form 10.0.1.x with subnet mask 255.255.255.0. Local network A is connected via a gateway to outside network C, which uses IP addresses of the form 192.168.0.x with subnet mask 255.255.255.0. Likewise, local network B is connected to outside network D via a gateway, which uses IP addresses of the form 192.168.1.x with subnet mask 255.255.255.0.

The goal is for our multi-NIC PC to be able to access any of the networks. We can connect one NIC to local network A and assign the IP address 10.0.0.5 with subnet mask 255.255.255.0, and we can connect the second NIC to local network B and assign the IP address 10.0.1.5 with subnet mask 255.255.255.0. If any default gateway were assigned, then packets destined for the outside networks may be sent through the wrong gateway, and so this is undesirable.

To solve this problem, we can leave the default gateway entries blank for the two NICs and configure packet routing more manually in the OS. While all OSs are configured differently, most enable the manual addition of routes by the user, and these routes can be configured to persist across reboots of the system. Specifically, we need to add a route with IP address 192.168.0.x and subnet mask 255.255.255.0 to use the IP address of the gateway between networks A and C (e.g. 10.0.0.1). The same needs to be done with IP address 192.168.1.x and subnet mask 255.255.255.0 for the gateway between networks B and D (e.g. address 10.0.1.1).

Table 6. While typically only one NIC in a controller will connect with a gateway (to a corporate network or the internet), more advanced configurations such as the one pictured in Figure 8 above may require special OS routing entries to function properly. 

Additional routes may need to be added as the number of distinct subnets increases. In practice, most networks are set up to avoid the need for this complex configuration by ensuring that each computer is connected to only one gateway.