NBX 100 on a data network

[issunboshi]

Need some advice here guys. Currently, in our office, we have an NBX 100 system, integrated with our data network. We use 3Com 3000 and 4400 Switches. I have considered seperating the 3com system onto it's own physical network, since it's a layer 2 device, I don't like the idea of having all of these broadcast devices on an IP network. Are there any ill effects to doing this, is it advised, not advised, reasons? Would appreciate any input.

Ken

 

[naysoft]

Hi Ken,

Whilst I appreciate your concerns, they are really not founded in the case of the nbx. We run upwards of 80 phones on a similar network without any problems - that's 80 phones, around 70 pc's all hooked in to a gigabit back-bone and we really cannot detect any degradation in performance. If you are experiencing poor performance, I would be interested to know in what way.

For what it's worth, we found the nbx to actually improve our network as it quickly identified inconsistencies in our cabling which the computers were tollerant of!

HTH

 

[techguru69]

I need to somewhat disagree with naysoft's reply in relation to two points with an NBX. Not knowing the size of your install, I'll go by what we have.

Naysoft - I'd be interested to see what a sniffer records as traffic on your lan, as well as 802.11 queue sizes and resends on the pc side. If this in fact working as you say, please give a bit more detail on your backbone infrastructure and config, as this would be extremely helpful for new and existing installations.

First, if you enable music-on-hold, multicasts will fill your IP network. Activity lights will be solid on your switches with a reduction in total overall data bandwidth available for other services. This is a known issue with NBX's. The reason this is is because 3Com does not use "on-demand" multicast for MOH, as Cisco and Mitel do. They just open the stream and let it fly constantly.

Secondly, by adding 18k per packet of voice traffic to your 10MB,100MB or even GB network, I find it hard to believe that the overall quality of your network would improve. VOIP, by design, cannot surpress digital packet latency and "jitter". Some switches can compensate for this, such as the 4400's, but only to a degree. Unless your PC's are talking GB to your switches, there's gotta be some loss there.

In our situation, we also use 4400's, but only for the phones (about 100 sets). Our backbone data core is seperated off by VLAN and QOS so no cross-traffic occurs, except for http and ftp requests to the NBX. Multicasts and voice packets are kept on the 4400's. The phone side is filled with multicasts, but errors and switch latency are minimal.

As an FYI - we do have a Qovia ION connected to our NBX that monitors just what we are talking about here. Anyone getting an NBX, I highly suggest spending the $3000 for it.

Just my $0.02.

Tallyho,
Mike

"Any society that needs disclaimers has too many lawyers."

 

[issunboshi]

Hoffmancorp, we currently are using 3300's with our integrated voice/data network. And yes, all of our activity lights are on constantly. Our consultant company (and I use that term lightly), makes claims that this is done, to make sure we do not saturate our switches.

So they (consulting firm) are suggesting that we upgrade to 4400 switches, so that they can use prioritation and QOS to improve our telephone situation, while leaving our network integrated. My suggestion was to use our existing 3300's, and dedicate them primarily to the phone system, and place the NBX on it's own subnet. If the 3300 can handle 12 phones, and 12 pc's at 100 full, they should be able to handle 24 phones, no problem. Since we transfer large email attachments (3 to 4 MB) and use a CRM solution that transfers large ammounts of data between client and server, the footprint of the telephone is not much in comparison.

I would estimate that we currently have 70 phones and 60 pc's on the 3300's in a stacked configuration (recomended by the same consulting firm). And this is all on a 10/100 backbone.

Here is my plan. Please tell me where I am going wrong. Place the phone system on the 3300's, and place the nbx on it's own vlan. Upgrade the backbone to GB, and place the data network on some new 4400's we plan to purchase. Our company is growing and a decent pace, and I want a solution that will grow with the company, not just bandaid it like the consulting firm has done in the past.

 

[techguru69]

Ok, first, if you have MOH enabled, that is the reason your lights are on solid - contrary to what your consultant says. Remember - VOIP MOH = Multicasts (and lots of them).

On your planned config - sounds fine to me if you are dead set on using the older 3300 technology and firmware and 3Com for your infrastructure (core and edge). I still have 6 year old 3300's running for various small tasks and they give me no troubles. We did bring in 4400's to give us the POE for the phones, and along with them came QOS and such for the VOIP and the GB Fiber uplinks.

The vlan setup is a must if you want to seperate the traffic. Just remember to tie the vlans together (via Spanning Tree or simple forwarding) so you get to the NBX Netset without having to re-route your traffic.

I'm one who always looks to the future when building systems like this. That is why I would not keep the 3300's and instead opt for the 4400's for the phones, and possibly your GB backbone, if you want to have a 3Com backbone. We didn't choose a 3Com backbone due to the fact that they got out of the core switch market years ago and are now just revisiting it. For a solid core, I would not use a 4400, but rather a dedicated core switch such as Extreme Networks Alpine 3808 (which we have as our core), an HP Procurve or a Cisco. If you have the opportunity to build (or re-build) your infrastructure now, I would do it from the core out so you are always ready for the future. The "big picture" isn't the edge, it's the core. A solid core will produce a solid data path.

Good luck!

Tallyho,
Mike

"Any society that needs disclaimers has too many lawyers."

 

[issunboshi]

Thanks Hoffmancorp, and yes, we have MOH enabled. I have no problem using the new 4400's for the phones, and keeping the 3300's for the data. The 3300's will be replace incrimentally as time goes on, just not all in one lump, no sense in getting rid of a perfectly good switch, even if it's a little older. My main goal is to get all of the voice and data traffic, off of the same logical network. Our backbone will be a 3com GB device, something like the 3824, and we have a layer 3 switch for the vlans.

Thanks again.

 

[GoTellBigDaddy]

NBX on Data Network

from 3KB:

Solution ID:
2.0.102112367.3754933


NBX - Recommended Network Design and VoIP Pre-Qualification

Problem: Recommended Network Design for 3Com NBX

Problem: Various functional consistency or audio quality issues

Fact: latency

Fact: VoIP

Fact: QoS

Fact: ToS

Fact: 802.1p/q

Fact: 3Com Ethernet Power Sources

Fact: jitter

Fact: switches

Fact: hubs

Fact: cables

Fact: firewall

Fact: VPN

Fact: TAPI

Fact: NBX TAPI

Fact: NBX 100

Fact: SuperStack 3 NBX

Fix: Recommended Design for VoIP and NBX Networked Telephony Products:
*******
Latency: Round trip delay should be <100 ms and not fluctuate to ensure toll voice quality.
*******
Hubs: Not recommended at all. NBX 25 with 8 phones or less, and NO PC's connected is the only exception.
*******
Switches:
--> For a large amount of phones and PC's running multiple applications, switches MUST support and be properly configured for 802.1p and 802.1q
--> If switches cannot be configured for 802.1p/q, it is recommended that NBX network and PC network be either totally separate and not connected, or, switches for NBX and PC equipment be separate, and only connected via a single switch port link between the networks. This will aid in troubleshooting, and allow the switch settings to be optimized for the NBX
--> LAN applications which use large amounts of bandwidth such as GHOST (hard drive replication) and Video Conferencing must be given special consideration to ensure they do not receive a higher priority than the NBX audio packets at any time.
--> Switches than can be configured to look for certain LAN traffic prioritization of audio packets is highly recommended
--> Gigabit Ethernet backbones are highly recommended. Depending on Network Traffic Fast Ethernet backbones can also be used depending on total applications running on the network
--> Multicast addresses used on the NBX should not be used by any other application on the network.
--> Layer 3 Switches must support and be configured for IGMP Query mode, and a multicast routing protocol such as OSPF, or DVMRP
*******
Cabling:
--> Category 5, Category 5E, or higher is required for 10/100 phones operating at 100 mb/S, and is recommended for 10 mb/s telephone operation
--> Category 3 may be used but is not recommended for 10 mb/s telephone operation
--> ATA/ATC devices MUST use Voice Grade connections (66-block or screw terminal jacks). This means the cable from the ATC port on the NBX chassis to the analog telephone jack must NOT pass through cat-5 terminations such as a cat-5 standard "patch panel" in any PC wiring closet. The reason is that ATA/ATC signaling is HIGH VOLTAGE, LOW FREQUENCY (100 volts DC at 20 hertz) which is NOT supported by the TIA standard. Cat-5 patch panels are the opposite, LOW VOLTAGE, HIGH FREQUENCY. Cat-5 patch panel connections are not designed to handle the 48vDC battery and 110 volts AC ringer voltages
*******
Firewalls:
--> NAT, PAT, and Proxy Servers are NOT SUPPORTED for NBX telephones and WILL NOT OPERATE
--> Private Networks are supported, meaning Point-to-Point T1's with all private addressing and multiple site NBX's will work fine, but connection via NAT/PAT/PROXY to a telephone/device is not.
--> If you assign a NAT Public IP for your Internal NCP address, the only functions supported are: NetSet Administration, IMAP connection to get voice mail messages
--> H.323 ConneXtions support NAT/PAT/Proxy, but communicate only with other H.323 Gateways or H.323-compliant clients such as NetMeeting sessions.
--> The NBX uses ports tcp 1040, and udp ports 2093, 2094, 2095, and 2096, which must be open in all directions through firewalls
*******
VPN's:
--> VPN's are fully supported
--> To connect an NBX business phone and PC/laptop at the same time, a hardware VPN device is required, in order to create the VPN subnet IP on the physical ports for the phone and PC to connect to. One static IP address for the hardware VPN device is required.
--> Alternatively, PcXset can possibly be installed on a PC using software (Dial Up Networking) VPN to connect to the NBX subnet. In order for this to work, the O/S on the PC must allow the default network to change to the VPN IP address when the VPN connection is active. Windows NT for one, and other OS's may not allow this. After establishing VPN connection, you must be able to "PING" the ncp directly from the DOS prompt at its ACTUAL (inside, private) address for the pcXset to work. PcXset soft telephones have pretty much the full functionality and multiple button mappings possible as with a standard Business Set
--> If the NCP has a public IP address and is connected directly to the Internet, VPN's are not required. The NCP will require a static public IP, and all phones will need to be on the Public Internet subnet. An IP license is required for the NCP, and you must have enough PUBLIC IP addresses to support all of your phones.
*******
Routers:
--> Any routed IP WAN protocol is supported - Frame Relay, Point-to-Point, ATM, DSL, Cable Modem, ISDN, etc.
--> Connections such as DSL/Cable modems for remote IP telephones generally provide inadequate voice quality, due to lack of QoS, and other factors, and are the most unreliable. Point-to-point T1 lines privately owned are preferred, as the entire network path can be customized by the customer-owned on-premise equipment, and is not subject to sharing bandwidth, or fluctuating bandwidth.
--> Frame Relay connections work excellent, provided they are configured correctly, with zero, or near-zero DE (discard eligibility) by design, as VoIP is a UDP stream. Frame circuits that allow "bursting" above the CIR may have high DE rates on the downswing from burst to CIR. Discuss this with the ISP.
--> Latency should not exceed 100ms round trip between any two devices that are talking (phone-phone, phone-NCP, phone-CO line card port, etc)
--> Check the IP Multicast Address in the NBX and avoid using it on other applications. It can be changed on the NBX and is not hard coded if need be to avoid conflict
--> IP ToS and Diff/Serve support is the Layer 3 equivalent to QoS on the switches at Layer2, and is critical for optimum performance of remote IP phones or devices.
--> All routers between NBX-communicating devices must support a Multicast Routing protocol such as DVMRP, OSPF, (Cisco is PIM Dense mode) in order to support the following features on remote phones: Paging, Conferencing, Correct Date and Time LCD display, and illumination of buttons for Mapped Lines, or DSS/BLF for extensions.
--> Bandwidth Requirements:
Phones and remote devices such as Line Cards in a remote chassis, per port:
- 87 kilobits/sec sustained throughput per conversation, normal mode
- 55 kilobits/sec minimum requirement for low bandwidth and silence suppression options enabled
H.323
- 19.2 kilobytes/sec - 87 kilobits/sec, depending on compression codec used
*******
UPS / Battery Backup:
--> Go to the APC web site (

http://www.apcc.com),

click on "Selectors", then "Go to UPS Selector", then "Advanced UPS Selectors", then "Telecom", then on the pull-down menu select "3COM" and enter the model you are providing UPS for (NBX 100, NBX 25, Ethernet Power Source, V5000 chassis, or telephone models). Follow instructions for sizing up your UPS for the desired length of time, etc.
--> For NBX Business telephones, the Ethernet Power Source product with splitter pack can be used to provide power through the Ethernet connection to NBX phones, and the black power brick on each phone can be eliminated. A UPS can then be attached to just the Ethernet Power Source device to protect and provide backup power for all telephones.