Both switches you've mentioned are targeted for the access-layer, not the aggregation or core layer like you are planning to use them.
Will they work? It depends on the traffic between these locations. You can provision an OC3 for customers and only use 2% traffic, in that situation, they will work without problems.
Edison, could you elaborate why you see an effective transfer rate of only 2% of an OC3 (if I understand you correctly).
If the handoff is Gig Ethernet, and WAN routing is being done on a carrier provided router (I think that's what's described), the only issue I see is what the provider does with the Gig to OC3 within their routers.
I just took a random %. My point was those switches aren't marketed to be WAN facing switches and the throughput may be degraded due the chosen hardware.
Would you terminate an OC3 on a 1800 router?
A 2800 router?
See my point?
I would agree if we were terminating an OC3 directly on any of these devices, or on 1800 or 2800. But, as I also wouldn't want to use 1800 or 2800 for a LAN router supporting 200 Mbps of bandwidth, 200 Mbps (or 155 Mbps) of Ethernet bandwidth, alone, shouldn't be an issue for 3550 or 2950.
Do we just have a disconnect in where these devices will be (my understanding, upstream of the actual WAN routers with Ethernet connections), or do you still see an issue?
I have encountered the situation where a 7200 with an OC-3 connected to a switch at 100 Mbps (where the FastE interface became the bottleneck). Then the 7200 to switch link was upgraded to gig Ethernet. Bottleneck moved to other side of switch which had another FastE interface. Then other side of switch moved to gig Ethernet. No performance issues on switch, OC-3 then became bottleneck.
> Do we just have a disconnect in where these devices will be (my understanding,
> upstream of the actual WAN routers with Ethernet connections), or do you still see an issue?
Let's take the 2950 as an example. The OC3 hand-off goes to one of the Gigabit uplink, then based on assumption, the other Gigabit uplink goes to a WAN router that performs the routing. What's the point of having the 2950 in the first place? Why not just connect the OC3 hand-off directly onto the router?
Yes I too agree with Edison !
Why we are terminating OC3 to a switch at customers place from a service provider ( Router ) , instead of terminating directly to the Router which can directly performe Routing .
"The OC3 hand-off goes to one of the Gigabit uplink, then based on assumption, the other Gigabit uplink goes to a WAN router that performs the routing."
No, not what I'm assuming, and why I suspected we had a disconnect (in our assumptions). I'm assuming the OC3 is connected to a provider WAN router which in turn is connected to either the 3550 or 2950 via Ethernet. This assumption is based on the Shannon's second post "The carrier will hand it to me from their Cisco router.".
"What's the point of having the 2950 in the first place?"
I would expect for the purpose of LAN fan-out. (I suspect working with my assumptions, you'll agree.)
"Why not just connect the OC3 hand-off directly onto the router?"
Yes, what I'm supposing, again though, the provider's router.
If the OC3 does hands off directly to the LAN device, like a Metro E, then I would agree neither the 3550 or 2950 is suitable. Although, at the loss of about a third of the bandwidth, in a real pinch I would downrate rate such a connection to 100 Mbps to maintain control of congestion.
In this scenario i would advice 6509 with SPA -200/400 which supports OC3 connection and also supports routing function with l3 capabilities.
Please share your ideas.
Certainly a 6500 with SPA-200/400 would easily handle both a WAN OC3 and the LAN, but Shannon's original post was whether he could use his existing 3550 and/or 2950.
What's not clear has been how the OC3 would be handed off to Shannon. From his original post, one would assume it might be an Ethernet hand off, and if so, Edison's concerns are on target.
From Shannon's second post, there appears there would be a provider router that takes the OC3 and hands off to Ethernet. If true, both the 3550 or 2950 could continued to be used as LAN network devices.
 But back to your request to share ideas; assuming the OC3 bandwidth is handled to us via Ethernet, we might find one of Cisco's Metro Ethernet switches suitable.
Shannon, if you could, please clarify the linkage between your devices and the OC3.
Good lord, you want to sell the guy a Cat6 for what is essentially media-converting (by the SP's WAN rtr before handoff) one puny OC3?
Holy, who's deep pockets is he supposed to raid?
Shannon, you'll likely be fine with what you've got using GigE in/out. Double-check your models for support if have a need for jumbo framing.
Make sure you bug your SP to enable support for GigE flowcontrol desired bidirectionally (and don't forget to do it yourself).
Remember if this is copper GigE, Cat6 is your friend.
This should help a little. I am a Wireless ISP and the carrier will hand me the connection to plug into my 3550. I have a wireless connection to the customer using a licensed Dragonwave 200 meg full Duplex connection. I currently have their DS3 trunked between the 3550 and a 2950 and hand them off from the 2950. I was hoping to have my existing switches work but if there is any degredation I will upgrade them. Thanks.
Both the 3550 and 2950 EI were marketed as Metro Access switches because of their advanced feature sets.
They both also appear likely to have sufficient performance to handle the additional bandwidth you wish to add.
One feature found in some of newer Cisco Metro Switches, but not found in these, is a shaper (other than physical port egress queuing). A shaper is a "must have" if you want to be able to fully manage some of your slower WAN bandwidth, but if you don't intend to do so, you should be able to use what you have.
It's funny you should mention a shaper. I just purchased a Neteqalizer traffic shaper and it has really helped with the conjestion. I will not be placing it on the OC3 port because it is only 45 meg.
Ah, that's interesting! I'm not surprised by the improvement you report.
When dealing with congestion, you can either try to obtain enough bandwidth such that congestion doesn't form, or manage it. Since bandwidth isn't available in infinite amounts, when congestion forms, optimal solutions often require a mixture of bandwidth and bandwidth management.
Switches and routers offer various levels of bandwidth management but such capabilities are often far short (currently) of what's offered by dedicated appliances. The primary advantage of using the capabilities of the switch or router is, it's often "free", and depending on the situation, also often "good enough".
If your increased bandwidth precludes using your dedicated shaper, and congestion becomes an issue, you might try using the features of your 2950/3550. If that's insufficient and you don't wish to increase bandwidth, you can move up to "smarter" switches and/or trade up your shaper appliance.