Re: OpenBSD 4.4 pf+vlan+bridge problem
Hi! 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. pf is not 100% percent multicast compat.? Since these days i tried out anyway how multicast routing is and decided to set up also similar configuration as described in the beginning of this thread assuming for pf multicast traffic is no different from any other 'ordinary' traffic. I believe the reason why with a rule like this pass out quick on vlan1101 proto udp from any to 239.16.1.1 you see the same traffic on every interface which is set up to multicast is because how pf decides to pass packets. Default state-policy is floating and it means that decision to pass traffic is based on packet's direction and src and dst ip and ports and not on what interface packet leaves (or enters). Normally this is ok and as i understand this approach for example saves memory not to keep information which excact interface is used for passing. But problem arises with multicast traffic as src ja dst addresses and ports are the same. I tried and adding 'keep state (if-bound)' seems to solve the problem. Imre Actually i experimented with tags, something like this .. pass in quick on $if_onelan inet to 239.x.x.x keep state (if-bound) tag MC pass out quick on $if_otherlan keep state (if-bound) tagged MC ...
Re: OpenBSD 4.4 pf+vlan+bridge problem
Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Wouldn't it be better to not use the bridge and use (multicast-)routing and pf to solve your problem? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si - is the ruleset loaded correctly? pfctl -sr - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Guido Tschakert guido.tschak...@src-gmbh.de: Key Aavoja schrieb: Hello, Hello, first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. Its needed because all those streams are already on one vlan, but its really needed to extract address based. Its the best way to put different streams on different vlans (using cisco switch is not a very good idea for this task, because some limitations, but its out of current topic). 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. pf is not 100% percent multicast compat.? As I said, I have no experience with multicast traffic, but that is how I would start digging. guido I have a problem with pf+bridge+vlan (multicast traffic) and I googled a lot, read the manuals and so on - no help. Finally I posted on wrong place :( sorry. Hopefully this time I'm writing to right place. Following setup is made for multicast traffic separation from one lan to multiple vlans. Setup: Two physical interfaces bnx0 bnx1 interfaces bnx0 and bnx1 has vlans: bnx0 vlan1100 bnx1 vlan1101 vlan1102 vlan1103 vlan1104 vlan1105 vlan1106 vlan1107 vlan1108 Bridge setup: bridge0 has all vlans as bridge members (vlan1100, vlan1101 ... vlan1108) PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? Thank you. -
Re: OpenBSD 4.4 pf+vlan+bridge problem
Quoting Stuart Henderson s...@spacehopper.org: On 2009-01-20, Guido Tschakert guido.tschak...@src-gmbh.de wrote: first thing: I do not have any experience with multicast traffic. But what you have build seems very strange to me. First you use vlan to separate the networks an then you put them alltogether with a bridge. I do not see the use of the vlans. It can indeed be useful to do this, even without multicast traffic in the equation. You might want to filter traffic between machines in the same subnet, and this is a way you can do it. Key Aavoja schrieb: PF config: block out on bnx1 all block out on vlan1100 all block out on vlan1101 all block out on vlan1102 all block out on vlan1103 all block out on vlan1104 all block out on vlan1105 all block out on vlan1106 all block out on vlan1107 all block out on vlan1108 all pass out quick on vlan1101 proto udp from any to 239.16.1.1 pass out quick on vlan1102 proto udp from any to 239.16.1.2 pass out quick on vlan1103 proto udp from any to 239.16.1.3 Wishful thinking, what the result should be: All multicast streams are available on vlan1100 and recieved via bnx0/vlan1100. Bridge should stream the multicast packets to what ever vlan - its the place where pf should help. Stream: 239.16.1.1 should be available only on vlan1101, and 239.16.1.2 avialable on vlan1102 and so on. . Real Result: Stream 239.16.1.1 is available on all three vlans: 11101,1102,1103 - same thing happens with other two streams (239.16.1.2, 239.16.1.3) It's really weird what's going on or did I understood something wrong and configuration is not correct? you should check the simple things first. - is PF enabled? pfctl -si PF is enabled, btw removing the last three rules the whole mcast traffic is diabled - for testing I have 10 streams as input but trying to allow only three. - is the ruleset loaded correctly? pfctl -sr yes this command shows that all rules are loaded - does it correctly block ordinary non-multicast traffic between the vlans? if you did indeed include your whole PF config in your email, only that particular multicast traffic should pass between the vlans, everything else should be blocked. I pasted here 100% of pf config, this non-multicast traffic needs to be tested, tomorrow I will do that. you might have already done this, but if you did, you should have mentioned in your email what you checked. with a routed (not bridged) environment, PF is able to control multicast traffic in either direction (I just tried). from my reading of if_bridge.c, on a bridge, pf filtering for multicast frames only happens _inbound_. multicast frames sent _out_ through a bridge are not subject to the outbound PF filter rules. bridge MAC filter rules _are_ applied outbound for multicast frames, I haven't tested but I think that will give you a way you can restrict this traffic.
Re: OpenBSD 4.4 pf+vlan+bridge problem
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.
Re: OpenBSD 4.4 pf+vlan+bridge problem
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
