Routing multicast messages
Download
1 / 24

Routing multicast messages - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

Routing multicast messages. How to adjust our Routing Table so we can examine the IGMP group membership messages. We need a ‘quiet’ LAN.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Routing multicast messages' - giles


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Routing multicast messages

Routing multicast messages

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


We need a quiet lan
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



Add route for ip multicasts
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



Using nicwatch
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
‘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
Special multicast addresses

  • Here are some multicast addresses which are dedicated to specific purposes:

    • 224.0.0.1 All systems on this local subnet

    • 224.0.0.2 All routers on this local subnet

    • 224.0.0.22 IGMP membership messages

    • 224.0.0.251 mDNS (multicast name lookup)

    • 224.0.0.252 ‘Link-Local’ name resolution


Effect of ifconfig
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
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’


Hosts and routers
Hosts and Routers

router

host

IGMP Report

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
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
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
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


Tcp ip protocol stack
TCP/IP Protocol Stack

HTTP

FTP

TELNET

SMTP

Application Layer

UDP

TCP

Transport Layer

ICMP

IGMP

IP

Network Layer

ARP

RARP

Ethernet

Token Ring

Link Layer


Igmp datagrams
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

version

Header

length

Type of

Service

Total Length

(in bytes)

Identification

D

M

Fragment offset

Time-to-Live

Protocol

ID-number

Header Checksum

Source IP-address

Destination IP-address

Options


When multirecv starts
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
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
‘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
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


Distinct subnets
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
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
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

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); }


ad