Mailing List Archive

Hi Rob,

My experience with Brocade support is rather positive. Usually quick
initial response, helpful in really urgent cases (I called them and had an
engineer on the phone for the whole time to resolution/workaround). But of
course, there are several engineers and attitude might vary.

Well, sometimes your request is not fully understood and engineers seem not
to have easy access to test equipment. Especially when it comes to
escalations to product development, things seem to become rather slow.

André


2016-02-24 16:45 GMT+01:00 Robert Hass <robhass@gmail.com>:

> Hi
> We just deployed test network running ICX switches for connecting many
> office users. We hit some software bugs (for example with not working OSPF
> as expected). We trying passing them to Brocade TAC, but my current
> experience is that cooperation with TAC is slow like a hell.
>
> Maybe it's just my bad luck.
>
> I'm looking for people having experiences with reporting bugs to Brocade
> TAC.
>
> Are you have positive experience with Brocade TAC ? How fast they can fix
> problems ? How professional they are ?
>
> Rob
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>



--
André Grüneberg
System Architect Web Operations

The unbelievable Machine Company GmbH
Grolmanstr. 40
10623 Berlin
Tel: +49 - 30 - 889 2656 43
Mobil: +49 - 172 - 686 1254
Fax.: +49 - 30 - 889 2656 - 11

https://www.unbelievable-machine.com

*Blog | *Karriere | *Facebook | *Twitter

Geschäftsführer: Ravin Mehta, Benno Wiedfeld
Sitz der Gesellschaft: Berlin, Deutschland
Handelsregister: Amtsgericht Charlottenburg HRB 115071B
Umsatzsteuer-Identifikationsnummer: DE261090159

*Ausgezeichnet: *um ist zweifacher „Big Data Leader 2016“*

Thanks

Just additional question to be sure : Were cases you mentioned was about
ICX products ? They was finishing with RMA or DEFECT plus software fix ?
Our cases at the moment are only software issues, looks like DEFECT in 100%
: e.g. adding second OSPF interface causing switch crash.

On Wed, Feb 24, 2016 at 4:54 PM, André Grüneberg <
andre.grueneberg@unbelievable-machine.com> wrote:

> Hi Rob,
>
> My experience with Brocade support is rather positive. Usually quick
> initial response, helpful in really urgent cases (I called them and had an
> engineer on the phone for the whole time to resolution/workaround). But of
> course, there are several engineers and attitude might vary.
>
> Well, sometimes your request is not fully understood and engineers seem
> not to have easy access to test equipment. Especially when it comes to
> escalations to product development, things seem to become rather slow.
>
> André
>
>
> 2016-02-24 16:45 GMT+01:00 Robert Hass <robhass@gmail.com>:
>
>> Hi
>> We just deployed test network running ICX switches for connecting many
>> office users. We hit some software bugs (for example with not working OSPF
>> as expected). We trying passing them to Brocade TAC, but my current
>> experience is that cooperation with TAC is slow like a hell.
>>
>> Maybe it's just my bad luck.
>>
>> I'm looking for people having experiences with reporting bugs to Brocade
>> TAC.
>>
>> Are you have positive experience with Brocade TAC ? How fast they can fix
>> problems ? How professional they are ?
>>
>> Rob
>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
>
> --
> André Grüneberg
> System Architect Web Operations
>
> The unbelievable Machine Company GmbH
> Grolmanstr. 40
> 10623 Berlin
> Tel: +49 - 30 - 889 2656 43
> Mobil: +49 - 172 - 686 1254
> Fax.: +49 - 30 - 889 2656 - 11
>
> https://www.unbelievable-machine.com
>
> *Blog | *Karriere | *Facebook | *Twitter
>
> Geschäftsführer: Ravin Mehta, Benno Wiedfeld
> Sitz der Gesellschaft: Berlin, Deutschland
> Handelsregister: Amtsgericht Charlottenburg HRB 115071B
> Umsatzsteuer-Identifikationsnummer: DE261090159
>
> *Ausgezeichnet: *um ist zweifacher „Big Data Leader 2016“*
>

I found with OSPF – coming from cisco world – it has a much lower maximum metric value.
I did however fix this issue before TAC even got back to me.

So make sure you BW values are not too small.. like tunnel interfaces etc.

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Robert Hass
Sent: 24 February 2016 15:45
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] Experiences with Brocade TAC -> ICX products

Hi
We just deployed test network running ICX switches for connecting many office users. We hit some software bugs (for example with not working OSPF as expected). We trying passing them to Brocade TAC, but my current experience is that cooperation with TAC is slow like a hell.

Maybe it's just my bad luck.

I'm looking for people having experiences with reporting bugs to Brocade TAC.

Are you have positive experience with Brocade TAC ? How fast they can fix problems ? How professional they are ?

Rob

Also, if you don't feel like TAC is handling your case as quickly as
they should, you can contact your SE and/or your VAR to put some
pressure on them.

--
Eldon

On Wed, Feb 24, 2016 at 10:32 AM, Nick Cutting <ncutting@edgetg.co.uk> wrote:
> I found with OSPF – coming from cisco world – it has a much lower maximum
> metric value.
>
> I did however fix this issue before TAC even got back to me.
>
>
> So make sure you BW values are not too small.. like tunnel interfaces etc.
>
>
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of
> Robert Hass
> Sent: 24 February 2016 15:45
> To: foundry-nsp@puck.nether.net
> Subject: [f-nsp] Experiences with Brocade TAC -> ICX products
>
>
>
> Hi
>
> We just deployed test network running ICX switches for connecting many
> office users. We hit some software bugs (for example with not working OSPF
> as expected). We trying passing them to Brocade TAC, but my current
> experience is that cooperation with TAC is slow like a hell.
>
>
>
> Maybe it's just my bad luck.
>
>
>
> I'm looking for people having experiences with reporting bugs to Brocade
> TAC.
>
>
>
> Are you have positive experience with Brocade TAC ? How fast they can fix
> problems ? How professional they are ?
>
>
>
> Rob
>
>
>
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Not just your bad luck. We have had VRRP, STP and BGP issues around ICX. As
an experienced engineer getting past T1 & 2 is painful with TAC.

Cheers
Mike

On 25 February 2016 at 02:45, Robert Hass <robhass@gmail.com> wrote:

> Hi
> We just deployed test network running ICX switches for connecting many
> office users. We hit some software bugs (for example with not working OSPF
> as expected). We trying passing them to Brocade TAC, but my current
> experience is that cooperation with TAC is slow like a hell.
>
> Maybe it's just my bad luck.
>
> I'm looking for people having experiences with reporting bugs to Brocade
> TAC.
>
> Are you have positive experience with Brocade TAC ? How fast they can fix
> problems ? How professional they are ?
>
> Rob
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>



--
Michael Gehrmann
Senior Network Engineer - Atlassian
m: +61 407 570 658

Maybe I've been lucky, but I have always sailed right past T1 TAC
towards their L3 escalation, and if the case is marked as P1 you've got
good chances of engineering getting involved on short notice.

It all comes down to how well you describe your problem when first
opening the case. That means including a show tech / support-save for
all of the involved devices right from the beginning, as well as a
network diagram if applicable, and a good amount of text explaining the
symptoms you are experiencing and the results you'd expect to see so the
TAC engineer can dive right in. After your case engineer has been
assigned, give them a call and walk them through the problem to make
sure there are no questions on their end. Finally, cc'ing your Brocade
SE into the case so they're aware something's going on never hurts.

I do have to say that if TAC identifies a new defect, you'll have to
hope there is a workaround to solve your problem for the time being
because it'll usually take several weeks for bugfixes to trickle down to
a new GA release.

Best regards,
Martijn

On 02/24/2016 10:51 PM, Michael Gehrmann wrote:
> Not just your bad luck. We have had VRRP, STP and BGP issues around
> ICX. As an experienced engineer getting past T1 & 2 is painful with TAC.
>
> Cheers
> Mike
>
> On 25 February 2016 at 02:45, Robert Hass <robhass@gmail.com
> <mailto:robhass@gmail.com>> wrote:
>
> Hi
> We just deployed test network running ICX switches for connecting
> many office users. We hit some software bugs (for example with not
> working OSPF as expected). We trying passing them to Brocade TAC,
> but my current experience is that cooperation with TAC is slow
> like a hell.
>
> Maybe it's just my bad luck.
>
> I'm looking for people having experiences with reporting bugs to
> Brocade TAC.
>
> Are you have positive experience with Brocade TAC ? How fast they
> can fix problems ? How professional they are ?
>
> Rob
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>
> --
> Michael Gehrmann
> Senior Network Engineer - Atlassian
> m: +61 407 570 658
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

Can I get that experience please. Maybe it's our timezone because we always
attach 'show tech' and then spend the next few hours trying to convince
them it's already attached to the ticket.

On 25 February 2016 at 09:29, i3D.net - Martijn Schmidt <
martijnschmidt@i3d.net> wrote:

> Maybe I've been lucky, but I have always sailed right past T1 TAC towards
> their L3 escalation, and if the case is marked as P1 you've got good
> chances of engineering getting involved on short notice.
>
> It all comes down to how well you describe your problem when first opening
> the case. That means including a show tech / support-save for all of the
> involved devices right from the beginning, as well as a network diagram if
> applicable, and a good amount of text explaining the symptoms you are
> experiencing and the results you'd expect to see so the TAC engineer can
> dive right in. After your case engineer has been assigned, give them a call
> and walk them through the problem to make sure there are no questions on
> their end. Finally, cc'ing your Brocade SE into the case so they're aware
> something's going on never hurts.
>
> I do have to say that if TAC identifies a new defect, you'll have to hope
> there is a workaround to solve your problem for the time being because
> it'll usually take several weeks for bugfixes to trickle down to a new GA
> release.
>
> Best regards,
> Martijn
>
>
> On 02/24/2016 10:51 PM, Michael Gehrmann wrote:
>
> Not just your bad luck. We have had VRRP, STP and BGP issues around ICX.
> As an experienced engineer getting past T1 & 2 is painful with TAC.
>
> Cheers
> Mike
>
> On 25 February 2016 at 02:45, Robert Hass <robhass@gmail.com> wrote:
>
>> Hi
>> We just deployed test network running ICX switches for connecting many
>> office users. We hit some software bugs (for example with not working OSPF
>> as expected). We trying passing them to Brocade TAC, but my current
>> experience is that cooperation with TAC is slow like a hell.
>>
>> Maybe it's just my bad luck.
>>
>> I'm looking for people having experiences with reporting bugs to Brocade
>> TAC.
>>
>> Are you have positive experience with Brocade TAC ? How fast they can fix
>> problems ? How professional they are ?
>>
>> Rob
>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
>
> --
> Michael Gehrmann
> Senior Network Engineer - Atlassian
> m: +61 407 570 658
>
>
> _______________________________________________
> foundry-nsp mailing listfoundry-nsp@puck.nether.nethttp://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>


--
Michael Gehrmann
Senior Network Engineer - Atlassian
m: +61 407 570 658

Michael,
we had same situation. Three times for three cases... "Please provide show
tech" which was provided after opening the case. This is specific probably
to ICX products. We also had some cases related to Fibre Channel equipment
where guys from TAC were much much better.



On Wed, Feb 24, 2016 at 11:47 PM, Michael Gehrmann <mgehrmann@atlassian.com>
wrote:

> Can I get that experience please. Maybe it's our timezone because we
> always attach 'show tech' and then spend the next few hours trying to
> convince them it's already attached to the ticket.
>
> On 25 February 2016 at 09:29, i3D.net - Martijn Schmidt <
> martijnschmidt@i3d.net> wrote:
>
>> Maybe I've been lucky, but I have always sailed right past T1 TAC towards
>> their L3 escalation, and if the case is marked as P1 you've got good
>> chances of engineering getting involved on short notice.
>>
>> It all comes down to how well you describe your problem when first
>> opening the case. That means including a show tech / support-save for all
>> of the involved devices right from the beginning, as well as a network
>> diagram if applicable, and a good amount of text explaining the symptoms
>> you are experiencing and the results you'd expect to see so the TAC
>> engineer can dive right in. After your case engineer has been assigned,
>> give them a call and walk them through the problem to make sure there are
>> no questions on their end. Finally, cc'ing your Brocade SE into the case so
>> they're aware something's going on never hurts.
>>
>> I do have to say that if TAC identifies a new defect, you'll have to hope
>> there is a workaround to solve your problem for the time being because
>> it'll usually take several weeks for bugfixes to trickle down to a new GA
>> release.
>>
>> Best regards,
>> Martijn
>>
>>
>> On 02/24/2016 10:51 PM, Michael Gehrmann wrote:
>>
>> Not just your bad luck. We have had VRRP, STP and BGP issues around ICX.
>> As an experienced engineer getting past T1 & 2 is painful with TAC.
>>
>> Cheers
>> Mike
>>
>> On 25 February 2016 at 02:45, Robert Hass <robhass@gmail.com> wrote:
>>
>>> Hi
>>> We just deployed test network running ICX switches for connecting many
>>> office users. We hit some software bugs (for example with not working OSPF
>>> as expected). We trying passing them to Brocade TAC, but my current
>>> experience is that cooperation with TAC is slow like a hell.
>>>
>>> Maybe it's just my bad luck.
>>>
>>> I'm looking for people having experiences with reporting bugs to Brocade
>>> TAC.
>>>
>>> Are you have positive experience with Brocade TAC ? How fast they can
>>> fix problems ? How professional they are ?
>>>
>>> Rob
>>>
>>>
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
>>
>> --
>> Michael Gehrmann
>> Senior Network Engineer - Atlassian
>> m: +61 407 570 658
>>
>>
>> _______________________________________________
>> foundry-nsp mailing listfoundry-nsp@puck.nether.nethttp://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>
>
> --
> Michael Gehrmann
> Senior Network Engineer - Atlassian
> m: +61 407 570 658
>

Our VAR is just as frustrated.

Frank

-----Original Message-----
From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Eldon Koyle
Sent: Wednesday, February 24, 2016 3:27 PM
To: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Experiences with Brocade TAC -> ICX products

Also, if you don't feel like TAC is handling your case as quickly as
they should, you can contact your SE and/or your VAR to put some
pressure on them.

--
Eldon

On Wed, Feb 24, 2016 at 10:32 AM, Nick Cutting <ncutting@edgetg.co.uk> wrote:
> I found with OSPF – coming from cisco world – it has a much lower maximum
> metric value.
>
> I did however fix this issue before TAC even got back to me.
>
>
> So make sure you BW values are not too small.. like tunnel interfaces etc.
>
>
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of
> Robert Hass
> Sent: 24 February 2016 15:45
> To: foundry-nsp@puck.nether.net
> Subject: [f-nsp] Experiences with Brocade TAC -> ICX products
>
>
>
> Hi
>
> We just deployed test network running ICX switches for connecting many
> office users. We hit some software bugs (for example with not working OSPF
> as expected). We trying passing them to Brocade TAC, but my current
> experience is that cooperation with TAC is slow like a hell.
>
>
>
> Maybe it's just my bad luck.
>
>
>
> I'm looking for people having experiences with reporting bugs to Brocade
> TAC.
>
>
>
> Are you have positive experience with Brocade TAC ? How fast they can fix
> problems ? How professional they are ?
>
>
>
> Rob
>
>
>
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

+1



From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Michael Gehrmann
Sent: Wednesday, February 24, 2016 4:47 PM
To: i3D.net - Martijn Schmidt <martijnschmidt@i3d.net>
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Experiences with Brocade TAC -> ICX products



Can I get that experience please. Maybe it's our timezone because we always attach 'show tech' and then spend the next few hours trying to convince them it's already attached to the ticket.



On 25 February 2016 at 09:29, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net <mailto:martijnschmidt@i3d.net> > wrote:

Maybe I've been lucky, but I have always sailed right past T1 TAC towards their L3 escalation, and if the case is marked as P1 you've got good chances of engineering getting involved on short notice.

It all comes down to how well you describe your problem when first opening the case. That means including a show tech / support-save for all of the involved devices right from the beginning, as well as a network diagram if applicable, and a good amount of text explaining the symptoms you are experiencing and the results you'd expect to see so the TAC engineer can dive right in. After your case engineer has been assigned, give them a call and walk them through the problem to make sure there are no questions on their end. Finally, cc'ing your Brocade SE into the case so they're aware something's going on never hurts.

I do have to say that if TAC identifies a new defect, you'll have to hope there is a workaround to solve your problem for the time being because it'll usually take several weeks for bugfixes to trickle down to a new GA release.

Best regards,
Martijn



On 02/24/2016 10:51 PM, Michael Gehrmann wrote:

Not just your bad luck. We have had VRRP, STP and BGP issues around ICX. As an experienced engineer getting past T1 & 2 is painful with TAC.



Cheers

Mike



On 25 February 2016 at 02:45, Robert Hass <robhass@gmail.com <mailto:robhass@gmail.com> > wrote:

Hi

We just deployed test network running ICX switches for connecting many office users. We hit some software bugs (for example with not working OSPF as expected). We trying passing them to Brocade TAC, but my current experience is that cooperation with TAC is slow like a hell.



Maybe it's just my bad luck.



I'm looking for people having experiences with reporting bugs to Brocade TAC.



Are you have positive experience with Brocade TAC ? How fast they can fix problems ? How professional they are ?



Rob






_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp







--

Michael Gehrmann

Senior Network Engineer - Atlassian

m: +61 407 570 658 <tel:%2B61%20407%20570%20658>



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp









--

Michael Gehrmann

Senior Network Engineer - Atlassian

m: +61 407 570 658

My experience has been that items that are not “service affecting right now” take many weeks to move along. We had two separate tickets resulting an ICX6650 upgrade to 8.0.3e and it took about three weeks to duplicate the (very straightforward!) bugs and then another week to assign a defect number. Both of those were affected by limited lab access/resources. I’m now on my fourth ICX ticket of the year, and it’s also not moving very quickly – just more and more questions each time, and now the case owner is asking for a few days to get feedback from dev.



Frank



From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of André Grüneberg
Sent: Wednesday, February 24, 2016 9:54 AM
To: Robert Hass <robhass@gmail.com>
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Experiences with Brocade TAC -> ICX products



Hi Rob,

My experience with Brocade support is rather positive. Usually quick initial response, helpful in really urgent cases (I called them and had an engineer on the phone for the whole time to resolution/workaround). But of course, there are several engineers and attitude might vary.

Well, sometimes your request is not fully understood and engineers seem not to have easy access to test equipment. Especially when it comes to escalations to product development, things seem to become rather slow.

André





2016-02-24 16:45 GMT+01:00 Robert Hass <robhass@gmail.com <mailto:robhass@gmail.com> >:

Hi

We just deployed test network running ICX switches for connecting many office users. We hit some software bugs (for example with not working OSPF as expected). We trying passing them to Brocade TAC, but my current experience is that cooperation with TAC is slow like a hell.



Maybe it's just my bad luck.



I'm looking for people having experiences with reporting bugs to Brocade TAC.



Are you have positive experience with Brocade TAC ? How fast they can fix problems ? How professional they are ?



Rob






_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp




--

André Grüneberg
System Architect Web Operations

The unbelievable Machine Company GmbH
Grolmanstr. 40
10623 Berlin
Tel: +49 - 30 - 889 2656 43
Mobil: +49 - 172 - 686 1254
Fax.: +49 - 30 - 889 2656 - 11

https://www.unbelievable-machine.com

*Blog | *Karriere | *Facebook | *Twitter

Geschäftsführer: Ravin Mehta, Benno Wiedfeld
Sitz der Gesellschaft: Berlin, Deutschland
Handelsregister: Amtsgericht Charlottenburg HRB 115071B
Umsatzsteuer-Identifikationsnummer: DE261090159

Ausgezeichnet: *um ist zweifacher „Big Data Leader 2016“

Come to think of it, our last ICX issue ended up going around TAC.

Apparently, some part of the LLDP parsing for SNMP dies if a device
sends LLDP packets without much useful info (ie. windows 8/10, some IP
phones, some access points), and SNMP doesn't report hostnames, etc.
on any port after that (really, I think the only thing we get is the
chassis id). This means we have a lot of uplink ports (since SFP
ports are at the end) that don't give useful LLDP info over SNMP.

After about a week, TAC replied that the LLDP-MIB is not supported on
fastiron according to the docs.

Our SE ended up pushing the issue directly to product management,
still waiting to hear back on it.

--
Eldon


On Wed, Feb 24, 2016 at 8:53 PM, <frnkblk@iname.com> wrote:
> My experience has been that items that are not “service affecting right now”
> take many weeks to move along. We had two separate tickets resulting an
> ICX6650 upgrade to 8.0.3e and it took about three weeks to duplicate the
> (very straightforward!) bugs and then another week to assign a defect
> number. Both of those were affected by limited lab access/resources. I’m
> now on my fourth ICX ticket of the year, and it’s also not moving very
> quickly – just more and more questions each time, and now the case owner is
> asking for a few days to get feedback from dev.
>
>
>
> Frank
>
>
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of
> André Grüneberg
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Robert Hass <robhass@gmail.com>
> Cc: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Experiences with Brocade TAC -> ICX products
>
>
>
> Hi Rob,
>
> My experience with Brocade support is rather positive. Usually quick initial
> response, helpful in really urgent cases (I called them and had an engineer
> on the phone for the whole time to resolution/workaround). But of course,
> there are several engineers and attitude might vary.
>
> Well, sometimes your request is not fully understood and engineers seem not
> to have easy access to test equipment. Especially when it comes to
> escalations to product development, things seem to become rather slow.
>
> André
>
>
>
>
>
> 2016-02-24 16:45 GMT+01:00 Robert Hass <robhass@gmail.com>:
>
> Hi
>
> We just deployed test network running ICX switches for connecting many
> office users. We hit some software bugs (for example with not working OSPF
> as expected). We trying passing them to Brocade TAC, but my current
> experience is that cooperation with TAC is slow like a hell.
>
>
>
> Maybe it's just my bad luck.
>
>
>
> I'm looking for people having experiences with reporting bugs to Brocade
> TAC.
>
>
>
> Are you have positive experience with Brocade TAC ? How fast they can fix
> problems ? How professional they are ?
>
>
>
> Rob
>
>
>
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>
> --
>
> André Grüneberg
> System Architect Web Operations
>
> The unbelievable Machine Company GmbH
> Grolmanstr. 40
> 10623 Berlin
> Tel: +49 - 30 - 889 2656 43
> Mobil: +49 - 172 - 686 1254
> Fax.: +49 - 30 - 889 2656 - 11
>
> https://www.unbelievable-machine.com
>
> *Blog | *Karriere | *Facebook | *Twitter
>
> Geschäftsführer: Ravin Mehta, Benno Wiedfeld
> Sitz der Gesellschaft: Berlin, Deutschland
> Handelsregister: Amtsgericht Charlottenburg HRB 115071B
> Umsatzsteuer-Identifikationsnummer: DE261090159
>
> Ausgezeichnet: *um ist zweifacher „Big Data Leader 2016“
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

We heard back a few months ago and I forgot to update this thread.
Their official response is: "The LLDP-MIB is not supported on
fastiron. Please send a feature request via your SE".

--
Eldon

On Fri, Feb 26, 2016 at 9:39 AM, Eldon Koyle
<ekoyle+puck.nether.net@gmail.com> wrote:
> Come to think of it, our last ICX issue ended up going around TAC.
>
> Apparently, some part of the LLDP parsing for SNMP dies if a device
> sends LLDP packets without much useful info (ie. windows 8/10, some IP
> phones, some access points), and SNMP doesn't report hostnames, etc.
> on any port after that (really, I think the only thing we get is the
> chassis id). This means we have a lot of uplink ports (since SFP
> ports are at the end) that don't give useful LLDP info over SNMP.
>
> After about a week, TAC replied that the LLDP-MIB is not supported on
> fastiron according to the docs.
>
> Our SE ended up pushing the issue directly to product management,
> still waiting to hear back on it.
>
> --
> Eldon
>
>
> On Wed, Feb 24, 2016 at 8:53 PM, <frnkblk@iname.com> wrote:
>> My experience has been that items that are not “service affecting right now”
>> take many weeks to move along. We had two separate tickets resulting an
>> ICX6650 upgrade to 8.0.3e and it took about three weeks to duplicate the
>> (very straightforward!) bugs and then another week to assign a defect
>> number. Both of those were affected by limited lab access/resources. I’m
>> now on my fourth ICX ticket of the year, and it’s also not moving very
>> quickly – just more and more questions each time, and now the case owner is
>> asking for a few days to get feedback from dev.
>>
>>
>>
>> Frank
>>
>>
>>
>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of
>> André Grüneberg
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Robert Hass <robhass@gmail.com>
>> Cc: foundry-nsp@puck.nether.net
>> Subject: Re: [f-nsp] Experiences with Brocade TAC -> ICX products
>>
>>
>>
>> Hi Rob,
>>
>> My experience with Brocade support is rather positive. Usually quick initial
>> response, helpful in really urgent cases (I called them and had an engineer
>> on the phone for the whole time to resolution/workaround). But of course,
>> there are several engineers and attitude might vary.
>>
>> Well, sometimes your request is not fully understood and engineers seem not
>> to have easy access to test equipment. Especially when it comes to
>> escalations to product development, things seem to become rather slow.
>>
>> André
>>
>>
>>
>>
>>
>> 2016-02-24 16:45 GMT+01:00 Robert Hass <robhass@gmail.com>:
>>
>> Hi
>>
>> We just deployed test network running ICX switches for connecting many
>> office users. We hit some software bugs (for example with not working OSPF
>> as expected). We trying passing them to Brocade TAC, but my current
>> experience is that cooperation with TAC is slow like a hell.
>>
>>
>>
>> Maybe it's just my bad luck.
>>
>>
>>
>> I'm looking for people having experiences with reporting bugs to Brocade
>> TAC.
>>
>>
>>
>> Are you have positive experience with Brocade TAC ? How fast they can fix
>> problems ? How professional they are ?
>>
>>
>>
>> Rob
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>>
>> --
>>
>> André Grüneberg
>> System Architect Web Operations
>>
>> The unbelievable Machine Company GmbH
>> Grolmanstr. 40
>> 10623 Berlin
>> Tel: +49 - 30 - 889 2656 43
>> Mobil: +49 - 172 - 686 1254
>> Fax.: +49 - 30 - 889 2656 - 11
>>
>> https://www.unbelievable-machine.com
>>
>> *Blog | *Karriere | *Facebook | *Twitter
>>
>> Geschäftsführer: Ravin Mehta, Benno Wiedfeld
>> Sitz der Gesellschaft: Berlin, Deutschland
>> Handelsregister: Amtsgericht Charlottenburg HRB 115071B
>> Umsatzsteuer-Identifikationsnummer: DE261090159
>>
>> Ausgezeichnet: *um ist zweifacher „Big Data Leader 2016“
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp