My cohorts in suits have begun wondering if HSRP is standard for customer
gateways, and from there wondering if it is something we should charge for.
I did some research and came up with mixed results; I'd like to hear
nanogers experiences with this:
In your experience, do datacenters provide free HSRP gateways, or do they
make you pay for it?
Real world examples are better than Google 
Thanks,
Randal
So is the question: you are selling transit to your customers and you
are wondering if you should charge your customer for allowing them to
use your HSRP gateway instead of a physical interface on your router?
Personally, if I saw a provider charging for that service, I would shy
away from them. Only because it tells me they are piece-mealing their
services and are cheap. I would think a good provider would include
that (and/or not sell it WITHOUT HSRP) in their sales offering. If for
the only reason of customer support nightmares. If you have your
customers on HSRP and you have a router go down, you wont have them
calling you every five minutes bitching at you...
-Mike
We currently offer HSRP everywhere, the problem is that it doesn't scale on
a budget. For example, a 3550 can do 16 HSRP groups, limiting the number of
customers that we can attach to (2x 3550s) to 16. That's a lot of
distribution infrastructure for 16 customers. Then to scale that, say, to
200+ customers, that means we have 12-13 pairs of distribution routers, each
with 2x gigE uplinks to the core ... Which means that either (A) the core
has to be really big or (b) we get fewer, more powerful distribution
devices.
This is where my employer is at now - I admit, we're tiny in the datacenter
world - but the cost to aggregate 100+ HSRP groups into the core, with room
to grow, is pretty staggering for a smb.
This why the suits are wondering if there is a revenue opportunity hiding
somewhere to finance such a thing. Ah, the joys of growing out of your
britches
Thanks for any continued response,
Randal
Check out this article:
http://www.cisco.com/en/US/products/hw/switches/ps646/products_qanda_item09186a00801cb707.shtml#q1
Get rid of the 3550. Get youself a 6509 or 6513 :0
-Mike
I had read that on our original deployment, and it's a nightmare to keep the
documenation and configuration in synch. My personal opinion is that
potentially failing 16 VSIs over to the standby at once (because they're all
in the same group) - instead of just the affected ones - is poor policy.
I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately
they cost a lot. Which is why the suits are considering financing them by
charging for the features they provide.
This has been a hot topic around the office, with all of us network guys
saying `keep hsrp everywhere` because it makes our phones ring less, but we
realize that network upgrades aren't free, which is making the non-IT folks
all antsy.
Regards,
Randal
Well, the suits will realize the support nightmare (which equals $$$)
if they don't keep HSRP. Hopefully, they won't have to learn that the
hard way.
-Mike
I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately
they cost a lot. Which is why the suits are considering financing them by
charging for the features they provide.
One way I've seen providers address is this to have two different classes of service offerings. One has redundancy built in and the other doesn't - then you price the offerings accordingly. That could apply to basic ping-and-power colo, managed services, or anything in between. The cost difference could be justified by the fact that the redundant service takes up resources (finite resources at that) on two different big expensive switches.
This has been a hot topic around the office, with all of us network guys
saying `keep hsrp everywhere` because it makes our phones ring less, but we
realize that network upgrades aren't free, which is making the non-IT folks
all antsy.
And that's a very valid point. Many organizations pay different amounts of attention to manpower costs vs. capex to buy the big expensive switches and opex to keep things running. Manpower is (hopefully 
in your organization) not cheap.
jms
Since you are already deploying redundant hardware, why not just run two links to the customer? 3550s support simple routing as well as BGP and this protects your customer from things like your 3550 failing...
And causes less HSRP and other chatter.
I would encourage my competitors to engineer customers on L2 interfaces with a redundancy protocol on-top all day long.
DJ
Randal Kohutek wrote:
While I'm not a huge fan of running more than 32 instances on a 3550, using
the FAQ posted earlier to get above 16 works quite well.
I'm not following the argument about failing 16 vlans at a time because
they're in the same group. Running a quick test in the lab, this wasn't my
experience at all. I'm not aware of the group instance having any
synchronization impact (such as it would with VRRP) when it comes to HSRP --
only a single vlan interface failed over when I did a shut on the primary.
The group simply determines the virtual mac address, but if I'm wrong on
this let me know.
The documentation/configuration synchronization issues are really more an
issue of how refined provisioning is. If your upstream links from these
aggregation devices are layer 3, and I hope they are, the vlans carry only
locally significance anyway. When the aggrs are spun up, the vlan
interfaces and groups could all be pre-defined before they're even needed.
Yes, you may not know the IP addresses or block sizes to pre-configure all
of the HSRP data, but you can hold the "standby x authentication" line
within a configuration without knowing any of the layer 3 information. At a
later point when the vlan interface is actually needed for a customer, the
provisioning group simply needs to match the group number they already see
in the configuration.
To get back to the original question, yes, I think HSRP is worth keeping
around and shouldn't really have a line-item cost associated with it to the
customer. I've worked with providers that charge an "HA" fee during
provisioning (and often a recurring one as well) for customers that want it,
but personally I think offering an HA network as a service provider should
almost be a given.
If you're still uncomfortable with the multiple vlans bound to one group
issue, there's also the 4948 model to consider. It removes the issue of
having a million eggs in one basket at the customer aggregation level,
effectively has a 4000 series sup, and Cisco tested this out for us with
1500 HSRP instances running (lab documents available offline if you'd like
to see). Alas, it does rise the aggregation costs a bit though.
Hope that helps,
Brad McConnell
CCIE #16147
I use 4948 series.
I pay $8400 for 4948-e and $6500 for 4948-s (non-10GE models).
The price delta isnt so great from the 3560G series. At the end of the day, it is a cat4500 in a 1u chassis.
Are these out of your budget?
j.
Randal Kohutek wrote:
No, in fact those are very interesting as they're a stop-gap between 3750s
and 4500s at a good price per port. Are there any HSRP limitations on them?
Guess I need to do some more research, as those are pretty hot.
Thanks for the heads up, we'll definitely take a closer look.
Regards,
Randal
No, in fact those are very interesting as they're a stop-gap between 3750s
and 4500s at a good price per port. Are there any HSRP limitations on them?
Guess I need to do some more research, as those are pretty hot.
Hasn't Cisco said for years that HSRP should not be used in new deployments and that VRRP should be used instead? Just curious.
-Don
On routers, you have your choice as of 12.2 (I believe). On the small 3550/3560 type MLS products only HSRP is offered. The 4948, being a cat4500 with a modern sup, offers both.
Of course the "new" animal in town is GLBP which offers load sharing.
j.
Donald Stahl wrote:
On routers, you have your choice as of 12.2 (I believe). On the small 3550/3560 type MLS products only HSRP is offered.
Sorry- wasn't thinking.
Of course the "new" animal in town is GLBP which offers load sharing.
GLBP being completely Cisco proprietary unfortunately.
-Don