Printing slow after IP schema change
We were running out of IP addresses on our Class C network and switched to Class B. Initially I researched and saw articles that were againsts this due to broadcast traffic. But they said each subnet shouldn't be larger than 500 hosts. We only have about 150 hosts on our network and are already seeing a slow down. Could this still be related to broadcast traffic even though we only have 150 hosts? I turned on WireShark (packet sniffer) and immediately saw loads of broadcast traffic being sent around. But I'm not sure how to gauge whether or not this broadcast traffic I'm observing is high enough to cause this kind of slow down. We are using HP ProCurve 2810-48G switches. Any ideas?
March 22nd, 2011 11:37am

There are a lot of variables to consider here so it's difficult to say whether broadcast traffic is specifically to blame. First, if you only have 150 hosts I don't see any need to throw them all into one giant subnet that can accommodate up to 65,534 hosts. They could have easily been left in the same /24 network. Second, simply altering the mask length doesn't cause more broadcast traffic if the number of hosts hasn't changed. Third, as the number of hosts increases (and you subsequently add more layer 2 switches) you must be cognizant of your layer 2 topology. Depending on how those switches are cabled together, i.e. are they daisy-chained, are their loops, is spanning-tree running and putting specific ports in a blocking state causing sub-optimal switching paths, etc, you could have introduced a bottle-neck somewhere that is being perceived as "slowness" when specific hosts attempt to transfer files or otherwise access the network. My advice would be to rethink your current switching infrastructure, check for high utilization on inter-switch links (if you are saturating specific links you could always use link-aggregation to increase the bandwidth between two switches as a stop-gap measure), and finally plan to create some VLANs and segregate your hosts into smaller broadcast domains. This will reduce the distance traffic like ARP needs to travel (from a switching perspective) and how far all those multicast neighbor solicitation (amongst others) messages will be sent if you're running IPv6 as well.Matt W. CCNP, CCSP, CCDA, RHCT, MCSE, MCSA, MCP+I, A+
Free Windows Admin Tool Kit Click here and download it now
March 22nd, 2011 1:28pm

I've narrowed the problem further. Our network is not slow at all. Direct pings to specific machines come back fine. Also, the only slow down we are noticing is with printing. However, if I add a network printer locally to my machine (NOT through the print server), it prints just fine to it. But if it has to go through the print server, it takes a while. We added print services to a separate box and printed to it, it went through fine. So the issue appears to be isolated to our domain controller (which is also our print server). This appears to have become noticeable after our IP schema change. We don't want to just move the print services to another box. I'd like to find out why our print server would be affected after the IP schema change. Any ideas?
March 22nd, 2011 2:42pm

Also, we noticed that when connecting to a file share that is hosted through a name space, it takes a while to connect. If the path is changed to a direct UNC path, it goes through fine. It appears that whenever the share has to be relayed through the domain controller, the slow down occurs. So it appears that something within the general sharing is affecting the speed of both file serving through name spaces and print serving as well. And this became apparent after switching to a class B network. So on the domain controller, there is something in common that both file and print sharing use that were affected by the IP schema change.
Free Windows Admin Tool Kit Click here and download it now
March 22nd, 2011 3:10pm

Ok so I discovered that File Sharing is not affected at all. I was under the impression because when accessing all the shares via name space (domain.local), it was slow. But that was because it's trying to pull all of the printers. I was able to verify this by connecting to name space shares directly and seeing them connect without issue. So it appears that the print serving functionality is the only thing that is slow. If you send a print job from the print server to a printer installed on it, it goes through fine. But if you send a print job to it from a workstation, it's slow. Once again, this issue became apparent after our IP address schema change.
March 22nd, 2011 4:12pm

Over the weekend we switched from a class C network to Class B. We only have 150 hosts. Since then, printing from our print server has become slow. Everything else is working ok. If you add the network printer directly to your workstation, it prints fine. If you send a print job directly from the server to the printer installed on it, it works fine. But if a print job has to go through a share to then print, it's really slow. The issue appears to be isolated to our domain controller. If you add a printer being hosted from another machine, the print job goes through fine. This became apparent right after our IP schema change. Any ideas? We ruled out network congestion or any issues relating to broadcast.
Free Windows Admin Tool Kit Click here and download it now
March 22nd, 2011 4:19pm

Simply switching your IP scheme's subnet mask (moving from a C to a B) would not make the network any slower if you didnt add any additional hosts. If you had 1 C before and now you have 1 B, then your broadcast domain has not changed. Did you make any other changes to your switches (duplex settings?), cabling, etc...? If you have the printer defined on the DC, you may want to run some performance monitoring on the DC, packet captures, check the switch port statistics, etc... It sounds like you already localized the problem to that specific host. EDIT:: Just noticed that this is a duplicate post. You should stick to one thread... http://social.technet.microsoft.com/Forums/en-US/winserverPN/thread/bbbbc97d-832f-4fe4-8d3b-886175cd9301 Visit: anITKB.com, an IT Knowledge Base.
March 22nd, 2011 7:39pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics