Multicast on the LAN

Transcription

Multicast on the LAN
1
Multicast on the LAN
Engineering Workshops
2
Multicast Addressing at Layer 2
• An IPv4 multicast address is 32 bits, of which the first 4
bits are always the same, leaving 28 bits.
• A MAC multicast address is 48 bits, of which the first 24
bits are always the same. One of the remaining bits is
reserved, leaving 23 bits.
• So, one multicast MAC address maps to 32 multicast IP
addresses.
Engineering Workshops
T
]
]
V ]
]
V \]
DA
=
T
T
T
V T
V T
V X<
T
V T
V TU
W
>
$
,
*
(
*+)
'
$
&
%
#$
" !
S
=
JK
=
=
F
GL
HI= G
EDC
?
AB
=
@?>
<
<
<
;<
P
K
M
R
Q
NM
O
[
[
K
?A
J
K
JK
Z
YF
,
7!
)
$#
9:
"!
8
(
+*)
$
#$
!
$!
*)
#
+65
"
(
*4
$
$
(
#
* (
'
01
23
0 %
1
$
/
*
.-
-
3
Ethernet Multicast Addressing
Engineering Workshops
4
IGMP
• Internet Group Management Protocol - how hosts tell routers about
group membership
• Routers also solicit group membership from directly connected hosts
• RFC 1112 specifies version 1 of IGMP
– Supported on Windows 95
• RFC 2236 specifies version 2 of IGMP
– Supported on latest service pack for Windows, newer Windows
releases, and most UNIX systems
• RFC 3376 specifies version 3 of IGMP
– Provides source include-list capabilities (SSM!)
– Included in Linux kernel 2.5 and later
– See http://videolab.uoregon.edu/projects.html
Engineering Workshops
5
IGMPv2
• Router:
– sends Membership Query messages to All Hosts (224.0.0.1)
• query-interval = 125 secs default
– router with lowest IP address is Querier (rest non-queriers)
– If lower-IP address query heard, back off to non-querier state
• Other Querier Present Interval default: (robust-count x
query-interval) + (0.5 x query-response-interval) = 255 secs
– listens for reports (whether querier or not) and adds group to
membership list for that interface
• query-response-interval = 10 secs default
– timeout (Group member interval) default:
• (robust-count x query-interval) + (1 x query-responseinterval) = 260 sec
– robust-count - provides fine-tuning to allow for expected packet
loss on a subnet. Default = 2 (tunable from 2-10)
Engineering Workshops
6
IGMPv2
• Host:
– sends Membership Report messages to groups
it is a member of
• waits 0-10 sec (default)
• Hosts listen to other host reports
• Only 1 host responds
– sends unsolicited Membership Reports (i.e., Join
Messages) to group address (e.g. 224.10.8.5)
– sends Leave messages to All Routers (224.0.0.2)
– reports group membership ONLY – no sources. Only
the existence of local group members is reported, not
the actual members themselves
Engineering Workshops
10
Soft State
• Say I set up an active Multicast group, say by issuing a
membership report. What happens if my computer goes
down and never directly leaves the group ?
• This is fixed with “Soft State”
– Everything has a timer, and if not periodically
reinitiated the timer will expire and the state will be
removed.
– So there is no danger of some rogue group lasting
forever.
Engineering Workshops
12
IGMPv3 Enhancements
• Group-Source Report message is defined. Enables
hosts to specify which senders it can receive or not
receive data from.
• Group-Source Leave message is defined. Enables
host to specify the specific IP addresses of a
(source,group) that it wishes to leave.
Engineering Workshops
13
Switches and Snooping
• IGMP host reports (Joins) tell the router to start
sending multicast traffic to the LAN, since one or
more hosts on the LAN are members of the group.
• In a conventional shared broadcast LAN using
switches that have no multicast smarts, the traffic
is sent to all hosts.
• With multiple high bandwidth multicast sources
(e.g. video at 5 Mbps), this does not scale beyond
approximately one source.
• There are a few techniques used to deal with this...
Engineering Workshops
14
IGMP Snooping
• Implemented by several vendors. Support for IGMPv2
is common; support for IGMPv3 is rare, but becoming
more common.
• What happens at the MAC layer:
– IGMP snoopers add a bridge table entry for each
multicast group destination address (GDA) to each
switch port that has the interested member's unicast
source address (USA) already on it. (Remember that
there are likely to be dumb hubs downstream of
switches, so more than one USA can be on a single port.)
– When an IGMP Leave is received, the GDA entries are
pruned.
Engineering Workshops
15
Why IGMP snooping is
harder than it looks
• The IGMP membership reports have to be captured
from each host and suppressed to other hosts to
prevent the others from going into idle-member state;
every interested host has to be spoofed into thinking it
is the only member of the group, so that it actively
sends membership reports. The IGMP snooper then
forwards one of these membership reports up to the
router (or makes up a fake membership report for
itself).
Engineering Workshops
Why IGMP snooping is
harder than it looks, continued
• Since multiple USAs can be on a port (via dumb hub),
the switch has to actually do the IGMP membership
query/timeout before pruning a port.
• Since membership reports are sent to the same GDA as
the (possibly high-bandwidth) multicast traffic, there is
a potential for heavy loading of the switch CPU, unless
you use more expensive ASICs that can separate the
IGMP protocol messages from general traffic and route
only the IGMP messages to the CPU.
• The switch has to know which is the multicast router
port. It does this by snooping for IGMP queries.
Engineering Workshops
16
17
CGMP
• The proprietary Cisco Group Management Protocol
puts the bulk of the Layer 3 logic in Layer 3 devices
rather than cramming it into Layer 2 devices like
IGMP snooping does.
• The router sends CGMP Joins and Leaves to the
switch, specifying the USA and GDA.
• On receipt of an IGMP Membership Report, the router
sends the switch a CGMP Join.
• On receipt of an IGMP Leave, the router sends the
switch a CGMP Leave.
• IGMP membership reports still have to be suppressed
so that hosts don't go into idle-member state.
• CGMP functioning is not well documented. Interactions
with IGMPv3 are unclear.
Engineering Workshops
18
PIM Snooping and RGMP
• For Layer 2 networks with routers but no hosts
(transit LANs).
• PIM, not IGMP, is spoken among routers, so IGMP
snooping does not work in this case.
• PIM snooping and the Cisco-proprietary Router
Group Management Protocol (RGMP) are used by
the Layer 2 switch to send only the multicast flows
that the router needs to the router's port. These
work analogously to IGMP snooping (smarts in the
switch) and CGMP (smarts in the router).
• PIM snooping is still mostly experimental. Some
Foundry Networks switches support it.
Engineering Workshops
19
Problems with Multicast on the LAN
• In general, multicast on the LAN is not as well
understood as multicast on the WAN.
• Switch behaviors are not standardized.
• Problems with switches:
– when snooping is enabled, they may drop
packets that shouldn’t be dropped.
– even without snooping, sometimes they step
outside their bailiwick, trying to do non-Layer-2
tasks.
Engineering Workshops
20
Case Study
A few months ago I converted all our interfaces over to
IGMP Version 3. Then I started getting complaints from
our lab/classroom support group that Norton Ghost was
failing for them. It would hang after about 3 minutes. So
far the fix, without understanding why it works, has been
to revert the interfaces to IGMP version 2. The switches
downstream from these interfaces are running CGMP and
CGMP LEAVE (which is actually a form of IGMP
snooping/spoofing for IGMP Leaves sent to 224.0.0.2). I
suspect that the fact that these switches are actually
looking at IGMP packets may have something to do with
the problem that reverting to v2 fixed...
— Alan Crosswell
Engineering Workshops
21
Case Study
This author traveled to Los Alamos, New Mexico to help
debug a multicast problem that had everyone stumped.
Everyone was assuming the only known router on the
subnet was also acting as the multicast gateway.
Unfortunately, this wasn’t the case. A nominally Layer
2 switch on the subnet was accidentally configured with
PIM active, and won the PIM Designated Router
election. Of course, this Layer 2 switch had no upstream
to anywhere.
— Bill Nickless
Engineering Workshops
One Approach to
Multicast on the LAN
• Avoid snooping, as it causes more problems than it
solves.
• Keep subnets small. A smaller subnet is less likely
to have people joining several different multicast
groups, traffic for each of which is sent to the entire
subnet.
• If at all possible, use routers, not switches or
bridges.
• If you have to use switches, try to at least buy them
all from the same vendor, so you won’t have
inconsistent behavior as well as unexpected
behavior.
Engineering Workshops
22
23
Another Approach to
Multicast on the LAN
• The previous approach reflects gigaPoP/WAN bias.
• On a campus, it just isn't possible to use routers
everywhere.
• Switches and snooping may be evils, but they are
necessary evils. Learn to cope with them.
http://www.cisco.com/warp/public/473/22.html
is a good place to start.
Engineering Workshops
24
Lab 1: Multicast on the LAN
Engineering Workshops
25
SSM
Engineering Workshops
26
PIM-SM
• SM stands for “Sparse Mode.”
– RFC 2362 and draft-ietf-pim-sm-v2-new-06.txt
– There is also a Dense Mode, but we don’t
recommend using it.
– Cisco has a proprietary “Sparse-Dense” mode
which is used for RP discovery.
• PIM-SM allows for both RPTs and SPTs.
• There are two ways to use PIM-SM…
Engineering Workshops
27
ASM and SSM
• ASM: Any-Source Multicast. Traditional multicast – data
and joins are forwarded to an RP.
– All routers in a PIM domain must have RP mapping.
– When load exceeds threshold, forwarding switches to an
SPT. The default threshold is one packet; in this case,
the sole purpose of the RPT is to learn which sources
are active. (With IGMPv2, the receiver can only specify
the group, not specific sources.)
– State increases (not everywhere) as number of sources
and number of groups increase.
– SPT state is refreshed when data is forwarded and with
Join/Prune control messages.
• SSM: Source-Specific Multicast. PIM-SM without RPs –
instead, the source is learned out-of-band, and the SPT is
built directly to it.
Engineering Workshops
28
SSM
• Source-Specific Multicast (SSM) is a subset of ASM,
so
– SSM concepts apply directly to ASM, but
– SSM is a lot simpler than ASM.
For these reasons, we cover SSM first in this
workshop.
• 232 / 8 is assigned to SSM as an address space. Other
address ranges can also be set up for SSM — this is
primarily a function of the receiving network.
• Source activity and IP addresses are assumed
known.
• IGMPv3 allows for “Include” lists of (S,G) pairs.
Engineering Workshops
29
SSM
• SSM - draft-ietf-ssm-arch-01.txt
– 232/8 – IANA assigned
– No RPTs
– Guarantees ONE source on any delivery tree
• Content security – no unwanted sources
– Reduced protocol dependence – more later...
– Solves address allocation issues for inter-domain one-to-many
• tree address is 64 bits – S,G
– Host must learn source address out-of-band (e.g, from a web page)
– Host-to-router join request specifies source as well as group
• requires IGMPv3 for include-source list
– SSM behavior in 232/8 by default
• Configurable to expand range
Engineering Workshops
30
SSM in Action
• Each (S,G) pair listed in the IGMPv3
include list generates a (S,G) Join directly
towards the source.
• That’s it. It’s very simple. All you need to
implement is :
– Edge routers need IGMPv3
– Interior routers need filters to prevent RP
(*,G) Joins & other RP state for the SSM
address block
Engineering Workshops
31
SSM Group Addresses
• 232 / 8 is assigned to SSM as an address space.
– You don’t have to ask, you can just pick one and
use it.
• How can this be ?
– Note that all joins are unique as long as the
combination of S and G are unique. Not only can
one source support multiple groups, but if there
are two sources using the same group address,
everything works just fine.
Engineering Workshops
34
Lab 2: SSM
Engineering Workshops