Routing multicast messages
How to adjust our Routing Table
so we can examine the IGMP
group membership messages
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
Initial routing table
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
Adjusted routing table
Using ‘nicwatch’
• Now we can use our ‘nicwatch’ utility to let
us inspect multicast packets that are sent
or received using our multicasting demos
‘hrn23521’
‘hrn23522’
$ ./multisend
$ ./multirecv
$ ./nicwatch eth1
$ ./nicwatch eth1
‘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
Special multicast addresses
• Here are some multicast addresses which
are dedicated to specific purposes:
– 224.0.0.1
– 224.0.0.2
– 224.0.0.22
– 224.0.0.251
– 224.0.0.252
All systems on this local subnet
All routers on this local subnet
IGMP membership messages
mDNS (multicast name lookup)
‘Link-Local’ name resolution
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’
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
single copy of an arriving
multicast datagram
router
multiple copies are forwarded to
the multicast group’s ‘members’
Hosts and Routers
IGMP Report
host
router
IGMP Query
Two types of IGMP Host Membership messages
are used in IGMP version 1
Type 1 = Query, Type 2 = Report
version
type
(unused)
checksum
Multicast group-address (or zero)
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
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
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 messagetypes to allow more member-information
within each individual IGMP message,
thus reducing the total ‘overhead’ traffic
TCP/IP Protocol Stack
HTTP
FTP
TELNET
UDP
ICMP
SMTP
Application Layer
Transport Layer
TCP
IGMP
Network Layer
IP
ARP
Ethernet
RARP
Token Ring
Link Layer
IGMP datagrams
MAC header
IP header
IGMP packet
Type: 1=Host Membership Query, 2=Host Membership Reply,
3=DVMRP (Distance Vector Multicast Routing Protocol)
Version Type
Max time
before
responding
IGMP Checksum
Group Address in Reply (or zeroed in Query)
stream of tagged data
in DVMRP messages
Recall IP header format
32 bits
IP
Header
version length
Type of
Service
Identification
Time-to-Live
Total Length
(in bytes)
Fragment offset
D M
Protocol
ID-number
Header Checksum
Source IP-address
Destination IP-address
Options
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
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
‘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
Subnet-to-subnet ‘hops’
• All of our classroom, CS Lab, and anchorcluster 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
Distinct subnets
‘steelhead’
‘spaten’
‘stella’
138.202.170.0 subnet
‘tt’
router
‘lectern01’
‘anchor02’
‘hrn53003’
‘hrn23504’
‘stargate’
138.202.171.0 subnet
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)
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
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
int
oval = 2;
int
olen = sizeof( oval );
if ( setsockopt( sock, SOL_IP, IP_MULTICAST_TTL, &oval, olen ) < 0 )
{ perror( “setsockopt IP_MULTICAST_TTL” ); exit(1); }
• Our ‘multihop.cpp’ demo lets a user enter
a desired default-value for TTL multicasts