On Wednesday, January 23, 2013 09:40:22 PM Chris Gotstein wrote: > We use an appliance to control bandwidth and setup > packages for our customers, so it needs to be in the > location it's at so I can feed it multiple connections > from different areas. It wasn't as big of a deal when > all our connections came through a single backhaul, but > now we are adding additional fiber connections that all > need to go through this one box.
This is the problem of using appliance-based bandwidth
managers.
In my experience, they are great when:
- All your customers are ONLY trying to get to the
Internet.
- You have one router connecting you to your
upstream.
- You don't have hardware redundancy in your core or
peering edge.
- You don't have traffic going out other routes like
peering.
- Your customers don't talk to each other, so there
isn't a need to manage bandwidth between them.
When all the above stops being the case, particularly when
you grow and your customers start demanding circuits that
remain on-net, or when you start popping up in different
locations to peer and/or buy additional transit for multi-
homing, you quickly realize that taking advantage of QoS
features for bandwidth management inside the routers (and
close to the edge as possible) is a much more scalable
approach.
If I were you, I'd start doing this now...
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
