Skip to content

Using IMUNES

Denis Salopek edited this page Aug 10, 2019 · 13 revisions

Jump to:

Ping

Open the topology imunes-examples/Ping/ping.imn and you should see this:

Execute the experiment, right click on the pc1 node and use Wireshark to capture traffic on the eth0 interface.

Double click on the pc1 node to open the console shell and execute:

root@pc1:/ # ping 10.0.8.10

to ping the server node.

After a few pings, terminate it by pressing Ctrl+C on your keyboard. The output of the ping command should be something like this:

root@pc1:/ # ping 10.0.8.10
PING 10.0.8.10 (10.0.8.10): 56 data bytes
64 bytes from 10.0.8.10: icmp_seq=0 ttl=59 time=23.202 ms
64 bytes from 10.0.8.10: icmp_seq=1 ttl=59 time=16.003 ms
64 bytes from 10.0.8.10: icmp_seq=2 ttl=59 time=15.834 ms
^C
--- 10.0.8.10 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.834/18.346/23.202/3.434 ms

After doing this, the Wireshark window should display some captured packets:

Packets 1 and 2 are ARP used by pc1 to find out the MAC address of its gateway router. After pc1 receives the address, it starts sending ICMP packets. While it's sending them, Wireshark should be able to 'see' the packets being sent (ping request) and received (ping reply) and that means the server node is available.

Traceroute

Open the topology imunes-examples/Traceroute/traceroute.imn and you should see this:

Execute the experiment, right click on the pc1 node and use Wireshark to capture traffic on the eth0 interface.

Double click on the pc1 node to open the console shell and execute:

root@pc1:/ # traceroute 10.0.8.10

to check the route to server node.

The output should be:

root@pc1:/ # traceroute 10.0.8.10
traceroute to 10.0.8.10 (10.0.8.10), 64 hops max, 52 byte packets
 1  10.0.0.1 (10.0.0.1)  3.618 ms  3.929 ms  3.978 ms
 2  10.0.1.1 (10.0.1.1)  5.965 ms  5.536 ms  5.976 ms
 3  10.0.2.2 (10.0.2.2)  7.969 ms  7.530 ms  7.979 ms
 4  10.0.3.1 (10.0.3.1)  9.969 ms  9.524 ms  9.980 ms
 5  10.0.7.2 (10.0.7.2)  11.969 ms  11.524 ms  11.984 ms
 6  10.0.8.10 (10.0.8.10)  15.968 ms  15.502 ms  15.972 ms

Wireshark should show a lot of captured packages:

First, pc1 sends 3 UDP packets with TTL (time-to-live) of 1 so when the next node in the network recieves it, it lowers its TTL for 1 (to 0) and sends an ICMP error message Time-to-live exceeded back to node pc1.

Because the ICMP header contains the nodes source IP address, node pc1 now knows the IP address of the first destination node. The next 3 UDP packets have TTL 2, so they will reach one node more than the previous batch. It keeps incrementing TTL and sending packets until the packets reach their final destination.

If you'd run traceroute from the server node, the output would be:

root@server:/ # traceroute 10.0.0.21
traceroute to 10.0.0.21 (10.0.0.21), 64 hops max, 52 byte packets
 1  10.0.8.1 (10.0.8.1)  7.366 ms  3.788 ms  3.977 ms
 2  10.0.7.1 (10.0.7.1)  7.959 ms  5.501 ms  5.965 ms
 3  10.0.3.2 (10.0.3.2)  9.968 ms  7.462 ms  7.979 ms
 4  10.0.2.1 (10.0.2.1)  11.970 ms  9.509 ms  9.971 ms
 5  10.0.1.2 (10.0.1.2)  13.974 ms  11.475 ms  11.978 ms
 6  10.0.0.21 (10.0.0.21)  19.975 ms  15.478 ms  15.973 ms

Notice the different step values are actually the same routers but different interfaces, and the routes from pc1 and server nodes are the same. Sometimes, this isn't the case (when routers configure their routes differently in different directions).

RIP

Open the topology imunes-examples/RIP/RIP.imn and you should see this:

Execute the experiment, right click on the router3 node and use Wireshark to capture traffic on the eth3 interface. You will see Request RIPv2 packets and their Response packets.

Response packet has the list of all the IP addresses and their metrics (number of routers in between) that router1 can "see", so now the router3 knows how to reach every one of them. Every router receives their neighbours' Responses and depending on the lowest metric to reach some other non-neighbour route, specific router is selected as its next hop.

Double click on the pc7 node to open the console shell and execute:

root@pc7:/ # ping 10.0.7.2

to ping the host5 node and check whether the routers work.

Next example shows what happens when one of the routers stops working.

Terminate the current experiment, open the topology imunes-examples/RIP/RIP1.imn and you should see this:

Execute the experiment, right click on the router2 node and use Wireshark to capture traffic on the eth2 interface.

To show the router2 routing table, right click on the router2 node, open the Quagga console shell (vtysh), press 'q' to enable command input and execute:

router2# show ip rip

The output should be:

router2# show ip rip
Codes: R - RIP, C - connected, S - Static, O - OSPF, B - BGP
Sub-codes:
      (n) - normal, (s) - static, (d) - default, (r) - redistribute,
      (i) - interface

     Network            Next Hop         Metric From            Tag Time
R(n) 0.0.0.0/0          10.0.7.2              2 10.0.7.2          0 02:51
C(i) 10.0.0.0/24        0.0.0.0               1 self              0
C(i) 10.0.1.0/24        0.0.0.0               1 self              0
R(n) 10.0.2.0/24        10.0.1.2              2 10.0.1.2          0 02:51
R(n) 10.0.3.0/24        10.0.0.1              2 10.0.0.1          0 02:51
R(n) 10.0.4.0/24        10.0.7.2              2 10.0.7.2          0 02:51
R(n) 10.0.5.0/24        10.0.1.2              3 10.0.1.2          0 02:51
R(n) 10.0.6.0/24        10.0.7.2              3 10.0.7.2          0 02:51
C(i) 10.0.7.0/24        0.0.0.0               1 self              0

If you ping the server node from the pc node, you will get the ping reply. According to the routing table, router2 should send every packet with the destination address for the 10.0.4.0/24 subnet on the Next hop router 10.0.7.2 (router7). You can turn the router7 off by right clicking on the router7 node and selecting Stop. Now the pc node will not be able to ping the server node until routes are changed or router7 starts again.

You can also check every route status in the vtysh shell with the show ip rip status command.

OSPF

Open the topology imunes-examples/OSPF/OSPF.imn and you should see this:

Execute the experiment, right click on the router2 node and use Wireshark to capture traffic on the eth2 interface.

You will see pairs of OSPF Hello Packet packets for exchanging routes: from router2 to router3 and from router3 to router2.

Double click on the pc7 node to open the console shell and execute:

root@pc7:/ # ping 10.0.7.2

to ping the host5 node and check whether the routers work.

Next example shows what happens when one of the routers stop working.

Terminate the current experiment, open the topology imunes-examples/OSPF/OSPF1.imn and you should see this:

Execute the experiment, right click on the router2 node and use Wireshark to capture traffic on the eth2 interface.

To show the router2 route table, right click on the router2 node, open the Quagga console shell (vtysh), press 'q' to enable command input and execute:

router2# show ip route

The output should be:

router2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

O   10.0.0.0/24 [110/10] is directly connected, eth0, 00:00:08
C>* 10.0.0.0/24 is directly connected, eth0
O   10.0.1.0/24 [110/10] is directly connected, eth1, 00:00:08
C>* 10.0.1.0/24 is directly connected, eth1
O   10.0.7.0/24 [110/10] is directly connected, eth2, 00:00:08
C>* 10.0.7.0/24 is directly connected, eth2
C>* 127.0.0.0/24 is directly connected, lo0
O>* 127.0.0.1/32 [110/10] is directly connected, lo0, 00:00:08

If you ping the server node from the pc node, you will get the ping reply and if you check the table again, router2 should send every packet with the destination address for the 10.0.4.0/24 subnet via router 10.0.7.2 (router7). You can turn the router7 off by right clicking on the router7 node and selecting Stop. Now the pc node will not be able to ping the server node until routes are changed or router7 starts again.

You can also check every route status in the vtysh shell with the show ip ospf command.

DHCP

Open the topology imunes-examples/DHCP/DHCP.imn and you should see this:

Execute the experiment and position yourself in the imunes-examples/DHCP/ folder on your computer (not in virtual nodes). Run the command as root:

# ./start_dhcp

Right click on the PC3 node and use Wireshark to capture traffic on the eth0 interface.

Double click on the PC3 node and run:

root@PC3:/ # dhclient eth0

To check if an IP address is assigned to the PC3 node, run the following command on the node:

root@PC3:/ # ifconfig eth0

Stop the Wireshark capture and locate the DHCP packets generated by the script start_dhcp.

DNS, Mail and WEB

Open the topology imunes-examples/DNS+Mail+WEB/NETWORK.imn and you should see this:

DNS

Execute the experiment.

To run the DNS servers, position yourself in the imunes-examples/DNS+Mail+WEB/ folder on your computer. Run the command:

# ./start_dns

The script configures the DNS servers for the entire network.

To check the IP address of mm.tel.fer.hr, double click on the pc.zpm.fer.hr (node pc in the ZPM area) and run the following command:

root@pc:/ # host -t A mm.tel.fer.hr
mm.tel.fer.hr has address 20.0.0.4

Mail

If not already running, Execute the experiment and start the DNS servers as explained above. To run the SMTP and POP servers, position yourself in the imunes-examples/DNS+Mail+WEB/ folder on your computer. Run the command:

# ./start_mail

To see SMTP packets, start capturing packets on the eth0 interface of the node mm and use Sylpheed (right click on the mm node and click Mail client) to send an e-mail to imunes@zpm.fer.hr. If running Sylpheed for the first time, follow the wizard to create a mailbox before sending a message:

  • select Create mailbox at the following default location (/root/Mail) -> OK
  • Select account type: POP3 -> Forward
  • Display name: Your Name, E-mail address: root@tel.fer.hr -> Forward
  • User ID: root, POP3 server & SMTP server: www.tel.fer.hr -> Forward
  • Close

Compose a custom message and send it to imunes@zpm.fer.hr.

After sending an e-mail, start capturing packets on the eth0 interface of the node pc and use Sylpheed to fetch a sent message. If running Sylpheed for the first time, follow the same wizard as before to create a mailbox on pc:

  • select Create mailbox at the following default location (/root/Mail) -> OK
  • Select account type: POP3 -> Forward
  • Display name: Imunes, E-mail address: imunes@zpm.fer.hr -> Forward
  • User ID: root, POP3 server & SMTP server: www.zpm.fer.hr -> Forward
  • Close

Press Get to fetch the previously sent message (the password for user imunes is imunes). Open the received message.

The POP packets should be visible in the Wireshark.

WEB

If not already running, Execute the experiment and start the DNS servers as explained above.

To run the web servers (lighttpd), position yourself in the imunes-examples/DNS+Mail+WEB/ folder on your computer. Run the command:

# ./start_http

The script configures the web servers for the entire network.

To see HTTP packets, start Wireshark on node pc and its interface eth0. To make a HTTP connection, run Firefox on node pc by right clicking on it and clicking Web Browser. Type www.tel.fer.hr into the address field and wait for the page to load. You can also click on hyperlink Link on ZPM to make another HTTP connection.

IPsec

Open the topology imunes-examples/ipsec/ipsec44.imn and you should see this:

Execute the experiment, right click on the routerX node and use Wireshark to capture traffic on any interface.

To configure and start ipsec, and also to establish a secure connection between routers moon and sun, position yourself in the imunes-examples/ipsec/ folder on your computer. Run the command:

# ./start44.sh

Key exchange and security association packets should be then visible in Wireshark and the output of the script should confirm that the secure connection is established successfully.

Double click on the pc1 node to open the console shell and execute:

root@pc1:/ # ping 10.0.1.20

The pc1 node should get ping replies and Wireshark should show ESP packets (encapsulated ping requests/replies) instead of plain ICMP packets.

This example uses IPv4 traffic going through IPv4 IPsec tunnel (as noted by the suffix -44 in the name). There are also other IPsec IMUNES topologies and scripts in this folder (with suffixes -46, -64 and -66), which are similar to this example, but use other traffic/tunnel combinations.

Clone this wiki locally
You can’t perform that action at this time.