[c-nsp] ME6524 alternative

[Justin Shore]

Rubens Kuhl Jr. wrote:
> Yeap, but we've got a 3x price hike on the ME6500 from our initial
> purchase to current quotes, which left us no choice but to evaluate
> alternatives.

Ouch.  Are you dealing with a partner or Cisco Direct?  There isn't any 
excuse for the price to go up, period.  If you like I could hook you up 
with our Cisco Direct guys.  If you got your order in this week you 
might be a decent discount simply because their fiscal year ends this 
month and the sales folks are hungry.

>> The BFD on SVIs is definitely something that bit me on all my SX/SR
>> platforms.  I still don't have a working solution for that problem.
> 
> I would really love to just hear what Cisco says about why BFD on SVIs
> are a bad thing. They might have a good point.

What I was told was that it was an "unintended feature".  Basically that 
means that while it worked it wasn't ever part of the intended design 
and wasn't ever tested.  It could have adverse affects on other things; 
then again it also might not affect anything.  They simply wouldn't know 
unless they incorporated that into the QA procedures and there has to be 
demand for that to happen.  So tell your account team every chance you 
get.  In fact I would recommend having your account team hook you up on 
a call with the product manager responsible for BFD support on your 
hardware and ask for it yourself (because often times I think requests 
like that tend to get overlooked).

> It's good to know that Cisco changed the speech regarding this
> product. I think that if one uses only as PE (no other P or PEs
> relying on it for LDP of a critical backbone), and it uses only 2
> uplinks (no ring or mesh, two uplinks to a P backbone), no L3VPN, it
> might work. In the mean time, I'm glad that all the 3750-Metro we've
> got were operational leases: we will return them all, so I won't have
> to write !@%¨#%¨#@ on the customer satisfaction surveys anymore.

Yeah, it's good to know what they're meant for.  I was thinking like a 
dumbass when I bought a pair of ME6524s for the core in a very small 
pop.  I didn't know much about the underlying platform and didn't even 
think about the TCAM on that box.  I was just thinking that they'd be a 
decent device for the price and throughput in that small POP and that 
they didn't need to be too fancy.  I ran out of TCAM back in January 
when the global route table exceeded the Sup2's limited reach.  I'll be 
replacing them in the future and pushing them closer to the edge where 
they belong.

The ME3750 was really meant primarily as a PE device but also as a P in 
a MetroE access ring.  In our training lab the ME3750 was used mainly as 
the access edge.  Most of the labs used it as a L2 edge switch 
essentially but a few labs had us extended the IGP to it, enable MPLS 
and push VCs all the way to it.  It worked fine, except for when I 
skipped an important step in the instructions...  They intended for it 
to be deployed in GigE rings too.  As they put it in the class, fiber is 
expensive.  You can't home-run every PE to an aggregation router.  It's 
just not cost-effective or reasonable.  But it is cost-effective to have 
half a dozen of them ringed together and home-run the edges back to the 
aggregation layer (ME6524s or larger hardware.  In fact much of the 
class dealt with building the access ring, tuning STP/RSTP/MST, etc. 
It's a good class if you're interested.

Justin