 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, So I am still on the hunt for the network delays I am seeing - so
some questions about network throughput.
My Hardware
Windows Domain Server - (1) 1 GB ethernet
File Server - (2) 1GB ethernet (bonded to share load into the same switch)
Patch panel and patch cords are CAT5e
In Wall wiring is combination of CAT5 and CAT5e
Switch is DELL PowerConnect 2724 running in a non-managed mode
about 10 users on the network
What slowdowns might this kind of setup cause?
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/12/2011 15:25, Tom Austin a écrit :
> OK, So I am still on the hunt for the network delays I am seeing - so
> some questions about network throughput.
>
> My Hardware
>
> Windows Domain Server - (1) 1 GB ethernet
>
> File Server - (2) 1GB ethernet (bonded to share load into the same switch)
>
> Patch panel and patch cords are CAT5e
>
> In Wall wiring is combination of CAT5 and CAT5e
>
> Switch is DELL PowerConnect 2724 running in a non-managed mode
>
> about 10 users on the network
>
>
> What slowdowns might this kind of setup cause?
>
How are the lights blinking on the Dell 2724 ?
(if it's a storm or a huge requesting of network resource, some should
blink very fast).
Now, there is other thing that storm in the network to cause a slowdown:
trying to reach/find inaccessible resource and awaiting time-out before
resorting to another solution. In such case the network is rather calm.
(and the light blinks slowly)
In theory Cat5 cable are not suitable for 1G. (cat5e is ok, but not
strict 5)
Have you tested "unloaded network" ? (Keep the WDS & fileserver, as well
as the switch, 1 user only (all other users are disconnected from the
switch). Does it work better ? or same ? or worse ?
Adding 1 user at a time ?
Putting back the Internet connection ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2011 10:23 AM, Le_Forgeron wrote:
> Le 21/12/2011 15:25, Tom Austin a écrit :
>> OK, So I am still on the hunt for the network delays I am seeing - so
>> some questions about network throughput.
>>
>> My Hardware
>>
>> Windows Domain Server - (1) 1 GB ethernet
>>
>> File Server - (2) 1GB ethernet (bonded to share load into the same switch)
>>
>> Patch panel and patch cords are CAT5e
>>
>> In Wall wiring is combination of CAT5 and CAT5e
>>
>> Switch is DELL PowerConnect 2724 running in a non-managed mode
>>
>> about 10 users on the network
>>
>>
>> What slowdowns might this kind of setup cause?
>>
>
> How are the lights blinking on the Dell 2724 ?
> (if it's a storm or a huge requesting of network resource, some should
> blink very fast).
>
Just making sure - a storm is bad
I'll keep an eye on the switch lights and try to have a look when
someone reports a problem.
Good idea.
> Now, there is other thing that storm in the network to cause a slowdown:
> trying to reach/find inaccessible resource and awaiting time-out before
> resorting to another solution. In such case the network is rather calm.
> (and the light blinks slowly)
>
So, I should label each 'computer' on the switch and look at everything
when there is a problem and pay attention to the 'problem' computer as well.
>
> In theory Cat5 cable are not suitable for 1G. (cat5e is ok, but not
> strict 5)
>
right - that's what I thought. The CAT5 is baked into the building so
it will be hard to replace.
But we can run a test with long patch cables to see if that helps.
> Have you tested "unloaded network" ? (Keep the WDS& fileserver, as well
> as the switch, 1 user only (all other users are disconnected from the
> switch). Does it work better ? or same ? or worse ?
>
We are going to try this next week when the office is pretty empty.
> Adding 1 user at a time ?
> Putting back the Internet connection ?
The main problem is not a small delay in getting a file - 10-15 seconds
can happen from time to time. But 5+ minutes is pretty bad.
Thanks for the tips.
Merry Christmas!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2011 8:45, Tom Austin wrote:
> The main problem is not a small delay in getting a file - 10-15 seconds can
> happen from time to time. But 5+ minutes is pretty bad.
On a gigabit network, that sounds like a long time to load a 5M file.
Do you do a lot of updates on the Linux server, like creating and deleting
thousands of files at a time? It's possible that the Linux server is just
locking up flushing its buffers if it has a lot of RAM. Sadly, I don't know
any sort of monitor that would actually tell you what's going on inside the
kernel of a Linux machine. (Anyone know what the equivalent of Performance
Monitor on Linux is?) If your file server has RAID, maybe there's a bad
spot on one of the disks and it retries a while before falling over to the
other disk? Maybe check through syslog records to see?
Check the domain server's event logs around the time of a problem, and see
if it's an authorization problem or something, where maybe you're waiting
for a new kerberos key to access the remote file and the domain server is
slow giving it out for some reason?
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/12/2011 18:00, Darren New nous fit lire :
> On 12/21/2011 8:45, Tom Austin wrote:
>> The main problem is not a small delay in getting a file - 10-15
>> seconds can
>> happen from time to time. But 5+ minutes is pretty bad.
>
> On a gigabit network, that sounds like a long time to load a 5M file.
On gigabit network, a 5M file which should transfer in about 4000
frames, should take less than 10s even at 1% of network usage, including
an acknowledge of each frame.
(1% of network: which means that even on a 10mbits, 10s is already large)
>
> Do you do a lot of updates on the Linux server, like creating and
> deleting thousands of files at a time? It's possible that the Linux
> server is just locking up flushing its buffers if it has a lot of RAM.
> Sadly, I don't know any sort of monitor that would actually tell you
> what's going on inside the kernel of a Linux machine. (Anyone know what
> the equivalent of Performance Monitor on Linux is?)
there is:
* text mode: top
* gnome : gnome-system-monitor
* kde : ksysguard
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2011 12:00 PM, Darren New wrote:
> On 12/21/2011 8:45, Tom Austin wrote:
>> The main problem is not a small delay in getting a file - 10-15
>> seconds can
>> happen from time to time. But 5+ minutes is pretty bad.
>
> On a gigabit network, that sounds like a long time to load a 5M file.
>
Agreed, but the occasional 'glitch' of 10-15 seconds is acceptable.
> Do you do a lot of updates on the Linux server, like creating and
> deleting thousands of files at a time? It's possible that the Linux
> server is just locking up flushing its buffers if it has a lot of RAM.
> Sadly, I don't know any sort of monitor that would actually tell you
> what's going on inside the kernel of a Linux machine. (Anyone know what
> the equivalent of Performance Monitor on Linux is?) If your file server
> has RAID, maybe there's a bad spot on one of the disks and it retries a
> while before falling over to the other disk? Maybe check through syslog
> records to see?
>
No updates, but a lot of large (5 MB) image files are being transferred
to and around the file system.
It is 32 bit - so only 4GB of physical ram with some extra swap just in
case.
It does have RAID - OS is RAID 1 on the software level, file drives are
RAID 1 on a 3Ware controller 2 mirrored sets as a logical volume.
> Check the domain server's event logs around the time of a problem, and
> see if it's an authorization problem or something, where maybe you're
> waiting for a new kerberos key to access the remote file and the domain
> server is slow giving it out for some reason?
>
That could be a very real possibility - and would bring our crappy
Windows domain server into question - like we want it to be :-)
This is good food for thought. I'll set up some tests that might help
flush some of this out.
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2011 12:38 PM, Le_Forgeron wrote:
>
> On gigabit network, a 5M file which should transfer in about 4000
> frames, should take less than 10s even at 1% of network usage, including
> an acknowledge of each frame.
> (1% of network: which means that even on a 10mbits, 10s is already large)
>
yes, agreed - but an occasional hiccup is tolerable so we didn't worry
about it. Now with more users and data maybe that hiccup 'error' is
being compounded.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-12-21 09:25, Tom Austin a écrit :
> OK, So I am still on the hunt for the network delays I am seeing - so
> some questions about network throughput.
>
> My Hardware
>
> Windows Domain Server - (1) 1 GB ethernet
>
Make sure the server NICs are hard-coded for 1 Gbps Full-duplex.
Gigabitethernet left in auto-detect mode can lead to funky things...
Make sure the switch ports facing the servers also have their speed and
duplex hardcoded, if possible.
> File Server - (2) 1GB ethernet (bonded to share load into the same switch)
>
How? Depending on the way it's set up, it can cause major problems with
the switch. Disconnect one of the patch cords and see if performance
improves. If it does, you had a loop between the two switch ports, and
the two NICs in your server. Either reconfigure your NICs to use
fail-over, or make sure "spanning-tree" is enabled on the switch ports
facing the server. Keep in mind that by doing that you will lose your
2Gbps aggregation speed and the second NIC will only be there to provide
a host-stanby.
> Patch panel and patch cords are CAT5e
>
Length? CAT5e specification says that desks-side patch cords must not
be longer than 3m (10ft), and that switch-side patch cords can not be
longer than 7m (25ft), while the total length of the premises cabling
(in the wall) must not exceed 90m (300ft). See below to know how to do
this.
> In Wall wiring is combination of CAT5 and CAT5e
>
Do you have lots of internediary patch panel connections (e.g.: desk to
wiring closet. Wiring closet to server room main wall. Server room
wall to rack patch panel)
> Switch is DELL PowerConnect 2724 running in a non-managed mode
>
According to TFM (which you should R), there are cable-testing functions
in the switch. Check to see if you have faulty cabling, exceed the
length of the standards, or if the premises cabling can really sustain
1Gbps. If not, downgrade the user ports to 100 Mbps.
> about 10 users on the network
>
Check, if possible, for rogue user activity (Is anyone running a
streaming app? Is anyone acting as a Counterstrike server? Does anyone
have NetBEUI turned on by mistake? etc...)
>
> What slowdowns might this kind of setup cause?
>
Apart from the risk of having a spanning-tree loop between the switch
and the dual-homed server, there's nothing inherently bad about this
setup. By default it should run fine.
>
> Thanks
>
>
>
>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-12-22 10:13, Francois Labreque a écrit :
>
> How? Depending on the way it's set up, it can cause major problems with
> the switch. Disconnect one of the patch cords and see if performance
> improves. If it does, you had a loop between the two switch ports, and
> the two NICs in your server. Either reconfigure your NICs to use
> fail-over, or make sure "spanning-tree" is enabled on the switch ports
> facing the server. Keep in mind that by doing that you will lose your
> 2Gbps aggregation speed and the second NIC will only be there to provide
> a host-stanby.
>
And by that, I mean "hot-standby". I Should have proof-read...
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/12/21 09:25, Tom Austin a écrit :
> OK, So I am still on the hunt for the network delays I am seeing - so
> some questions about network throughput.
>
> My Hardware
>
> Windows Domain Server - (1) 1 GB ethernet
>
> File Server - (2) 1GB ethernet (bonded to share load into the same switch)
>
> Patch panel and patch cords are CAT5e
>
> In Wall wiring is combination of CAT5 and CAT5e
>
> Switch is DELL PowerConnect 2724 running in a non-managed mode
>
> about 10 users on the network
>
>
> What slowdowns might this kind of setup cause?
>
>
> Thanks
>
>
>
>
I know someone who had slow network. He discovered that he was
configured as peer to peer instead of on a domain. This can realy slow
things down.
Check for crushed or otherwise damaged cables. Any work on a wall
containint cabling? It could have damaged some cabling.
I think that, at least sometimes, a faulty network adaptor on one
computer may cause erratic trafic over the network.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/22/2011 10:13 AM, Francois Labreque wrote:
> Le 2011-12-21 09:25, Tom Austin a écrit :
>> OK, So I am still on the hunt for the network delays I am seeing - so
>> some questions about network throughput.
>>
>> My Hardware
>>
>> Windows Domain Server - (1) 1 GB ethernet
>>
>
> Make sure the server NICs are hard-coded for 1 Gbps Full-duplex.
> Gigabitethernet left in auto-detect mode can lead to funky things...
>
> Make sure the switch ports facing the servers also have their speed and
> duplex hardcoded, if possible.
>
I will look into this.
>> File Server - (2) 1GB ethernet (bonded to share load into the same
>> switch)
>>
>
> How? Depending on the way it's set up, it can cause major problems with
> the switch. Disconnect one of the patch cords and see if performance
> improves. If it does, you had a loop between the two switch ports, and
> the two NICs in your server. Either reconfigure your NICs to use
> fail-over, or make sure "spanning-tree" is enabled on the switch ports
> facing the server. Keep in mind that by doing that you will lose your
> 2Gbps aggregation speed and the second NIC will only be there to provide
> a host-stanby.
>
Hmmm - something to look at. I'll try to run a test in the near future.
It has run like this for 4 years without a visible issue - but that
could be due to a light load.
>> Patch panel and patch cords are CAT5e
>>
>
> Length? CAT5e specification says that desks-side patch cords must not be
> longer than 3m (10ft), and that switch-side patch cords can not be
> longer than 7m (25ft), while the total length of the premises cabling
> (in the wall) must not exceed 90m (300ft). See below to know how to do
> this.
>
desk-side - 5-10 ft typical - a very few longer - < 15 ft
switch-side - < 3 ft
in wall - < 100 ft (building is 100' long and net room is in the
middle.
>> In Wall wiring is combination of CAT5 and CAT5e
>>
>
> Do you have lots of internediary patch panel connections (e.g.: desk to
> wiring closet. Wiring closet to server room main wall. Server room wall
> to rack patch panel)
>
server patch directly switch
switch patch to panel
panel run to wall outlet
wall outlet patch to computer
>> Switch is DELL PowerConnect 2724 running in a non-managed mode
>>
>
> According to TFM (which you should R), there are cable-testing functions
> in the switch. Check to see if you have faulty cabling, exceed the
> length of the standards, or if the premises cabling can really sustain
> 1Gbps. If not, downgrade the user ports to 100 Mbps.
>
Working on RTFM - as time allows.
Just set the switch to 'managed mode' while nobody was in the office.
Now to figure out how to 'use' it.
>> about 10 users on the network
>>
>
> Check, if possible, for rogue user activity (Is anyone running a
> streaming app? Is anyone acting as a Counterstrike server? Does anyone
> have NetBEUI turned on by mistake? etc...)
>
We do have people running streaming music and video - and even a small
minecraft server for local use (guys like to lunch it)
My thought is that the bandwidth that these things use is small enough
as to not impact usability. We have never seen things like this impact
the network before.
Our pipe to the internet is 50/10 and is pretty consistent - but that
should not overly impact server-client speeds in out office - should it?
>>
>> What slowdowns might this kind of setup cause?
>>
>
> Apart from the risk of having a spanning-tree loop between the switch
> and the dual-homed server, there's nothing inherently bad about this
> setup. By default it should run fine.
>
We have been running the network like this since 2007 without noticing
any problems. But with a few extra guys in the office it sounds like it
could cause some latent problems to crop up.
The spanning-tree loop sounds like something to look into. I'll run
some tests with disconnecting a port to see if that may be the cause of
the problem as well as using the managed features of the switch to run
down some issues.
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/23/2011 8:12 AM, Francois Labreque wrote:
> Le 2011-12-22 10:13, Francois Labreque a écrit :
>
>>
>> How? Depending on the way it's set up, it can cause major problems with
>> the switch. Disconnect one of the patch cords and see if performance
>> improves. If it does, you had a loop between the two switch ports, and
>> the two NICs in your server. Either reconfigure your NICs to use
>> fail-over, or make sure "spanning-tree" is enabled on the switch ports
>> facing the server. Keep in mind that by doing that you will lose your
>> 2Gbps aggregation speed and the second NIC will only be there to provide
>> a host-stanby.
>>
>
> And by that, I mean "hot-standby". I Should have proof-read...
>
I picked up on that - is there a 'safe' setup that would allow ganging
of ports like I have?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/23/2011 6:57 PM, Alain wrote:
> Le 2011/12/21 09:25, Tom Austin a écrit :
>> OK, So I am still on the hunt for the network delays I am seeing - so
>> some questions about network throughput.
>>
>> My Hardware
>>
>> Windows Domain Server - (1) 1 GB ethernet
>>
>> File Server - (2) 1GB ethernet (bonded to share load into the same
>> switch)
>>
>> Patch panel and patch cords are CAT5e
>>
>> In Wall wiring is combination of CAT5 and CAT5e
>>
>> Switch is DELL PowerConnect 2724 running in a non-managed mode
>>
>> about 10 users on the network
>>
>>
>> What slowdowns might this kind of setup cause?
>>
>>
>> Thanks
>>
>>
>>
>>
>
> I know someone who had slow network. He discovered that he was
> configured as peer to peer instead of on a domain. This can realy slow
> things down.
>
> Check for crushed or otherwise damaged cables. Any work on a wall
> containint cabling? It could have damaged some cabling.
>
> I think that, at least sometimes, a faulty network adaptor on one
> computer may cause erratic trafic over the network.
I'll set up some monitoring to see if I can see what traffic is flowing.
I am pretty confidant that we are all running on domain.
Cabling to some offices may be suspect - but not too much to do about it
as it is in-wall. We may run some patch cords to do some tests.
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-01-03 07:48, Tom Austin a écrit :
> On 12/23/2011 8:12 AM, Francois Labreque wrote:
>> Le 2011-12-22 10:13, Francois Labreque a écrit :
>>
>>>
>>> How? Depending on the way it's set up, it can cause major problems with
>>> the switch. Disconnect one of the patch cords and see if performance
>>> improves. If it does, you had a loop between the two switch ports, and
>>> the two NICs in your server. Either reconfigure your NICs to use
>>> fail-over, or make sure "spanning-tree" is enabled on the switch ports
>>> facing the server. Keep in mind that by doing that you will lose your
>>> 2Gbps aggregation speed and the second NIC will only be there to provide
>>> a host-stanby.
>>>
>>
>> And by that, I mean "hot-standby". I Should have proof-read...
>>
>
> I picked up on that - is there a 'safe' setup that would allow ganging
> of ports like I have?
>
>
Look into LACP (IEEE 802.3ad Link Aggregation Control Protocol). Both
your NICs and the swith need support it (and be configured for it,
obviously!) Cisco also has proprietary equivalents (EtherChannel and
PAgP) that are sometimes supported by third party hardware.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-01-03 07:47, Tom Austin a écrit :
> On 12/22/2011 10:13 AM, Francois Labreque wrote:
>> Le 2011-12-21 09:25, Tom Austin a écrit :
>>> OK, So I am still on the hunt for the network delays I am seeing - so
>>> some questions about network throughput.
>>>
>>> My Hardware
>>>
>>> Windows Domain Server - (1) 1 GB ethernet
>>>
>>
>> Make sure the server NICs are hard-coded for 1 Gbps Full-duplex.
>> Gigabitethernet left in auto-detect mode can lead to funky things...
>>
>> Make sure the switch ports facing the servers also have their speed and
>> duplex hardcoded, if possible.
>>
>
> I will look into this.
>
>>> File Server - (2) 1GB ethernet (bonded to share load into the same
>>> switch)
>>>
>>
>> How? Depending on the way it's set up, it can cause major problems with
>> the switch. Disconnect one of the patch cords and see if performance
>> improves. If it does, you had a loop between the two switch ports, and
>> the two NICs in your server. Either reconfigure your NICs to use
>> fail-over, or make sure "spanning-tree" is enabled on the switch ports
>> facing the server. Keep in mind that by doing that you will lose your
>> 2Gbps aggregation speed and the second NIC will only be there to provide
>> a host-stanby.
>>
>
> Hmmm - something to look at. I'll try to run a test in the near future.
> It has run like this for 4 years without a visible issue - but that
> could be due to a light load.
>
>
>>> Patch panel and patch cords are CAT5e
>>>
>>
>> Length? CAT5e specification says that desks-side patch cords must not be
>> longer than 3m (10ft), and that switch-side patch cords can not be
>> longer than 7m (25ft), while the total length of the premises cabling
>> (in the wall) must not exceed 90m (300ft). See below to know how to do
>> this.
>>
>
> desk-side - 5-10 ft typical - a very few longer - < 15 ft
> switch-side - < 3 ft
> in wall - < 100 ft (building is 100' long and net room is in the middle.
>
Do not assume anything. Cabling conduits sometimes take funky routes
around (or into... but that's a big fire hazard!) ventilation ducts,
plumbing, elevator shafts, etc... I've seen cables strung as tight as
piano wire, I've seen bundles of cables thrown under the floors because
the cabling guys were too lazy to cut them to the proper lengths, I've
seen attack ship fire off the shoulder of Orion...
>>> In Wall wiring is combination of CAT5 and CAT5e
>>>
>>
>> Do you have lots of internediary patch panel connections (e.g.: desk to
>> wiring closet. Wiring closet to server room main wall. Server room wall
>> to rack patch panel)
>>
>
> server patch directly switch
> switch patch to panel
> panel run to wall outlet
> wall outlet patch to computer
>
>
>>> Switch is DELL PowerConnect 2724 running in a non-managed mode
>>>
>>
>> According to TFM (which you should R), there are cable-testing functions
>> in the switch. Check to see if you have faulty cabling, exceed the
>> length of the standards, or if the premises cabling can really sustain
>> 1Gbps. If not, downgrade the user ports to 100 Mbps.
>>
>
> Working on RTFM - as time allows.
> Just set the switch to 'managed mode' while nobody was in the office.
> Now to figure out how to 'use' it.
>
>
>
>>> about 10 users on the network
>>>
>>
>> Check, if possible, for rogue user activity (Is anyone running a
>> streaming app? Is anyone acting as a Counterstrike server? Does anyone
>> have NetBEUI turned on by mistake? etc...)
>>
>
> We do have people running streaming music and video - and even a small
> minecraft server for local use (guys like to lunch it)
>
> My thought is that the bandwidth that these things use is small enough
> as to not impact usability. We have never seen things like this impact
> the network before.
>
Things have certainly improved since Doom 1.1 wrecked havoc on company
LANs in the early 90s, but it's always a good think to know what's out
there and be ready to limit extra-curricular activies, if it's
preventing people from working.
>
> Our pipe to the internet is 50/10 and is pretty consistent - but that
> should not overly impact server-client speeds in out office - should it?
>
Unless someone has gotten access to your server and is running a proxy
from it, no.
>
>
>>>
>>> What slowdowns might this kind of setup cause?
>>>
>>
>> Apart from the risk of having a spanning-tree loop between the switch
>> and the dual-homed server, there's nothing inherently bad about this
>> setup. By default it should run fine.
>>
>
> We have been running the network like this since 2007 without noticing
> any problems. But with a few extra guys in the office it sounds like it
> could cause some latent problems to crop up.
>
> The spanning-tree loop sounds like something to look into. I'll run some
> tests with disconnecting a port to see if that may be the cause of the
> problem as well as using the managed features of the switch to run down
> some issues.
>
>
> Thanks
>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/3/2012 9:12 AM, Francois Labreque wrote:
> Le 2012-01-03 07:48, Tom Austin a écrit :
>> On 12/23/2011 8:12 AM, Francois Labreque wrote:
>>> Le 2011-12-22 10:13, Francois Labreque a écrit :
>>>
>>>>
>>>> How? Depending on the way it's set up, it can cause major problems with
>>>> the switch. Disconnect one of the patch cords and see if performance
>>>> improves. If it does, you had a loop between the two switch ports, and
>>>> the two NICs in your server. Either reconfigure your NICs to use
>>>> fail-over, or make sure "spanning-tree" is enabled on the switch ports
>>>> facing the server. Keep in mind that by doing that you will lose your
>>>> 2Gbps aggregation speed and the second NIC will only be there to
>>>> provide
>>>> a host-stanby.
>>>>
>>>
>>> And by that, I mean "hot-standby". I Should have proof-read...
>>>
>>
>> I picked up on that - is there a 'safe' setup that would allow ganging
>> of ports like I have?
>>
>>
>
> Look into LACP (IEEE 802.3ad Link Aggregation Control Protocol). Both
> your NICs and the swith need support it (and be configured for it,
> obviously!) Cisco also has proprietary equivalents (EtherChannel and
> PAgP) that are sometimes supported by third party hardware.
>
>
I found a bit of time and put our switch into managed mode and R some of TM.
Looks like it supports "Link Aggregate Groups".
The linux box is set up with aggregation already - ethernet bonding with
round-robin - actually pretty cool setup that I figured out when I set
it up.
The switch and linux box are pre 2008 so they don't support the 802.1 -
but should do the 802.3ad.
Some reading shows that I should be able to link the 2 server ports on
the switch - don't know if it will make much difference but it seems
like it is the way it should be.
Will have to try it in the morning when no-one is in the office.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/3/2012 9:21 AM, Francois Labreque wrote:
>
> Do not assume anything. Cabling conduits sometimes take funky routes
> around (or into... but that's a big fire hazard!) ventilation ducts,
> plumbing, elevator shafts, etc... I've seen cables strung as tight as
> piano wire, I've seen bundles of cables thrown under the floors because
> the cabling guys were too lazy to cut them to the proper lengths, I've
> seen attack ship fire off the shoulder of Orion...
>
Our own guys wired the building when they moved in way back - ~1999.
While likely not the best installation it wasn't the worst either. It
is amazing what a bunch of engineers that don't know what htey are doing
can do?
>>
>> My thought is that the bandwidth that these things use is small enough
>> as to not impact usability. We have never seen things like this impact
>> the network before.
>>
>
> Things have certainly improved since Doom 1.1 wrecked havoc on company
> LANs in the early 90s, but it's always a good think to know what's out
> there and be ready to limit extra-curricular activies, if it's
> preventing people from working.
>
Always on the mind - always keeping an eye out for it. Conceptually it
doesn't seem top be the problem, but I am no network expert.
>>
>> Our pipe to the internet is 50/10 and is pretty consistent - but that
>> should not overly impact server-client speeds in out office - should it?
>>
>
> Unless someone has gotten access to your server and is running a proxy
> from it, no.
>
In the office there are no worries, but from out the office - we have
always tried to have a decent firewall between us and the internet. But
that is never a guarantee. Doesn't seem like something weird is running
- but I am not a network/computer expert.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
