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.
> 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?
> For layer 3 PBR, the only problem is with folks that use "fastroute",
> because the packets will be delivered out of IP and run into the
> problem you're looking at.
>
> Now, if bge0 and bge1 are bridged together, with the IP only having
> an address on bge0, you wouldn't be able to do "to bge1" or even
> "to bge1:1.2.3.4" because IP doesn't see that interface at all.
True.
> 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.
--
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]
