1. Routing multicast messages How to adjust our Routing Table so we can examine the IGMP group membership messages

2. We need a ‘quiet’ LAN If we want to examine the actual datagram exchanges that implement IP multicasting, then we should do it on the local network that doesn’t have hundreds of irrelevant packets going by which would distract us By default our Linux systems will forward multicast packets to our ‘public’ network, so we’ll need to modify our routing tables

3. Initial routing table

4. Add route for IP-multicasts Here is the command you can use to add a routing-table entry which will direct all of the outgoing IP-multicast packets to ‘eth1’ (which is on a much less ‘noisy’ network) $ sudo /sbin/route add –net 224.0.0.0 netmask 255.0.0.0 dev eth1

5. Adjusted routing table

6. Using ‘nicwatch’ Now we can use our ‘nicwatch’ utility to let us inspect multicast packets that are sent or received using our multicasting demos $./multisend $./nicwatch eth1 ‘hrn23521’ $./multirecv $./nicwatch eth1 ‘hrn23522’

7. ‘transparent’ management We discover that some lower levels of the TCP/IP protocol stack exchange various messages in support of multitasking which are ‘unseen’ by application-layer software Some examples are: –When ‘ifconfig’ changes an interface’s state –When a host ‘joins’ a multicast group –When a host ‘leaves’ a multicast group

8. Special multicast addresses Here are some multicast addresses which are dedicated to specific purposes: –224.0.0.1All systems on this local subnet –224.0.0.2All routers on this local subnet –224.0.0.22IGMP membership messages –224.0.0.251mDNS (multicast name lookup) –224.0.0.252‘Link-Local’ name resolution

9. Effect of ‘ifconfig’ This UDP datagram was sent to the multicast-DNS group address (224.0.0.251) by the ‘eth1’ interface on hrn23528 when the ‘/sbin/ifconfig’ command was used to assign an IP-address to that interface, and simultaneously to bring it ‘UP’

10. Reliance on routers Multicasting works by relying on routers to make copies of multicast packets for hosts on a router’s local subnet that have asked to receive them router single copy of an arriving multicast datagram multiple copies are forwarded to the multicast group’s ‘members’

11. Hosts and Routers router host IGMP Report IGMP Query Two types of IGMP Host Membership messages are used in IGMP version 1 versiontype(unused)checksum Multicast group-address (or zero) Type 1 = Query, Type 2 = Report

12. IGMP version 1 Whenever a host joins a multicast group, it sends an IGMP Host Membership Report to the specific group multicast address A multicast router listens for all multicast messages, so it will process these IGMP Host Membership Reports upon receipt And periodically a router will send a Host Membership Query, to refresh awareness

13. IGMP version 2 A third type of Host Membership Message is added to the IGMP protocol, called the Leave Group message, resulting in more prompt awareness by the router that the group’s membership has been changed, so it can stop forwarding messages to a host that is no longer a group-member

14. IGMP version 3 Some additional message-types added to allow the various routers on a network to stay informed about group memberships, and expansion of some former message- types to allow more member-information within each individual IGMP message, thus reducing the total ‘overhead’ traffic

15. TCP/IP Protocol Stack Application Layer Transport Layer Network Layer Link Layer HTTPFTPTELNETSMTP UDPTCP ICMPIGMP ARPRARP IP EthernetToken Ring

16. IGMP datagrams Version IGMP Checksum Group Address in Reply (or zeroed in Query) Max time before responding Type Type: 1=Host Membership Query, 2=Host Membership Reply, 3=DVMRP (Distance Vector Multicast Routing Protocol) MAC headerIP headerIGMP packet stream of tagged data in DVMRP messages

17. Recall IP header format Time-to-Live Header Checksum Source IP-address Destination IP-address IdentificationFragment offset Header length Total Length (in bytes) Type of Service IP version Protocol ID-number DM 32 bits Options

18. When ‘multirecv’ starts… These duplicate packets were sent to the IGMP multicast group (224.0.0.16) from the ‘eth1’ interface on hrn23528 when our ‘multirecv’ program started, with a brief, but noticible, time-delay in between these two transmissions

19. When ‘multirecv’ quits… These duplicate packets were sent to the IGMP multicast group (224.0.0.16) from the ‘eth1’ interface on hrn23528 when our ‘multirecv’ program ended, with a brief, but noticible, time-delay in between these two transmissions

20. ‘router alert’ Notice that the IGMP membership report messages include an IP option, known as the ‘router alert’ option It’s a 2-byte option: 0x94 0x04 (but then it’s padded with NOPs to fill out 32-bits) Notice also that the IP-header’s TOS field uses precedence code 6, signaling that it’s an ‘internetwork management’ datagram

21. Subnet-to-subnet ‘hops’ All of our classroom, CS Lab, and anchor- cluster machines, as well as the ‘stargate’ gateway-server, belong to the university’s 138.202.171.0 subnetwork The CS department’s machines named ‘steelhead’, ‘spaten’ and ‘stella’ belong to another university subnet: 138.202.170.0 So internetworking goes through a router

22. Distinct subnets router ‘tt’ ‘steelhead’‘spaten’‘stella’ ‘anchor02’‘hrn53003’‘hrn23504’ ‘stargate’ 138.202.171.0 subnet 138.202.170.0 subnet ‘lectern01’ Note: Our router’s current firewall configuration blocks multicast packets sent by hosts on the 138.202.171.0 subnet -- but ‘stargate’ and ‘lectern01’ are setup as ‘exceptions’ to that general firewall policy (for purposes of our class demo)

23. TTL == 1? By default, the Time-to-Live field in the IP header for multicast packets is set to 1 This means routers won’t ‘forward’ these multicast packets beyond the local subnet But we can ‘adjust’ this default TTL-value in our multicasting application programs if we use the ‘setsockopt()’ socket-function Our ‘multihop.cpp’ demo-program does it

24. IP_MULTICAST_TTL Here is how our ‘multisend.cpp’ demo can be modified to allow its multicast packets to ‘hop’ from one subnet to the next one Our ‘multihop.cpp’ demo lets a user enter a desired default-value for TTL multicasts intoval = 2; intolen = sizeof( oval ); if ( setsockopt( sock, SOL_IP, IP_MULTICAST_TTL, &oval, olen ) < 0 ) { perror( “setsockopt IP_MULTICAST_TTL” ); exit(1); }