10

Current Configuration

The diagram below shows our current network architecture. All connections are running at 100 Mbps full duplex with the exception of the TalkSwitch phone systems which run at 10 Mbs half duplex (upper right-hand corner of diagram). The TalkSwitch boxes each provide 8 analog and 8 IP-based phone connections, so we can have a total of 16 analog and 16 IP-based phones.

Note: The four HP ProCurve 2524 managed switches are not configured with separate VLANs.

I'm concerned about the performance impact of having both switches, both TalkSwitch boxes, and the wireless bridge connected to our RV082 VPN router in our HQ.

enter image description here

Proposed Configuration

I'm proposing that we change our configuration as shown below. My thought is that this will limit the RV082 to only seeing internet bound traffic with the exception of providing DHCP to the dynamic clients; however, I wouldn't expect that to be much of a performance impact given that the client lease time is set to 24 hours.

Thoughts? Concerns? Recommendations?

One concern is that in building #2 & #3, the IP-based phones communicate with the TalkSwitch boxes at 10 Mbps half duplex. Will that adversely impact the performance of the rest of the network?

enter image description here

3
  • 7
    +1 for having awesome diagramming skills Apr 22, 2011 at 21:10
  • 1
    you say the top drawing is current and you worry about performance, the question that I have is does it work as is? Voip over wifi with 7 users seems like it may be an issue which has nothing to do with the vpn concentrator.
    – tony roth
    Apr 22, 2011 at 23:32
  • @tony roth: The system works, but we have various performance issues (most likely both with our ISP and with our network architecture). I'll add some details to my question. Thanks. May 2, 2011 at 23:02

3 Answers 3

4

As Wim noted already, the half-duplex doesn't matter. The switches are capable of running each port at different speeds and duplex.

The easiest way to evaluate it is to think of the path from component to component, and taking the weakest link. All your communication between building #2 and headquarters happens via a 3Mbps/300kpbs line shared with other internet duties; whether you have a 10Mbps or 100Mbps connection back at headquarters won't matter because the VPN link will be the dominant factor in determining the interconnection bandwidth.

Looking at your diagram, the material change I see in your proposal is introducing a 1Gbps link between the two HP 2524 switches at headquarters. One one switch you have a bunch of servers, each limited to 100Mbps, and on the other you have a bunch of client workstations, also limited to 100Mbps or 54Mpbs on wireless. No one machine here is going to be capable of exhausting the data link between the two switches, but with heavy traffic on multiple machines between the clients and the servers, you'll appreciate the 1Gbps link.

2

Are you trying to solve a theoretical design problem or are you having an actual VoIP call quality problem?

Any of the switches should be able to handle a mix of port speeds (10/100/1000) and duplexes (half/full). That in itself shouldn't be a problem.

I would let the RV082 be only the router, with a single LAN cable going to your HP switch. Let the router be a router, and the switch a switch...

It is a bit silly that the Talkswitch only does 10 HD. But still, an uncompressed ulaw/alaw VoIP call takes max 100 kbps so you can run lots of concurrent calls no problem.

You could/should explore the QoS features of your router and switches a bit more.

This might help: http://www.hp.com/rnd/pdf_html/traffic_profiles.htm#environment2 but you may have to hunt a bit more for correct doc for your switch.

1
  • This is not a theoretical design problem. We are having VoIP call quality problems in building #3. Although those improved when we replaced the hub in building #3 with the HP ProCure 2524 switch. Our bigger problem is internet performance. I'm concerned that the TalkSwitches operating at 10 Mbps half duplex are adversely impacting general network performance. However, I have not yet narrowed down the problem to determine the root cause. I believe the problem is multi-faceted, including ISP related performance issues. May 2, 2011 at 23:05
1

I've run specialized, critical telephony systems for stock traders at 10 Mbit, half-duplex, and I haven't seen issues with that aspect of the system. (The IPC turrets operated only at 10/half.)

Have you tested call quality with an IP telephone directly connected to the Procurves at the HQ? That should eliminate the switching gear as a possible culprit.

I'm sensing also that you haven't got any sort of monitoring system in place to evaluate bandwidth usage on those RV082's. If there isn't an easy way to check bandwidth usage using the web admin console for those routers, consider implementing a performance monitoring system. Another quick Google shows that those routers support SNMP. If you can find a spare computer upon which to throw Cacti or PRTG, that should go a long way towards determining the saturation level of the Internet link. (Throw Nagios on there too, and you've got an availability monitor for your network.)

Without hard data, I suspect it's the Internet link at Building #3 that is constraining your bandwidth. So it's worth talking to your provider to understand your options and costs for upgrading. But before buying an upgrade, I would advise confirming the problem through performance monitoring. Understand how much more you need to buy before buying it.

Also, what codec are those IP phones using? I'm not familiar with Talkswitch, but a quick Google shows they support G.711 or G.729. If they are using G.711, which uses 80 kbits bandwidth, you'll be able to run at most 3 calls across that Internet link at the remote site. G.729 will cut telephony bandwidth usage by an order of magnitude. The call quality will suffer, so make sure your management is on board before you make that change. But it might be helpful to do that in the short term if evaluation of bandwidth usage ends up taking longer.

HTH!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .