[ Broadening the discussion to clearview-discuss; the context is that Sowmini noticed that the IP MIB code does not filter out routes marked IRE_MARK_TESTHIDDEN in e.g. ip_snmp_get2_v4(), so those routes are still visible to in.routed and confuse it a bit. It's clear we need to filter those out, but I wondered whether a new EXPER_IP_ROUTE_TESTHIDDEN type was needed to allow in.mpathd to see these routes so it could use them as probe targets if need be. ]
Looking at this closer, I think I was needlessly worried about in.mpathd. In particular, once an interface is in a group, there's no way to create routes for targets that are IRE_MARK_TESTHIDDEN because ip_rts_request() will map e.g. "-ifp under1" requests to e.g. "-ifp ipmp0" internally for backward compatibility with normal route creation. To provide a specific example, if I have data addresses on 10.8.57/24 and test addresses on 192.168.0/24, then (as before) I can create explicit targets for those 192.168.0/24 addresses through host routes: route add -host 192.168.0.254 192.168.0.254 -static ... but this route will not be tied to any interface, so its ire_ipif will be NULL and it will not be marked IRE_MARK_TESTHIDDEN. So in.mpathd will see these -- along with everything else -- which is what we want. If you try to do this: route add -host 192.168.0.254 192.168.0.254 -static -ifp under1 ... then the kernel will internally map it to something like: route add -host 192.168.0.254 192.168.0.254 -static -ifp ipmp0 ... which will fail with ENETUNREACH since ipmp0 only has 10.8.57/24 addresses. So again nothing will be created that needs to be marked IRE_MARK_TESTHIDDEN. So again, it should be fine. The only corner case I see is that *before* placing an interface into a group, one could configure a route like: route add -host 192.168.0.254 192.168.0.254 -static -ifp under1 When under1 is added to a group, this route will remain but will be marked IRE_MARK_TESTHIDDEN (this is really a byproduct of the implementation and going through ipif_recover_ire()). Later, if the interface is removed from the group, this route will be cleared of IRE_MARK_TESTHIDDEN and will work like normal again. But it's not clear to me that anyone would ever do this in practice and expect in.mpathd to pick up that route as a target. So I'm reluctant to add new MIB goo just to allow in.mpathd to retrieve those. So the executive summary is that I think I can just filter IRE_MARK_TESTHIDDEN routes as Sowmini originally requested. If anyone sees a problem with this, please speak up. -- meem
