Subject: Re: Multicast for switches ?

From: Toerless Eckert <[email-masked]>
Date: Mon, 12 Aug 1996 19:40:44 +0200 (MET DST)

> As suffering from this problem myself I played around with the thougth of how
> one migth do it... the idea is that you make the switch IGMP sensitive so that
> it will snoop up IGMP messages and turn such traffic on and off just like you
> do for unicast traffic, except for the fact that you migth send it to several
> ports... IGMP messages needs to be forwarded off course (that should be the
> IGMP spoofing part... or rather, that group is allways forwarded).

Actually only passive "snooping" will lead to problems. The primary problem
is that IGMP is set up so that not ALL hosts will report their group
membership, but only the first one that reports (there's a random timer
between the Query and the Report). Thus passive spoofing would never
discover all segments with members.

I guess, IGMP-spoofing for a pure L2 switch runs a little bit like this:

1. Spoof for IGMP Query messages. Broadcast them on all segments and
   call segments from which IGMP Query messages are received "uplink".
   Call the other segments "downlink" or "leaf". Do some senseful timeout
   on the uplink/downlink state of a segment (5 minutes).

2. Filter on IGMP Reply messages. Broadcast IGMP Reply messages to 
   all "uplink" segments, but not to "downlink" segments. This is the
   important action to avoid that only the first member of a certain multicast
   group will respond.
   
3. Take the reported membership from IGMP Reply message to set up forwarding
   for the reported multicast group. Always forward to "uplink" segments.
   Forward only to those downlink segments that have reported membership
   since the last query for that multicast group was send or generated (see 4.).

4. If for some time, no IGMP Query message is received (5 minutes),
   generate one of your own to detect membership for multicast groups.
   Act on the received membership reports as outlined in 2./3. This case is
   for an ip network without multicast routers. All segments are "downlink".
   In case of a multi-switch network, the inter-link segments would be
   "uplink", but this is already a case where you would need real
   ip multicast routing to be more efficient than a switch.

Is this correct ?

As far as i understand it, the real problem with this behaviour is that the
switch must always pass all received multicast packets to the internal CPU
to see the IGMP Report packets, unless the switch is able to filter
packets to be passed to the CPU by something else than the destination ethernet
address. The reason is that the IGMP membership reports are destined to
the multicast group that they are meant for. I think this problem has been
solved in IGMP-V2 or later, but i havn't yet read them.

Best regards
	Toerless

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 12 Aug 1996 18:51:52 +0200

> Hi
> 
> I think this topic has been discussed some time ago, but as i really
> don't have a good clue for the outcome and the probable changes in the
> meantime, here is the question again:
> 
> Q: What shall i do to support multicasting in switched networks ?
> 
>    People start to deploy switches, especially between 10 and 100 Mbps
>    ethernet segments, and these switches tend to be a real p... i. t.. a..
>    when it comes to multicasting, because at least all those switches i've
>    seen do not support multicasting. I know that they cannot "legally"
>    support real multicasting, because there is no "EGMP", but i know
>    of at least one switch, the Catalyst 1200 that does support IGMP spoofing.
>    The problem is just: which switches with 10 and 100 Mbps support the
>    very same feature ? This would all be for stub leaf networks, so
>    there is really no problem with multicast routing here, only for a little
>    bit of last-hop  pruning on the 10 Mbps ports of a 10/100 Mbps ethernet
>    switch.
> 
>    Any solutions upcoming or existing ?

Magnus

> Toerless Eckert
> Universitaet Erlangen Nuernberg
> Lehrstuhl fuer Betriebsysteme 
> Martensstrasse 1
> D-91058 Erlangen, Germany
> Tel.: +49 9131 85 7278
> FAX: +49 9131 85 8732
> [email-masked]
> /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/
>

---

From: Bill Fenner <[email-masked]>
Date: Mon, 12 Aug 1996 15:43:43 PDT

>   on the uplink/downlink state of a segment (5 minutes).

All multicast routers on a subnet must be able to hear IGMP Report
messages, and all multicast traffic must be passed between all
multicast routers.  So you really need manual configuration to tell
the switches what segments routers are on; they can't guess.

>Is this correct ?

Other than the bit about the routers, it seems more or less right.
Note that most layer-2 switching architectures don't lend themselves
well to failing to forward packets based on their content, so this
scheme is likely to be unimplementable on many switches.

  Bill

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 13 Aug 1996 06:32:54 +0200

> discover all segments with members.

[Cut of some stuff]

> solved in IGMP-V2 or later, but i havn't yet read them.

The only packets the switch CPU would be interested in are in the all-systems
multicast group (224.0.0.1) in which IGMP messages are passed. This group 
should
also be forwarded to all multicast interfaces of the switch so that the
machines still see it as a single cable (even if you happens to hide packets).

If you do it this way I don't really think you need to actively spoof things
since your IGMP querier will be heard on all the subnets splitted with the
switch. In the same way will IGMP joins etc. be heard on all subnets.

Now, will this passive spoofing cause trouble?
Of course are there a small few groups that also should be defaultly forwarded
everywhere...

Magnus

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Aug 1996 13:04:05 +0200 (MET DST)

> the switches what segments routers are on; they can't guess.

And i was guessing that you could get around manual configuration by
listening to the IGMP query messages and consider those segments to hold
a router from which the switch receives IGMP query messages.
Is that not a valid assumption ?

> scheme is likely to be unimplementable on many switches.

Yes, that's why i was asking if this scheme is how it's done, because
it would result in poor scaling.

Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Aug 1996 13:22:24 +0200 (MET DST)

> Of course are there a small few groups that also should be defaultly forwarded

??

The information, where group members are for certain multicast groups is
contained in IGMP membership reports. These are not sent to 224.0.0.1 but
to the multicast group that they apply to. Don't you think a switch CPU should
be interested in those packets to detect members ?

Toerless

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 13 Aug 1996 15:16:27 +0200

> be interested in those packets to detect members ?

Nope... not if I am able to read... all IGMP messages are sent on 224.0.0.1 and
224.0.0.2 if I am able to read the latest draft correctly... and it makes sense
too since you cannot expect routers to listen for IGMP messages on all 
multicast
adresses, it would die at high traffic, no it only tunes in to a very few well
know groups...

You carry the multicast group number with the querry.

You join the group but you never send the message to the group. It's the router
(or in this case the switch) which are interested in that info...

(OK everyone... I must admitt it was some time ago I read all this... :)
Magnus

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Aug 1996 15:24:30 +0200 (MET DST)

> 224.0.0.2 if I am able to read the latest draft correctly... and it makes sense

I was referring to rfc1112 which is still the internet standard, or is it ?

Of course, newer IGMP versions will be better.

Toerless

---

From: Mark Handley <[email-masked]>
Date: Tue, 13 Aug 96 14:42:56 +0100

>> to the multicast group that they apply to. Don't you think a switch CPU shou

>Nope... not if I am able to read... all IGMP messages are sent on 224.0.0.1 an
>224.0.0.2 if I am able to read the latest draft correctly...

A quick tcpdump shows IGMP reports go to the group, IGMP queries go to
ALL-SYSTEMS.MCAST.NET.  

shrew.cs.ucl.ac.uk: tcpdump dst 224.2.127.254
tcpdump: listening on le0
14:33:35.300629 shrew.cs.ucl.ac.uk > 224.2.127.254: igmp report 224.2.127.254 [ttl 1]
...

shrew.cs.ucl.ac.uk: tcpdump proto igmp
tcpdump: listening on le0
14:31:12.922060 laphroaig.cs.ucl.ac.uk > DVMRP.MCAST.NET: igmp dvmrp 1.15.8.3 [b1=0x1] [ttl 1]
...

shrew.cs.ucl.ac.uk:  tcpdump dst 224.0.0.1 or dst 224.0.0.2
tcpdump: listening on le0
14:35:40.940746 laphroaig.cs.ucl.ac.uk > ALL-SYSTEMS.MCAST.NET: igmp query [b1=0x64] [ttl 1]
...

Mark

---

From: Steve Deering <[email-masked]>
Date: Tue, 13 Aug 1996 07:34:16 PDT

> > to the multicast group that they apply to.
> 
> Nope... not if I am able to read... all IGMP messages are sent on 224.0.0.1
> and 224.0.0.2 if I am able to read the latest draft correctly...

Magnus: you're wrong and Toerless was right.  Membership reports are sent
to the address of the group in which membership is being claimed.  Review
RFC-1112.  (No, this property has not changed in more recent versions of
IGMP.)

> ...and it makes sense too since you cannot expect routers to listen for
> IGMP messages on all multicast adresses, it would die at high traffic,...

That may not be what you expect, but it is true.  IP multicast routers are
required to be promiscuous to all IP multicasts.  The IP multicast service
model allows any host to send multicast to any IP multicast group at any
time, and the routers cannot anticipate what those groups will be (the
senders need not be members of the groups they send to), so they must listen
to all possible group addresses.  IGMP is not the reason for this
requirement, but it takes advantage of it, to enable suppression of multiple
reports for the same group.

Steve

---

From: Jim Bogard <[email-masked]>
Date: Tue, 13 Aug 1996 10:46:30 -0400 (EDT)

> > the multicast group that they are meant for. I think this problem has been

This is correct, per RFC 1054.

> machines still see it as a single cable (even if you happens to hide packets).

All all-hosts traffic should be forwarded everywhere (being 
all-hosts).  In addition, there exists IGMP traffic on addresses other than 
224.0.0.1.  See the above.

> Of course are there a small few groups that also should be defaultly forwarded

'Should' and 'required' are not the same. :)  224.0.0.1 is the only one 
necessary for the spec.

J-.
Of course, I could be wrong...

---

From: Bill Fenner <[email-masked]>
Date: Tue, 13 Aug 1996 08:14:17 PDT

>a router from which the switch receives IGMP query messages.

But not all routers send IGMP query messages, only the elected querier.
You could have 20 multicast routers on a subnet but only hear IGMP query
messages from one of them.

  Bill

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Aug 1996 17:50:57 +0200 (MET DST)

> Regarding traffic rates: any decent router ought to be able to handle
> packets at the maximum rate of its attached interfaces; after all, cheap
> bridges can do so, so why shouldn't routers be able to do the same?

*rotfl*

---

From: Steve Deering <[email-masked]>
Date: Tue, 13 Aug 1996 08:45:23 PDT

Steve

---

From: Steve Deering <[email-masked]>
Date: Tue, 13 Aug 1996 09:06:08 PDT

> It seems like the LanPlex 2500's _can_ guess. I don't know how they
> do it though... I've setup my LP2500's to do IGMP snooping&querying:

Yes, it can guess, but it's not robust.  The multicast routers elect a single
IGMP querier among themselves, so in steady state only one router sends
periodic queries.  Each router will send at least one or two IGMP Queries
when it starts up, before it learns whether or not it wins the election.
If the bridge misses or forgets a non-winning router's initial Queries for
whatever reason (temporary partitioning, bridge being power-cycled, bridge
queue overflow, etc.), it will fail to recognize the presence of that router.

Also, a bridge can watch for DVMRP packets, and assume that the senders are
multicast routers, but that's also unreliable because:

	(a) the routers may be running some multicast routing protocol
	    other than DVMRP.

	(b) non-routers (e.g., management hosts) may issue DVMRP packets
	    for diagnostic reasons (this case could result in unnecessary
	    forwarding, rather than failure to forward adequately).

I believe the only way to assure robust behavior of IGMP snooping bridges
or switches is to put all the multicast routers on the same segment or
the same switch port.  If that's unacceptable, manual configuration of the
switches, to tell them where the routers are, would be the next best approach.

Steve

---

From: Bill Fenner <[email-masked]>
Date: Tue, 13 Aug 1996 08:14:17 PDT

Bill

---

From: [email-masked]
Date: Tue, 13 Aug 1996 13:01:06 -0700 (PDT)

> Q: What shall i do to support multicasting in switched networks ?

	Have you looked at the P-MP discussions in the IP/ATM groups?

-- 
--bill

---

From: Petri Helenius <[email-masked]>
Date: Tue, 13 Aug 1996 23:16:21 +0300 (EET DST)

> bridges can do so, so why shouldn't routers be able to do the same?
Before you dive deeper on this, please give a thought whether you are
talking about the assumed subscribed bandwidth on virtual-connectivity
based interfaces or the line rate.

Anyone having some cheap OC-12 to Fast Ethernet bridges, can send some
this way.

Pete

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Aug 1996 11:04:17 +0200 (MET DST)

> switches, to tell them where the routers are, would be the next best approach.

Ok, and how is the bridge expected to learn about segments with hosts on
a certain multicast group WITHOUT passing all multicast packets from ALL
segments continuosly through the CPU to find and filter IGMP messages ?

Toerless

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Aug 1996 10:41:46 PDT

> segments continuosly through the CPU to find and filter IGMP messages ?

I'm not sure which issue you are asking about: the need for every bridge
to get a copy every multicast packet, or the CPU cost within a bridge of
looking inside every multicast packet it sees?  Regarding the first issue,
a bridge need not forward multicast packets down branches that do not
lead towards either a multicast router or members of the destination group
(that's the whole point), so obviously downstream bridges on such branches
will not see all packets.

Regarding the second issue: yes, in order to recognize IGMP membership
reports, a bridge has to look inside the packets -- that's why it's called
snooping.  Snooping is a clever but flawed hack to avoid doing the right
thing, which is either to have the bridges implement an "EGMP", or replace
the bridges with routers.

Steve

---

From: Petri Helenius <[email-masked]>
Date: Wed, 14 Aug 1996 23:40:50 +0300 (EET DST)

> the bridges with routers.
People seem to be doing this the other way around since they have been
fooled by renaming bridges to switches and I would say, mainly because
there is no sufficiently performant routers available presently.
(specially if price makes any difference for you)

Pete

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Aug 1996 14:21:50 PDT

> (specially if price makes any difference for you)

Yeah, I know.  I find it rather depressing.

Steve

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 14 Aug 1996 18:52:36 -0700

>> Yeah, I know.  I find it rather depressing.

    Hey, we can make them fast. But we can't make them fast and cheap.

Dino

---

From: Petri Helenius <[email-masked]>
Date: Thu, 15 Aug 1996 09:01:37 +0300 (EET DST)

>     Hey, we can make them fast. But we can't make them fast and cheap.
The relative performance development of dedicated routing hardware
(and software) compared to for example the PC industry seems slow at
best which leads to the fact that under many circumstances, my $2k PC
can outperform a $20k router.

...and since there is no device that would provide reasonable
functionality at 200kpps in a real-life environment, I would say that
some innovations are required to go beyond 1Mpps routing (or just much
more raw CPU). However with all the buzz about going OC-12 and beyond
routed speeds, one is either going to end up with letting one car run
on a highway at a time or putting some performance where their mouth
is, which, it remains to be seen, I estimate to see both within next
12 months.

Bring me a box that can run and have some room for bursts at 1000 kpps
(300 byte packets, please) and run RED on OC-3 interfaces at congested
traffic levels and I'll put my money where my mouth is.

Pete

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Aug 1996 10:40:05 +0200 (MET DST)

> can outperform a $20k router.

"Could" would be more appropriate. If you had the software to make a
decent router out of your PC. Undoubtly 4.4BSD with gated is a good start,
but then even this setup does not work well at high loads due to
a totally insufficient scheduling for the task. So, from the OS perspective
you'd better go for some god real-time OS or micro-kernel OS to get appropriate
real-time packet scheduling strategies and performance.

On the hardware side it is even more complex, because except for ethernet
and maybe ISDN interfaces, all other networking interfaces are a pain if
it comes to support for any other operating systems beside MiroSux-something.
So you can add another gigantic amount of development time to integrate
those network interfaces into your software that they run FAST (and i've seen
some ugly bad and slow FDDI and ATM drivers).

To sum up: Anybody that goes out yelling: 
MY PC IS A BETTER: WORKSTATION, ROUTER, TELEPHONE, COFFEE-MACHINE OR PSYCHATRIST
will get flames from me.
(sorry that it was you, pete, this time ;-)

> is, which, it remains to be seen, I estimate to see both within next

It remains to be seem if routed at OC-12 will be the primary way to go.
Surely there will be boxes to do it, but i would guess that is anything
positive comeas out of ATM it may really be to reduce the load on packet
switching for some poor CPUs in the long term.

> traffic levels and I'll put my money where my mouth is.

It would just be too expensive right now.

Toerless

---

From: Petri Helenius <[email-masked]>
Date: Thu, 15 Aug 1996 12:38:47 +0300 (EET DST)

> some ugly bad and slow FDDI and ATM drivers).

DEC FDDI cards run fine with FreeBSD as does their Fast Ethernet
ones. TCP performances is around 98Mbps sustained.
 > (sorry that it was you, pete, this time ;-)
Can your telephone do CD-quality audio? :-) Or do germans spell it
'ISDN', I guess with Telekom it goes the 'I See D-Mark's Now' :-)

 > switching for some poor CPUs in the long term.
Global 'switched' networks? Not bloody likely. Intercontinental ATM?
Would you want to give up 20Mbps off your OC-3 link for nothing?
I'd run my wide-area backbone links frame based for Internet use, ATM
for VPN. Of course if you provision services, FR or ATM is the way to
go but for an ISP, plugging OC-3 or OC-12 fiber into the routing
device sounds attractive.

 > It would just be too expensive right now.
But you don't have to have many of these devices.

Pete

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Aug 1996 11:49:31 +0200 (MET DST)

> ones. TCP performances is around 98Mbps sustained.

One example for one OS. On the other hand the FreeBSD boxes around here don't
seem to run quite stable. Talk about support...

> 'ISDN', I guess with Telekom it goes the 'I See D-Mark's Now' :-)

I Still Dont Now.

> But you don't have to have many of these devices.

That's just one reason for the high price.

Toerless

---

From: Petri Helenius <[email-masked]>
Date: Thu, 15 Aug 1996 14:25:18 +0300 (EET DST)

> seem to run quite stable. Talk about support...
Yea, I haven't seen any problem reports on [email-masked] lists
from [email-masked] so I assume this is just a false assertion. 
Also there is readily available selection of MBone-tools for
FreeBSD. I myself swapped over from ISC years ago and haven't had a
single crash ever. However, as all software, FreeBSD also comes with
different flavors, some are called RELEASE some aren't and contrary
to some router vendors, FreeBSD RELEASE code is of high quality. 
Usefulness of 2.2-CURRENT varies from day-to-day but that's a
playground if you want to sacrifice operational stability.

 > That's just one reason for the high price.
People buy expensive items if they need or like them. You just have to
make ones offering attractive and you have a business.

Pete