Multicast :: Part IV – Lab, multicast practice

Multicast in an Ethernet network explained:
There are tons of multicast posts that talk about Multicast routing at IP level. But how exactly does multicast behave in an Ethernet environment? This series tries to answer that question.

IGMP snooping topology

The lab setup consists of four Nexus 5500 switches. It’s a classical Ethernet setup running Spanning-Tree. IGMP snooping is enabled on all switches. The tests are executed in VLAN 1000. The topology of VLAN 1000 is show in the figure (red crosses represent the Spanning-Tree blocked ports). There are two test hosts connected to this topology which run Debian Linux.

Test 1: send a layer 2 multicast frame:

The goal of this test is to show that a layer 2 multicast frame is flooded throughout the layer 2 network. IGMP snooping does not affect layer 2 multicast handling. Examples of layer 2 multicast frames are CDP, UDLD and BPDU frames (and hundreds of others registered layer 2 protocols). What is the definition of a L2 multicast frame?

  1. If the Individual/Group (I/G) bit is set within the destination MAC address.
  2. A L2 multicast frame doesn’t have an IP payload.

With Scapy we will send a layer 2 multicast frame from Host01. At Host02 we try to capture the frame. We will multicast an ARP packet, which is of course nonsense (ARP is normally send to the broadcast address) but the goal of this test is to show that layer 2 multicast packets are flooded throughout the layer 2 network. I choose an ARP packet because I’m 100% sure that it will not be intercepted by a switch. Many layer 2 frames like CDP, UDLD and BPDUs are not flooded but intercepted and processed by the switch that receives the frame.

root@host01:~# scapy
Welcome to Scapy (2.2.0)
>>> a=Ether(dst = "01:00:00:00:00:01", src="00:16:17:6b:06:19")/ARP(pdst="192.168.1.12")
>>> sendp(a, iface="eth2", count=1,)                     
.
Sent 1 packets.
root@host02:~# tshark -V -f "ether host 01:00:00:00:00:01" -i eth2

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
-SNIP-
Ethernet II, Src: Msi_6b:06:19 (00:16:17:6b:06:19), Dst: 00:00:00_00:00:01 (01:00:00:00:00:01)
    Destination: 00:00:00_00:00:01 (01:00:00:00:00:01)
        Address: 00:00:00_00:00:01 (01:00:00:00:00:01)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Msi_6b:06:19 (00:16:17:6b:06:19)
        Address: Msi_6b:06:19 (00:16:17:6b:06:19)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: ARP (0x0806)
-SNIP-

The multicast ARP is received by Host02. For the record, Host02 (192.168.1.12) did reply to the multicasted ARP. Layer 2 multicast packets are always flooded.

Test 2: send a layer 3 link scope multicast packet:

The goal of this test is to show that a layer 3 link scope multicast packet is flooded throughout the layer 2 network. IGMP snooping does not affect layer 3 link scope multicast handling.

Class D IP addresses (IP group addresses) represent the IP multicast range 224.0.0.0 to 239.255.255.255. Within this range , 224.0.0.0 to 224.0.0.255 (the link scope range) is reserved for use in local subnets (multicast routers do not forward IPs from this range out of the local subnet). Local link addresses are reserved for various network protocols.

Every class D address is mapped to the reserved Ethernet multicast MAC address 0100.5Exx.xxxx used for IP (Layer 3) multicasting (see part II).

With Scapy we will send a layer 3 link scoped multicast packet from Host01. At Host02 we try to capture the frame.

root@host01:~# scapy
>>> a=Ether(dst = "01:00:5e:00:00:01", src="00:16:17:6b:06:19")/IP(dst="224.0.0.1", src="192.168.1.11")/UDP(dport=44444, sport=55555)/"Hello world"
>>> sendp(a, iface="eth2", count=1,)
.
Sent 1 packets.
>>>
root@host02:~# tshark -V -f "ether host 01:00:5e:00:00:01" -i eth2
Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
-SNIP-
Ethernet II, Src: Msi_6b:06:19 (00:16:17:6b:06:19), Dst: IPv4mcast_00:00:01 (01:00:5e:00:00:01)
    Destination: IPv4mcast_00:00:01 (01:00:5e:00:00:01)
        Address: IPv4mcast_00:00:01 (01:00:5e:00:00:01)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Msi_6b:06:19 (00:16:17:6b:06:19)
        Address: Msi_6b:06:19 (00:16:17:6b:06:19)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
-SNIP-

As you can see the packet was flooded. Packets send to an address in the 224.0.0.0/24 range are always flooded.

Test 3: send a layer 3 global scope multicast packet:

The goal of this test is to show that a layer 3 global scoped multicast packet is not flooded throughout the layer 2 network if IGMP snooping is enabled.

In this test we will generate a packet that is within the global scope IP multicast range (224.0.1.0 to 238.255.255.255).

With Scapy we will send a layer 3 global scope multicast packet from Host01. At Host02 we try to capture the frame.

root@host01:~# scapy
>>> a=Ether(dst = "01:00:5e:00:01:01", src="00:16:17:6b:06:19")/IP(dst="224.0.1.1", src="192.168.1.11")/UDP(dport=44444, sport=55555)/"Hello world"
>>> sendp(a, iface="eth2", count=1,)  
.
Sent 1 packets.
root@host02:~# tshark -V -f "ether host 01:00:5e:00:01:01" -i eth2

Nothing captureed……………

The global scoped frame was not flooded throughout the network. To be 100% sure this is caused by IGMP snooping we will disable IGMP snooping (no ip igmp snooping) at all switches and then repeat the test.

root@host01:~# scapy
>>> a=Ether(dst = "01:00:5e:00:01:01", src="00:16:17:6b:06:19")/IP(dst="224.0.1.1", src="192.168.1.11")/UDP(dport=44444, sport=55555)/"Hello world"
>>> sendp(a, iface="eth2", count=1,)
.
Sent 1 packets.
root@host02:~# tshark -V -f "ether host 01:00:5e:00:01:01" -i eth2

Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
-SNIP-
Ethernet II, Src: Msi_6b:06:19 (00:16:17:6b:06:19), Dst: IPv4mcast_00:01:01 (01:00:5e:00:01:01)
    Destination: IPv4mcast_00:01:01 (01:00:5e:00:01:01)
        Address: IPv4mcast_00:01:01 (01:00:5e:00:01:01)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Msi_6b:06:19 (00:16:17:6b:06:19)
        Address: Msi_6b:06:19 (00:16:17:6b:06:19)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
-SNIP-

With IGMP snooping disabled the global scoped packet is flooded throughout the layer 2 network. With IGMP snooping enabled it isn’t flooded. Multicast packets send to an address from the global scope or administrative scope ranges are not flooded in an IGMP snooping enabled network.

Before we start the next test we will re-enable IGMP snooping.

Test 4: send an IGMP membership report and then a layer 3 global scope multicast packet:

The Internet Group Management Protocol (IGMP) is used by hosts to signal their interest in one or more multicast groups. A host sends an IGMP membership report that contains multicast group address subscription(s). IGMP snooping running at the switch intercepts the IGMP membership reports and uses the group information in the IGMP packet to build an IGMP snooping table. The IGMP snooping table allows the switch to forward multicast packets only to interested receivers (and this is exactly where IGMP snooping is used for, limit the amount of flooded multicast traffic in a layer 2 network).

In this test we send an IGMP membership report to subscribe to group address 224.0.1.1 towards the switch. The switch will intercept the IGMP membership and builds its IGMP snooping table. Then we will repeat test 3 and see if the layer 3 global scoped multicast packet is forwarded.

The IGMP membership report is sent from Host02. Iperf is used to generate the IGMP membership report. But first a route must be added to bind interface eth2 to the 224.0.1.1 multicast address.

root@host02:~# route add 224.0.1.1 dev eth2
root@host02:~# iperf -s -u -B 224.0.1.1 -i 1

The by iperf generated IGMP membership report looks like this:

root@host02:~# tshark -V -f "igmp" -i eth2
-SNIP-
Ethernet II, Src: Msi_8f:21:ea (00:16:17:8f:21:ea), Dst: IPv4mcast_00:00:16 (01:00:5e:00:00:16)
    Destination: IPv4mcast_00:00:16 (01:00:5e:00:00:16)
        Address: IPv4mcast_00:00:16 (01:00:5e:00:00:16)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Msi_8f:21:ea (00:16:17:8f:21:ea)
        Address: Msi_8f:21:ea (00:16:17:8f:21:ea)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.12 (192.168.1.12), Dst: 224.0.0.22 (224.0.0.22)
-SNIP-
Internet Group Management Protocol
    [IGMP Version: 3]
    Type: Membership Report (0x22)
    Header checksum: 0xf8fc [correct]
    Num Group Records: 1
    Group Record : 224.0.1.1  Change To Exclude Mode
        Record Type: Change To Exclude Mode (4)
        Aux Data Len: 0
        Num Src: 0
        Multicast Address: 224.0.1.1 (224.0.1.1)

Host02 is connected to switch S2, after the sending the IGMP membership report the switch IGMP snooping table of S2 looks like this:

S2# sh ip igmp snooping groups vlan 1000
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  224.0.1.1          v3   D     Eth100/1/2

Now we repeat test 3 sending traffic destined to multicast address 224.0.1.1 and check if it will be received by Host02.

root@host01:~# scapy
>>> a=Ether(dst = "01:00:5e:00:01:01", src="00:16:17:6b:06:19")/IP(dst="224.0.1.1", src="192.168.1.11")/UDP(dport=44444, sport=55555)/"Hello world"
>>> sendp(a, iface="eth2", count=1,) 
.
Sent 1 packets.
root@host02:~# tshark -V -f "ether host 01:00:5e:00:01:01" -i eth2

Nothing captureed……………

Nothing received, that’s a bummer. After checking the snooping table of the other switches it turned out that they are empty. The v3 IGMP membership report was sent to link scope address 224.0.0.22. As learned earlier in test 2 “send a layer 3 link scope multicast packet” link scope destined packets are flooded, however not in this case. The v3 IGMP membership report was intercepted by the IGMP snooping process of switch S2 and not flooded to the other switches. Something is missing to make global scope multicasting work in IGMP enabled layer 2 network. In the next test we will introduce an IGMP querier.

Test 5: introduce an IGMP querier, send an IGMP membership report and then a layer 3 global scope multicast packet:

In this test we will introduce an IGMP querier in the form of a router. The next figure shows the network topology.

IGMP querier

IGMP operates according to a query response model. The IGMP querier sends out membership queries, interested hosts respond to these queries with IGMP membership reports. The router is configured in the following way:

ip pim rp-address 192.168.1.2 20
ip pim send-rp-announce GigabitEthernet0/0 scope 32 group-list 10
!
access-list 10 permit 224.0.0.0 15.255.255.255
access-list 20 deny   224.0.1.39
access-list 20 deny   224.0.1.40
access-list 20 permit 224.0.0.0 15.255.255.255

Now we capture the IGMP membership queries send out by the querier:

root@host02:~# tshark -f "igmp" -i eth2
  0.000000  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
 60.006991  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
120.008416  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
180.012450  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
240.016615  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
300.020772  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general

Every 60 seconds the querier sends out an IGMP membership query. Something interesting happened to the IGMP snooping tables of all switches:

S1# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Eth1/16
S2# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po1
S3# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po1
S4# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po2

What you see is the formation of multicast router interfaces. Multicast router interfaces point towards the multicast querier. IGMP membership queries (general membership queries in this case) are forwarded to all interfaces within the same VLAN (they are flooded). If an IGMP membership query is received at a switch interface the snooping process knows that this interface leads towards the IGMP querier and will add this information to the snooping table. A general membership query is displayed as “*/*” within the snooping table. In the next figure the formation of the multicast router interfaces is visualized.

formation of multicast router interfaces

Now we will restart iperf (Iperf is used to generate the IGMP membership report) and see what happens to the query process:

root@host02:~# iperf -s -u -B 224.0.1.1 -i 1
root@host02:~# tshark -f "igmp" -i eth2
  0.000000  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
 60.004496  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
120.008318  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
- Iperf was started here -
176.782950 192.168.1.12 -> 224.0.1.1    IGMPv2 46 Membership Report group 224.0.1.1
180.012604  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
182.990956 192.168.1.12 -> 224.0.1.1    IGMPv2 46 Membership Report group 224.0.1.1
240.016829  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
240.354953 192.168.1.12 -> 224.0.1.1    IGMPv2 46 Membership Report group 224.0.1.1
300.020879  192.168.1.2 -> 224.0.0.1    IGMPv2 60 Membership Query, general
301.386953 192.168.1.12 -> 224.0.1.1    IGMPv2 46 Membership Report group 224.0.1.1

Take a look at the IGMP snooping tables:

S1# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Eth1/16
1000  224.0.1.1          v2   D     Po2
S2# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po1
1000  224.0.1.1          v2   D     Eth100/1/2
S3# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po1
S4# sh ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan  Group Address      Ver  Type  Port list
1000  */*                -    R     Po2
1000  224.0.1.1          v2   D     Po1

Next to the formation of multicast router ports we also see the formation of multicast group member interfaces. The multicast group member interfaces point towards hosts that are interested in receiving traffic for a specific multicast group (224.0.1.1). In the next figure the formation of multicast member interfaces is visualized.

multicast group member interface

Now the snooping tables contain correct membership information for multicast group 224.0.1.1. The snooping tables didn’t contain the group membership information during the previous test (test 4). This is because IGMP membership reports generated by a host are only sent towards multicast router interfaces. During test 4 no multicast router interfaces (and thus no member interfaces) where formed because there was no querier active.

It’s interesting to see that S3 did not form a multicast group member interface. This is because there is no interested host connected to S3. In other words S3 did never receive an IGMP membership report for group 224.0.1.1.

Now we repeat test 3, send traffic destined to multicast address 224.0.1.1 from Host01 and check if it will be received by Host02.

root@host01:~# scapy
>>> a=Ether(dst = "01:00:5e:00:01:01", src="00:16:17:6b:06:19")/IP(dst="224.0.1.1", src="192.168.1.11")/UDP(dport=44444, sport=55555)/"Hello world"
>>> sendp(a, iface="eth2", count=1,)
.
Sent 1 packets.
root@host02:~# tshark -f "ether host 01:00:5e:00:01:01" -i eth2
0.000000 192.168.1.12 -> 224.0.1.1 IGMPv2 46 Membership Report group 224.0.1.1
3.236374 192.168.1.11 -> 224.0.1.1 UDP 60 Source port: 55555 Destination port: 44444

This time it worked. We see also a membership report send out by host 2 during the capture. You could ask yourself what if we connect the multicast source (Host01) to switch S3? The snooping table of S3 does not contain membership information for group 224.0.1.1. Would it still work? Yes it will work, this is because an unregistered multicast packet (a packet that has no associated group information in the snooping table) is sent towards the multicast router port in the same VLAN. A registered multicast packet (a packet that has associated group information in the snooping table) is sent towards multicast router interfaces and multicast member interfaces in the same VLAN.

The next figure visualizes the multicast traffic flow:

Multicast traffic flow

Summary:

  • L2 multicast frames have the IG bit set and do not carry a IP payload. L2 multicast is always flooded throughout the L2 domain.
  • L3 multicast packets map to the reserved MAC address: 0100.5Exx.xxxx.
  • Link scope multicast packets (class D: 224.0.0.0/24) are flooded throughout the L2 domain just like L2 multicast packets. But we saw that this is not true for IGMP membership reports, they are intercepted by the snooping process and only send to multicast router ports (if there are any).
  • Global scope and administrative scope multicast packets are not flooded if IGMP snooping is enabled. Switching of global scope multicast packets relies on the formation of multicast router interfaces and multicast group member interfaces. These interfaces will only form if there is a IGMP querier available in the VLAN.

The opinions expressed in this blog are my own views and not those of Cisco.

Leave a Reply

Your email address will not be published. Required fields are marked *