Do I need a switch with VLAN and QoS?

Very nice phone system

About any Cisco or HP switch should suffice.

This should get you started as this is the smallest switch to look into depending on bandwidth needs

QoS is a layer 3 method of prioritizing IP traffic so that lower priority traffic is dropped before higher priority traffic when there is conjestion on a link between routers. A switch is a layer 2 device which does not apply QoS but it can be used to mark the priority of the traffic. In your case you need a router that does QoS at the two locations where the VoIP traffic is. You will need to mark the traffic appropriately so that you and your MPLS provider use the same QoS markings and that they mean the same thing. You will also need to make sure that the VoIP traffic is prioritized on your outbound links to the MPLS cloud, so that your router is dropping the non-VoIP traffic before other traffic. Once in the MPLS cloud your provider will honor the markings and also drop non-VoIP traffic first. I would suggest you get some assistance in putting this together. The vendor that supports your Avaya system is a good place to look for help as they will be very familier with QoS and how to implement it correctly.

QoS only has an effect when you have congestion.

If the PBX local interfaces are on their own LAN interfaces, then the traffic level will be sub 100 Kbps per active call - so room for 1000 calls on a 100 Mbps port......

The main thing is to make sure the way you mark your traffic is compatible with the MPLS service (and that you have those MPLS options in your service, that they are turned on and working).

This implies your MPLS access link is Ethernet based?

you havent really given enough detail for any of us to suggest a "fire and forget" network design.

A lot will depend on what kind of MPLS service you have, the QoS you get, your traffic profile and so on.

I suspect a layer 3 switch that can remark the traffic going into the WAN is a good starting point if your existing equipment cannot handle that - but there are limitations

also note if you have a "rate limited" WAN interface feeding into the MPLS (say a 10 Mbps pipe, but you can only use 4 Mbps), then most switches cannot combine QoS prioritisation and rate limiting on the same port - for that you may need a router.

I like Cat 3560s / 3750s which are pretty flexible - but they do not have resilience options such as dual power feeds......

They can rate limit is 10% port speed steps and still do QoS within that.

Incidentally, I am using Catalyst 3750 switches in conjunction with external RPS (RPS 675) which can act as a redundant power supply if you were to lose a Power supply on one switch.

And then if you do lose external power, you have to reboot the switch to get back your power redundancy. Whee... (can you tell I'm not a big fan of the Cisco RPS solutions?).

Why cisco doesn't make a true dual power switch in that product level is still a total mystery, other than pushing that class of users up to the very expensive next line of switches that do.

I am also not a fan of Cisco's RPS solution for the same reasons plus a few more. The current solution just isn't workable in because of the reboot issue. We used to install RPS's in all our closets that we put in 3750's but not anymore. The reboot issue to get power to switch back was a real problem. I think you can switch it back without a reboot, but you need to push some buttons on the RPS to do it, and that's impossible at remote sites. We had one location that had a bad power circuit and the thing would switch over the RPS every time. We would then need to schedule a reboot of the switch in the evening. The other problem is that sometimes the WAN router would also go down during the power blip and the SNMP trap from the switch wouldn't make it to the NMS. The device should send the the trap that it's on the RPS every 10 minutes to ensure that the trap is received. After having this problem all the time, the NOC finally said enough and we stopped deploying them and removed them from most locations.

The othe problem is that RPS's aren't managable, you should be able to get the status of the RPS via the devices its attached to. It should also be able to power more than one device if the sum of power requirements of the requested devices is less than it's total output. We all know that Cisco doesn't want to be in the RPS business, so why not publish a spec and let others develop them? A great solution would have the following specs:

Intelligent interface between the RPS and the device it's attached to. A simple inexpensive interface would have the existing power connections, with an integrated USB, so that the RPS and the device could each exchange capabilities and status.

The RPS is also a UPS, with battery backup. This could be the way that Cisco encourages other vendors to supply products, namely UPS vendors. Cisco could develop a proprietary RPS interface and then license it to UPS vendors. The UPS vendors could then sell a plethora of solutions with different numbers of power interfaces, total output power, and battery times. A great solution for Cisco AND its customers. I would pay a premium for this product because now you could not only have redundant power, but also backup power, and you could size the system to meet the specific needs of each location. The current one-size-fits-all solution is too expensive and not flexible enough and much to clunky to deploy on a large scale.

I think that he docs say that the switch *may* reboot when switching back (via) the front panel.

I believe that the RPS for the 3750-E is remotely managable. I know its different 'cos some bright spark ordered these for some 3750's. Has more pins on connector.

BTW - I don't like the solution either. I fail to see how it will actually help uptime. Maybe if you had flaky power? In the UK mains power is *very* reliable.