2

I googled but cant find anything about this. We have a diskless environment where our 28 client boots from ISCSI based diskless program called ccboot.

Now, the clients also need to access file share from a different win 2012 server using SMB protocol.

Problem is, the SMB traffic is quite big, usually the data transferred is in 2-4 GB size. And this causes some clients to reboot, maybe because 1GB environment is not enough to support this kind of scenario?

I'm not 100% sure that SMB traffic is causing the reboots, But i want to try limiting SMB / CIFS traffic from client side, is it possible? Client is running 1703 windows 10.

I have limited the SMB traffic from SMB server side using this method http://fixmyitsystem.com/2013/12/QOS01.html, but it doesn't seem to help, random reboot still happens.

Edit : i'm using these Iscsi server 10g > CRS226-24G-2S+RM > Tp link sg2452 The clients are connected to both switches, smb server is connected to tp link

I tried editing DSCP priority and schedule mode.. Schedule is saved, but DSCP priority always returns to blank value, even after pressing apply and save config.. any idea why? Sorry im completely new at managed switch.. managed switch DSCP

3

You can use a powerShell command Set-SmbBandwidthLimit to limit the SMB bandwidth

  • This is what i did on my smb server, i lowered the value until the most acceptable value for client, but reboot still occurs.. lowering it further would not be ideal for the clients.. running it on clients might also help but i googled and it doesnt seem to be compatible with win 10 – denywinarto Nov 6 '17 at 12:51
3

Running iSCSI and normal, high-volume traffic on the same infrastructure can be a problem.

The SMB traffic may be suppressing the iSCSI access to the system disk which at least for Windows is a major problem.

The best apporach is to physically separate the traffic (VLANs & interconnects). If you can't and can't at least widen interconnect bottlenecks (core to access switches) you might want to prioritize traffic, so that iSCSI is preferred and doesn't get dropped. If you post details to your network, layout and hardware configurations we might be able to figure out how to do the prioritization.

edit after your comment:

The TL-SG2452 is a poor choice for iSCSI - it's only got 1.5 MB buffer. With a single GbE link, this buffer is exhausted in just .01 s...

Given you're running everything on a single link without VLANs on the client side(?), and storage & client are likely not using DSCP, you need to prioritize by source port, i.e. your iSCSI storage uplink. You'll probably want DSCP 0x0a (high priority, low drop probability). I'd set schedule mode to WRR-Mode and use TC2 for iSCSI, giving a 4:1 priority.

  • I presume the prioritization is done on client side? And how would i do this on windows 10 client using realtek nic? – denywinarto Nov 6 '17 at 7:47
  • No. The prioritization needs to be done in the network, on the switches. When upstream traffic is also a problem, then you'd need to configure it on each client as well. – Zac67 Nov 6 '17 at 11:48
  • As long as you do VLANs and QoS for a proper traffic separation you'll be fine! – BaronSamedi1958 Nov 6 '17 at 12:03
  • Hmm i'm gonna look into this again, my tp link switch sg2452 is supposed to be capable for this, but i had some troubles configuring it in the past – denywinarto Nov 6 '17 at 12:54
  • I forgot to mention i also got crs mikrotik 10g switch coming from iscsi server. I have updated my question with complete specs.. Any better switch recommendation? Managed switch is kinda rare in my country – denywinarto Nov 6 '17 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.