Darren Reed writes: > >Unless, of course, the keyword is used only in the context of a > >functioning bridge. In *that* case, "fastroute" could reasonably mean > >"continue bridging just as before, computing destination based on > >learned sources." It's just outside of a bridge that I have trouble > >interpreting that keyword. > > > > > > Right, which is why at present I'm tempted to leave it as a no-op > or even just generate a syntax error.
I'd expect it to be a syntax error if it can't do something reasonable. > But the idea of tieing it in with bridging is interesting...how would > bridging communicate its presence and how would that presence > be used? There are (or will be) bridge instances, just as there are IP stack instances. Each one has a forwarding table that has the learned sources, and we could easily supply an interface that maps from a given destination MAC address into an output link (of some sort). I'm a little puzzled in how or why anyone would be manipulating forwarding down at this level (it's a little easier to see how someone would want to bypass IP routing), but I guess it'd be possible. It might be better, though, to step back and figure out what sorts of problems such a feature would solve. Not just what the IP Filter syntax allows or what could be done with the bridging code, but what sort of problem a user would be trying to solve with something like this. I'm not too clear on what that'd be. > >When I heard "L2 Filtering," I'd expected that we were going to > >intercept packets at L2, do L3 (and above) filtering on them, and then > >pass them along -- as in something useful as a stealth firewall, but > >not quite a statically-routed bridge. Is that right? > > > > > > The best solution (for my money) in doing a stealth firewall is > to marry layer 2 filtering with bridging and I've been pushing > for this for quite a long time. In that case, I think you really don't need "to" or "fastroute." The bridge itself learns the destinations and sends the packets where they go. The most important part is to get hooked somewhere in the bridge forwarding path so that you have a chance to inspect the packets and do your filtering. (You can get a _little_ more detail on what we're doing in the RBridge project ON gate, but it's a work in progress.) > >I'm not sure what a "MAC header for delivery to 1.2.3.4" looks like > >... that's an IP address, and it has to be resolved to some local MAC > >address first. You don't mean taking the ARP-resolved MAC address > >seen on bge1 and using that on bge0, do you? That seems like > >surprising behavior to me. > > > > > > This was with respect to use with layer 3 rules... > And yes, if 1.2.3.4 has its MAC address resolved only on bge1, > using that in the MAC header for sending out bge0. Other than the passive monitoring port I mentioned earlier, I don't see how doing that is terribly useful. What do people _do_ with it? > Whilst this may not seem to make a lot of sense, it allows the > ARP cache to be primed with static IP-ethernet mappings and > for those to work - when using "arp(1m)", there is no way to > specify which network interface the address is to be used with. > Whether or not that's a bug, is another matter altogether :) It's a feature gap, in that the stack allows us to set ARP entries with more information. But I think it's also a bug if you've got to use that command at all. Static mappings are for the birds; they're too hard to manage in any real sense. Your first hardware swap or upgrade will give you a really bad day. It's like trying to manage a network with static routes. We're surrounded by these computers with the ability to figure out how to talk to each other, and it seems that some are afraid to use that awesome power or just want to do it all by hand. Or like creating illuminated manuscripts ... -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
