SMB clients hitting jumbo NFS dynamic IP pool meant for nfs traffic

[avinash patil]

Hi Isilon users,

I have a unique situation. We have 3 different IP pools, say apj.isilon.com(for SMB connections with static IPs), nfs.apj.isilon.com(dynamic ip for unix mounts) and a jumbo.nfs.apj.isilon.com(for jumbo nfs mounts). However we noticed that SMB users are often not able access to share when they try accessing share  '\\apj.isilon.com\smbdata'.  They have to reboot a few times and it suceeds. We notced in firwall that whenever they are hitting to jumbo Ips they face disconnect, it succeeds share access when they hit the normal fqdn meant for smb (apj.isilon.com). By looking a t firewall polices  we feel firewall is behaving normally, It is rightly restricting access through all request that are outside of 'apj.isilon.com' IP range. However we are not able to figure out why even the  satic IP pool 'apj.isilon.com' is even resolving to a dynamic or a jumbo dymanic IP or who is redirecting it to a jumbo or a nfs IP address. Has anyone seen this kind of behaviour ? 

[Hector Barrera]

When doing nslookup from the windows clients to the smb smart connect access zone, do you only hit the correct IPs?

On Wed, Jan 24, 2024, 10:30 PM avinash patil <avinash...@gmail.com> wrote:

Hi Isilon users,

I have a unique situation. We have 3 different IP pools, say apj.isilon.com(for SMB connections with static IPs), nfs.apj.isilon.com(dynamic ip for unix mounts) and a jumbo.nfs.apj.isilon.com(for jumbo nfs mounts). However we noticed that SMB users are often not able access to share when they try accessing share  '\\apj.isilon.com\smbdata'.  They have to reboot a few times and it suceeds. We notced in firwall that whenever they are hitting to jumbo Ips they face disconnect, it succeeds share access when they hit the normal fqdn meant for smb (apj.isilon.com). By looking a t firewall polices  we feel firewall is behaving normally, It is rightly restricting access through all request that are outside of 'apj.isilon.com' IP range. However we are not able to figure out why even the  satic IP pool 'apj.isilon.com' is even resolving to a dynamic or a jumbo dymanic IP or who is redirecting it to a jumbo or a nfs IP address. Has anyone seen this kind of behaviour ? 

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/28cc80b0-d978-4cb6-971f-1d08f82e5ecen%40googlegroups.com.

[avinash patil]

Yes, nslookup hits only to correct IPs.

> To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/CAF0ZAj%3D-dnonP5o0220q3ZLoRUfWidMMWh%3DCDonW-74m3LepXQ%40mail.gmail.com.

[Youssef GHORBAL]

Hello,

 My educated guess would be that you are most likely hitting an SMBv3 multichannel pitfall on OneFS. In fact, when an SMBv3 multichannel is stanlished the isilon node advertises *all* the nodes IP addresses those. So if through your SMB session you hit node X and X happens to be part of multiple pools, all IP adresses of the host will be sent verbatim, without any further filtering,  to the client. If the client, then tries to establish multiple SMB sessions towards those IPs adresses (the IP selection on the client side is OS dependent) and this is where you see your SMB clients hitting NFS IP pool.

 On a windows box you can get multichannel status through Get-SmbMultichannelConnection (on a mac smbutil multichannel -a)

 We’ve been in that situation a couple years ago. Dell/Isilon/Powerscal did not seem to care when we reported the issue back then. We ended up disabling SMBv3 multichannel alltogether on the cluster (there is a gconfig for that if I recall correctly)

 Best luck!

Youssef

On 25 Jan 2024, at 07:30, avinash patil <avinash...@gmail.com> wrote:

Hi Isilon users,

I have a unique situation. We have 3 different IP pools, say apj.isilon.com(for SMB connections with static IPs), nfs.apj.isilon.com(dynamic ip for unix mounts) and a jumbo.nfs.apj.isilon.com(for jumbo nfs mounts). However we noticed that SMB users are often not able access to share when they try accessing share  '\\apj.isilon.com\smbdata'.  They have to reboot a few times and it suceeds. We notced in firwall that whenever they are hitting to jumbo Ips they face disconnect, it succeeds share access when they hit the normal fqdn meant for smb (apj.isilon.com). By looking a t firewall polices  we feel firewall is behaving normally, It is rightly restricting access through all request that are outside of 'apj.isilon.com' IP range. However we are not able to figure out why even the  satic IP pool 'apj.isilon.com' is even resolving to a dynamic or a jumbo dymanic IP or who is redirecting it to a jumbo or a nfs IP address. Has anyone seen this kind of behaviour ? 

--

[avinash patil]

Thanks Youssef. I am feeling it could be a similar situation with smb
multichanneling. Would there be any impact if I diable smb3
multichannel feature in SMB settings ?

Thank you!
Avinash

> To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/5F16F6F5-BB5C-4127-B620-683F5E0408E1%40pasteur.fr.

[Youssef GHORBAL]

If you have client hosts levereging SMBv3 mutichannel, I guess that you'll see a throughput hit.
Personnaly, my setup was a vast majority of campus client hosts single attached with NICs not supporting SSR, so Multichannel was not effective even if it was negociated in SMBv3 session establishement.

Youssef
-----------------

> On 25 Jan 2024, at 13:11, avinash patil <avinash...@gmail.com> wrote:
>
> Thanks Youssef. I am feeling it could be a similar situation with smb
> multichanneling. Would there be any impact if I diable smb3
> multichannel feature in SMB settings ?
>
> Thank you!
> Avinash
>
> On Thu, Jan 25, 2024 at 1:23 PM Youssef GHORBAL
> <youssef...@pasteur.fr> wrote:
>>
>> Hello,
>>
>> My educated guess would be that you are most likely hitting an SMBv3 multichannel pitfall on OneFS. In fact, when an SMBv3 multichannel is stanlished the isilon node advertises *all* the nodes IP addresses those. So if through your SMB session you hit node X and X happens to be part of multiple pools, all IP adresses of the host will be sent verbatim, without any further filtering, to the client. If the client, then tries to establish multiple SMB sessions towards those IPs adresses (the IP selection on the client side is OS dependent) and this is where you see your SMB clients hitting NFS IP pool.
>>
>> On a windows box you can get multichannel status through Get-SmbMultichannelConnection (on a mac smbutil multichannel -a)
>>
>> We’ve been in that situation a couple years ago. Dell/Isilon/Powerscal did not seem to care when we reported the issue back then. We ended up disabling SMBv3 multichannel alltogether on the cluster (there is a gconfig for that if I recall correctly)
>>
>> Best luck!
>>
>> Youssef
>>
>> On 25 Jan 2024, at 07:30, avinash patil <avinash...@gmail.com> wrote:
>>
>> Hi Isilon users,
>> I have a unique situation. We have 3 different IP pools, say apj.isilon.com(for SMB connections with static IPs), nfs.apj.isilon.com(dynamic ip for unix mounts) and a jumbo.nfs.apj.isilon.com(for jumbo nfs mounts). However we noticed that SMB users are often not able access to share when they try accessing share '\\apj.isilon.com\smbdata'. They have to reboot a few times and it suceeds. We notced in firwall that whenever they are hitting to jumbo Ips they face disconnect, it succeeds share access when they hit the normal fqdn meant for smb (apj.isilon.com). By looking a t firewall polices we feel firewall is behaving normally, It is rightly restricting access through all request that are outside of 'apj.isilon.com' IP range. However we are not able to figure out why even the satic IP pool 'apj.isilon.com' is even resolving to a dynamic or a jumbo dymanic IP or who is redirecting it to a jumbo or a nfs IP address. Has anyone seen this kind of behaviour ?
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.

>> To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/isilon-user-group/28cc80b0-d978-4cb6-971f-1d08f82e5ecen*40googlegroups.com__;JQ!!JFdNOqOXpB6UZW0!tgyxbZVMYOGFK6pTbj56jvaWKzb_t0iI4qqX0AG3ijzfEheZ5i4bafjspKD-5Y9gPmJ4s4rg6vUp48TpdKJgQJ9Ifqf7LiuD$ .

>>
>> --
>> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.

>> To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/isilon-user-group/5F16F6F5-BB5C-4127-B620-683F5E0408E1*40pasteur.fr__;JQ!!JFdNOqOXpB6UZW0!tgyxbZVMYOGFK6pTbj56jvaWKzb_t0iI4qqX0AG3ijzfEheZ5i4bafjspKD-5Y9gPmJ4s4rg6vUp48TpdKJgQJ9IfughGHME$ .

>
> --
> You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.

> To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/isilon-user-group/CAN09CHOPMfCph3MKi*3DqkM_2JZ-*2BKVhQQQvafHbuxvn*2By5JpFAw*40mail.gmail.com__;JSUlJQ!!JFdNOqOXpB6UZW0!tgyxbZVMYOGFK6pTbj56jvaWKzb_t0iI4qqX0AG3ijzfEheZ5i4bafjspKD-5Y9gPmJ4s4rg6vUp48TpdKJgQJ9IfuY5q-ZQ$ .