James Carlson wrote: >Darren Reed writes: > > >>We've been having a discussion with Cathy about vanity naming >>in the kernel as IPFilter does all interface name to identifier >>conversion in the kernel, so using libdladm is out of question. >> >> > >Ah, ok. That sounds like a rather different problem from the ones I'm >looking at. > > > >>So there are 3 modes of operation here to consider. >>* rules with "fastroute" - lookup a table that says which NIC to >>use to reach a given MAC address; >>* rules with "to bge0" - the outgoing NIC is specified, regardless >>of what is in any tables; >>* rule with "to bge0:00:11:22:33:44:55" - the outgoing NIC is specified >>and I suspect the destination MAC address needs to be changed. >> >>Of these three, I suspect that the first is going to be a no-op and >>quite possibly not supported. In IP, it provides forwarding without >>TTL drecement - there's no such advantage to be gained at layer 2. >> >> > >Indeed. The best you could do for some sort of automated "fastroute" >would be to fall back to IP behavior -- if the packet happens to be >IP, look up the IP destination address in IP's routing table. L2 >doesn't quite have the same function. > >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. But the idea of tieing it in with bridging is interesting...how would bridging communicate its presence and how would that presence be used? >>For the other two, I don't see the same problem that you have >>because we're not looking at the IP routing table at all. >> >> > >True, but an L2 "to bge0" comes with some interesting new problems. > > 1. With the existing L3 version of this, I believe you'd ARP for > that address. Are we really assuming that the original MAC > destination address on the packet (which, if unicast, was > obviously one of our *own* MAC addresses) is going to be a valid > place to send this packet on some other interface? That's weird. > It means that there's either a separate node out there with the > same MAC address (gulp!) or a forwarding loop. > > Perhaps it's useful in a very restrictive environment where you > use "dup to" to create a special monitoring port with sniffing > software. It's hard to see how it'd be useful in any real data > path, though. > > 2. You're not implementing Spanning Tree or any other bridging- > related software to avoid forwarding loops, and L2 packets (at > least for Ethernet) have no TTL, so you're in danger of melting > the network. > >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. >>Alas, >>if you did "to bge0:1.2.3.4" but 1.2.3.4 was connected via bge1, the >>packet will be forced out bge0 with a MAC header for delivery to >>1.2.3.4 - ie it'll go nowhere unless someone picks it up in promiscuous >>mode, but that's the intention. >> >> > >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. 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 :) Darren _______________________________________________ networking-discuss mailing list [email protected]
