Prev: router contains a built-in switch versus router without a built-in switch
Next: port forwarding/ opening port
From: Triffid on 14 Oct 2005 00:37


Somebody. wrote:

> "Triffid" <triffid(a)nebula.net> wrote in message
> news:J9k3f.4917$vD4.349465(a)news20.bellglobal.com...
>
>>
>>Somebody. wrote:
>>
>>
>>>"Triffid" <triffid(a)nebula.net> wrote in message
>>>news:%703f.4875$S43.569621(a)news20.bellglobal.com...
>>>
>>>
>>>>Leythos wrote:
>>>>
>>>>
>>>>
>>>>>In article <I5l1f.8308$2F2.972520(a)news20.bellglobal.com>,
>>>>>triffid(a)nebula.net says...
>>>>>
>>>>>
>>>>>
>>>>>>Agreed, but in this case the vendor is not offering the update, via a
>>>>>>support contract or otherwise, at any price. I fail to see a downside
>>>>>>to their making it freely available on an as-is (unsupported) basis,
>>>>>>indeed doing so might enhance their reputation somewhat and reduce the
>>>>>>probability of complaints from users of illicit (potentially
>>>>>>compromised) firmware.
>>>>>
>>>>>
>>>>>I have a support contract for my WatchGuard firewall units, with the
>>>>>support contract I can download any version of their software for any
>>>>>appliance that I am marked as owning - you register their serial numbers
>>>>>and they provide access to the firmware/software. All updates, supported
>>>>>or not, are available to me because I have kept the support agreement on
>>>>>at least one current product.
>>>>>
>>>>
>>>>Netscreen used to work that way. I'm not sure anyone is entirely clear
>>>>how Juniper works it.
>>>>
>>>>Triffid
>>>
>>>
>>>Yes, and they still do.
>>
>>Not consistently, IME - see below
>>
>>
>>> The question is how they are handling obsolete products for which
>>>customers run but don't have the last (old) firmware.
>>>
>>>-Russ.
>>
>>Indeed - especially cases where the user obtained the unit as a discard
>>from work, or perhaps on ebay, and would like to update and run it at
>>home. Not state of the art, but still safer than the NAT router they
>>probably have now, and an opportunity to learn. Overall, a good thing for
>>both user and vendor IMHO.
>>
>>I bought new-in-box 5GT on ebay to replace my NAT router - came with
>>4.something, and the DI and AV subscriptions had expired since it
>>originally shipped just over 12 months before I bought it. Juniper said I
>>would have to ship the unit to them (at my cost both ways) for
>>'inspection' before they would take my $ for a support contract. They
>>refused to sell updates or subscriptions otherwise - send it to us, or run
>>it as-is. Screw that.
>>
>>So I log into my TAC account and grab the latest 5GT firmware. Legal? I
>>dunno, AFAIK the smallest unit registered on my account is a 500, but I
>>appear to have access to all firmware for all boxes. The other day a
>>colleague at work needed to update a 208, he's sure he has several
>>registered, but his TAC account wouldn't give him the file. Mine did.
>>Fouled up or what?
>>
>>You're even worse off if you own a unit Juniper considers obsolete - so I
>>won't be berating individuals who own one old NS box for asking after
>>firmware updates on the newsgroups. I won't give (or sell) them firmware
>>updates either - but Juniper should IMHO.
>>
>>Triffid
>
>
> We've been beating on them hard to offer non-hardware support, but so far
> they won't budge. Imagine your 500 was off support and you realize that
> your needs have changed, you need tech support and firmware support, but the
> same thing happens -- they won't debundle it from the hardware support and
> you have to pay all the back-dues since the hardware support went off, or,
> send it to them for inspection. Now imagine it's a 5200 and a year of
> back-support is gonna cost you five figures... just to earn the privledge of
> paying another 5 figures for the current year's support...
>
> Juniper really, really has to just give themselves a shake and put
> themselves in their customer's shoes for a bit... they have great products
> that they are somehow managing to turn into a nightmare for their clients.
> Hopefully somebody up there will fix it soon. The fixes truly aren't that
> complicated.
>
> 1. Offer 1-time obsolete firmware purchase option for very little money, or
> even free
> 2. Break up tech support, software support, hardware support into separate
> packages
> 3. Publish DI and AV throughput number ranges
> 4. Track ticket response times and FIX them when they see how broken they
> are
>
> -Russ.

Couldn't agree more.

5. Clean up and document debug (without crippling it, please), then
teach tech support how to use it effectively.

Not only are ticket response times abysmal, tech support rarely resolves
a damn thing.

IME the way to nail down ScreenOS issues is to bang away with debug in
the lab. The problem with debug is it spits out whatever the module
developer found useful during coding - so there is no consistency of
format or content across modules, and no documentation. Consequently,
few of the techs know how to configure debug effectively or interpret
the results - especially when clustered virtual systems are in play.

I find it more efficient to do my own debugging, interpreting the output
as best I can, and open a ticket only when I have clear evidence of
anomalous behavior I can't work around, or I need help decoding debug
babble.

I've managed to extract rudimentary scraps of documentation from
developers a couple of times, occasionally they'll suggest trying
something that may not have occurred to me yet proves helpful, but in
general tech support has been fairly useless. I often resolve tickets
myself, by finding a fix or workaround. I've been known to sit on a fix
for 3 weeks waiting for them to toss the ticket back :-) To give them
some credit, fixes often appear in a subsequent release note.

Triffid
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: router contains a built-in switch versus router without a built-in switch
Next: port forwarding/ opening port