[c-nsp] ME6524 alternative

[Rubens Kuhl Jr.]

I don't have a problem with a reseller getting a piece of the action
if it's a vendor choice to do so. I always tell vendors that we will
compare the product by the price we can get it, no matter how many
hands it come across... on a competitive market like selling
networking gear to service providers, they know that... every time
Cisco or a reseller complains it has no margins, say something like
"it's not my problem", "that's a self-inflicted pain" and so forth...
either they stop wining and gives you the discount you want, or you
buy from someone else.

The math they make is that sometimes a channel will bring a customer;
if that probability is higher than the discount you have to give to
put the middle man, they make a profit on an aggregate level.

Not Cisco, but many other vendors considers us to be a channel as we
buy CPEs to provide them as service, and let us buy directly from
distributors or from the manufacturer, which puts more pressure on
Cisco. Sometimes it doesn't work (as it didn't in this 3x price hike
for the ME6524), sometimes it does.

Rubens


On Wed, Jul 23, 2008 at 11:10 AM, Dan Armstrong <dan at beanfield.com> wrote:
> 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/
>>
>
>