Accidentally hit two articles with completely opposite content.
https://kb.netapp.com/support/index?page=content&id=3011977: Does the filer support Etherchannel? states that ip.fastpath will answer on the same physical interface of a trunk that packet came in:
With fastpath, the interface, on which the request came in, and the MAC address of the caller is saved on input. The reply is delivered on the same link using the saved src MAC address, except that it is now the dst MAC address. This avoids a route and an arp lookup. If the filer is connected to a switch, the switch will distribute NFS (or CIFS or HTTP) requests as they flow into the filer. Since the filer responds on the same physical interface as the one on which the request was received, there is no need to distribute responses out to the physical links on the trunk. Basically, the filer load-balances over the links of the trunk without having to de-multiplex the traffic out. Non-fastpath traffic and broadcasts are always sent out on one of the links of the trunk. One of the physical links in the trunk is marked as the "primary link" of the trunk. Non-fastpath frames, broadcast frames, etc., are sent on this "primary link."
https://kb.netapp.com/support/index?page=content&id=3011178: How does a multimode vif interact with ip.fastpath? clearly explains:
Therefore the fastpath-function will only see vif-interfaces as a single interface. ip.fastpath will not be aware of the individual physical ports or 1st level vifs/ifgrps that are members of the top level vif/ifgrp.
Which one is correct?
