Slow : stacked switches and Pfsense : SOLVED
-
Hello Supermule, thanks for taking the time to read my post.
These things are low-end unmanaged switches with no dedicated stacking port. The original network installer has been running them stacked as I've showed them in my diagram, first port facing_back-from_left. They've been running fine like that for a number of years.
-
Yes, but can you pls give us the make and nr on the switches…? 8)
Then we might have a clue...
-
SureCom EP-808SX
-
http://forums.whirlpool.net.au/forum-replies-archive.cfm/592025.html
Seriously…. Find other switches..... It could be related to heat and pure performance, related to the throughput of the Pfsense box.
Look at HP 1400-8g or -24g as replacement unit. Cheap and very stable....
-
Your recommendations are much appreciated Supermule - a 16 or 24 port switch is what I will recommend.
On that note, whilst I'm aware of the FreeBSD hardware compatibility list, do you recommend any particular model of NIC, for pfsense?
On the lan side I'm currently using : http://www.3com.com/products/en_US/detail.jsp?tab=support&sku=3C905C-TX-M&pathtype=supportI had hoped it would be some obscure setting in pfsense that could resolve the issue fast and cheaply. I had already eliminated heat and throughput issues by first powering down the devices for 10 minutes - then connecting only a single host on switch(B).
Thanks again.
-
Your recommendations are much appreciated Supermule - a 16 or 24 port switch is what I will recommend.
On that note, whilst I'm aware of the FreeBSD hardware compatibility list, do you recommend any particular model of NIC, for pfsense?
On the lan side I'm currently using : http://www.3com.com/products/en_US/detail.jsp?tab=support&sku=3C905C-TX-M&pathtype=supportI had hoped it would be some obscure setting in pfsense that could resolve the issue fast and cheaply. I had already eliminated heat and throughput issues by first powering down the devices for 10 minutes - then connecting only a single host on switch(B).
Thanks again.
That's easy - Intel network chipsets are a safe bet as long as it isn't so new as not to have proper working drivers.
-
I would recommend swapping the cable that links the two switches together. It may be that they have not auto-negotiated properly and as they are unmanaged your only indication will be an LED on the switch. One end may have negotiated to 100/full but the other may have negotiated to 100/half. Make sure you use a cross cable to rule out auto-MDIX issues and I can tell you now this is nothing to do with pfsense this is a layer2 issue.
What is the speed like between PC's attached to the slow switch and PC's on the quick one?
All the best…
-
That's easy - Intel network chipsets are a safe bet as long as it isn't so new as not to have proper working drivers.
Thanks for the tip about intel NIC's, will go with either Intel PRO100/1000 GT or Intel PRO100/1000 MT.
-
I would recommend swapping the cable that links the two switches together. It may be that they have not auto-negotiated properly and as they are unmanaged your only indication will be an LED on the switch. One end may have negotiated to 100/full but the other may have negotiated to 100/half. Make sure you use a cross cable to rule out auto-MDIX issues and I can tell you now this is nothing to do with pfsense this is a layer2 issue.
What is the speed like between PC's attached to the slow switch and PC's on the quick one?
All the best…
Super! I was not previously aware of either of these essential connectivity issues, thank you twice.
In the case of the auto-negotiation issue I can only think that, pfsense with the card I have, is either set to auto-negotiate while others are not(I don't think so because switches worked with a modern fast adsl router) or vice versa (more likely the card is set/bug to a manual duplex mode and its either going to half-duplex or/and 10 instead of 100bits).
It has to be something to do with the introduction of the pfsense box(hardware and/or software) because the setup was working fine with a direct link to the adsl router.I'll definitely get a cross-over cable and test it instead of the straight-through. I will also assume that this is what you meant when you wrote, " I would recommend swapping the cable that links the two switches together.", just before you introduced the auto-negotiation issue.
As for the speed between the PC's I did not test it at the time - but on the base of your post I have a number of diagnostic tests planned, that being one of them.
Thanks again for your highly informative post.
-
The cross cable needs to go between the two switches not pfsense and switch A.
Also you shouldn't assume its pfsense just because it is new, unless you can put back the old modem and the speed returnes, also switch B may have been power-cycled recently.
A simple test would be to do a file transfer between two PC's attached to Switch A and then do one between two PC's attached to switch A and B, if all three PC's are in the same network segment and subnet the speeds should be about the same, If not try re-patching the uplink to a new port on switch B after having already ruled out the cable.Regards
-
cheesyboofs!
Problem solved!
Due to the nature of the environment I had limited time to perform thorough experiments, so I don't have anything conclusive to report, other then I have the system working.
What I did:
-I changed card to Intel Pro 100/1000 GT.
-I added a cross-over cable and changed cable port placement to new corresponding ports(8thport(A) to 8thport(B).
-I first connected the switches then turned them on, with nothing else connected - then I added the pfsense box, which had also been turned off.At this point the whole thing works fine, clients are able to connect to captive portal quickly and download files at 2-300 kbytes, from either switch.
Another change was the uninstallation of squid as it turned out we didn't need it anyway and it allowed a means to bypass the captive portal easily."Also you shouldn't assume its pfsense just because it is new, unless you can put back the old modem and the speed returnes…"
Yep that's what we did. If I had time to peform experiments I think I would have found it was the old 3com card, that caused negotiation issues, that probably muddled the auto-midx mechanism.Can't thank you enough cheesyboofs, solution to the problem and so many nice tips and tricks