Quoting Stuart Henderson <s...@spacehopper.org>:
On 2009-01-20, Key Aavoja <k...@neoon.com> wrote:
Wouldn't it be better to not use the bridge and use (multicast-)routing
and pf to solve your problem?
Multicast routing with "dvrmpd" is tested with pf, does not work. the
same thing happens, if streamX is allowed to pass out on vlanX and
streamY is allowed to pass out on vlanY, result is pretty similar:
vlanX outputs both streams (streamX, streamY) and the same thing with
vlanY.
if you get rid of the bridge and change it for a routed setup with
igmpproxy (it's in packages), does that do what you're looking for?
pf is not 100% percent multicast compat.?
see the last couple of paragraphs of my earlier post about that -
fine when it's routed, some limitations as a bridge.
Thanks, I read and now I understand completely.
Btw. test with dvrmpd was without a bridge, but pf filtering on "out"
@ vlans had same results as with bridge. Using a igmpproxy in my setup
is not a option because equipments expecting a stream are sometimes
"far away" in network topology and cannot be sure, that igmp-join is
always received.
Anyway for others who are googling multicast & bridge topics:
I found a "workaround".
Use Linux 2.6 kernel + vlan + bridge + ebtables.
Net setup will be the same, all what you need to add on your own script is:
#!/bin/bash
#default policy to drop everything (no matter which protocol).
ebtables -P FORWARD DROP
#flush existing rules.
ebtables -F
#now the exceptions
ebtables -A FORWARD -i eth0.1100 -o eth1.1101 -p IPv4 --ip-dst
239.16.1.1 -j ACCEPT
ebtables -A FORWARD -i eth0.1100 -o eth1.1102 -p IPv4 --ip-dst
239.16.1.2 -j ACCEPT
ebtables -A FORWARD -i eth0.1100 -o eth1.1103 -p IPv4 --ip-dst
239.16.1.3 -j ACCEPT
/etc/init.d/ebtables save && echo "ebtables: rules updated!"
Thats all what you need to do!
Machine with two broadcom interfaces (not so good as intel) , 2GHz
xeon (dual core)
has acceptable performance: load: 0.00, cpu:0%, interrupts:eth0=6800;
eth1=4300 90Mbit/s is the traffic on eth1 and pkt/s=8000
* This setup is giving a gaurantee, that no SpanningTree and other
messages does not travel between interfaces, and vlans are staying
still "separated"
--------
Key
