Re: [cifs-protocol] MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334
Hi Jeff, I didn't see a response to my previous request. It's not clear to us what you are looking for here. Having a single netname for multiple nodes sounds similar to a SOFS configuration. We use DNS to enumerate the IP addresses. Windows uses witness for the following: - If networking interface on the server has changed then hint client about that so it can query list of new interfaces sooner than default 10 minutes poling interval. Do you mean the witness GetInterfaceList() call or the FSCTL_QUERY_NETWORK_INTERFACE_INFO used for smb3 multichannel? - If cluster node is down then notify client about that so it can disconnect from the downer and connect to some other node, before TCP/IP timeout expires. Would work only of cluster can detect downer faster than TCP/IP timeout. I'll refer to this below with RESOURCE_CHANGE. - If cluster has asymmetric storage (one node can process IOs faster than the others) then hint client that it should move to that node. In Windows if Direct IO is possible then storage connectivity is considered symmetrical and we prefer load balancing clients across all cluster nodes. If we are in File System Redirected IO (same blog) then storage connectivity is asymmetrical and client is advised to move to the node that has file system mounted to avoid double hop.. I'll refer to this below with CLIENT_MOVE_NOTIFICATION. All notifications are advisory. Could you clarify your expectations for the doc and tell us more about what you're trying to accomplish? I'll try... This is in regards to your question: Question 9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events. E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName So far I found this in my testing: A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_UNAVAILABLE will trigger a reconnect, but the RESOURCE_CHANGE.name content is completely ignored, currently I'm sending the ip address string that's no longer available, it's mainly in order to make it easier to read wireshark traces or logs. It could also be "SoME RandOM-StriNg!!!". A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_AVAILABLE also doesn't have any notable effect. I think this should be documented somewhere. If needed I an create network captures for it. Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single InterfaceGroupName for all nodes? The line/question above is no longer useful, as I found how to get the client react on RESOURCE_CHANGE with WITNESS_RESOURCE_STATE_UNAVAILABLE. But by testing I found that a CLIENT_MOVE_NOTIFICATION is ignored if the list of ip addresses if the also contains the ip address that was given to the Register[Ex]() call. I have only tested the case where all ip addresses have IPADDR_ONLINE set, but I haven't tested if it's needed or what happens with IPADDR_OFFLINE or when the given ip address if not part of the set that is resolved by dns and/or isn't available. I think this should be documented somewhere. If needed I an create network captures for it. I'm ready to file document change requests to explain the processing, but I don't fully understand your example question. I hope the above makes it clearer. Resource Change notifications are used when resources such as disks change status The point is that as noted above it seems RESOURCE_CHANGE.name seems to be completely ignored. while Client Move notifications are used when a node has gone down and the client needs to move to another node. Yes, I found what I needed, but these details should be documented somewhere in order to let server implementers know how to drive a windows client to a desired/expected behavior. They aren't interchangeable. Could you clarify your question? I got it thanks! metze ___ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334
Hi Stefan, Could you let me know when you think you'll have time to provide more information as requested below? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Jeff McCashland (He/him) Sent: Monday, December 18, 2023 2:49 PM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: RE: MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334 Hi Stefan, I didn't see a response to my previous request. It's not clear to us what you are looking for here. Having a single netname for multiple nodes sounds similar to a SOFS configuration. We use DNS to enumerate the IP addresses. Windows uses witness for the following: - If networking interface on the server has changed then hint client about that so it can query list of new interfaces sooner than default 10 minutes poling interval. - If cluster node is down then notify client about that so it can disconnect from the downer and connect to some other node, before TCP/IP timeout expires. Would work only of cluster can detect downer faster than TCP/IP timeout. - If cluster has asymmetric storage (one node can process IOs faster than the others) then hint client that it should move to that node. In Windows if Direct IO is possible then storage connectivity is considered symmetrical and we prefer load balancing clients across all cluster nodes. If we are in File System Redirected IO (same blog) then storage connectivity is asymmetrical and client is advised to move to the node that has file system mounted to avoid double hop. All notifications are advisory. Could you clarify your expectations for the doc and tell us more about what you're trying to accomplish? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Jeff McCashland (He/him) Sent: Tuesday, November 28, 2023 11:00 AM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334 Hi Stefan, This is in regards to your question: Question 9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events. E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single InterfaceGroupName for all nodes? I'm ready to file document change requests to explain the processing, but I don't fully understand your example question. Resource Change notifications are used when resources such as disks change status, while Client Move notifications are used when a node has gone down and the client needs to move to another node. They aren't interchangeable. Could you clarify your question? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Tom Jebo Sent: Tuesday, November 7, 2023 9:47 AM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: RE: [EXTERNAL] Trying to let a Windows client use MS-SWN against a samba cluster - TrackingID#2311070040009453 [dochelp to bcc] [support mail to cc] Hi Stefan, Thanks for your request regarding MS-SWN (various questions). One of the Open Specifications team members will respond to assist you. In the meantime, we’ve created the following cases to track this request (I've added the first case to the subject so initially, please leave that case number in the subject when communicating with our team about this request. Q1: 2311070040009453 Q2: 2311070040009696 Q3: 2311070040009793 Q4: 2311070040009927 Q5: 2311070040010003 Q6: 2311070040010094 Q7: 2311070040010182 Q8: 2311070040010257 Q9: 2311070040010334 Q10: 2311070040010406 Q11: 2311070040010486 Best regards, Tom Jebo Microsoft Open Specifications Support -Original Message- From: Stefan Metzmacher Sent: Tuesday, November 7, 2023 6:30 AM To: Interoperability Documentation
Re: [cifs-protocol] MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334
Hi Stefan, I didn't see a response to my previous request. It's not clear to us what you are looking for here. Having a single netname for multiple nodes sounds similar to a SOFS configuration. We use DNS to enumerate the IP addresses. Windows uses witness for the following: - If networking interface on the server has changed then hint client about that so it can query list of new interfaces sooner than default 10 minutes poling interval. - If cluster node is down then notify client about that so it can disconnect from the downer and connect to some other node, before TCP/IP timeout expires. Would work only of cluster can detect downer faster than TCP/IP timeout. - If cluster has asymmetric storage (one node can process IOs faster than the others) then hint client that it should move to that node. In Windows if Direct IO is possible then storage connectivity is considered symmetrical and we prefer load balancing clients across all cluster nodes. If we are in File System Redirected IO (same blog) then storage connectivity is asymmetrical and client is advised to move to the node that has file system mounted to avoid double hop. All notifications are advisory. Could you clarify your expectations for the doc and tell us more about what you're trying to accomplish? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Jeff McCashland (He/him) Sent: Tuesday, November 28, 2023 11:00 AM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334 Hi Stefan, This is in regards to your question: Question 9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events. E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single InterfaceGroupName for all nodes? I'm ready to file document change requests to explain the processing, but I don't fully understand your example question. Resource Change notifications are used when resources such as disks change status, while Client Move notifications are used when a node has gone down and the client needs to move to another node. They aren't interchangeable. Could you clarify your question? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Tom Jebo Sent: Tuesday, November 7, 2023 9:47 AM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: RE: [EXTERNAL] Trying to let a Windows client use MS-SWN against a samba cluster - TrackingID#2311070040009453 [dochelp to bcc] [support mail to cc] Hi Stefan, Thanks for your request regarding MS-SWN (various questions). One of the Open Specifications team members will respond to assist you. In the meantime, we’ve created the following cases to track this request (I've added the first case to the subject so initially, please leave that case number in the subject when communicating with our team about this request. Q1: 2311070040009453 Q2: 2311070040009696 Q3: 2311070040009793 Q4: 2311070040009927 Q5: 2311070040010003 Q6: 2311070040010094 Q7: 2311070040010182 Q8: 2311070040010257 Q9: 2311070040010334 Q10: 2311070040010406 Q11: 2311070040010486 Best regards, Tom Jebo Microsoft Open Specifications Support -Original Message- From: Stefan Metzmacher Sent: Tuesday, November 7, 2023 6:30 AM To: Interoperability Documentation Help Cc: cifs-protocol@lists.samba.org Subject: [EXTERNAL] Trying to let a Windows client use MS-SWN against a samba cluster Hi DocHelp, I'm currently implementing MS-SWN for samba in order to allow clients to move to a different network interface or cluster node if a specific interface or a complete cluster node gets offline. In a Samba cluster we have multiple nodes, but just a single netname for all of them, so there's only a single computer with it's sAMAccountName in active directory. But each node can have multiple ip addresses, which may move around between nodes, but some can be node local. Now my goal is to let a Windows client use the witness service in order to get notified about ip addresses going down, because the interface
[cifs-protocol] MS-SWN Q9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY - TrackingID#2311070040010334
Hi Stefan, This is in regards to your question: Question 9: Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives an RESP_ASYNC_NOTIFY, but there's no specification on how the individual witness registrations handle specific notification events. E.g. based on the different posibilities for RESOURCE_CHANGE.ResourceName Is a CLIENT_MOVE_NOTIFICATION a better choice when using a single InterfaceGroupName for all nodes? I'm ready to file document change requests to explain the processing, but I don't fully understand your example question. Resource Change notifications are used when resources such as disks change status, while Client Move notifications are used when a node has gone down and the client needs to move to another node. They aren't interchangeable. Could you clarify your question? Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 -Original Message- From: Tom Jebo Sent: Tuesday, November 7, 2023 9:47 AM To: metze Cc: cifs-protocol@lists.samba.org; Microsoft Support Subject: RE: [EXTERNAL] Trying to let a Windows client use MS-SWN against a samba cluster - TrackingID#2311070040009453 [dochelp to bcc] [support mail to cc] Hi Stefan, Thanks for your request regarding MS-SWN (various questions). One of the Open Specifications team members will respond to assist you. In the meantime, we’ve created the following cases to track this request (I've added the first case to the subject so initially, please leave that case number in the subject when communicating with our team about this request. Q1: 2311070040009453 Q2: 2311070040009696 Q3: 2311070040009793 Q4: 2311070040009927 Q5: 2311070040010003 Q6: 2311070040010094 Q7: 2311070040010182 Q8: 2311070040010257 Q9: 2311070040010334 Q10: 2311070040010406 Q11: 2311070040010486 Best regards, Tom Jebo Microsoft Open Specifications Support -Original Message- From: Stefan Metzmacher Sent: Tuesday, November 7, 2023 6:30 AM To: Interoperability Documentation Help Cc: cifs-protocol@lists.samba.org Subject: [EXTERNAL] Trying to let a Windows client use MS-SWN against a samba cluster Hi DocHelp, I'm currently implementing MS-SWN for samba in order to allow clients to move to a different network interface or cluster node if a specific interface or a complete cluster node gets offline. In a Samba cluster we have multiple nodes, but just a single netname for all of them, so there's only a single computer with it's sAMAccountName in active directory. But each node can have multiple ip addresses, which may move around between nodes, but some can be node local. Now my goal is to let a Windows client use the witness service in order to get notified about ip addresses going down, because the interface link or a whole node gets offline. In order to archive that I need to understand the exact client behavior implemented in the Windows clients (also with possible differences of various Windows versions). However this is hard from just reading the existing docs... MS-SWN "3.2 Witness Client Details" doesn't contain any detail for the logical processing, e.g. - 3.2.4.1 Application Requests Witness Register doesn't say that WITNESS_INTERFACE_INFO.InterfaceGroupName is that name used as part of the servicePrincipalName (after being prefixed by 'CIFS/') passed to the authentication layer (spnego, kerberos, ntlm), but I'm seeing this behavior from a Windows 2022 server as client. In older version (Windows 2012) I saw that the principal was requested by the method from MS-RPCE 2.2.1.3.4 rpc_mgmt_inq_princ_name. Question 1: Can you please update this with a product behavior note reflecting the reality with all Windows versions. - 3.2.4.2 Application Requests Witness Event Notification only says: ... The status and any received RESP_ASYNC_NOTIFY result obtained from the server in the previous step MUST be returned to the caller. - 3.2.4.3 Application Requests Witness UnRegister Has the following notable section: ... or if the WitnessRegistration.WitnessNotifyRequest is TRUE, the client MUST stop processing and return an implementation-defined local error to the caller. So it seems with a pending AsyncNotify request the Unregister seems to be skipped. With that I'd expect the core logic/behavior of a Windows client being specified in MS-SMB2, when I look there I found the following 3.2.5.2 Receiving an SMB2 NEGOTIATE Response ... If SMB2_GLOBAL_CAP_PERSISTENT_HANDLES is set in the Capabilities field of the SMB2 NEGOTIATE Response, the client SHOULD invoke the event as specified in [MS-SWN] section 3.2.4.1 by providing Connection.ServerName as Netname
