Wireless Networks Thread, Topologies/Switch Throughput in Technical; As was said, lets keep any bashing of people's ideas elsewhere. I'm all for constructive criticism and I think enough ...
24th November 2011, 08:12 PM #61
As was said, lets keep any bashing of people's ideas elsewhere. I'm all for constructive criticism and I think enough of us are grown up enough to agree to disagree on some things.
Sorry Synack, I think I missed one of your posts/replies. I'm not sure about routing between subnets, however having spent an hour discussing the same subject last night with one of the most genius networking guys I know (who heads up various technical teams at Cisco UK) we had two options: we have a cracking Cisco router provided by ISP but we're not allowed to touch it. On the other hand, any vaguely modern PC with a decent linux distribution and IP tables will outperform just about any layer 3 device under 2 grand. That's not alot, discounting layer 2+ stuff, but plenty (apparently) for a network of our size. He also mentioned STP can be a prime suspect for throttling ports too much - however we only enabled it after the problems started.
Didn't know about using STP on uplinks and RSTP on clients - what's the reasoning behind this? All the sales bullpoo just shouts "RSTP is better, thanks" with no actual information, as a result RSTP has been enabled across the board, on the units that support it (which is just the Dlink 1210-24s, not the 1224's or Procurves.) Easily done though, we have per-port control of the units.
We'll see how things transpire with the improvements over the last few days and then start seriously planning for the near future.
Many thanks to everyone that's chipped in - even the off topic stuff has been extremely enlightening and may hopefully be of use to others.
Last edited by synaesthesia; 24th November 2011 at 08:14 PM.
IDG Tech News
24th November 2011, 08:26 PM #62
24th November 2011, 08:35 PM #63
RSTP is just rapid STP and designed for clients so it only runs a few tests before enabling the port and allowing actual network connection. Full STP whould be on any interswitch links which runs more through tests but takes about 30s for the port to become 'live' for network connectivity.
The linux PC route is valid but becomes a massive bottleneck (everything pushed through 1GB NICs) rather than running on a switching fabric. There is also a bunch more latency thanks to the larger software stack inbetween and the fact that it is implemented entirely in software. Still a possibility but better to tie it in to a device like a switch if that is an option.
24th November 2011, 08:47 PM #64
Yes but given my configuration of my switches typically has 2 or 3 VLANS on it, Usually Building VLAN, VOICE, Printers etc which are all usually untagged (apart from Voice) and then I have my uplinks which will be tagged in all 3 VLANS. How do I define the ports that use STP and the ones that use RTSP. The configurations seem to apply to a whole VLAN and I haven't seen a particular example of it applying to a subset of ports. In a psedo code type of example I would expect to see:
Originally Posted by SYNACK
Vlan 6 "MainBuilding"
Untagged 1-48 Mode RSTP
Tagged 49-50 mode STP
or am I missing something here and it just magically happens as it knows the difference between and inter switch link and an end user device?
24th November 2011, 08:55 PM #65
No magic, you need to set it up manually and in some scenarios you may need to use per VLAN STP or MSTP
Originally Posted by ChrisH
Last edited by SYNACK; 24th November 2011 at 09:00 PM.
24th November 2011, 09:14 PM #66
My rationale here is that working with the lowest common denominator ensures stability. If you give machines 1Gb/s they have the possibility of using it; this can cause issues with older networks, inadequate switches and with mixed environments that have 10/100Mb/s and 1000mb/s devices. suppose 50 machines are sharing a 1GB uplink, any slowdown caused by inadequate switches dropping packets will cause TCP acknowledgements to be delayed/missed and this effect can slow down a network massively as the transmission rate is slowed. Now imagine how left out a 100mb/s machine would feel in a mixed 1gb/s environment with slow uplinks!
Originally Posted by SYNACK
Simulation TCP 1: Reliable Transfer
Clearly I'm not against high network speeds! just that the network needs to be able to cope with it regularly and reliably for it to work correctly - I just think it's better to have all running correctly and without errors. If the switches and uplinks won't be able to deal with the traffic it makes more sense to slow the traffic. Think along the lines of running country lanes with min speed limits, you get more traffic through at 30mph than 100mph.
On 3com (I understand they use 3com OS on even new HP now, certainly some of our HP branded stuff has 3com ios)
Originally Posted by ChrisH
it would be
Last edited by CyberNerd; 24th November 2011 at 09:19 PM.
24th November 2011, 09:39 PM #67
Looking at a few of my switch configs they are set to RTSP already. I think some of the commands I was grasping for are in here:
The ones about the admin edge modes.
It looks like only my Procurve 2610 and 5610 know about these though. My 2650 and 2826 don't seem to have this and most of of my edge switches are 2650 so I guess I better dig out the specific manuals.
25th November 2011, 06:11 PM #68
Not going to say much until Monday but I think problems have been solved
Dlink switches: not a problem. In fact, they've been holding up rather admirably considering when we recreated the problem with the Procurves they fell over and died immediately.
So it seems the networking issues in general were not related to some machines only connecting at 100mbit. We discounted, wrongly, the computers as the culprit - the drivers for the nForce 10/100/1000Mbit ethernet were nackered. Replaced them with the "wrong" driver, a little hacking of the .inf file, streamed into the CC3 build area and job was a goodun. So that effected our DT department, library and a few other machines which will all get a rebuild during a certain quiet period next week
So the speed issues?
Kept pinging suspect areas and narrowed it down to one. Core > edge 1 > edge 2 > edge 3 (horrible daisy chain but no choice!) NM found a slight loop - someone plugged network printer directly into PC then wall port to wall port. Joy. That was removed anyway, a bit of jiggery with those edge switches, lo and behold pings started going through reliably and not dropping out ever few seconds.
Phone call from our techy at the other site. "You know that problem I was having with my PC? It's stopped. It's perfect"
Won't say too much, I'm touching wood as I type this, until Monday so we can confirm. We will still be buying in better switches (L2+) for the core and will certainly be vlanning for the new network next year, it's pointless wasting time on it now.
We're really rather happy Should have a new procurve on Monday thanks to warranty but we've found another dodgy one today - and it's only a few months old. I hate them.
6th December 2011, 01:04 PM #69
Just taken delivery of a pair of Procurve 5406zl 44+4SFP POE switches at a ridiculously low price
Very happy! 2 weeks of testing ahoy!
6th December 2011, 02:11 PM #70
Haven't seen much of this thread apart from the last couple of pages but I'd stick with the HP 5400 series (zl) for your core and built the edge up with the E-Series switches. We've got the v1910s for our iSCSI network and although they work OK the ProCurve E series seem a bit more solid and easier to manage in the long-term. Also add up the lifetime vs 3 year warranty (and subsequent care packs) to get a comparative price.
As for speeds, no point having 1Gb to the desktop if it's wobbly and unmanageable.. buy good kit buy once
6th December 2011, 04:43 PM #71
Well, the cheap gigabit switches which are oddly enough holding up better than the not-cheap procurve edge kit are holding out just fine Either way, 3 grand for 30 switches - end max speed to desktop wasn't important, it was a step up from crap 3com baseline switches which had a bucketload of inherent issues.
As said, we've invested in those 2 cores. I would appreciate a little more advice if possible on vlans.
2 sites. A and B.
Each site has a shiny new ProCurve 5406zl. Connected via fibre (which will eventually be link aggregated - I won't say trunked because that now confuses the hell out of me as I've been reading about vlans and trunks which have nothing to do with them)
We need to stay simple. This is important. Any advanced stuff can wait until the new network when we will probably vlan off printers, wireless APs etc as well.
So, 2 sites. There are servers on both sites which will connect to each core. We wish to simply have Vlan1 for site A and Vlan2 for site B which would effectively kill off the unnecessary broadcast traffic over that fibre link (the trunk)
The site workstations and printers do not need to communicate with eachother, just the servers at each site. Internet router which is untouchable is at site B. Obviously site A also needs internet.
So far my understanding is that I would need to tag the ports on the core and each edge switch at site A as VID1 and site B as VID2 and create a bridge (trunk?) between them.
If the above is correct, do we need to separate DHCP via AD for each physical site? Each time I see about DHCP something crops up about DHCP helpers and the procurve documentation seems extremely vague on this.
Am I massively oversimplifying this?
6th December 2011, 05:05 PM #72
You have to be very careful when talking between people with Cisco-speak networking terms and HP-speak as the words "trunk" and "tag" don't mean the same thing between brands
If you set a Trunk port on ProCurve that's link aggregation aka EtherChannel in Cisco speak
If you tag ports to a VLAN (as you say for link between two switches) that's a trunk in Cisco world
See Trunking Between Cisco and HP Switches « Andrew Travis's Blog
Last edited by gshaw; 6th December 2011 at 05:07 PM.
6th December 2011, 05:36 PM #73
luckily much of the newer HP uses the 3com based OS, and a link aggregation is just that.
6th December 2011, 07:15 PM #74
Indeed - I just try to be clear between the two whilst looking for advice and finding people talking about different things for the same words
Righto, a little diagram to help further explain.
Last edited by synaesthesia; 6th December 2011 at 07:31 PM.
6th December 2011, 11:46 PM #75
- Rep Power
Originally Posted by gshaw
HP Trunks are NOT the same as "link aggregation aka EtherChannel in Cisco speak". HP Trunks are a dedicated HP protocol that performs a very similar jobs as Link aggregation but with a few extra features, HP Trunks only work between HP switches that support them.
If you need to connected multiple links between switches of different manufactures then you need to configure the link as LACP (Link Aggregation Control Protocol IEEE 802.3ad) at the HP end and the other switch end
By Craggus2000 in forum Wireless Networks
Last Post: 11th June 2009, 11:23 PM
By ChrisH in forum Wireless Networks
Last Post: 16th January 2006, 12:04 PM
By MuppetQueen in forum Hardware
Last Post: 17th November 2005, 06:42 PM
By russdev in forum Hardware
Last Post: 15th November 2005, 03:16 PM
By mark in forum Wireless Networks
Last Post: 12th November 2005, 03:58 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)