Re: Best/simplest/fastest approach for creating virtual switch out of
On 03/16/2013 10:45:57 PM, Bonnie Packet wrote: The question is how best to create a virtual switch out of em2 and em3, I'd love some advice on what the best way to accomplish this is. (Best = in my particular case means first, lowest total firewall cpu cost to route/= filter; second, lowest PF ruleset complexity; and third, lowest network tr= affic [ie, no packets going out ports that will just drop them anyways]. An= d I guess fourth, future lexibility in case I need to add a third or fouth = damn access point...) Um, given these requirements, a physical switch would seem to be optimal. (Of course this is the lazy way out, but this way there's absolutely no danger of burning out any precious brain cells from design-fatigue. ;-) Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Best/simplest/fastest approach for creating virtual switch out of
Come to think of it you wouldn't need to frob the arp tables since I presume the gateway is all on the soekris. And with proper dhcp configuration you could just frob the gateway address supplied to each access point. On 03/18/2013 08:03:39 AM, Karl O. Pinc wrote: On 03/17/2013 07:47:43 PM, Karl O. Pinc wrote: Um, given these requirements, a physical switch would seem to be optimal. (Of course this is the lazy way out, but this way there's absolutely no danger of burning out any precious brain cells from design-fatigue. ;-) Note that the above reply is a bit snarky. If you want to avoid extra hardware there's surely a best way to do it. I'm not paying enough attention to think what it might be. Thinking out loud (my having forgotten your requirements) is to use a separate network for your access points. You could deliver them dhcp, etc. You could frob the soekris arp table so that the gateway IP address is reachable by all ports with access points plugged in. (Something avoided by bridging?) Then your pf rules would filter by network. Of course you'd have to setup routing tables for the wireless networks and I can't remember if you're looking for handover to pass a roaming device from one to the next. Perhaps not the most general solution. All the same, spending the time to engineer something sounds like it might not be cost effective, interesting as it may be to find a way to do it right. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Best/simplest/fastest approach for creating virtual switch out of
Yes, bridge between em2 and em3.
Assign the IP (used as gateway by the clients) to bridge0.
You'll have to duplicate the MAC filter rules per interface.
The pf rules need to match both interfaces with 'on { em2 em3 }',
and floating state-policy (default) will simply work. No increase in
complexity there.
If you dislike the syntax there, you can use an interface group, but
it's purely cosmetical.
HTH,
Daniel
Re: Best/simplest/fastest approach for creating virtual switch out of
On 2013/03/18 15:25, Daniel Hartmeier wrote:
Yes, bridge between em2 and em3.
Assign the IP (used as gateway by the clients) to bridge0.
This isn't possible on OpenBSD, you either need to put the IP on one
real interface (then it may go down if the port is down), or bridge a
vether with it (http://www.openbsd.org/faq/faq6.html#Bridge, but you
will end up with made-up MAC addresses on the wire that way).
iirc NetBSD has changed their bridge(4) to allow an address directly
configured on it.
You'll have to duplicate the MAC filter rules per interface.
The pf rules need to match both interfaces with 'on { em2 em3 }',
and floating state-policy (default) will simply work. No increase in
complexity there.
If you dislike the syntax there, you can use an interface group, but
it's purely cosmetical.
HTH,
Daniel
Re: Best/simplest/fastest approach for creating virtual switch out
Shoot. Forgot to mention the most important user advantage of the current s= etup: since there's only one physical interface on the firewall handling al= l the (aggregated by the switch) wireless traffic, everyone can use that in= terface's IP as the same gateway address, no matter which AP they connect t= o. Any other solution has to keep that kind of single-address happiness so it'= s transparent to the users no matter how many APs we have. Figure that's no= t hard, but necessary to mention. Tanks.
