James Carlson wrote: >Darren Reed writes: > > >>We've been cracking our heads on another problem: >>the desire to use link names (rather than mac names) >>of interfaces as the administrative interface, the lack >>of a mapping between the two and how to overcome that. >> >>More specifically, the question being debated is whether >>or not to allow "renamed" links to be used with their >>"vanity" name or their "real" name. >> >>It sounds like you want to take the approach of ignoring >>the vanity name and only use the mac name - which makes >>life easier. >> >> > >Actually, no, that's not quite true. The issue I was talking about in >this thread was how to handle the data path in DLS and/or MAC. I need >to intercept and inject packets at a level that the framework doesn't >seem to support directly. That doesn't involve the link name. > >I expect the user interface to deal in link names (like everything >else in dladm), and the kernel to get numeric (unchanging) >datalink_id_t values that it can use. That's a completely separate >issue. > >I'd guess that L2 Filtering ought to be doing the same thing -- using >libdladm to look up link identities as required -- but that's probably >something you need to discuss with the Clearview folks. > >
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. >>"policy routing" for layer 2 is not something that we've >>been focused on at present (which is what I expect would >>tie in with the work you're doing here.) >> >> > >Yes, that sounds right. > > 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. 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. 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. 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. Darren _______________________________________________ networking-discuss mailing list [email protected]
