Event 30803, SMBClient; Windows Server 2016 Nano, Failover Cluster, Storage Spaces Direct; Network Routing Bug? RRS feed

  • Dotaz

  • We're seeing 32 "30803" events every 10 minutes each on four Windows 2016 Nano servers in a failover cluster with storage spaces direct.

    The machines are configured with five 10G NICs (1x management, 2x storage/cluster, 2x Hyper-V). The storage/cluster NICs are running in a dedicated VLAN on different 10.10... subnets, the management NIC is also running in a dedicated VLAN with a dedicated subnet, with no routing between the storage/cluster and management networks. Only the management adapter has a gateway configured. netstat show multiple established connection within the different storage/cluster networks between all servers and in general the cluster works fine.

    Every time a "30803" event is logged, I’m seeing multiple corresponding failed connection attempts in a network trace from a management IP to a storage IP.

    With other words, failed connection attempts from the management NIC via the gateway to a storage/cluster NIC in a different subnet and VLAN. Is this a Bug? Correctly established connections from storage/cluster NICs to corresponding storage/cluster NICs of different machines can also be observed.

    Running "Find-NetRoute -RemoteIPAddress 10.10. …" gives a route that uses the correct storage/cluster adapter. I’ve checked the outputs of "ipconfig /all", "route PRINT" and "arp -a" and all are as expected, so not a trivial network misconfig - I guess. With the exception, that I don’t understand the role of the "Microsoft Failover Cluster Virtual Adapter" with a self-assigned IP address.

    Since these connection attempts via the wrong interface are creating 10,000 alerts per day in our central firewall monitoring system, I unfortunately cannot just ignore this error,

    If you are getting the "30803" event as well, I would appreciate it if you could run a network trace and lookout for failed connections. For the network trace I’m using:

    New-NetEventSession -Name 'foo'

    Add-NetEventPacketCaptureProvider -SessionName 'foo' -Level 4 -CaptureType Physical

    Start-NetEventSession 'foo'


    Stop-NetEventSession 'foo'

    Remove-NetEventSession 'foo'

    Use "Microsoft Message Analyzer" to look at the created etl-file.

    Im creating this new thread, since a related thread seems stale:

    pondělí 12. června 2017 12:09

Všechny reakce