«

On Mon, 15 Jun 2009 14:55:44 -0700, "just bob" <kilbyfan@aoldotcom>
wrote:

>I think I finally need a real managed switch with VLAN and QoS. I need to
>somehow prioritize VoIP traffic on a LAN.
>
>Basically San Francisco and Los Angeles Springs each have an Avaya IP Office
>PBX which transfers calls over VoIP. We have no VoIP phones or other
>devices, just these PBX's supporting VoIP to each other.
>
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......

>Previously these locations were connected via a Point-to-Point circuit with
>gobs of extra bandwidth, and at my busy SF location I had the PBX on a sub
>network away from all other traffic. But that is going away so now we need
>to prioritize the local traffic. The new MPLS circuit will prioritize across
>the WAN but locally I need to do something, too.
>
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).

>Let me know if you have any ideas. I'm hoping a very inexpensive switch with
>basic management will do this for me.
>
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.

>Thanks!
>
--
Regards

- replace xyz with ntl

On Jun 16, 3:53*pm, Stephen <stephen_h...@xyzworld.com> wrote:
> On Mon, 15 Jun 2009 14:55:44 -0700, "just bob" <kilbyfan@aoldotcom>
> wrote:
>
> >I think I finally need a real managed switch with VLAN and QoS. I need to
> >somehow prioritize VoIP traffic on a LAN.
>
> >Basically San Francisco and Los Angeles Springs each have an Avaya IP Office
> >PBX which transfers calls over VoIP. We have no VoIP phones or other
> >devices, just these PBX's supporting VoIP to each other.
>
> 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......
>
> >Previously these locations were connected via a Point-to-Point circuit with
> >gobs of extra bandwidth, and at my busy SF location I had the PBX on a sub
> >network away from all other traffic. But that is going away so now we need
> >to prioritize the local traffic. The new MPLS circuit will prioritize across
> >the WAN but locally I need to do something, too.
>
> 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).
>
> >Let me know if you have any ideas. I'm hoping a very inexpensive switch with
> >basic management will do this for me.
>
> 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.
>
> >Thanks!
>
> --
> Regards
>
> stephen_h...@xyzworld.com - replace xyz with ntl

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.

"" <> writes:
>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.


"Doug McIntyre" <> wrote in message
news:4a3a9986$0$92360$. net...
> "" <> writes:
>>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.

On 19 June, 00:20, "Thrill5" <nos...@somewhere.com> wrote:

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.

The RPS is only a redundant power supply, just in case the internal power
supply fails. With the blinders on, that is the product that Cisco
developed. A system with built-in redundant power supplies doesn't have the
same limitations. For example, a 6500 with redundant power supplies can be
connected to two different circuits, and one of them can be connected to a
UPS. If either side fails, the other can take over, and they automatically
switch back and forth. You can easily switch over to an RPS, but it's not
easy to switch back which is its achilles heel.

"bod43" <> wrote in message
news:f0ed94c6-102d-426b-bf8f-...
> On 19 June, 00:20, "Thrill5" <nos...@somewhere.com> wrote:
>
> 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.
>
>
>