I'm poring over a number of Windows 10 to SMB Server pcaps and noticing a pattern which looks like this: (1) Negotiate Protocol (2) Session Setup (3) Tree Connect Request Tree: \server\share (4) Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO ...
It is this 4th step where I want to focus attention.
In the Response to this Ioctl Request, the Server enumerates its interfaces. In my environment, the average SMB Server has a single interface -- the one over which the current SMB is established, and so the Ioctl Response looks like this: Out Data - Network Interface, RSS, 1.0 Gbits/s, IPv4: a.b.c.d
However, some of our SMB Servers have multiple interfaces (typically NAS boxes): Out Data - Network Interface, RSS, 1.0 Gbits/s, IPv4: a.b.c.d - Network Interface, RSS, 10.0 Gbits/s, IPv4: a.b.e.f
The existing SMB session is traversing the 10Gb interface, as we intend: we call this the 'front-end' interface of the NAS cluster. We use the 1Gb interface for management traffic: syslog, snmp, ntp, ssh/http for admins administering the box.
However, sometimes Clients will read/write files across the 10Gb interface ... and then ... start a second SMB session across the 1Gb interface. We don't want that -- it works, but we don't want client traffic traversing the dedicated management network -- and I'm looking for ways to unbind SMB from these 'mgmt' interfaces.
But in the meantime, I would like to better understand why a Client might choose to do this. Any ideas?
Errata - Typically, our Clients & SMB Servers are settling on the 3.1.1 SMB Dialect, supporting Leasing, Large MTU, Multi-Channel, Persistent Handles
--sk
Stuart Kendrick
