[c-nsp] ASR-100x intro

[Scott Pettit]

You sound like a similar situation to us.  We purchased an ASR1001 in
August 2012 and have been extremely happy with it.

Advice from my experience:

* You can buy them in bundles which are considerably cheaper than buying a
base ASR1001 and adding all the licensing, so we purchased the broadband
bundle which included a 4000 subscriber license (for ISG/BRAS features).
We upgraded it from the base 4GB to 8GB of RAM as we needed to be able to
hold a couple of BGP feeds.  The ASR1001 ships with 2.5G throughput and
you can upgrade it to 5G throughput if/when required.

* Re your question about the "new" IOS - it's essentially identical to the
standard IOS.  The only difference is the ASR runs linux and IOS runs as a
daemon on linux.  All the functions are the same except a few features for
service providers that exclusively run on IOS XE as opposed to standard
IOS.  I have learnt not to bother with implementing IOS redundancy on the
ASR1001 - it is possible to configure it so two copies of IOS are running
at once and you can upgrade your standby IOS to a newer version, reload
that then cutover to the upgraded IOS with a few milliseconds
interruption. The downside is it gulps up half your RAM which you need for
multiple BGP tables.

Further on the above point, we've had IOS crash once due to an SSH bug, it
reboots very quickly as it's a daemon so there is no waiting for normal
hardware boot up.  All we noticed was a 30 second interruption and by the
time I was looking into what was going on, everything was back again.
Needless to say that bug has been logged.

* Re total cost, for our bundle we paid approx. $25k USD, plus approx. $8k
per annum USD for 24x7x2 on-site.  We spent a lot of time thinking about
whether to buy two ASR's and 8x5xNBD support or a single ASR with 24x7x2.
Knowing where the Cisco parts in our city are, we decided we could afford
to wait 2 hours in a worst case scenario.

* Your query on QoS/shaping - it's pretty easy using either rate-limit
directly on the sub interface pointing towards the customer, or via policy
maps.  You can do exactly what you describe for "cap traffic on this vlan
to X Mb/s but reserve and prioritize Y Mb/s for VoIP" with a policy map.
You'd create two class maps, one that classifies the VoIP traffic (by ACL,
listing the IP's of your SIP SBC's), priority xMbit, then dump the rest in
a non-prioritised queue.

* IPv6 all works fine, our customers are all dual stacked.

* If you aren't using PPPoE, the ASR can authenticate based on VLAN, so
even your MetroE customers can still be authenticated.  I know lots of
providers just configure the a /30 and a rate-limit and leave the customer
to it - we authenticate still based on the port so that we can hook in
with our billing platform easily.  One scenario we've implemented with our
ASR (using ISG) is when a customer's account goes overdue, they get an
email giving them 5 days notice.  After 5 days their HTTP/HTTPS traffic is
automatically redirected to a payment page and upon processing a credit
card payment their internet access is back on immediately.  We went with
this scenario as it doesn't break their VoIP (which bad debtors use as an
excuse - "If I can't call emergency services, you can't cut me off!").

* Having the ISG (on ASR) has been invaluable to us.  Another solution
we've implemented is DNS redirection for IPv4 and IPv6.  Customers
configuring Open DNS/Google DNS started to become a real headache as it
completely ruins the performance of anything on CDN e.g. We'd see someone
configure Open DNS then call us complaining that Apple Update/Windows
Update is slow because their Akamai traffic was now coming out of Japan
(we're in New Zealand).  So using ISG we transparently redirect all DNS
queries to our DNS resolvers.  Customers can still use Open DNS/Google DNS
and it works, but all the responses come from our DNS servers.  We haven't
had a single support call regarding CDN issues since.

Bottom line for us is the ASR is a swiss army knife that I haven't gotten
close to digesting all the documentation to see what else we can do with
it.

Thanks,

-Scott

-- 






On 6/01/13 1:32 AM, "Charles Sprickman" <spork at bway.net> wrote:

>
>On Jan 5, 2013, at 6:54 AM, Robert Hass wrote:
>
>> On Sat, Jan 5, 2013 at 12:09 PM, Charles Sprickman <spork at bway.net>
>>wrote:
>>> We're tentatively shopping around, and I'm looking for that sort of
>>>information on the ASR lineup.  The 1002 and 1002-X look very
>>>interesting on paper, but I'm not finding much about what folks in a
>>>small service provider role have to say about them.  We're at the point
>>>where everything is ethernet now, so our 7206 with an NPE-G2 is feeling
>>>pretty silly.  Some of the ASR stuff seems to be in the used channel
>>>already, which is nice (I'd rather have two used than one new, FWIW).
>
>Right now and for the foreseeable future we don't need anything fancy,
>with one exception, which I'll save for last.
>
>We're doing lots of ethernet aggregation - both metro-e services and
>DSL/EoC (delivered over GigE, one vlan per customer, no PPPoe - straight
>bridging).  The people on the other end of these circuits are all
>customers, we're not an enterprise with branch offices, so many features
>like IPSEC are totally useless at this point.
>
>On the "core" side (we are really too small to think about having core
>vs. edge gear) we will likely never go beyond 3 transit providers with
>full BGP feeds, and as our traffic ramps up some more, there are probably
>a handful of private peering opportunities.  IPv6 support is a necessity.
>
>The one area where I would like to be more "high touch" is in traffic
>shaping and QoS.  Often times we'll have a metro-ethernet customer who
>wants 50Mb/s and our metro-e provider can only provide an unthrottled
>100Mb/s connection.  The brute-force shaping I can do on the NPE-G2 is
>not very nice, and it tends to kill VoIP.  Customers tend to balk at
>installing any substantial CPE that could do shaping on their end.  Any
>gear that offered a drop-dead easy way of saying "cap traffic on this
>vlan to X Mb/s but reserve and prioritize Y Mb/s for VoIP" would add
>serious value.  How exactly one would accomplish that for customer-bound
>traffic where you don't know if DSCP values have been stripped upstream,
>well that's tough, although our VoIP provider has offered to setup a
>private peering connection, so being able to prioritize anything headed
>to or from their port would be nice.
>
>All I know is that every time we've lurched towards just being a "dumb
>pipe", there's always one or two customers where we'd have a sale if we
>could accommodate their scenario where they need a more high-touch
>solution.