... | ... | @@ -33,4 +33,64 @@ which is instantiated (in red) in the following figure: |
|
|
|
|
|
![control-net](/uploads/b1817366237c25fe40d5e56f61c9cd4a/control-net.png)
|
|
|
|
|
|
From your vantage point out in the Internet, you can access a node in your
|
|
|
experiment via its canonical Emulab name (e.g., "pc12.emulab.net") or by
|
|
|
the DNS alias that is assigned when your experiment is created (e.g.,
|
|
|
"node2.foo.testbed.emulab.net"). Both types of names use the fixed control
|
|
|
network link (IP: 155.101.132.12) to access the node. These control net
|
|
|
links are shown in blue in the figure.
|
|
|
|
|
|
The view from inside an experiment node is different. In an ideal world,
|
|
|
applications running inside the experiment would not even know about the
|
|
|
control network, since it is not part of the topology. However, the control
|
|
|
net must be visible to nodes for several practical reasons, most notably
|
|
|
allowing login from remote sites and the ability of the node to access the
|
|
|
Emulab infrastructure servers. As the control net is visible to
|
|
|
applications on a node, it can lead to its inadvertent use by
|
|
|
applications. In the above example, consider a ping from node1 to
|
|
|
node2. The expectation is that traffic will pass through the included
|
|
|
router and over the shaped link to node2, resulting in round-trip times of
|
|
|
20ms:
|
|
|
|
|
|
```
|
|
|
node1.foo.testbed.emulab.net> ping node2
|
|
|
PING node2-linkB (10.1.1.2) from 10.1.2.2 : 56(84) bytes of data.
|
|
|
64 bytes from node2-linkB (10.1.1.2): icmp_seq=1 ttl=63 time=20.3 ms
|
|
|
64 bytes from node2-linkB (10.1.1.2): icmp_seq=2 ttl=63 time=20.3 ms
|
|
|
```
|
|
|
|
|
|
But if the ping travels over the control network rather than the
|
|
|
experimental network, there will be no delay:
|
|
|
|
|
|
```
|
|
|
node1.foo.testbed.emulab.net> ping node2.foo.testbed.emulab.net
|
|
|
PING pc12.emulab.net (155.101.132.12) from 155.101.132.10 : 56(84) bytes of data.
|
|
|
64 bytes from pc12.emulab.net (155.101.132.12): icmp_seq=1 ttl=64 time=0.291 ms
|
|
|
64 bytes from pc12.emulab.net (155.101.132.12): icmp_seq=2 ttl=64 time=0.124 ms
|
|
|
```
|
|
|
|
|
|
Notice the subtle difference between the pings, the correct one uses an
|
|
|
unqualified name, the incorrect one uses the fully qualified name.
|
|
|
Unqualified names are resolved from a local /etc/hosts file that is created
|
|
|
on each node. Fully qualified names are resolved by the Emulab nameserver
|
|
|
and return the routable, control network address. The figure above shows
|
|
|
the various names each node can be named by, and which interface they will
|
|
|
resolve to. Accidental use of the control net interface in an experiment
|
|
|
commonly occurs due to one of three reasons:
|
|
|
|
|
|
* The experiment user configures an application incorrectly. By
|
|
|
specifying either a node's fully qualified name or its control net
|
|
|
address when configuring an application, that application will use the
|
|
|
wrong interface.
|
|
|
* An application itself decides which interface to use based on a node's
|
|
|
hostname. Since the hostname is set to the fully qualified name, that
|
|
|
name will resolve to the control net address.
|
|
|
* An application uses all available interfaces. By default, many server
|
|
|
applications will listen on all interfaces they discover via ioctls or
|
|
|
other kernel mechanisms. This will include the control interface.
|
|
|
|
|
|
In the first case, you just need to be careful to use the correct name or
|
|
|
address. For the latter two cases, you might need to modify the
|
|
|
application. Fortunately, most applications include options enabling you to
|
|
|
explicitly specify which interfaces to use (or not use).
|
|
|
|