A Simple Mininet Example|MININET
A Simple Mininet Example
Starting Mininet via the mn command (as root!), with no command-line arguments, creates a simple network of two hosts and one switch, h1–s1–h2, and starts up the Mininet command-line interface (CLI). By convention, Mininet host names begin with ‘h’ and switch names begin with ‘s’; numbering begins with 1.
At this point one can issue various Mininet-CLI commands. The command nodes, for example, yields the following output:
available nodes are:
The node c0 is the controller for the switch s1. The default controller action her makes s1 behave like an Ethernet learning switch (2.4.1 Ethernet Learning Algorithm). The command intfs lists the interfaces for each of the nodes, and links lists the connections, but the most useful command is net, which shows the nodes, the interfaces and the connections:
s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0
From the above, we can see that the network looks like this:
Running Commands on Nodes
The next step is to run commands on individual nodes. To do this, we use the Mininet CLI and prefix the command name with the node name:
h1 ping h2
The first command here shows that h1 (or, more properly, h1-eth0) has IP address 10.0.0.1. Note that the name ‘h2’ in the second is recognized. The ifconfig command also shows the MAC address of h1-eth0, which may vary but might be something like 62:91:68:bf:97:a0. We will see in the following section how to get more human-readable MAC addresses.
There is a special Mininet command pingall that generates pings between each pair of hosts.
We can open a full shell window on node h1 using the Mininet command below; this works for both host nodes and switch nodes.
Note that the xterm runs with root privileges. From within the xterm, the command ping h2 now fails, as hostname h2 is not recognized. We can switch to ping 10.0.0.2, or else add entries to /etc/hosts for
As the Mininet system shares its filesystem with h1 and h2, this means that any /etc/host entries will be defined everywhere within Mininet (though be forewarned that when a different Mininet configuration assigns different addresses to h1 or h2, chaos will ensue).
From within the xterm on h1 we might try logging into h2 via ssh: ssh h2 (if h2 is defined in /etc/hosts as above). But the connection is refused: the ssh server is not running on node h2. We will return to this in the following example.
We can also start up WireShark, and have it listen on interface h1-eth0, and see the progress of our pings. To start WireShark on a host node, say h1, we can either enter h1 wireshark & at the mininet> prompt, or else launch WireShark from within an xterm window running on h1. With either approach, all the interfaces of h1 will be visible.
These methods also work for starting WireShark on a switch node. However, there is a simpler way, that takes advantage of the fact that, unlike for host interfaces, all switch interfaces are by default visible to the top-level Linux system; in the simple example above these are s1-eth1 and s1-eth2. So we can simply start WireShark in
These methods also work for starting WireShark on a switch node. However, for switches we can also simply start WireShark at the top (host) level, in any top-level terminal window, as switches by default share all their network systems with the Mininet host system. (In terms of the container model, switches do not by default get their own network namespace; they share the “root” namespace with the host.) We can see this by running the following from the Mininet command line
and comparing the output with that of ifconfig run on the Mininet host, while Mininet is running but using a terminal not associated with the Mininet process itself. In the example above we see these interfaces:
We see the same interfaces on the controller node c0, even though the net and intfs commands above showed no interfaces for c0.
Mininet WireShark Demos
We can take advantage of this simple h1–s1–h2 configuration to observe traffic with WireShark on a nearly idle network; by default, the Mininet nodes are not connected to the outside world. After starting Mininet in one terminal window, we start WireShark in another and set it to listening to, say, s1-eth1.
To watch a TCP connection we then could start up xterm windows on h1 and h2. We run netcat -l 5432 on h2 and then netcat 10.0.0.2 5432 on h1. At this point we can see the ARP exchange
An Introduction to Computer Networks, Release 2.0.4
followed by the TCP three-way handshake.
If we type a line of text to netcat on h1, we can watch the data packet and the returning ACK in WireShark. We can drill into the data packet to see the message contents. Typing cntl-D (or cntl-C) to netcat on h1 will result in the closing exchange of FIN packets. Often there is no other traffic at all, though if we wait long enough we will see more ARP packets.
Wireshark filtering is not needed (though in a busier environment we could filter all the non-TCP, non-port-5432 traffic with the WireShark filter option tcp.port == 5432).
Frequently Asked Questions
- Uses of Computer Networks
- Network Hardware
- Installing and Running ns-3|THE NS-3 NETWORK SIMULATOR
- A Single TCP Sender| The ns-3 Network Simulator
- Wireless|The ns-3 Network Simulator
- The ns-2 simulator|NETWORK SIMULATIONS: NS-2
- A Single TCP Sender| The ns-3 Network Simulator
- Two TCP Senders Competing|THE NS-3 NETWORK SIMULATOR
- Wireless Simulation|NETWORK SIMULATIONS: NS-2