[c-nsp] ME6524 alternative

[Dan Armstrong]

Not to push this thread off topic,


But we *hate* the Cisco model of the 'valueless' reseller.  We deal with 
a Cisco rep, we deal with a Cisco SE, our discount is set by Cisco, we 
deal with Cisco's TAC - but when it's time to buy something, we get 
shuffled off to some twit that does absolutely nothing and makes a cut?  
It drives us nuts.  It's confusing, and unnecessarily complicated. 


We'll never be able to get away from Cisco completely, but when possible 
this stupid crap drives us to the point we will do anything to avoid 
buying from Cisco, and look to their competitors. 




Rubens Kuhl Jr. wrote:
>> 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.
>>     
>
> Thru partner. Cisco insists to tell us that there is no Cisco Direct
> in our country, although I know there is and know some customers that
> use such channel.
>
> The partner is trying very hard to sell us this month, but they can
> only work on their margins.
>
>
>   
>>>> 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).
>>     
>
> They seem to be listening about this, but the only real measure is the
> latency till it's implemented.
>
>
>   
>>> 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.
>>     
>
> That's the only place in the network we have 7600s with PFC XL... but
> you could try filtering some routes down to the non-XL TCAM capacity
> and pointing a default route to the these prefixes.
>
>
>   
>> 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
>>     
>
> After the MPLS bugs we've seen here, you wouldn't even try using it as
> P even for the ring only. May be the 3750 IP Services, with no MPLS,
> combined with 2 ME6524 on the ring would be a good fit. That's the
> option we're exploring for some cities where we can do ring-only:
> using L2 (Extreme Summit X150 is the most likely candidate, but Cisco
> ME3400 with METROACCESS would do the job if one prefers to stick to
> Cisco); some cities are too complex to cover with ring-only, so in
> those we need full L3/MPLS.
>
>   
>> 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
>>     
>
> Humm, 3750s do L2 like a charm...
>
>   
>> 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
>>     
>
> But then you need a PE you can trust for being a P, even for a limited
> number of PEs.
>
>   
>> 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.
>>     
>
> I think such rings would be better served by using REP (Cisco) or
> EAPS(Extreme); ME6524 doesn't support REP today, but that's probably
> just one version away.
>
> Rubens
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>