Source aware routing, aka "packets go out the right interface", is available in onnv_135.
By sowmini on Mar 17, 2010
Solaris Nevada onnv_135 now provides a way for administrators to ensure "source-aware route selection". What this achieves is the following: consider a system trying to send out a locally originated packet. If there are multiple "longest match" routes for the IP destination of the packet going through different interfaces, when the "ip_strict_src_multihoming" is set to a non-zero value, the route selection will give preference to a route going through an interface on which the IP source of the outgoing packet is configured. If no such route is available (i.e., all the available routes are through interfaces which do not have the IP source of the outgoing packet), and ip_strict_src_multihoming is set to 1, aka "preferred source aware routing, (or if the ip_strict_src_multihoming is set to 0) the route selection will pick the next matching route permitted by the applicable ECMP parameters and longest match.
If ip_strict_src_multihoming is set to 2 (aka "strict source multihoming"), the IP source of the outgoing packet MUST be configured on the outgoing interface, so if no such matching
route is available, the packet is dropped.
What does all this mean for the Administrator?
If you want simple ECMP, with "weak multihoming", set your ip_strict_dst_multihoming and ip_strict_src_multihoming to 0.
If you would like symmetric path selection (i.e., request/response packets go in/out the same interface), or have to ensure that originated packets are not dropped due to downstream ingress filtering, you may choose one of the following settings for transmit behavior:
- ip_strict_src_multihoming == 1, where the first preference would be for an interface matching the IP source, and if that's not available, the system would fall back to the "weak" behavior.
- ip_strict_src_multihoming == 2, where routes would only be selected if the outgoing interface has the IP source.
ip_strict_dst_multihoming remains unchanged, and impacts the "receive-side" behavior of the system.
Stay tuned: we expect to be adding some user-friendly tunables for all this through ipadm in the very near future!