You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -171,10 +171,10 @@ There are 3 fundamental components to a Mininet topology: *Hosts*, *Switches* an
171
171
The topology in the lab template code defines a custom class that extends the `Topo` class in Mininet. This class contains the logic to create the nodes and links that make up the topology. The documentation for the `Topo` class can be found [here](http://mininet.org/api/classmininet_1_1topo_1_1Topo.html), and it allows adding each of these components via the `addHost`, `addSwitch` and `addLink` methods. We will discuss these methods in more detail in Stage 4 and use them to implement custom topologies.
|`addHost(name, ip=None, default=None, **opts)`| Adds a host to the topology with the given name. You can optionally set an IP address for the first interface, define a default route for the host, and control other options. |
177
-
|`addSwitch(name, **opts)`| Adds a switch to the topology with the given name and options. Mininet supports a range of switch types, including Open vSwitch, Linux Bridge, and user-space switches, which can be specified via options. For this lab, we will use the Linux Bridge switch (`lxbr`) and replace the switch class with a P4 switch in later activities. |
177
+
|`addSwitch(name, **opts)`| Adds a switch to the topology with the given name and options. Mininet supports a range of switch types, including Open vSwitch, Linux Bridge, and user-space switches, which can be specified via options. For this lab, we will use the Linux Bridge switch (`lxbr`) and replace the switch class with a P4 switch in later activities. |
178
178
|`addLink(node1, node2, intf1=None, intf2=None, params1=None, params2=None, **opts)`| Adds a link between two nodes (hosts or switches) with the given options. The param1 and param2 options accept a dictionary containing configuration for the interfaces created in each host to support the link. For example, the dictionary params1={'ip': '10.20.0.5/24', 'mac': '00:00:00:00:00:01'} will set the interface IP address to 10.20.0.5 and the MAC address to 00:00:00:00:00:01 for node1. The intf1 and intf2 variables define the interface names. |
179
179
||
180
180
@@ -236,11 +236,11 @@ A learning switch maintains a MAC address table that maps MAC addresses to speci
236
236
237
237
Linux uses the term *bridge* to describe a software-based switch. In Mininet, when we create a switch with the `lxbr` switch type, we create a Linux bridge that behaves like a learning switch. The Linux bridge will learn MAC addresses and forward frames in the same way as a physical Ethernet switch.
238
238
239
-
In order to inspect the MAC table of a Linux bridge, you can use the `bridge` CLI tool. For example, to view the MAC address table of a switch named `s1`, you can run the following command in the Mininet prompt `s1 bridge fdb show br "s1"`. You can also flush the MAC address table using the command `s1 bridge fdb flush br s1`.
239
+
In order to inspect the MAC table of a Linux bridge, you can use the `bridge` CLI tool. For example, to view the MAC address table of a switch named `s1`, you can run the following command in the Mininet prompt `s1 bridge fdb show br "s1"`. You can also flush the MAC address table using the command `s1 bridge fdb flush dev "s1"`.
240
240
241
241
### Verifying Switch Functionality with Wireshark
242
242
243
-
Let's now open a Wireshark instance on host `h2` and start capturing packets on interface `h2-eth0`. Once Wireshark is running, go back to the Mininet CLI and run the command `h1 ping -c 5 h2` to send 5 ICMP echo requests from host `h1` to host `h2`. You should not see the corresponding ICMP packets appearing in Wireshark on host `h2`. This happens because the switch has learned the MAC addresses of both hosts and is forwarding packets only to the correct destination. Run now on the Mininet terminal the command `s1 bridge fdb flush br s1` and repeat the ping command from `h1` to `h2`. This time, you should see **one** ICMP packet appearing in Wireshark on host `h2`, as the switch has flushed its MAC address table and is flooding the packets to all ports. MAC addresses are relearned by the switch as packets are sent between the hosts. In parallel, a timeout value is associated with each entry in the MAC address table, so that if no packets are received from a device for a specific period of time, the entry is removed from the table.
243
+
Let's now open a Wireshark instance on host `h2` and start capturing packets on interface `h2-eth0`. Once Wireshark is running, go back to the Mininet CLI and run the command `h1 ping -c 5 h2` to send 5 ICMP echo requests from host `h1` to host `h2`. You should not see the corresponding ICMP packets appearing in Wireshark on host `h2`. This happens because the switch has learned the MAC addresses of both hosts and is forwarding packets only to the correct destination. Run now on the Mininet terminal the command `s1 bridge fdb flush dev "s1"` and repeat the ping command from `h1` to `h2`. This time, you should see **one** ICMP packet appearing in Wireshark on host `h2`, as the switch has flushed its MAC address table and is flooding the packets to all ports. MAC addresses are relearned by the switch as packets are sent between the hosts. In parallel, a timeout value is associated with each entry in the MAC address table, so that if no packets are received from a device for a specific period of time, the entry is removed from the table.
244
244
245
245
> **Your task**: Using the provided topology, answer the questions in the fourth part of the [Week1 Unassessed Quiz](https://modules.lancaster.ac.uk/mod/quiz/view.php?id=2824281).
0 commit comments