Ask Your Question

Revision history [back]

SMB client changing from one server interface to another

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

SMB client changing from one server interface to another

I'm poring over a number of Windows 10 to SMB Server pcaps and noticing a pattern which looks like this: (1) this:

  1. Negotiate Protocol (2) Protocol
  2. Session Setup (3) Setup
  3. Tree Connect Request Tree: \server\share (4) \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: this:

Out Data
- Network Interface, RSS, 1.0 Gbits/s, IPv4:  a.b.c.d

a.b.c.d

However, some of our SMB Servers have multiple interfaces (typically NAS boxes): 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

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

SMB client changing from one server interface to another

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

SMB client changing from one server interface to another

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 FSCTL_QUERY_NETWORK_INTERFACE_INFO
  5. ...

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

SMB client changing from one server interface to another

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
  5. ...

It is this the 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