Mailing List Archive

Hi,

Nothing notable for me, atm... I have been running it on a couple of my
CER-RT, withing a quite simple setup (BGP Fullview with
IX/MPLS-LDP/OSPF) and everything went fine, in my setup.

--
Clément Cavadore

On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr wrote:
> Hello,
>
> Anyone running NI5.6 on MLXe/CER-RT out there ?
>
>
> Any gotchas of nasty things to be aware of ?
>
>
> Thank you for your feedbacks.
>
>
> Best regards.
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
> _______________________________________________
> 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

Hello,

Thank you for the feedback Clement.

Looking for someone running MLXe + CER-RT with :

ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full views

Very basic setup.

Thanks.




2014-02-19 10:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:

> Hi,
>
> Nothing notable for me, atm... I have been running it on a couple of my
> CER-RT, withing a quite simple setup (BGP Fullview with
> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
>
> --
> Clément Cavadore
>
> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr wrote:
> > Hello,
> >
> > Anyone running NI5.6 on MLXe/CER-RT out there ?
> >
> >
> > Any gotchas of nasty things to be aware of ?
> >
> >
> > Thank you for your feedbacks.
> >
> >
> > Best regards.
> >
> >
> >
> > --
> > Youssef BENGELLOUN-ZAHR
> >
> > _______________________________________________
> > foundry-nsp mailing list
> > foundry-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>


--
Youssef BENGELLOUN-ZAHR

Hello,

Anyone else ?

Best regards.



> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>
> Hello,
>
> Thank you for the feedback Clement.
>
> Looking for someone running MLXe + CER-RT with :
>
> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full views
>
> Very basic setup.
>
> Thanks.
>
>
>
>
> 2014-02-19 10:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:
>> Hi,
>>
>> Nothing notable for me, atm... I have been running it on a couple of my
>> CER-RT, withing a quite simple setup (BGP Fullview with
>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
>>
>> --
>> Clément Cavadore
>>
>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr wrote:
>> > Hello,
>> >
>> > Anyone running NI5.6 on MLXe/CER-RT out there ?
>> >
>> >
>> > Any gotchas of nasty things to be aware of ?
>> >
>> >
>> > Thank you for your feedbacks.
>> >
>> >
>> > Best regards.
>> >
>> >
>> >
>> > --
>> > Youssef BENGELLOUN-ZAHR
>> >
>> > _______________________________________________
>> > foundry-nsp mailing list
>> > foundry-nsp@puck.nether.net
>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> --
> Youssef BENGELLOUN-ZAHR

Hello again Youssef,

Since the first message, I have noticed what seems to be a cosmetic bug
(since it does not hurt anything, afaik) on the last 5.6:

I have that kind of messages in my logs:
Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13 to MAC 001b.5374.6976 / port 1/13
Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port 1/13
Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed from MAC c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13
Feb 16 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to MAC 001b.2189.d2a6 / port 1/13
Feb 16 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port 1/13

There is no MAC change or physical port change, 1/13 is connected to an
IX (tagged mode, vlan 2 + ve2), and is route-only.

Regards,

--
Clément

On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
> Hello,
>
>
> Anyone else ?
>
>
> Best regards.
>
>
>
>
> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr> a
> écrit :
>
>
> > Hello,
> >
> > Thank you for the feedback Clement.
> >
> > Looking for someone running MLXe + CER-RT with :
> >
> >
> > ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full views
> >
> >
> > Very basic setup.
> >
> >
> > Thanks.
> >
> >
> >
> >
> > 2014-02-19 10:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:
> > Hi,
> >
> > Nothing notable for me, atm... I have been running it on a
> > couple of my
> > CER-RT, withing a quite simple setup (BGP Fullview with
> > IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
> >
> > --
> > Clément Cavadore
> >
> > On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
> > wrote:
> > > Hello,
> > >
> > > Anyone running NI5.6 on MLXe/CER-RT out there ?
> > >
> > >
> > > Any gotchas of nasty things to be aware of ?
> > >
> > >
> > > Thank you for your feedbacks.
> > >
> > >
> > > Best regards.
> > >
> > >
> > >
> > > --
> > > Youssef BENGELLOUN-ZAHR
> > >
> >
> > > _______________________________________________
> > > foundry-nsp mailing list
> > > foundry-nsp@puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/foundry-nsp
> >
> >
> >
> >
> >
> > --
> > Youssef BENGELLOUN-ZAHR
> >
> _______________________________________________
> 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

Hello,

Preparing deployment of 5.6c code. Any nasty things to be aware of ?

Y.



> Le 1 mars 2014 à 14:18, Clement Cavadore <clement@cavadore.net> a écrit :
>
> Hello again Youssef,
>
> Since the first message, I have noticed what seems to be a cosmetic bug
> (since it does not hurt anything, afaik) on the last 5.6:
>
> I have that kind of messages in my logs:
> Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13 to MAC 001b.5374.6976 / port 1/13
> Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port 1/13
> Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed from MAC c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13
> Feb 16 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to MAC 001b.2189.d2a6 / port 1/13
> Feb 16 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port 1/13
>
> There is no MAC change or physical port change, 1/13 is connected to an
> IX (tagged mode, vlan 2 + ve2), and is route-only.
>
> Regards,
>
> --
> Clément
>
>> On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
>> Hello,
>>
>>
>> Anyone else ?
>>
>>
>> Best regards.
>>
>>
>>
>>
>> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr> a
>> écrit :
>>
>>
>>> Hello,
>>>
>>> Thank you for the feedback Clement.
>>>
>>> Looking for someone running MLXe + CER-RT with :
>>>
>>>
>>> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full views
>>>
>>>
>>> Very basic setup.
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> 2014-02-19 10:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:
>>> Hi,
>>>
>>> Nothing notable for me, atm... I have been running it on a
>>> couple of my
>>> CER-RT, withing a quite simple setup (BGP Fullview with
>>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
>>>
>>> --
>>> Clément Cavadore
>>>
>>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
>>> wrote:
>>>> Hello,
>>>>
>>>> Anyone running NI5.6 on MLXe/CER-RT out there ?
>>>>
>>>>
>>>> Any gotchas of nasty things to be aware of ?
>>>>
>>>>
>>>> Thank you for your feedbacks.
>>>>
>>>>
>>>> Best regards.
>>>>
>>>>
>>>>
>>>> --
>>>> Youssef BENGELLOUN-ZAHR
>>>
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp@puck.nether.net
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Youssef BENGELLOUN-ZAHR
>> _______________________________________________
>> 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

Hi Youssef,

I would not recommend to use this code. We tried it on a MLXe-8. We
just did a downgrade this morning because we ran into memory issues.
First we were not able to connect via SSH to the IPv6 loopback address
(v4 worked), later we were not able to connect via IPv4 as well. And
finally we did not get any SNMP output anymore. Since the downgrade
it's running stable again.

We run BGP/OSPF/MPLS-LDP (VPLS/VLL)/IPv4 and IPv6 unicast BGP.

Unfortunately I did not have the time to look deeper into it.

Regards,

Markus

On Fri, 23 May 2014 17:47:07 +0200
Youssef Bengelloun-Zahr <youssef@720.fr> wrote:

> Hello,
>
> Preparing deployment of 5.6c code. Any nasty things to be aware of ?
>
> Y.
>
>
>
> > Le 1 mars 2014 à 14:18, Clement Cavadore <clement@cavadore.net> a
> > écrit :
> >
> > Hello again Youssef,
> >
> > Since the first message, I have noticed what seems to be a cosmetic
> > bug (since it does not hurt anything, afaik) on the last 5.6:
> >
> > I have that kind of messages in my logs:
> > Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx
> > MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13
> > to MAC 001b.5374.6976 / port 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2
> > IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed
> > from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port
> > 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address
> > 194.68.129.yyy MAC movement detected, changed from MAC
> > c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13 Feb 16
> > 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC
> > movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to
> > MAC 001b.2189.d2a6 / port 1/13 Feb 16 03:20:11 rt-th2/lo1-rt-th2
> > IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed
> > from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port
> > 1/13
> >
> > There is no MAC change or physical port change, 1/13 is connected
> > to an IX (tagged mode, vlan 2 + ve2), and is route-only.
> >
> > Regards,
> >
> > --
> > Clément
> >
> >> On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
> >> Hello,
> >>
> >>
> >> Anyone else ?
> >>
> >>
> >> Best regards.
> >>
> >>
> >>
> >>
> >> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr>
> >> a écrit :
> >>
> >>
> >>> Hello,
> >>>
> >>> Thank you for the feedback Clement.
> >>>
> >>> Looking for someone running MLXe + CER-RT with :
> >>>
> >>>
> >>> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full
> >>> views
> >>>
> >>>
> >>> Very basic setup.
> >>>
> >>>
> >>> Thanks.
> >>>
> >>>
> >>>
> >>>
> >>> 2014-02-19 10:08 GMT+01:00 Clement Cavadore
> >>> <clement@cavadore.net>: Hi,
> >>>
> >>> Nothing notable for me, atm... I have been running it on a
> >>> couple of my
> >>> CER-RT, withing a quite simple setup (BGP Fullview with
> >>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
> >>>
> >>> --
> >>> Clément Cavadore
> >>>
> >>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
> >>> wrote:
> >>>> Hello,
> >>>>
> >>>> Anyone running NI5.6 on MLXe/CER-RT out there ?
> >>>>
> >>>>
> >>>> Any gotchas of nasty things to be aware of ?
> >>>>
> >>>>
> >>>> Thank you for your feedbacks.
> >>>>
> >>>>
> >>>> Best regards.
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Youssef BENGELLOUN-ZAHR
> >>>
> >>>> _______________________________________________
> >>>> foundry-nsp mailing list
> >>>> foundry-nsp@puck.nether.net
> >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Youssef BENGELLOUN-ZAHR
> >> _______________________________________________
> >> 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


--
Markus Wellauer

---------------------
Fiber7. No Limits.
https://www.fiber7.ch
---------------------

Init7 (Switzerland) Ltd
AS13030
St. Georgen-Strasse 70
CH-8400 Winterthur
phone: +41 44 315 44 00
fax: +41 44 315 44 01
twitter: @init7_noc
http://www.init7.net/

Hello,

Thanks for the feedback. I was planing to run 56b but Brocade advised us
not to do that because of TSB TSB 2014-184-A :

"This is a high severity operational issue.

Affected Products:
NetIron XMR/MLX/CER/CES, MLX-e (5.6.00a and 5.6.00b only)

Corrected in Release:
5.6.00c and above

Bulletin Overview:
Facility FRR LSPs may drop traffic after local-repair, i.e., failover to
backup."

I thought I would sit this one out and wait for 56c which corrects an awful
lot of DEFECTS when reading the release notes.

Anyone else out there ?

Y.



2014-05-23 18:16 GMT+02:00 Markus Wellauer <wellauer@init7.net>:

> Hi Youssef,
>
> I would not recommend to use this code. We tried it on a MLXe-8. We
> just did a downgrade this morning because we ran into memory issues.
> First we were not able to connect via SSH to the IPv6 loopback address
> (v4 worked), later we were not able to connect via IPv4 as well. And
> finally we did not get any SNMP output anymore. Since the downgrade
> it's running stable again.
>
> We run BGP/OSPF/MPLS-LDP (VPLS/VLL)/IPv4 and IPv6 unicast BGP.
>
> Unfortunately I did not have the time to look deeper into it.
>
> Regards,
>
> Markus
>
> On Fri, 23 May 2014 17:47:07 +0200
> Youssef Bengelloun-Zahr <youssef@720.fr> wrote:
>
> > Hello,
> >
> > Preparing deployment of 5.6c code. Any nasty things to be aware of ?
> >
> > Y.
> >
> >
> >
> > > Le 1 mars 2014 à 14:18, Clement Cavadore <clement@cavadore.net> a
> > > écrit :
> > >
> > > Hello again Youssef,
> > >
> > > Since the first message, I have noticed what seems to be a cosmetic
> > > bug (since it does not hurt anything, afaik) on the last 5.6:
> > >
> > > I have that kind of messages in my logs:
> > > Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx
> > > MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13
> > > to MAC 001b.5374.6976 / port 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2
> > > IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed
> > > from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port
> > > 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address
> > > 194.68.129.yyy MAC movement detected, changed from MAC
> > > c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13 Feb 16
> > > 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC
> > > movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to
> > > MAC 001b.2189.d2a6 / port 1/13 Feb 16 03:20:11 rt-th2/lo1-rt-th2
> > > IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed
> > > from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port
> > > 1/13
> > >
> > > There is no MAC change or physical port change, 1/13 is connected
> > > to an IX (tagged mode, vlan 2 + ve2), and is route-only.
> > >
> > > Regards,
> > >
> > > --
> > > Clément
> > >
> > >> On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
> > >> Hello,
> > >>
> > >>
> > >> Anyone else ?
> > >>
> > >>
> > >> Best regards.
> > >>
> > >>
> > >>
> > >>
> > >> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr>
> > >> a écrit :
> > >>
> > >>
> > >>> Hello,
> > >>>
> > >>> Thank you for the feedback Clement.
> > >>>
> > >>> Looking for someone running MLXe + CER-RT with :
> > >>>
> > >>>
> > >>> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full
> > >>> views
> > >>>
> > >>>
> > >>> Very basic setup.
> > >>>
> > >>>
> > >>> Thanks.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 2014-02-19 10:08 GMT+01:00 Clement Cavadore
> > >>> <clement@cavadore.net>: Hi,
> > >>>
> > >>> Nothing notable for me, atm... I have been running it on a
> > >>> couple of my
> > >>> CER-RT, withing a quite simple setup (BGP Fullview with
> > >>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
> > >>>
> > >>> --
> > >>> Clément Cavadore
> > >>>
> > >>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
> > >>> wrote:
> > >>>> Hello,
> > >>>>
> > >>>> Anyone running NI5.6 on MLXe/CER-RT out there ?
> > >>>>
> > >>>>
> > >>>> Any gotchas of nasty things to be aware of ?
> > >>>>
> > >>>>
> > >>>> Thank you for your feedbacks.
> > >>>>
> > >>>>
> > >>>> Best regards.
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Youssef BENGELLOUN-ZAHR
> > >>>
> > >>>> _______________________________________________
> > >>>> foundry-nsp mailing list
> > >>>> foundry-nsp@puck.nether.net
> > >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Youssef BENGELLOUN-ZAHR
> > >> _______________________________________________
> > >> 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
>
>
> --
> Markus Wellauer
>
> ---------------------
> Fiber7. No Limits.
> https://www.fiber7.ch
> ---------------------
>
> Init7 (Switzerland) Ltd
> AS13030
> St. Georgen-Strasse 70
> CH-8400 Winterthur
> phone: +41 44 315 44 00
> fax: +41 44 315 44 01
> twitter: @init7_noc
> http://www.init7.net/
>



--
Youssef BENGELLOUN-ZAHR

As my colleague Markus already mentioned, 5.6c is seriously broken.

We (Init7 / AS13030) run 5.5d on most boxes (XMR, MLXe, CER) with full mesh iBGP (about 40 neighbors), hundreds of eBGP, both v4/v6, OSPF and MPLS really stable for months. If you are good with the 5.5 feature set and want to be on the safe side go for 5.5d.

--
Fredy Kuenzler
Init7 (Switzerland) Ltd.
St.-Georgen-Strasse 70
CH-8400 Winterthur
Switzerland

http://www.init7.net/


> Am 23.05.2014 um 18:22 schrieb Youssef Bengelloun-Zahr <youssef@720.fr>:
>
> Hello,
>
> Thanks for the feedback. I was planing to run 56b but Brocade advised us not to do that because of TSB TSB 2014-184-A :
>
> "This is a high severity operational issue.
>
> Affected Products:
> NetIron XMR/MLX/CER/CES, MLX-e (5.6.00a and 5.6.00b only)
>
> Corrected in Release:
> 5.6.00c and above
>
> Bulletin Overview:
> Facility FRR LSPs may drop traffic after local-repair, i.e., failover to backup."
>
> I thought I would sit this one out and wait for 56c which corrects an awful lot of DEFECTS when reading the release notes.
>
> Anyone else out there ?
>
> Y.
>
>
>
> 2014-05-23 18:16 GMT+02:00 Markus Wellauer <wellauer@init7.net>:
>> Hi Youssef,
>>
>> I would not recommend to use this code. We tried it on a MLXe-8. We
>> just did a downgrade this morning because we ran into memory issues.
>> First we were not able to connect via SSH to the IPv6 loopback address
>> (v4 worked), later we were not able to connect via IPv4 as well. And
>> finally we did not get any SNMP output anymore. Since the downgrade
>> it's running stable again.
>>
>> We run BGP/OSPF/MPLS-LDP (VPLS/VLL)/IPv4 and IPv6 unicast BGP.
>>
>> Unfortunately I did not have the time to look deeper into it.
>>
>> Regards,
>>
>> Markus
>>
>> On Fri, 23 May 2014 17:47:07 +0200
>> Youssef Bengelloun-Zahr <youssef@720.fr> wrote:
>>
>> > Hello,
>> >
>> > Preparing deployment of 5.6c code. Any nasty things to be aware of ?
>> >
>> > Y.
>> >
>> >
>> >
>> > > Le 1 mars 2014 à 14:18, Clement Cavadore <clement@cavadore.net> a
>> > > écrit :
>> > >
>> > > Hello again Youssef,
>> > >
>> > > Since the first message, I have noticed what seems to be a cosmetic
>> > > bug (since it does not hurt anything, afaik) on the last 5.6:
>> > >
>> > > I have that kind of messages in my logs:
>> > > Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx
>> > > MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13
>> > > to MAC 001b.5374.6976 / port 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2
>> > > IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed
>> > > from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port
>> > > 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address
>> > > 194.68.129.yyy MAC movement detected, changed from MAC
>> > > c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13 Feb 16
>> > > 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC
>> > > movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to
>> > > MAC 001b.2189.d2a6 / port 1/13 Feb 16 03:20:11 rt-th2/lo1-rt-th2
>> > > IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed
>> > > from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port
>> > > 1/13
>> > >
>> > > There is no MAC change or physical port change, 1/13 is connected
>> > > to an IX (tagged mode, vlan 2 + ve2), and is route-only.
>> > >
>> > > Regards,
>> > >
>> > > --
>> > > Clément
>> > >
>> > >> On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
>> > >> Hello,
>> > >>
>> > >>
>> > >> Anyone else ?
>> > >>
>> > >>
>> > >> Best regards.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr>
>> > >> a écrit :
>> > >>
>> > >>
>> > >>> Hello,
>> > >>>
>> > >>> Thank you for the feedback Clement.
>> > >>>
>> > >>> Looking for someone running MLXe + CER-RT with :
>> > >>>
>> > >>>
>> > >>> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full
>> > >>> views
>> > >>>
>> > >>>
>> > >>> Very basic setup.
>> > >>>
>> > >>>
>> > >>> Thanks.
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2014-02-19 10:08 GMT+01:00 Clement Cavadore
>> > >>> <clement@cavadore.net>: Hi,
>> > >>>
>> > >>> Nothing notable for me, atm... I have been running it on a
>> > >>> couple of my
>> > >>> CER-RT, withing a quite simple setup (BGP Fullview with
>> > >>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
>> > >>>
>> > >>> --
>> > >>> Clément Cavadore
>> > >>>
>> > >>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
>> > >>> wrote:
>> > >>>> Hello,
>> > >>>>
>> > >>>> Anyone running NI5.6 on MLXe/CER-RT out there ?
>> > >>>>
>> > >>>>
>> > >>>> Any gotchas of nasty things to be aware of ?
>> > >>>>
>> > >>>>
>> > >>>> Thank you for your feedbacks.
>> > >>>>
>> > >>>>
>> > >>>> Best regards.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>> Youssef BENGELLOUN-ZAHR
>> > >>>
>> > >>>> _______________________________________________
>> > >>>> foundry-nsp mailing list
>> > >>>> foundry-nsp@puck.nether.net
>> > >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Youssef BENGELLOUN-ZAHR
>> > >> _______________________________________________
>> > >> 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
>>
>>
>> --
>> Markus Wellauer
>>
>> ---------------------
>> Fiber7. No Limits.
>> https://www.fiber7.ch
>> ---------------------
>>
>> Init7 (Switzerland) Ltd
>> AS13030
>> St. Georgen-Strasse 70
>> CH-8400 Winterthur
>> phone: +41 44 315 44 00
>> fax: +41 44 315 44 01
>> twitter: @init7_noc
>> http://www.init7.net/
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

Hello,

Thank you for your feedback. Well, that's the point : I'm interested with
5.6 feature set.

I've been running 56b on a CER-RT for a month now, it's been steady and
stable (even for a backup box). I think I'll keep away from 56c for now and
go with b.

Am I the only one who's noticed that preparing upgrades with $B looks very
much like playing the russian roulette ? Don' get me wrong, it's the same
with other vendors.

Y.




2014-05-23 20:01 GMT+02:00 Fredy Kuenzler <kuenzler@init7.net>:

> As my colleague Markus already mentioned, 5.6c is seriously broken.
>
> We (Init7 / AS13030) run 5.5d on most boxes (XMR, MLXe, CER) with full
> mesh iBGP (about 40 neighbors), hundreds of eBGP, both v4/v6, OSPF and MPLS
> really stable for months. If you are good with the 5.5 feature set and want
> to be on the safe side go for 5.5d.
>
> --
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
> St.-Georgen-Strasse 70
> CH-8400 Winterthur
> Switzerland
>
> http://www.init7.net/
>
>
> Am 23.05.2014 um 18:22 schrieb Youssef Bengelloun-Zahr <youssef@720.fr>:
>
> Hello,
>
> Thanks for the feedback. I was planing to run 56b but Brocade advised us
> not to do that because of TSB TSB 2014-184-A :
>
> "This is a high severity operational issue.
>
> Affected Products:
> NetIron XMR/MLX/CER/CES, MLX-e (5.6.00a and 5.6.00b only)
>
> Corrected in Release:
> 5.6.00c and above
>
> Bulletin Overview:
> Facility FRR LSPs may drop traffic after local-repair, i.e., failover to
> backup."
>
> I thought I would sit this one out and wait for 56c which corrects an
> awful lot of DEFECTS when reading the release notes.
>
> Anyone else out there ?
>
> Y.
>
>
>
> 2014-05-23 18:16 GMT+02:00 Markus Wellauer <wellauer@init7.net>:
>
>> Hi Youssef,
>>
>> I would not recommend to use this code. We tried it on a MLXe-8. We
>> just did a downgrade this morning because we ran into memory issues.
>> First we were not able to connect via SSH to the IPv6 loopback address
>> (v4 worked), later we were not able to connect via IPv4 as well. And
>> finally we did not get any SNMP output anymore. Since the downgrade
>> it's running stable again.
>>
>> We run BGP/OSPF/MPLS-LDP (VPLS/VLL)/IPv4 and IPv6 unicast BGP.
>>
>> Unfortunately I did not have the time to look deeper into it.
>>
>> Regards,
>>
>> Markus
>>
>> On Fri, 23 May 2014 17:47:07 +0200
>> Youssef Bengelloun-Zahr <youssef@720.fr> wrote:
>>
>> > Hello,
>> >
>> > Preparing deployment of 5.6c code. Any nasty things to be aware of ?
>> >
>> > Y.
>> >
>> >
>> >
>> > > Le 1 mars 2014 à 14:18, Clement Cavadore <clement@cavadore.net> a
>> > > écrit :
>> > >
>> > > Hello again Youssef,
>> > >
>> > > Since the first message, I have noticed what seems to be a cosmetic
>> > > bug (since it does not hurt anything, afaik) on the last 5.6:
>> > >
>> > > I have that kind of messages in my logs:
>> > > Feb 15 23:55:18 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.xxx
>> > > MAC movement detected, changed from MAC 001b.53f4.6976 / port 1/13
>> > > to MAC 001b.5374.6976 / port 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2
>> > > IP/ARP: IP address 194.68.129.yyy MAC movement detected, changed
>> > > from MAC c47d.4f6b.7ac0 / port 1/13 to MAC c47d.4feb.7ac0 / port
>> > > 1/13 Feb 16 03:02:33 rt-th2/lo1-rt-th2 IP/ARP: IP address
>> > > 194.68.129.yyy MAC movement detected, changed from MAC
>> > > c47d.4feb.7ac0 / port 1/13 to MAC c47d.4f6b.7ac0 / port 1/13 Feb 16
>> > > 03:20:11 rt-th2/lo1-rt-th2 IP/ARP: IP address 194.68.129.zzz MAC
>> > > movement detected, changed from MAC 001b.2109.d2a6 / port 1/13 to
>> > > MAC 001b.2189.d2a6 / port 1/13 Feb 16 03:20:11 rt-th2/lo1-rt-th2
>> > > IP/ARP: IP address 194.68.129.zzz MAC movement detected, changed
>> > > from MAC 001b.2189.d2a6 / port 1/13 to MAC 001b.2109.d2a6 / port
>> > > 1/13
>> > >
>> > > There is no MAC change or physical port change, 1/13 is connected
>> > > to an IX (tagged mode, vlan 2 + ve2), and is route-only.
>> > >
>> > > Regards,
>> > >
>> > > --
>> > > Clément
>> > >
>> > >> On Sat, 2014-03-01 at 11:57 +0000, Youssef Bengelloun-Zahr wrote:
>> > >> Hello,
>> > >>
>> > >>
>> > >> Anyone else ?
>> > >>
>> > >>
>> > >> Best regards.
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Le 19 févr. 2014 à 09:48, Youssef Bengelloun-Zahr <youssef@720.fr>
>> > >> a écrit :
>> > >>
>> > >>
>> > >>> Hello,
>> > >>>
>> > >>> Thank you for the feedback Clement.
>> > >>>
>> > >>> Looking for someone running MLXe + CER-RT with :
>> > >>>
>> > >>>
>> > >>> ISIS / BFD / MPLS-LDP (VPLS mostly) / MPLS-RSVP-TE / BGP full
>> > >>> views
>> > >>>
>> > >>>
>> > >>> Very basic setup.
>> > >>>
>> > >>>
>> > >>> Thanks.
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2014-02-19 10:08 GMT+01:00 Clement Cavadore
>> > >>> <clement@cavadore.net>: Hi,
>> > >>>
>> > >>> Nothing notable for me, atm... I have been running it on a
>> > >>> couple of my
>> > >>> CER-RT, withing a quite simple setup (BGP Fullview with
>> > >>> IX/MPLS-LDP/OSPF) and everything went fine, in my setup.
>> > >>>
>> > >>> --
>> > >>> Clément Cavadore
>> > >>>
>> > >>> On Wed, 2014-02-19 at 10:03 +0100, Youssef Bengelloun-Zahr
>> > >>> wrote:
>> > >>>> Hello,
>> > >>>>
>> > >>>> Anyone running NI5.6 on MLXe/CER-RT out there ?
>> > >>>>
>> > >>>>
>> > >>>> Any gotchas of nasty things to be aware of ?
>> > >>>>
>> > >>>>
>> > >>>> Thank you for your feedbacks.
>> > >>>>
>> > >>>>
>> > >>>> Best regards.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>> Youssef BENGELLOUN-ZAHR
>> > >>>
>> > >>>> _______________________________________________
>> > >>>> foundry-nsp mailing list
>> > >>>> foundry-nsp@puck.nether.net
>> > >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Youssef BENGELLOUN-ZAHR
>> > >> _______________________________________________
>> > >> 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
>>
>>
>> --
>> Markus Wellauer
>>
>> ---------------------
>> Fiber7. No Limits.
>> https://www.fiber7.ch
>> ---------------------
>>
>> Init7 (Switzerland) Ltd
>> AS13030
>> St. Georgen-Strasse 70
>> CH-8400 Winterthur
>> phone: +41 44 315 44 00
>> fax: +41 44 315 44 01
>> twitter: @init7_noc
>> http://www.init7.net/
>>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>


--
Youssef BENGELLOUN-ZAH

Hi,

(Apologies for not quoting, etc as I don't have the original email in my
mailbox)

Too bad that 5.6 seems 'buggy' ... some of it's new features look nice, and
I was planning to put it on a new box...
now I'm not so sure about that any longer...


Also interesting that you seem to run 5.5d without problems, as we came
across a bug in 5.5 with regards
to the IPv6 route cache - DEFECT000500944

Due to it's characteristics, my guess would be that we really can't be the
only one that faced that problem ? :)

The issue is that after a link between 2 MLXe's fails and the IGP selects a
different path ... it fails to update the IPv6 cache.
However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
through the router appears to keep working without issue and
everything _seems_ correctly (even from looking at CAM), only traffic
originated from the router itself (eg. loopback) is still pointing
to the wrong interface, which for example affected IPv6 iBGP sessions in our
case.

The provided method to resolve it is to manually clear the IPv6 cache by
running "clear ipv6 cache"
(Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
DEFECT000503937)


According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
with IS-IS and OSPF.
In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
v5.5d and v5.5e
Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.


Just wondering if anyone else faced this as well ?


Best regards,

Wouter

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

Hi,

Interesting... Did TAC give you 56d GA release date ?

Y.



> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
>
> Hi,
>
> (Apologies for not quoting, etc as I don't have the original email in my
> mailbox)
>
> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice, and
> I was planning to put it on a new box...
> now I'm not so sure about that any longer...
>
>
> Also interesting that you seem to run 5.5d without problems, as we came
> across a bug in 5.5 with regards
> to the IPv6 route cache - DEFECT000500944
>
> Due to it's characteristics, my guess would be that we really can't be the
> only one that faced that problem ? :)
>
> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> different path ... it fails to update the IPv6 cache.
> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> through the router appears to keep working without issue and
> everything _seems_ correctly (even from looking at CAM), only traffic
> originated from the router itself (eg. loopback) is still pointing
> to the wrong interface, which for example affected IPv6 iBGP sessions in our
> case.
>
> The provided method to resolve it is to manually clear the IPv6 cache by
> running "clear ipv6 cache"
> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> DEFECT000503937)
>
>
> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> with IS-IS and OSPF.
> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> v5.5d and v5.5e
> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
>
>
> Just wondering if anyone else faced this as well ?
>
>
> Best regards,
>
> Wouter
>
> _______________________________________________
> 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

Hi,

Answering my own post. Just heard from my SE, 56d GA is targeted for July 16th.

Best regards.



> Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>
> Hi,
>
> Interesting... Did TAC give you 56d GA release date ?
>
> Y.
>
>
>
>> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
>>
>> Hi,
>>
>> (Apologies for not quoting, etc as I don't have the original email in my
>> mailbox)
>>
>> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice, and
>> I was planning to put it on a new box...
>> now I'm not so sure about that any longer...
>>
>>
>> Also interesting that you seem to run 5.5d without problems, as we came
>> across a bug in 5.5 with regards
>> to the IPv6 route cache - DEFECT000500944
>>
>> Due to it's characteristics, my guess would be that we really can't be the
>> only one that faced that problem ? :)
>>
>> The issue is that after a link between 2 MLXe's fails and the IGP selects a
>> different path ... it fails to update the IPv6 cache.
>> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
>> through the router appears to keep working without issue and
>> everything _seems_ correctly (even from looking at CAM), only traffic
>> originated from the router itself (eg. loopback) is still pointing
>> to the wrong interface, which for example affected IPv6 iBGP sessions in our
>> case.
>>
>> The provided method to resolve it is to manually clear the IPv6 cache by
>> running "clear ipv6 cache"
>> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
>> DEFECT000503937)
>>
>>
>> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
>> with IS-IS and OSPF.
>> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
>> v5.5d and v5.5e
>> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
>>
>>
>> Just wondering if anyone else faced this as well ?
>>
>>
>> Best regards,
>>
>> Wouter
>>
>> _______________________________________________
>> 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

Hi Youssef,

OK, that is the same date I received :)

Regards,

Wouter

> -----Original Message-----
> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
> Sent: Sunday, May 25, 2014 22:16
> To: Wouter de Jong
> Cc: <foundry-nsp@puck.nether.net>
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> Answering my own post. Just heard from my SE, 56d GA is targeted for
> July 16th.
>
> Best regards.
>
>
>
> > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
> :
> >
> > Hi,
> >
> > Interesting... Did TAC give you 56d GA release date ?
> >
> > Y.
> >
> >
> >
> >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> >>
> >> Hi,
> >>
> >> (Apologies for not quoting, etc as I don't have the original email in my
> >> mailbox)
> >>
> >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> and
> >> I was planning to put it on a new box...
> >> now I'm not so sure about that any longer...
> >>
> >>
> >> Also interesting that you seem to run 5.5d without problems, as we
> came
> >> across a bug in 5.5 with regards
> >> to the IPv6 route cache - DEFECT000500944
> >>
> >> Due to it's characteristics, my guess would be that we really can't be
> the
> >> only one that faced that problem ? :)
> >>
> >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> >> different path ... it fails to update the IPv6 cache.
> >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> >> through the router appears to keep working without issue and
> >> everything _seems_ correctly (even from looking at CAM), only traffic
> >> originated from the router itself (eg. loopback) is still pointing
> >> to the wrong interface, which for example affected IPv6 iBGP sessions
> in our
> >> case.
> >>
> >> The provided method to resolve it is to manually clear the IPv6 cache
> by
> >> running "clear ipv6 cache"
> >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> >> DEFECT000503937)
> >>
> >>
> >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> >> with IS-IS and OSPF.
> >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> >> v5.5d and v5.5e
> >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> >>
> >>
> >> Just wondering if anyone else faced this as well ?
> >>
> >>
> >> Best regards,
> >>
> >> Wouter
> >>
> >> _______________________________________________
> >> 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

Hi,

I hope this one will be more mature and stable :-)

Y.



2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:

> Hi Youssef,
>
> OK, that is the same date I received :)
>
> Regards,
>
> Wouter
>
> > -----Original Message-----
> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
> > Sent: Sunday, May 25, 2014 22:16
> > To: Wouter de Jong
> > Cc: <foundry-nsp@puck.nether.net>
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
> > Hi,
> >
> > Answering my own post. Just heard from my SE, 56d GA is targeted for
> > July 16th.
> >
> > Best regards.
> >
> >
> >
> > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a
> écrit
> > :
> > >
> > > Hi,
> > >
> > > Interesting... Did TAC give you 56d GA release date ?
> > >
> > > Y.
> > >
> > >
> > >
> > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> > >>
> > >> Hi,
> > >>
> > >> (Apologies for not quoting, etc as I don't have the original email in
> my
> > >> mailbox)
> > >>
> > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look
> nice,
> > and
> > >> I was planning to put it on a new box...
> > >> now I'm not so sure about that any longer...
> > >>
> > >>
> > >> Also interesting that you seem to run 5.5d without problems, as we
> > came
> > >> across a bug in 5.5 with regards
> > >> to the IPv6 route cache - DEFECT000500944
> > >>
> > >> Due to it's characteristics, my guess would be that we really can't be
> > the
> > >> only one that faced that problem ? :)
> > >>
> > >> The issue is that after a link between 2 MLXe's fails and the IGP
> selects a
> > >> different path ... it fails to update the IPv6 cache.
> > >> However, it updates the RIB, etc correctly .... so IPv6 traffic
> transiting
> > >> through the router appears to keep working without issue and
> > >> everything _seems_ correctly (even from looking at CAM), only traffic
> > >> originated from the router itself (eg. loopback) is still pointing
> > >> to the wrong interface, which for example affected IPv6 iBGP sessions
> > in our
> > >> case.
> > >>
> > >> The provided method to resolve it is to manually clear the IPv6 cache
> > by
> > >> running "clear ipv6 cache"
> > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> > >> DEFECT000503937)
> > >>
> > >>
> > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and
> both
> > >> with IS-IS and OSPF.
> > >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS,
> with
> > >> v5.5d and v5.5e
> > >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> > >>
> > >>
> > >> Just wondering if anyone else faced this as well ?
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Wouter
> > >>
> > >> _______________________________________________
> > >> foundry-nsp mailing list
> > >> foundry-nsp@puck.nether.net
> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>



--
Youssef BENGELLOUN-ZAHR

Will be interesting to hear your feedback in a few months !!

Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!

Kindest Regards

James Braunegg
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666
W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21


[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, May 26, 2014 6:48 PM
To: Wouter de Jong
Cc: <foundry-nsp@puck.nether.net>
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi,
I hope this one will be more mature and stable :-)
Y.

2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>>:
Hi Youssef,

OK, that is the same date I received :)

Regards,

Wouter

> -----Original Message-----
> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr<mailto:youssef@720.fr>]
> Sent: Sunday, May 25, 2014 22:16
> To: Wouter de Jong
> Cc: <foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>>
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> Answering my own post. Just heard from my SE, 56d GA is targeted for
> July 16th.
>
> Best regards.
>
>
>
> > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr<mailto:youssef@720.fr>> a écrit
> :
> >
> > Hi,
> >
> > Interesting... Did TAC give you 56d GA release date ?
> >
> > Y.
> >
> >
> >
> >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>> a écrit :
> >>
> >> Hi,
> >>
> >> (Apologies for not quoting, etc as I don't have the original email in my
> >> mailbox)
> >>
> >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> and
> >> I was planning to put it on a new box...
> >> now I'm not so sure about that any longer...
> >>
> >>
> >> Also interesting that you seem to run 5.5d without problems, as we
> came
> >> across a bug in 5.5 with regards
> >> to the IPv6 route cache - DEFECT000500944
> >>
> >> Due to it's characteristics, my guess would be that we really can't be
> the
> >> only one that faced that problem ? :)
> >>
> >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> >> different path ... it fails to update the IPv6 cache.
> >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> >> through the router appears to keep working without issue and
> >> everything _seems_ correctly (even from looking at CAM), only traffic
> >> originated from the router itself (eg. loopback) is still pointing
> >> to the wrong interface, which for example affected IPv6 iBGP sessions
> in our
> >> case.
> >>
> >> The provided method to resolve it is to manually clear the IPv6 cache
> by
> >> running "clear ipv6 cache"
> >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> >> DEFECT000503937)
> >>
> >>
> >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> >> with IS-IS and OSPF.
> >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> >> v5.5d and v5.5e
> >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> >>
> >>
> >> Just wondering if anyone else faced this as well ?
> >>
> >>
> >> Best regards,
> >>
> >> Wouter
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp



--
Youssef BENGELLOUN-ZAHR

Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of
code, this on the XMR.

in 5.6b (but fixed in 5.6c):

Defect ID: DEFECT000502305

Technical Severity: Medium Probability: High

Product: Multi-Service IronWare Technology: Management

Reported In Release: NI 05.6.00 Technology Area: SFLOW

Closed In Release(s): NI 05.6.00c(Fixed)

Symptom: An incorrect raw packet header length in the sFlow protocol is
observed.

Condition: Issue is seen while running L3 traffic along while enabling
sFlow on an interface. sFlow enabled

interfaces send sFlow data packets to an sFlow collector. At the collector
the raw packet header

length is less than what was originally sent.

In 5.6c (not in 5.6b, no fix yet):

Defect 505978
BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP
cpnnection is in SYN-SENT state.
It will occur if you peer using loopback address with /128 mask.
It will be fixed in 5.6d which is not released yet.
Current workaround would be to not use /128 mask or to downgrade your code.





On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com
> wrote:

> Will be interesting to hear your feedback in a few months !!
>
>
>
> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d
> is !!
>
>
>
> Kindest Regards
>
>
>
>
> *James Braunegg**P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03)
> 9751 7616
>
> *E:* james.braunegg@micron21.com | *ABN:* 12 109 977 666
> *W:* www.micron21.com/ddos-protection *T:* @micron21
>
>
>
>
> [image: Description: Description: Description: Description: M21.jpg]
> This message is intended for the addressee named above. It may contain
> privileged or confidential information. If you are not the intended
> recipient of this message you must not use, copy, distribute or disclose it
> to anyone other than the addressee. If you have received this message in
> error please return the message to the sender by replying to it and then
> delete the message from your computer.
>
>
>
> *From:* foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
> Behalf Of *Youssef Bengelloun-Zahr
> *Sent:* Monday, May 26, 2014 6:48 PM
>
> *To:* Wouter de Jong
> *Cc:* <foundry-nsp@puck.nether.net>
> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>
>
>
> Hi,
>
> I hope this one will be more mature and stable :-)
>
> Y.
>
>
>
> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
>
> Hi Youssef,
>
> OK, that is the same date I received :)
>
> Regards,
>
> Wouter
>
>
> > -----Original Message-----
> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
>
> > Sent: Sunday, May 25, 2014 22:16
> > To: Wouter de Jong
> > Cc: <foundry-nsp@puck.nether.net>
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
>
> > Hi,
> >
> > Answering my own post. Just heard from my SE, 56d GA is targeted for
> > July 16th.
> >
> > Best regards.
> >
> >
> >
> > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a
> écrit
> > :
> > >
> > > Hi,
> > >
> > > Interesting... Did TAC give you 56d GA release date ?
> > >
> > > Y.
> > >
> > >
> > >
> > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> > >>
> > >> Hi,
> > >>
> > >> (Apologies for not quoting, etc as I don't have the original email in
> my
> > >> mailbox)
> > >>
> > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look
> nice,
> > and
> > >> I was planning to put it on a new box...
> > >> now I'm not so sure about that any longer...
> > >>
> > >>
> > >> Also interesting that you seem to run 5.5d without problems, as we
> > came
> > >> across a bug in 5.5 with regards
> > >> to the IPv6 route cache - DEFECT000500944
> > >>
> > >> Due to it's characteristics, my guess would be that we really can't be
> > the
> > >> only one that faced that problem ? :)
> > >>
> > >> The issue is that after a link between 2 MLXe's fails and the IGP
> selects a
> > >> different path ... it fails to update the IPv6 cache.
> > >> However, it updates the RIB, etc correctly .... so IPv6 traffic
> transiting
> > >> through the router appears to keep working without issue and
> > >> everything _seems_ correctly (even from looking at CAM), only traffic
> > >> originated from the router itself (eg. loopback) is still pointing
> > >> to the wrong interface, which for example affected IPv6 iBGP sessions
> > in our
> > >> case.
> > >>
> > >> The provided method to resolve it is to manually clear the IPv6 cache
> > by
> > >> running "clear ipv6 cache"
> > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> > >> DEFECT000503937)
> > >>
> > >>
> > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and
> both
> > >> with IS-IS and OSPF.
> > >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS,
> with
> > >> v5.5d and v5.5e
> > >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> > >>
> > >>
> > >> Just wondering if anyone else faced this as well ?
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Wouter
> > >>
> > >> _______________________________________________
> > >> foundry-nsp mailing list
> > >> foundry-nsp@puck.nether.net
> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

Hi,

Little update as 56d GA was postponed until July 31st.

Best regards.



2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:

> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of
> code, this on the XMR.
>
> in 5.6b (but fixed in 5.6c):
>
> Defect ID: DEFECT000502305
>
> Technical Severity: Medium Probability: High
>
> Product: Multi-Service IronWare Technology: Management
>
> Reported In Release: NI 05.6.00 Technology Area: SFLOW
>
> Closed In Release(s): NI 05.6.00c(Fixed)
>
> Symptom: An incorrect raw packet header length in the sFlow protocol is
> observed.
>
> Condition: Issue is seen while running L3 traffic along while enabling
> sFlow on an interface. sFlow enabled
>
> interfaces send sFlow data packets to an sFlow collector. At the collector
> the raw packet header
>
> length is less than what was originally sent.
>
> In 5.6c (not in 5.6b, no fix yet):
>
> Defect 505978
> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP
> cpnnection is in SYN-SENT state.
> It will occur if you peer using loopback address with /128 mask.
> It will be fixed in 5.6d which is not released yet.
> Current workaround would be to not use /128 mask or to downgrade your code.
>
>
>
>
>
> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <
> james.braunegg@micron21.com> wrote:
>
>> Will be interesting to hear your feedback in a few months !!
>>
>>
>>
>> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d
>> is !!
>>
>>
>>
>> Kindest Regards
>>
>>
>>
>>
>> *James Braunegg **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03)
>> 9751 7616
>>
>> *E:* james.braunegg@micron21.com | *ABN:* 12 109 977 666
>> *W:* www.micron21.com/ddos-protection *T:* @micron21
>>
>>
>>
>>
>> [image: Description: Description: Description: Description: M21.jpg]
>> This message is intended for the addressee named above. It may contain
>> privileged or confidential information. If you are not the intended
>> recipient of this message you must not use, copy, distribute or disclose it
>> to anyone other than the addressee. If you have received this message in
>> error please return the message to the sender by replying to it and then
>> delete the message from your computer.
>>
>>
>>
>> *From:* foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
>> Behalf Of *Youssef Bengelloun-Zahr
>> *Sent:* Monday, May 26, 2014 6:48 PM
>>
>> *To:* Wouter de Jong
>> *Cc:* <foundry-nsp@puck.nether.net>
>> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>>
>>
>>
>> Hi,
>>
>> I hope this one will be more mature and stable :-)
>>
>> Y.
>>
>>
>>
>> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
>>
>> Hi Youssef,
>>
>> OK, that is the same date I received :)
>>
>> Regards,
>>
>> Wouter
>>
>>
>> > -----Original Message-----
>> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
>>
>> > Sent: Sunday, May 25, 2014 22:16
>> > To: Wouter de Jong
>> > Cc: <foundry-nsp@puck.nether.net>
>> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>> >
>>
>> > Hi,
>> >
>> > Answering my own post. Just heard from my SE, 56d GA is targeted for
>> > July 16th.
>> >
>> > Best regards.
>> >
>> >
>> >
>> > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a
>> écrit
>> > :
>> > >
>> > > Hi,
>> > >
>> > > Interesting... Did TAC give you 56d GA release date ?
>> > >
>> > > Y.
>> > >
>> > >
>> > >
>> > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
>> > >>
>> > >> Hi,
>> > >>
>> > >> (Apologies for not quoting, etc as I don't have the original email
>> in my
>> > >> mailbox)
>> > >>
>> > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look
>> nice,
>> > and
>> > >> I was planning to put it on a new box...
>> > >> now I'm not so sure about that any longer...
>> > >>
>> > >>
>> > >> Also interesting that you seem to run 5.5d without problems, as we
>> > came
>> > >> across a bug in 5.5 with regards
>> > >> to the IPv6 route cache - DEFECT000500944
>> > >>
>> > >> Due to it's characteristics, my guess would be that we really can't
>> be
>> > the
>> > >> only one that faced that problem ? :)
>> > >>
>> > >> The issue is that after a link between 2 MLXe's fails and the IGP
>> selects a
>> > >> different path ... it fails to update the IPv6 cache.
>> > >> However, it updates the RIB, etc correctly .... so IPv6 traffic
>> transiting
>> > >> through the router appears to keep working without issue and
>> > >> everything _seems_ correctly (even from looking at CAM), only traffic
>> > >> originated from the router itself (eg. loopback) is still pointing
>> > >> to the wrong interface, which for example affected IPv6 iBGP sessions
>> > in our
>> > >> case.
>> > >>
>> > >> The provided method to resolve it is to manually clear the IPv6 cache
>> > by
>> > >> running "clear ipv6 cache"
>> > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
>> > >> DEFECT000503937)
>> > >>
>> > >>
>> > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and
>> both
>> > >> with IS-IS and OSPF.
>> > >> In our case, this was on MLXe-4's with 4x10G X-blades, running
>> IS-IS, with
>> > >> v5.5d and v5.5e
>> > >> Fix should come in 5.6d .. not sure in what version 5.5 will be
>> fixed.
>> > >>
>> > >>
>> > >> Just wondering if anyone else faced this as well ?
>> > >>
>> > >>
>> > >> Best regards,
>> > >>
>> > >> Wouter
>> > >>
>> > >> _______________________________________________
>> > >> foundry-nsp mailing list
>> > >> foundry-nsp@puck.nether.net
>> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>>
>> _______________________________________________
>> 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
>



--
Youssef BENGELLOUN-ZAHR

Thanks for that update ☺

We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue ☺

Cordially Yours,

Skylar MacMinn
www.crissic.net<http://www.crissic.net>
Crissic Solutions, LLC

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Friday, July 18, 2014 8:43 AM
To: Josh Galvez
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi,
Little update as 56d GA was postponed until July 31st.
Best regards.


2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com<mailto:josh@zevlag.com>>:
Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.

in 5.6b (but fixed in 5.6c):

Defect ID: DEFECT000502305
Technical Severity: Medium Probability: High
Product: Multi-Service IronWare Technology: Management
Reported In Release: NI 05.6.00 Technology Area: SFLOW
Closed In Release(s): NI 05.6.00c(Fixed)
Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
length is less than what was originally sent.

In 5.6c (not in 5.6b, no fix yet):

Defect 505978
BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
It will occur if you peer using loopback address with /128 mask.
It will be fixed in 5.6d which is not released yet.
Current workaround would be to not use /128 mask or to downgrade your code.





On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com<mailto:james.braunegg@micron21.com>> wrote:
Will be interesting to hear your feedback in a few months !!

Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!

Kindest Regards

James Braunegg
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666<tel:12%20109%20977%20666>
W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21


[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net<mailto:foundry-nsp-bounces@puck.nether.net>] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, May 26, 2014 6:48 PM

To: Wouter de Jong
Cc: <foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>>
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi,
I hope this one will be more mature and stable :-)
Y.

2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>>:
Hi Youssef,

OK, that is the same date I received :)

Regards,

Wouter

> -----Original Message-----
> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr<mailto:youssef@720.fr>]
> Sent: Sunday, May 25, 2014 22:16
> To: Wouter de Jong
> Cc: <foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>>
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> Answering my own post. Just heard from my SE, 56d GA is targeted for
> July 16th.
>
> Best regards.
>
>
>
> > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr<mailto:youssef@720.fr>> a écrit
> :
> >
> > Hi,
> >
> > Interesting... Did TAC give you 56d GA release date ?
> >
> > Y.
> >
> >
> >
> >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>> a écrit :
> >>
> >> Hi,
> >>
> >> (Apologies for not quoting, etc as I don't have the original email in my
> >> mailbox)
> >>
> >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> and
> >> I was planning to put it on a new box...
> >> now I'm not so sure about that any longer...
> >>
> >>
> >> Also interesting that you seem to run 5.5d without problems, as we
> came
> >> across a bug in 5.5 with regards
> >> to the IPv6 route cache - DEFECT000500944
> >>
> >> Due to it's characteristics, my guess would be that we really can't be
> the
> >> only one that faced that problem ? :)
> >>
> >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> >> different path ... it fails to update the IPv6 cache.
> >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> >> through the router appears to keep working without issue and
> >> everything _seems_ correctly (even from looking at CAM), only traffic
> >> originated from the router itself (eg. loopback) is still pointing
> >> to the wrong interface, which for example affected IPv6 iBGP sessions
> in our
> >> case.
> >>
> >> The provided method to resolve it is to manually clear the IPv6 cache
> by
> >> running "clear ipv6 cache"
> >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> >> DEFECT000503937)
> >>
> >>
> >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> >> with IS-IS and OSPF.
> >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> >> v5.5d and v5.5e
> >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> >>
> >>
> >> Just wondering if anyone else faced this as well ?
> >>
> >>
> >> Best regards,
> >>
> >> Wouter
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp



--
Youssef BENGELLOUN-ZAHR

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


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



--
Youssef BENGELLOUN-ZAHR

Hi all,

560d is out :-)

Y.



2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:

> Thanks for that update J
>
>
>
> We updated to 5.6.0.c and have been fine with sflow since. Thanks again to
> everyone who helped point out the issue J
>
>
>
> Cordially Yours,
>
>
>
> Skylar MacMinn
>
> www.crissic.net
> Crissic Solutions, LLC
>
>
>
> *From:* foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
> Behalf Of *Youssef Bengelloun-Zahr
> *Sent:* Friday, July 18, 2014 8:43 AM
> *To:* Josh Galvez
>
> *Cc:* foundry-nsp@puck.nether.net
> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>
>
>
> Hi,
>
> Little update as 56d GA was postponed until July 31st.
>
> Best regards.
>
>
>
> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
>
> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of
> code, this on the XMR.
>
>
>
> in 5.6b (but fixed in 5.6c):
>
>
>
> Defect ID: DEFECT000502305
>
> Technical Severity: Medium Probability: High
>
> Product: Multi-Service IronWare Technology: Management
>
> Reported In Release: NI 05.6.00 Technology Area: SFLOW
>
> Closed In Release(s): NI 05.6.00c(Fixed)
>
> Symptom: An incorrect raw packet header length in the sFlow protocol is
> observed.
>
> Condition: Issue is seen while running L3 traffic along while enabling
> sFlow on an interface. sFlow enabled
>
> interfaces send sFlow data packets to an sFlow collector. At the collector
> the raw packet header
>
> length is less than what was originally sent.
>
>
>
> In 5.6c (not in 5.6b, no fix yet):
>
> Defect 505978
> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP
> cpnnection is in SYN-SENT state.
> It will occur if you peer using loopback address with /128 mask.
> It will be fixed in 5.6d which is not released yet.
> Current workaround would be to not use /128 mask or to downgrade your code.
>
>
>
>
>
>
>
> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <
> james.braunegg@micron21.com> wrote:
>
> Will be interesting to hear your feedback in a few months !!
>
>
>
> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d
> is !!
>
>
>
> Kindest Regards
>
>
>
>
> *James Braunegg **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03)
> 9751 7616
>
> *E:* james.braunegg@micron21.com | *ABN:* 12 109 977 666
> *W:* www.micron21.com/ddos-protection *T:* @micron21
>
>
>
>
> [image: Description: Description: Description: Description: M21.jpg]
> This message is intended for the addressee named above. It may contain
> privileged or confidential information. If you are not the intended
> recipient of this message you must not use, copy, distribute or disclose it
> to anyone other than the addressee. If you have received this message in
> error please return the message to the sender by replying to it and then
> delete the message from your computer.
>
>
>
> *From:* foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
> Behalf Of *Youssef Bengelloun-Zahr
> *Sent:* Monday, May 26, 2014 6:48 PM
>
>
> *To:* Wouter de Jong
> *Cc:* <foundry-nsp@puck.nether.net>
> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>
>
>
> Hi,
>
> I hope this one will be more mature and stable :-)
>
> Y.
>
>
>
> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
>
> Hi Youssef,
>
> OK, that is the same date I received :)
>
> Regards,
>
> Wouter
>
>
> > -----Original Message-----
> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
>
> > Sent: Sunday, May 25, 2014 22:16
> > To: Wouter de Jong
> > Cc: <foundry-nsp@puck.nether.net>
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
>
> > Hi,
> >
> > Answering my own post. Just heard from my SE, 56d GA is targeted for
> > July 16th.
> >
> > Best regards.
> >
> >
> >
> > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a
> écrit
> > :
> > >
> > > Hi,
> > >
> > > Interesting... Did TAC give you 56d GA release date ?
> > >
> > > Y.
> > >
> > >
> > >
> > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> > >>
> > >> Hi,
> > >>
> > >> (Apologies for not quoting, etc as I don't have the original email in
> my
> > >> mailbox)
> > >>
> > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look
> nice,
> > and
> > >> I was planning to put it on a new box...
> > >> now I'm not so sure about that any longer...
> > >>
> > >>
> > >> Also interesting that you seem to run 5.5d without problems, as we
> > came
> > >> across a bug in 5.5 with regards
> > >> to the IPv6 route cache - DEFECT000500944
> > >>
> > >> Due to it's characteristics, my guess would be that we really can't be
> > the
> > >> only one that faced that problem ? :)
> > >>
> > >> The issue is that after a link between 2 MLXe's fails and the IGP
> selects a
> > >> different path ... it fails to update the IPv6 cache.
> > >> However, it updates the RIB, etc correctly .... so IPv6 traffic
> transiting
> > >> through the router appears to keep working without issue and
> > >> everything _seems_ correctly (even from looking at CAM), only traffic
> > >> originated from the router itself (eg. loopback) is still pointing
> > >> to the wrong interface, which for example affected IPv6 iBGP sessions
> > in our
> > >> case.
> > >>
> > >> The provided method to resolve it is to manually clear the IPv6 cache
> > by
> > >> running "clear ipv6 cache"
> > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> > >> DEFECT000503937)
> > >>
> > >>
> > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and
> both
> > >> with IS-IS and OSPF.
> > >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS,
> with
> > >> v5.5d and v5.5e
> > >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> > >>
> > >>
> > >> Just wondering if anyone else faced this as well ?
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Wouter
> > >>
> > >> _______________________________________________
> > >> foundry-nsp mailing list
> > >> foundry-nsp@puck.nether.net
> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>



--
Youssef BENGELLOUN-ZAHR

Who wants to test it….

Kindest Regards

James Braunegg
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666
W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21


[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
Sent: Friday, August 01, 2014 5:14 AM
To: Skylar MacMinn
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi all,
560d is out :-)
Y.


2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net<mailto:skylar@crissic.net>>:
Thanks for that update ☺

We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue ☺

Cordially Yours,

Skylar MacMinn
www.crissic.net<http://www.crissic.net>
Crissic Solutions, LLC

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net<mailto:foundry-nsp-bounces@puck.nether.net>] On Behalf Of Youssef Bengelloun-Zahr
Sent: Friday, July 18, 2014 8:43 AM
To: Josh Galvez

Cc: foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi,
Little update as 56d GA was postponed until July 31st.
Best regards.

2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com<mailto:josh@zevlag.com>>:
Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.

in 5.6b (but fixed in 5.6c):

Defect ID: DEFECT000502305
Technical Severity: Medium Probability: High
Product: Multi-Service IronWare Technology: Management
Reported In Release: NI 05.6.00 Technology Area: SFLOW
Closed In Release(s): NI 05.6.00c(Fixed)
Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
length is less than what was originally sent.

In 5.6c (not in 5.6b, no fix yet):

Defect 505978
BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
It will occur if you peer using loopback address with /128 mask.
It will be fixed in 5.6d which is not released yet.
Current workaround would be to not use /128 mask or to downgrade your code.





On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com<mailto:james.braunegg@micron21.com>> wrote:
Will be interesting to hear your feedback in a few months !!

Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!

Kindest Regards

James Braunegg
P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
E: james.braunegg@micron21.com<mailto:james.braunegg@micron21.com> | ABN: 12 109 977 666<tel:12%20109%20977%20666>
W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21


[Description: Description: Description: Description: M21.jpg]
This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net<mailto:foundry-nsp-bounces@puck.nether.net>] On Behalf Of Youssef Bengelloun-Zahr
Sent: Monday, May 26, 2014 6:48 PM

To: Wouter de Jong
Cc: <foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>>
Subject: Re: [f-nsp] Netiron 5.6 feedbacks

Hi,
I hope this one will be more mature and stable :-)
Y.

2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>>:
Hi Youssef,

OK, that is the same date I received :)

Regards,

Wouter

> -----Original Message-----
> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr<mailto:youssef@720.fr>]
> Sent: Sunday, May 25, 2014 22:16
> To: Wouter de Jong
> Cc: <foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>>
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> Answering my own post. Just heard from my SE, 56d GA is targeted for
> July 16th.
>
> Best regards.
>
>
>
> > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr<mailto:youssef@720.fr>> a écrit
> :
> >
> > Hi,
> >
> > Interesting... Did TAC give you 56d GA release date ?
> >
> > Y.
> >
> >
> >
> >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl<mailto:wouter@widexs.nl>> a écrit :
> >>
> >> Hi,
> >>
> >> (Apologies for not quoting, etc as I don't have the original email in my
> >> mailbox)
> >>
> >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> and
> >> I was planning to put it on a new box...
> >> now I'm not so sure about that any longer...
> >>
> >>
> >> Also interesting that you seem to run 5.5d without problems, as we
> came
> >> across a bug in 5.5 with regards
> >> to the IPv6 route cache - DEFECT000500944
> >>
> >> Due to it's characteristics, my guess would be that we really can't be
> the
> >> only one that faced that problem ? :)
> >>
> >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> >> different path ... it fails to update the IPv6 cache.
> >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> >> through the router appears to keep working without issue and
> >> everything _seems_ correctly (even from looking at CAM), only traffic
> >> originated from the router itself (eg. loopback) is still pointing
> >> to the wrong interface, which for example affected IPv6 iBGP sessions
> in our
> >> case.
> >>
> >> The provided method to resolve it is to manually clear the IPv6 cache
> by
> >> running "clear ipv6 cache"
> >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> >> DEFECT000503937)
> >>
> >>
> >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> >> with IS-IS and OSPF.
> >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> >> v5.5d and v5.5e
> >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> >>
> >>
> >> Just wondering if anyone else faced this as well ?
> >>
> >>
> >> Best regards,
> >>
> >> Wouter
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp



--
Youssef BENGELLOUN-ZAHR

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


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



--
Youssef BENGELLOUN-ZAHR



--
Youssef BENGELLOUN-ZAHR

Hello,

Has anyone tried it yet ? I was planning to do so when I come back next week but any early feedbacks will be appreciated.

Best regards.



> Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com> a écrit :
>
> Who wants to test it….
>
> Kindest Regards
>
> James Braunegg
> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> E: james.braunegg@micron21.com | ABN: 12 109 977 666
> W: www.micron21.com/ddos-protection T: @micron21
>
>
> <image001.jpg>
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> Sent: Friday, August 01, 2014 5:14 AM
> To: Skylar MacMinn
> Cc: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi all,
>
> 560d is out :-)
>
> Y.
>
>
>
> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:
> Thanks for that update J
>
> We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue J
>
> Cordially Yours,
>
> Skylar MacMinn
> www.crissic.net
> Crissic Solutions, LLC
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> Sent: Friday, July 18, 2014 8:43 AM
> To: Josh Galvez
>
> Cc: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> Little update as 56d GA was postponed until July 31st.
>
> Best regards.
>
>
> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.
>
> in 5.6b (but fixed in 5.6c):
>
> Defect ID: DEFECT000502305
> Technical Severity: Medium Probability: High
> Product: Multi-Service IronWare Technology: Management
> Reported In Release: NI 05.6.00 Technology Area: SFLOW
> Closed In Release(s): NI 05.6.00c(Fixed)
> Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
> Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
> interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
> length is less than what was originally sent.
>
> In 5.6c (not in 5.6b, no fix yet):
> Defect 505978
> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
> It will occur if you peer using loopback address with /128 mask.
> It will be fixed in 5.6d which is not released yet.
> Current workaround would be to not use /128 mask or to downgrade your code.
>
>
>
>
>
>
>
> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com> wrote:
> Will be interesting to hear your feedback in a few months !!
>
> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!
>
> Kindest Regards
>
> James Braunegg
> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> E: james.braunegg@micron21.com | ABN: 12 109 977 666
> W: www.micron21.com/ddos-protection T: @micron21
>
>
> <image001.jpg>
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> Sent: Monday, May 26, 2014 6:48 PM
>
> To: Wouter de Jong
> Cc: <foundry-nsp@puck.nether.net>
> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>
> Hi,
>
> I hope this one will be more mature and stable :-)
>
> Y.
>
>
>
> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
> Hi Youssef,
>
> OK, that is the same date I received :)
>
> Regards,
>
> Wouter
>
> > -----Original Message-----
> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
> > Sent: Sunday, May 25, 2014 22:16
> > To: Wouter de Jong
> > Cc: <foundry-nsp@puck.nether.net>
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
> > Hi,
> >
> > Answering my own post. Just heard from my SE, 56d GA is targeted for
> > July 16th.
> >
> > Best regards.
> >
> >
> >
> > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
> > :
> > >
> > > Hi,
> > >
> > > Interesting... Did TAC give you 56d GA release date ?
> > >
> > > Y.
> > >
> > >
> > >
> > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> > >>
> > >> Hi,
> > >>
> > >> (Apologies for not quoting, etc as I don't have the original email in my
> > >> mailbox)
> > >>
> > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> > and
> > >> I was planning to put it on a new box...
> > >> now I'm not so sure about that any longer...
> > >>
> > >>
> > >> Also interesting that you seem to run 5.5d without problems, as we
> > came
> > >> across a bug in 5.5 with regards
> > >> to the IPv6 route cache - DEFECT000500944
> > >>
> > >> Due to it's characteristics, my guess would be that we really can't be
> > the
> > >> only one that faced that problem ? :)
> > >>
> > >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> > >> different path ... it fails to update the IPv6 cache.
> > >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> > >> through the router appears to keep working without issue and
> > >> everything _seems_ correctly (even from looking at CAM), only traffic
> > >> originated from the router itself (eg. loopback) is still pointing
> > >> to the wrong interface, which for example affected IPv6 iBGP sessions
> > in our
> > >> case.
> > >>
> > >> The provided method to resolve it is to manually clear the IPv6 cache
> > by
> > >> running "clear ipv6 cache"
> > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> > >> DEFECT000503937)
> > >>
> > >>
> > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> > >> with IS-IS and OSPF.
> > >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> > >> v5.5d and v5.5e
> > >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> > >>
> > >>
> > >> Just wondering if anyone else faced this as well ?
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Wouter
> > >>
> > >> _______________________________________________
> > >> foundry-nsp mailing list
> > >> foundry-nsp@puck.nether.net
> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
> _______________________________________________
> 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
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
>
>
> --
> Youssef BENGELLOUN-ZAHR

I am seeing some invalid data from SNMP on 5.6d. 10G interfaces will
periodically transfer at rates of multiple petabits per second and I am
also seeing SNMP reporting 4G RX/TX discards on an interface that reports 0
errors/discards on 'show stat' and 'show int'.

--
Eldon Koyle
--
Behold the warranty -- the bold print giveth and the fine print taketh away.

On Aug 12 10:25+0200, Youssef Bengelloun-Zahr wrote:
> Hello,
>
> Has anyone tried it yet ? I was planning to do so when I come back next week but any early feedbacks will be appreciated.
>
> Best regards.
>
>
>
> > Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com> a écrit :
> >
> > Who wants to test it….
> >
> > Kindest Regards
> >
> > James Braunegg
> > P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> > E: james.braunegg@micron21.com | ABN: 12 109 977 666
> > W: www.micron21.com/ddos-protection T: @micron21
> >
> >
> > <image001.jpg>
> > This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
> >
> > From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> > Sent: Friday, August 01, 2014 5:14 AM
> > To: Skylar MacMinn
> > Cc: foundry-nsp@puck.nether.net
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
> > Hi all,
> >
> > 560d is out :-)
> >
> > Y.
> >
> >
> >
> > 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:
> > Thanks for that update J
> >
> > We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue J
> >
> > Cordially Yours,
> >
> > Skylar MacMinn
> > www.crissic.net
> > Crissic Solutions, LLC
> >
> > From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> > Sent: Friday, July 18, 2014 8:43 AM
> > To: Josh Galvez
> >
> > Cc: foundry-nsp@puck.nether.net
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
> > Hi,
> >
> > Little update as 56d GA was postponed until July 31st.
> >
> > Best regards.
> >
> >
> > 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
> > Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.
> >
> > in 5.6b (but fixed in 5.6c):
> >
> > Defect ID: DEFECT000502305
> > Technical Severity: Medium Probability: High
> > Product: Multi-Service IronWare Technology: Management
> > Reported In Release: NI 05.6.00 Technology Area: SFLOW
> > Closed In Release(s): NI 05.6.00c(Fixed)
> > Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
> > Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
> > interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
> > length is less than what was originally sent.
> >
> > In 5.6c (not in 5.6b, no fix yet):
> > Defect 505978
> > BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
> > It will occur if you peer using loopback address with /128 mask.
> > It will be fixed in 5.6d which is not released yet.
> > Current workaround would be to not use /128 mask or to downgrade your code.
> >
> >
> >
> >
> >
> >
> >
> > On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com> wrote:
> > Will be interesting to hear your feedback in a few months !!
> >
> > Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!
> >
> > Kindest Regards
> >
> > James Braunegg
> > P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> > E: james.braunegg@micron21.com | ABN: 12 109 977 666
> > W: www.micron21.com/ddos-protection T: @micron21
> >
> >
> > <image001.jpg>
> > This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
> >
> > From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> > Sent: Monday, May 26, 2014 6:48 PM
> >
> > To: Wouter de Jong
> > Cc: <foundry-nsp@puck.nether.net>
> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >
> > Hi,
> >
> > I hope this one will be more mature and stable :-)
> >
> > Y.
> >
> >
> >
> > 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
> > Hi Youssef,
> >
> > OK, that is the same date I received :)
> >
> > Regards,
> >
> > Wouter
> >
> > > -----Original Message-----
> > > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
> > > Sent: Sunday, May 25, 2014 22:16
> > > To: Wouter de Jong
> > > Cc: <foundry-nsp@puck.nether.net>
> > > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> > >
> > > Hi,
> > >
> > > Answering my own post. Just heard from my SE, 56d GA is targeted for
> > > July 16th.
> > >
> > > Best regards.
> > >
> > >
> > >
> > > > Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
> > > :
> > > >
> > > > Hi,
> > > >
> > > > Interesting... Did TAC give you 56d GA release date ?
> > > >
> > > > Y.
> > > >
> > > >
> > > >
> > > >> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> > > >>
> > > >> Hi,
> > > >>
> > > >> (Apologies for not quoting, etc as I don't have the original email in my
> > > >> mailbox)
> > > >>
> > > >> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> > > and
> > > >> I was planning to put it on a new box...
> > > >> now I'm not so sure about that any longer...
> > > >>
> > > >>
> > > >> Also interesting that you seem to run 5.5d without problems, as we
> > > came
> > > >> across a bug in 5.5 with regards
> > > >> to the IPv6 route cache - DEFECT000500944
> > > >>
> > > >> Due to it's characteristics, my guess would be that we really can't be
> > > the
> > > >> only one that faced that problem ? :)
> > > >>
> > > >> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> > > >> different path ... it fails to update the IPv6 cache.
> > > >> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> > > >> through the router appears to keep working without issue and
> > > >> everything _seems_ correctly (even from looking at CAM), only traffic
> > > >> originated from the router itself (eg. loopback) is still pointing
> > > >> to the wrong interface, which for example affected IPv6 iBGP sessions
> > > in our
> > > >> case.
> > > >>
> > > >> The provided method to resolve it is to manually clear the IPv6 cache
> > > by
> > > >> running "clear ipv6 cache"
> > > >> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> > > >> DEFECT000503937)
> > > >>
> > > >>
> > > >> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> > > >> with IS-IS and OSPF.
> > > >> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> > > >> v5.5d and v5.5e
> > > >> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> > > >>
> > > >>
> > > >> Just wondering if anyone else faced this as well ?
> > > >>
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Wouter
> > > >>
> > > >> _______________________________________________
> > > >> foundry-nsp mailing list
> > > >> foundry-nsp@puck.nether.net
> > > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >
> >
> >
> > --
> > Youssef BENGELLOUN-ZAHR
> >
> > _______________________________________________
> > 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
> >
> >
> >
> > --
> > Youssef BENGELLOUN-ZAHR
> >
> >
> >
> > --
> > Youssef BENGELLOUN-ZAHR

> _______________________________________________
> 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

Hi Eldon,

On which platform did you notice this ? Did you open a case with BTAC ?

Best regards.



> Le 13 août 2014 à 00:50, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>
> I am seeing some invalid data from SNMP on 5.6d. 10G interfaces will
> periodically transfer at rates of multiple petabits per second and I am
> also seeing SNMP reporting 4G RX/TX discards on an interface that reports 0
> errors/discards on 'show stat' and 'show int'.
>
> --
> Eldon Koyle
> --
> Behold the warranty -- the bold print giveth and the fine print taketh away.
>
>> On Aug 12 10:25+0200, Youssef Bengelloun-Zahr wrote:
>> Hello,
>>
>> Has anyone tried it yet ? I was planning to do so when I come back next week but any early feedbacks will be appreciated.
>>
>> Best regards.
>>
>>
>>
>>> Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com> a écrit :
>>>
>>> Who wants to test it….
>>>
>>> Kindest Regards
>>>
>>> James Braunegg
>>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
>>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
>>> W: www.micron21.com/ddos-protection T: @micron21
>>>
>>>
>>> <image001.jpg>
>>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>>>
>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>> Sent: Friday, August 01, 2014 5:14 AM
>>> To: Skylar MacMinn
>>> Cc: foundry-nsp@puck.nether.net
>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>
>>> Hi all,
>>>
>>> 560d is out :-)
>>>
>>> Y.
>>>
>>>
>>>
>>> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:
>>> Thanks for that update J
>>>
>>> We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue J
>>>
>>> Cordially Yours,
>>>
>>> Skylar MacMinn
>>> www.crissic.net
>>> Crissic Solutions, LLC
>>>
>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>> Sent: Friday, July 18, 2014 8:43 AM
>>> To: Josh Galvez
>>>
>>> Cc: foundry-nsp@puck.nether.net
>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>
>>> Hi,
>>>
>>> Little update as 56d GA was postponed until July 31st.
>>>
>>> Best regards.
>>>
>>>
>>> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
>>> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.
>>>
>>> in 5.6b (but fixed in 5.6c):
>>>
>>> Defect ID: DEFECT000502305
>>> Technical Severity: Medium Probability: High
>>> Product: Multi-Service IronWare Technology: Management
>>> Reported In Release: NI 05.6.00 Technology Area: SFLOW
>>> Closed In Release(s): NI 05.6.00c(Fixed)
>>> Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
>>> Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
>>> interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
>>> length is less than what was originally sent.
>>>
>>> In 5.6c (not in 5.6b, no fix yet):
>>> Defect 505978
>>> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
>>> It will occur if you peer using loopback address with /128 mask.
>>> It will be fixed in 5.6d which is not released yet.
>>> Current workaround would be to not use /128 mask or to downgrade your code.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com> wrote:
>>> Will be interesting to hear your feedback in a few months !!
>>>
>>> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!
>>>
>>> Kindest Regards
>>>
>>> James Braunegg
>>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
>>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
>>> W: www.micron21.com/ddos-protection T: @micron21
>>>
>>>
>>> <image001.jpg>
>>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>>>
>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>> Sent: Monday, May 26, 2014 6:48 PM
>>>
>>> To: Wouter de Jong
>>> Cc: <foundry-nsp@puck.nether.net>
>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>
>>> Hi,
>>>
>>> I hope this one will be more mature and stable :-)
>>>
>>> Y.
>>>
>>>
>>>
>>> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
>>> Hi Youssef,
>>>
>>> OK, that is the same date I received :)
>>>
>>> Regards,
>>>
>>> Wouter
>>>
>>>> -----Original Message-----
>>>> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
>>>> Sent: Sunday, May 25, 2014 22:16
>>>> To: Wouter de Jong
>>>> Cc: <foundry-nsp@puck.nether.net>
>>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>>
>>>> Hi,
>>>>
>>>> Answering my own post. Just heard from my SE, 56d GA is targeted for
>>>> July 16th.
>>>>
>>>> Best regards.
>>>>
>>>>
>>>>
>>>>>> Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
>>>>> :
>>>>>
>>>>> Hi,
>>>>>
>>>>> Interesting... Did TAC give you 56d GA release date ?
>>>>>
>>>>> Y.
>>>>>
>>>>>
>>>>>
>>>>>> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> (Apologies for not quoting, etc as I don't have the original email in my
>>>>>> mailbox)
>>>>>>
>>>>>> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
>>>> and
>>>>>> I was planning to put it on a new box...
>>>>>> now I'm not so sure about that any longer...
>>>>>>
>>>>>>
>>>>>> Also interesting that you seem to run 5.5d without problems, as we
>>>> came
>>>>>> across a bug in 5.5 with regards
>>>>>> to the IPv6 route cache - DEFECT000500944
>>>>>>
>>>>>> Due to it's characteristics, my guess would be that we really can't be
>>>> the
>>>>>> only one that faced that problem ? :)
>>>>>>
>>>>>> The issue is that after a link between 2 MLXe's fails and the IGP selects a
>>>>>> different path ... it fails to update the IPv6 cache.
>>>>>> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
>>>>>> through the router appears to keep working without issue and
>>>>>> everything _seems_ correctly (even from looking at CAM), only traffic
>>>>>> originated from the router itself (eg. loopback) is still pointing
>>>>>> to the wrong interface, which for example affected IPv6 iBGP sessions
>>>> in our
>>>>>> case.
>>>>>>
>>>>>> The provided method to resolve it is to manually clear the IPv6 cache
>>>> by
>>>>>> running "clear ipv6 cache"
>>>>>> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
>>>>>> DEFECT000503937)
>>>>>>
>>>>>>
>>>>>> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
>>>>>> with IS-IS and OSPF.
>>>>>> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
>>>>>> v5.5d and v5.5e
>>>>>> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
>>>>>>
>>>>>>
>>>>>> Just wondering if anyone else faced this as well ?
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Wouter
>>>>>>
>>>>>> _______________________________________________
>>>>>> foundry-nsp mailing list
>>>>>> foundry-nsp@puck.nether.net
>>>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>>
>>>
>>> --
>>> Youssef BENGELLOUN-ZAHR
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> --
>>> Youssef BENGELLOUN-ZAHR
>>>
>>>
>>>
>>> --
>>> Youssef BENGELLOUN-ZAHR
>
>> _______________________________________________
>> 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 are running MLX and MLXe. Opening a ticket with Brocade is on my
to-do list.

--
Eldon Koyle
--
Mathematics deals exclusively with the relations of concepts
to each other without consideration of their relation to experience.
-- Albert Einstein

On Aug 13 6:33+0200, Youssef Bengelloun-Zahr wrote:
> Hi Eldon,
>
> On which platform did you notice this ? Did you open a case with BTAC ?
>
> Best regards.
>
>
>
> > Le 13 août 2014 à 00:50, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> >
> > I am seeing some invalid data from SNMP on 5.6d. 10G interfaces will
> > periodically transfer at rates of multiple petabits per second and I am
> > also seeing SNMP reporting 4G RX/TX discards on an interface that reports 0
> > errors/discards on 'show stat' and 'show int'.
> >
> > --
> > Eldon Koyle
> > --
> > Behold the warranty -- the bold print giveth and the fine print taketh away.
> >
> >> On Aug 12 10:25+0200, Youssef Bengelloun-Zahr wrote:
> >> Hello,
> >>
> >> Has anyone tried it yet ? I was planning to do so when I come back next week but any early feedbacks will be appreciated.
> >>
> >> Best regards.
> >>
> >>
> >>
> >>> Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com> a écrit :
> >>>
> >>> Who wants to test it….
> >>>
> >>> Kindest Regards
> >>>
> >>> James Braunegg
> >>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> >>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
> >>> W: www.micron21.com/ddos-protection T: @micron21
> >>>
> >>>
> >>> <image001.jpg>
> >>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
> >>>
> >>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> >>> Sent: Friday, August 01, 2014 5:14 AM
> >>> To: Skylar MacMinn
> >>> Cc: foundry-nsp@puck.nether.net
> >>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >>>
> >>> Hi all,
> >>>
> >>> 560d is out :-)
> >>>
> >>> Y.
> >>>
> >>>
> >>>
> >>> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:
> >>> Thanks for that update J
> >>>
> >>> We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue J
> >>>
> >>> Cordially Yours,
> >>>
> >>> Skylar MacMinn
> >>> www.crissic.net
> >>> Crissic Solutions, LLC
> >>>
> >>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> >>> Sent: Friday, July 18, 2014 8:43 AM
> >>> To: Josh Galvez
> >>>
> >>> Cc: foundry-nsp@puck.nether.net
> >>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >>>
> >>> Hi,
> >>>
> >>> Little update as 56d GA was postponed until July 31st.
> >>>
> >>> Best regards.
> >>>
> >>>
> >>> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
> >>> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.
> >>>
> >>> in 5.6b (but fixed in 5.6c):
> >>>
> >>> Defect ID: DEFECT000502305
> >>> Technical Severity: Medium Probability: High
> >>> Product: Multi-Service IronWare Technology: Management
> >>> Reported In Release: NI 05.6.00 Technology Area: SFLOW
> >>> Closed In Release(s): NI 05.6.00c(Fixed)
> >>> Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
> >>> Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
> >>> interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
> >>> length is less than what was originally sent.
> >>>
> >>> In 5.6c (not in 5.6b, no fix yet):
> >>> Defect 505978
> >>> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
> >>> It will occur if you peer using loopback address with /128 mask.
> >>> It will be fixed in 5.6d which is not released yet.
> >>> Current workaround would be to not use /128 mask or to downgrade your code.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com> wrote:
> >>> Will be interesting to hear your feedback in a few months !!
> >>>
> >>> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!
> >>>
> >>> Kindest Regards
> >>>
> >>> James Braunegg
> >>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> >>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
> >>> W: www.micron21.com/ddos-protection T: @micron21
> >>>
> >>>
> >>> <image001.jpg>
> >>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
> >>>
> >>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
> >>> Sent: Monday, May 26, 2014 6:48 PM
> >>>
> >>> To: Wouter de Jong
> >>> Cc: <foundry-nsp@puck.nether.net>
> >>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >>>
> >>> Hi,
> >>>
> >>> I hope this one will be more mature and stable :-)
> >>>
> >>> Y.
> >>>
> >>>
> >>>
> >>> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
> >>> Hi Youssef,
> >>>
> >>> OK, that is the same date I received :)
> >>>
> >>> Regards,
> >>>
> >>> Wouter
> >>>
> >>>> -----Original Message-----
> >>>> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
> >>>> Sent: Sunday, May 25, 2014 22:16
> >>>> To: Wouter de Jong
> >>>> Cc: <foundry-nsp@puck.nether.net>
> >>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >>>>
> >>>> Hi,
> >>>>
> >>>> Answering my own post. Just heard from my SE, 56d GA is targeted for
> >>>> July 16th.
> >>>>
> >>>> Best regards.
> >>>>
> >>>>
> >>>>
> >>>>>> Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
> >>>>> :
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Interesting... Did TAC give you 56d GA release date ?
> >>>>>
> >>>>> Y.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> (Apologies for not quoting, etc as I don't have the original email in my
> >>>>>> mailbox)
> >>>>>>
> >>>>>> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
> >>>> and
> >>>>>> I was planning to put it on a new box...
> >>>>>> now I'm not so sure about that any longer...
> >>>>>>
> >>>>>>
> >>>>>> Also interesting that you seem to run 5.5d without problems, as we
> >>>> came
> >>>>>> across a bug in 5.5 with regards
> >>>>>> to the IPv6 route cache - DEFECT000500944
> >>>>>>
> >>>>>> Due to it's characteristics, my guess would be that we really can't be
> >>>> the
> >>>>>> only one that faced that problem ? :)
> >>>>>>
> >>>>>> The issue is that after a link between 2 MLXe's fails and the IGP selects a
> >>>>>> different path ... it fails to update the IPv6 cache.
> >>>>>> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
> >>>>>> through the router appears to keep working without issue and
> >>>>>> everything _seems_ correctly (even from looking at CAM), only traffic
> >>>>>> originated from the router itself (eg. loopback) is still pointing
> >>>>>> to the wrong interface, which for example affected IPv6 iBGP sessions
> >>>> in our
> >>>>>> case.
> >>>>>>
> >>>>>> The provided method to resolve it is to manually clear the IPv6 cache
> >>>> by
> >>>>>> running "clear ipv6 cache"
> >>>>>> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
> >>>>>> DEFECT000503937)
> >>>>>>
> >>>>>>
> >>>>>> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
> >>>>>> with IS-IS and OSPF.
> >>>>>> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
> >>>>>> v5.5d and v5.5e
> >>>>>> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
> >>>>>>
> >>>>>>
> >>>>>> Just wondering if anyone else faced this as well ?
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Wouter
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> foundry-nsp mailing list
> >>>>>> foundry-nsp@puck.nether.net
> >>>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>>
> >>>
> >>>
> >>> --
> >>> Youssef BENGELLOUN-ZAHR
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> Youssef BENGELLOUN-ZAHR
> >>>
> >>>
> >>>
> >>> --
> >>> Youssef BENGELLOUN-ZAHR
> >
> >> _______________________________________________
> >> 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

On 8/12/14 4:25 AM, Youssef Bengelloun-Zahr wrote:
> Hello,
>
> Has anyone tried it yet ? I was planning to do so when I come back next
> week but any early feedbacks will be appreciated.
>
> Best regards.

This week we upgraded five MLXe-16 routers in our core from 5.4.00d* to
5.6.00d. It looks like there is an sFlow export regression in this code
that we didn't pick up during our lab validation. At least one obvious
problem I've identified so far by looking at raw sFlow data is that the
input and output packet counters are lower by about a factor of 3 than
the corresponding counters in the CLI and in the SNMP ifXTable (which
agree with each other). We've contacted Brocade and I would be glad to
follow up here when we resolve the issue.

I'm really hoping we can solve it without another hit-full code change.

* Actually a CVR with a work-around for DEFECT000508412---the main
reason we chose to upgrade---which is fixed in 5.6.00d.

> Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>> a écrit :
>
>> Who wants to test it….
>>
>>
>>
>> Kindest Regards
>>
>>
>>
>> *James Braunegg
>> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03) 9751 7616
>>
>> *E:* james.braunegg@micron21.com
>> <mailto:james.braunegg@micron21.com> | *ABN:* 12 109 977 666
>> *W:* www.micron21.com/ddos-protection
>> <http://www.micron21.com/ddos-protection> *T:* @micron21
>>
>>
>>
>>
>> <image001.jpg>
>> This message is intended for the addressee named above. It may contain
>> privileged or confidential information. If you are not the intended
>> recipient of this message you must not use, copy, distribute or
>> disclose it to anyone other than the addressee. If you have received
>> this message in error please return the message to the sender by
>> replying to it and then delete the message from your computer.
>>
>>
>>
>> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
>> Behalf Of *Youssef Bengelloun-Zahr
>> *Sent:* Friday, August 01, 2014 5:14 AM
>> *To:* Skylar MacMinn
>> *Cc:* foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
>> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>>
>>
>>
>> Hi all,
>>
>> 560d is out :-)
>>
>> Y.
>>
>>
>>
>> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net
>> <mailto:skylar@crissic.net>>:
>>
>> Thanks for that update J
>>
>>
>>
>> We updated to 5.6.0.c and have been fine with sflow since. Thanks
>> again to everyone who helped point out the issue J
>>
>>
>>
>> Cordially Yours,
>>
>>
>>
>> Skylar MacMinn
>>
>> www.crissic.net <http://www.crissic.net>
>> Crissic Solutions, LLC
>>
>>
>>
>> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
>> <mailto:foundry-nsp-bounces@puck.nether.net>] *On Behalf Of *Youssef
>> Bengelloun-Zahr
>> *Sent:* Friday, July 18, 2014 8:43 AM
>> *To:* Josh Galvez
>>
>>
>> *Cc:* foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
>> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>>
>>
>>
>> Hi,
>>
>> Little update as 56d GA was postponed until July 31st.
>>
>> Best regards.
>>
>>
>>
>> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com
>> <mailto:josh@zevlag.com>>:
>>
>> Just an FYI, I've ran in to two rather annoying bugs it the 5.6
>> line of code, this on the XMR.
>>
>>
>>
>> in 5.6b (but fixed in 5.6c):
>>
>>
>>
>> Defect ID: DEFECT000502305
>>
>> Technical Severity: Medium Probability: High
>>
>> Product: Multi-Service IronWare Technology: Management
>>
>> Reported In Release: NI 05.6.00 Technology Area: SFLOW
>>
>> Closed In Release(s): NI 05.6.00c(Fixed)
>>
>> Symptom: An incorrect raw packet header length in the sFlow
>> protocol is observed.
>>
>> Condition: Issue is seen while running L3 traffic along while
>> enabling sFlow on an interface. sFlow enabled
>>
>> interfaces send sFlow data packets to an sFlow collector. At the
>> collector the raw packet header
>>
>> length is less than what was originally sent.
>>
>>
>>
>> In 5.6c (not in 5.6b, no fix yet):
>>
>> Defect 505978
>> BGPv6 neighborship not coming up over loopback interfaces as the
>> ipv6 TCP cpnnection is in SYN-SENT state.
>> It will occur if you peer using loopback address with /128 mask.
>> It will be fixed in 5.6d which is not released yet.
>> Current workaround would be to not use /128 mask or to downgrade
>> your code.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, May 26, 2014 at 7:48 AM, James Braunegg
>> <james.braunegg@micron21.com <mailto:james.braunegg@micron21.com>>
>> wrote:
>>
>> Will be interesting to hear your feedback in a few months !!
>>
>>
>>
>> Was about to upgrade to 5.5 but maybe it’s worth the wait to
>> see how 5.6d is !!
>>
>>
>>
>> Kindest Regards
>>
>>
>>
>> *James Braunegg
>> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03) 9751 7616
>>
>> *E:* james.braunegg@micron21.com
>> <mailto:james.braunegg@micron21.com> | *ABN:* 12 109 977
>> 666 <tel:12%20109%20977%20666>
>> *W:* www.micron21.com/ddos-protection
>> <http://www.micron21.com/ddos-protection> *T:* @micron21
>>
>>
>>
>>
>> <image001.jpg>
>> This message is intended for the addressee named above. It may
>> contain privileged or confidential information. If you are not
>> the intended recipient of this message you must not use, copy,
>> distribute or disclose it to anyone other than the addressee.
>> If you have received this message in error please return the
>> message to the sender by replying to it and then delete the
>> message from your computer.
>>
>>
>>
>> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
>> <mailto:foundry-nsp-bounces@puck.nether.net>] *On Behalf Of
>> *Youssef Bengelloun-Zahr
>> *Sent:* Monday, May 26, 2014 6:48 PM
>>
>>
>> *To:* Wouter de Jong
>> *Cc:* <foundry-nsp@puck.nether.net
>> <mailto:foundry-nsp@puck.nether.net>>
>> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
>>
>>
>>
>> Hi,
>>
>> I hope this one will be more mature and stable :-)
>>
>> Y.
>>
>>
>>
>> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl
>> <mailto:wouter@widexs.nl>>:
>>
>> Hi Youssef,
>>
>> OK, that is the same date I received :)
>>
>> Regards,
>>
>> Wouter
>>
>>
>> > -----Original Message-----
>> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr
>> <mailto:youssef@720.fr>]
>>
>> > Sent: Sunday, May 25, 2014 22:16
>> > To: Wouter de Jong
>> > Cc: <foundry-nsp@puck.nether.net
>> <mailto:foundry-nsp@puck.nether.net>>
>> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>> >
>>
>> > Hi,
>> >
>> > Answering my own post. Just heard from my SE, 56d GA is
>> targeted for
>> > July 16th.
>> >
>> > Best regards.
>> >
>> >
>> >
>> > > Le 25 mai 2014 Ã 20:34, Youssef Bengelloun-Zahr
>> <youssef@720.fr <mailto:youssef@720.fr>> a écrit
>> > :
>> > >
>> > > Hi,
>> > >
>> > > Interesting... Did TAC give you 56d GA release date ?
>> > >
>> > > Y.
>> > >
>> > >
>> > >
>> > >> Le 25 mai 2014 Ã 12:57, Wouter de Jong <wouter@widexs.nl
>> <mailto:wouter@widexs.nl>> a écrit :
>> > >>
>> > >> Hi,
>> > >>
>> > >> (Apologies for not quoting, etc as I don't have the
>> original email in my
>> > >> mailbox)
>> > >>
>> > >> Too bad that 5.6 seems 'buggy' ... some of it's new
>> features look nice,
>> > and
>> > >> I was planning to put it on a new box...
>> > >> now I'm not so sure about that any longer...
>> > >>
>> > >>
>> > >> Also interesting that you seem to run 5.5d without
>> problems, as we
>> > came
>> > >> across a bug in 5.5 with regards
>> > >> to the IPv6 route cache - DEFECT000500944
>> > >>
>> > >> Due to it's characteristics, my guess would be that we
>> really can't be
>> > the
>> > >> only one that faced that problem ? :)
>> > >>
>> > >> The issue is that after a link between 2 MLXe's fails and
>> the IGP selects a
>> > >> different path ... it fails to update the IPv6 cache.
>> > >> However, it updates the RIB, etc correctly .... so IPv6
>> traffic transiting
>> > >> through the router appears to keep working without issue and
>> > >> everything _seems_ correctly (even from looking at CAM),
>> only traffic
>> > >> originated from the router itself (eg. loopback) is still
>> pointing
>> > >> to the wrong interface, which for example affected IPv6
>> iBGP sessions
>> > in our
>> > >> case.
>> > >>
>> > >> The provided method to resolve it is to manually clear
>> the IPv6 cache
>> > by
>> > >> running "clear ipv6 cache"
>> > >> (Note that 'cache' is hidden in the outout from "clear
>> ipv6 ?" ...
>> > >> DEFECT000503937)
>> > >>
>> > >>
>> > >> According to TAC, this issue occurs in both 5.5.x and
>> 5.6.x ... and both
>> > >> with IS-IS and OSPF.
>> > >> In our case, this was on MLXe-4's with 4x10G X-blades,
>> running IS-IS, with
>> > >> v5.5d and v5.5e
>> > >> Fix should come in 5.6d .. not sure in what version 5.5
>> will be fixed.
>> > >>
>> > >>
>> > >> Just wondering if anyone else faced this as well ?
>> > >>
>> > >>
>> > >> Best regards,
>> > >>
>> > >> Wouter
>> > >>
>> > >> _______________________________________________
>> > >> foundry-nsp mailing list
>> > >> foundry-nsp@puck.nether.net
>> <mailto:foundry-nsp@puck.nether.net>
>> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>>
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>


--
John W. O'Brien
Senior Network Engineer
Information Systems and Computing
University of Pennsylvania
obrienjw@upenn.edu 215-898-9818
OpenPGP key ID: 0x155016CB

John,

Is this only for particular line cards? Or are you seeing problems from all
cards?

I've not actually done a stare and compare of CLI/SNMP/SFLOW on 5.6.0c, it
just appeared to be right. (5.6.0b most definitely was not)

-Josh




On Thu, Aug 14, 2014 at 7:01 PM, John W. O'Brien <obrienjw@upenn.edu> wrote:

> On 8/12/14 4:25 AM, Youssef Bengelloun-Zahr wrote:
> > Hello,
> >
> > Has anyone tried it yet ? I was planning to do so when I come back next
> > week but any early feedbacks will be appreciated.
> >
> > Best regards.
>
> This week we upgraded five MLXe-16 routers in our core from 5.4.00d* to
> 5.6.00d. It looks like there is an sFlow export regression in this code
> that we didn't pick up during our lab validation. At least one obvious
> problem I've identified so far by looking at raw sFlow data is that the
> input and output packet counters are lower by about a factor of 3 than
> the corresponding counters in the CLI and in the SNMP ifXTable (which
> agree with each other). We've contacted Brocade and I would be glad to
> follow up here when we resolve the issue.
>
> I'm really hoping we can solve it without another hit-full code change.
>
> * Actually a CVR with a work-around for DEFECT000508412---the main
> reason we chose to upgrade---which is fixed in 5.6.00d.
>
> > Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com
> > <mailto:james.braunegg@micron21.com>> a écrit :
> >
> >> Who wants to test it….
> >>
> >>
> >>
> >> Kindest Regards
> >>
> >>
> >>
> >> *James Braunegg
> >> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03) 9751 7616
> >>
> >> *E:* james.braunegg@micron21.com
> >> <mailto:james.braunegg@micron21.com> | *ABN:* 12 109 977 666
> >> *W:* www.micron21.com/ddos-protection
> >> <http://www.micron21.com/ddos-protection> *T:* @micron21
> >>
> >>
> >>
> >>
> >> <image001.jpg>
> >> This message is intended for the addressee named above. It may contain
> >> privileged or confidential information. If you are not the intended
> >> recipient of this message you must not use, copy, distribute or
> >> disclose it to anyone other than the addressee. If you have received
> >> this message in error please return the message to the sender by
> >> replying to it and then delete the message from your computer.
> >>
> >>
> >>
> >> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] *On
> >> Behalf Of *Youssef Bengelloun-Zahr
> >> *Sent:* Friday, August 01, 2014 5:14 AM
> >> *To:* Skylar MacMinn
> >> *Cc:* foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi all,
> >>
> >> 560d is out :-)
> >>
> >> Y.
> >>
> >>
> >>
> >> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net
> >> <mailto:skylar@crissic.net>>:
> >>
> >> Thanks for that update J
> >>
> >>
> >>
> >> We updated to 5.6.0.c and have been fine with sflow since. Thanks
> >> again to everyone who helped point out the issue J
> >>
> >>
> >>
> >> Cordially Yours,
> >>
> >>
> >>
> >> Skylar MacMinn
> >>
> >> www.crissic.net <http://www.crissic.net>
> >> Crissic Solutions, LLC
> >>
> >>
> >>
> >> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
> >> <mailto:foundry-nsp-bounces@puck.nether.net>] *On Behalf Of *Youssef
> >> Bengelloun-Zahr
> >> *Sent:* Friday, July 18, 2014 8:43 AM
> >> *To:* Josh Galvez
> >>
> >>
> >> *Cc:* foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi,
> >>
> >> Little update as 56d GA was postponed until July 31st.
> >>
> >> Best regards.
> >>
> >>
> >>
> >> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com
> >> <mailto:josh@zevlag.com>>:
> >>
> >> Just an FYI, I've ran in to two rather annoying bugs it the 5.6
> >> line of code, this on the XMR.
> >>
> >>
> >>
> >> in 5.6b (but fixed in 5.6c):
> >>
> >>
> >>
> >> Defect ID: DEFECT000502305
> >>
> >> Technical Severity: Medium Probability: High
> >>
> >> Product: Multi-Service IronWare Technology: Management
> >>
> >> Reported In Release: NI 05.6.00 Technology Area: SFLOW
> >>
> >> Closed In Release(s): NI 05.6.00c(Fixed)
> >>
> >> Symptom: An incorrect raw packet header length in the sFlow
> >> protocol is observed.
> >>
> >> Condition: Issue is seen while running L3 traffic along while
> >> enabling sFlow on an interface. sFlow enabled
> >>
> >> interfaces send sFlow data packets to an sFlow collector. At the
> >> collector the raw packet header
> >>
> >> length is less than what was originally sent.
> >>
> >>
> >>
> >> In 5.6c (not in 5.6b, no fix yet):
> >>
> >> Defect 505978
> >> BGPv6 neighborship not coming up over loopback interfaces as the
> >> ipv6 TCP cpnnection is in SYN-SENT state.
> >> It will occur if you peer using loopback address with /128 mask.
> >> It will be fixed in 5.6d which is not released yet.
> >> Current workaround would be to not use /128 mask or to downgrade
> >> your code.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 26, 2014 at 7:48 AM, James Braunegg
> >> <james.braunegg@micron21.com <mailto:james.braunegg@micron21.com>>
> >> wrote:
> >>
> >> Will be interesting to hear your feedback in a few months !!
> >>
> >>
> >>
> >> Was about to upgrade to 5.5 but maybe it’s worth the wait to
> >> see how 5.6d is !!
> >>
> >>
> >>
> >> Kindest Regards
> >>
> >>
> >>
> >> *James Braunegg
> >> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03) 9751
> 7616
> >>
> >> *E:* james.braunegg@micron21.com
> >> <mailto:james.braunegg@micron21.com> | *ABN:* 12 109 977
> >> 666 <tel:12%20109%20977%20666>
> >> *W:* www.micron21.com/ddos-protection
> >> <http://www.micron21.com/ddos-protection> *T:* @micron21
> >>
> >>
> >>
> >>
> >> <image001.jpg>
> >> This message is intended for the addressee named above. It may
> >> contain privileged or confidential information. If you are not
> >> the intended recipient of this message you must not use, copy,
> >> distribute or disclose it to anyone other than the addressee.
> >> If you have received this message in error please return the
> >> message to the sender by replying to it and then delete the
> >> message from your computer.
> >>
> >>
> >>
> >> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
> >> <mailto:foundry-nsp-bounces@puck.nether.net>] *On Behalf Of
> >> *Youssef Bengelloun-Zahr
> >> *Sent:* Monday, May 26, 2014 6:48 PM
> >>
> >>
> >> *To:* Wouter de Jong
> >> *Cc:* <foundry-nsp@puck.nether.net
> >> <mailto:foundry-nsp@puck.nether.net>>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi,
> >>
> >> I hope this one will be more mature and stable :-)
> >>
> >> Y.
> >>
> >>
> >>
> >> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl
> >> <mailto:wouter@widexs.nl>>:
> >>
> >> Hi Youssef,
> >>
> >> OK, that is the same date I received :)
> >>
> >> Regards,
> >>
> >> Wouter
> >>
> >>
> >> > -----Original Message-----
> >> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr
> >> <mailto:youssef@720.fr>]
> >>
> >> > Sent: Sunday, May 25, 2014 22:16
> >> > To: Wouter de Jong
> >> > Cc: <foundry-nsp@puck.nether.net
> >> <mailto:foundry-nsp@puck.nether.net>>
> >> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >> >
> >>
> >> > Hi,
> >> >
> >> > Answering my own post. Just heard from my SE, 56d GA is
> >> targeted for
> >> > July 16th.
> >> >
> >> > Best regards.
> >> >
> >> >
> >> >
> >> > > Le 25 mai 2014 Ã 20:34, Youssef Bengelloun-Zahr
> >> <youssef@720.fr <mailto:youssef@720.fr>> a écrit
> >> > :
> >> > >
> >> > > Hi,
> >> > >
> >> > > Interesting... Did TAC give you 56d GA release date ?
> >> > >
> >> > > Y.
> >> > >
> >> > >
> >> > >
> >> > >> Le 25 mai 2014 Ã 12:57, Wouter de Jong <wouter@widexs.nl
> >> <mailto:wouter@widexs.nl>> a écrit :
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> (Apologies for not quoting, etc as I don't have the
> >> original email in my
> >> > >> mailbox)
> >> > >>
> >> > >> Too bad that 5.6 seems 'buggy' ... some of it's new
> >> features look nice,
> >> > and
> >> > >> I was planning to put it on a new box...
> >> > >> now I'm not so sure about that any longer...
> >> > >>
> >> > >>
> >> > >> Also interesting that you seem to run 5.5d without
> >> problems, as we
> >> > came
> >> > >> across a bug in 5.5 with regards
> >> > >> to the IPv6 route cache - DEFECT000500944
> >> > >>
> >> > >> Due to it's characteristics, my guess would be that we
> >> really can't be
> >> > the
> >> > >> only one that faced that problem ? :)
> >> > >>
> >> > >> The issue is that after a link between 2 MLXe's fails and
> >> the IGP selects a
> >> > >> different path ... it fails to update the IPv6 cache.
> >> > >> However, it updates the RIB, etc correctly .... so IPv6
> >> traffic transiting
> >> > >> through the router appears to keep working without issue
> and
> >> > >> everything _seems_ correctly (even from looking at CAM),
> >> only traffic
> >> > >> originated from the router itself (eg. loopback) is still
> >> pointing
> >> > >> to the wrong interface, which for example affected IPv6
> >> iBGP sessions
> >> > in our
> >> > >> case.
> >> > >>
> >> > >> The provided method to resolve it is to manually clear
> >> the IPv6 cache
> >> > by
> >> > >> running "clear ipv6 cache"
> >> > >> (Note that 'cache' is hidden in the outout from "clear
> >> ipv6 ?" ...
> >> > >> DEFECT000503937)
> >> > >>
> >> > >>
> >> > >> According to TAC, this issue occurs in both 5.5.x and
> >> 5.6.x ... and both
> >> > >> with IS-IS and OSPF.
> >> > >> In our case, this was on MLXe-4's with 4x10G X-blades,
> >> running IS-IS, with
> >> > >> v5.5d and v5.5e
> >> > >> Fix should come in 5.6d .. not sure in what version 5.5
> >> will be fixed.
> >> > >>
> >> > >>
> >> > >> Just wondering if anyone else faced this as well ?
> >> > >>
> >> > >>
> >> > >> Best regards,
> >> > >>
> >> > >> Wouter
> >> > >>
> >> > >> _______________________________________________
> >> > >> foundry-nsp mailing list
> >> > >> foundry-nsp@puck.nether.net
> >> <mailto:foundry-nsp@puck.nether.net>
> >> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net
> >
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >
> >
> > _______________________________________________
> > foundry-nsp mailing list
> > foundry-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
> >
>
>
> --
> John W. O'Brien
> Senior Network Engineer
> Information Systems and Computing
> University of Pennsylvania
> obrienjw@upenn.edu 215-898-9818
> OpenPGP key ID: 0x155016CB
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

Hello Eldon,

Any news from BTAC ?

Best regards.



> Le 13 août 2014 à 23:29, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>
> We are running MLX and MLXe. Opening a ticket with Brocade is on my
> to-do list.
>
> --
> Eldon Koyle
> --
> Mathematics deals exclusively with the relations of concepts
> to each other without consideration of their relation to experience.
> -- Albert Einstein
>
>> On Aug 13 6:33+0200, Youssef Bengelloun-Zahr wrote:
>> Hi Eldon,
>>
>> On which platform did you notice this ? Did you open a case with BTAC ?
>>
>> Best regards.
>>
>>
>>
>>> Le 13 août 2014 à 00:50, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>>
>>> I am seeing some invalid data from SNMP on 5.6d. 10G interfaces will
>>> periodically transfer at rates of multiple petabits per second and I am
>>> also seeing SNMP reporting 4G RX/TX discards on an interface that reports 0
>>> errors/discards on 'show stat' and 'show int'.
>>>
>>> --
>>> Eldon Koyle
>>> --
>>> Behold the warranty -- the bold print giveth and the fine print taketh away.
>>>
>>>> On Aug 12 10:25+0200, Youssef Bengelloun-Zahr wrote:
>>>> Hello,
>>>>
>>>> Has anyone tried it yet ? I was planning to do so when I come back next week but any early feedbacks will be appreciated.
>>>>
>>>> Best regards.
>>>>
>>>>
>>>>
>>>>> Le 1 août 2014 à 02:09, James Braunegg <james.braunegg@micron21.com> a écrit :
>>>>>
>>>>> Who wants to test it….
>>>>>
>>>>> Kindest Regards
>>>>>
>>>>> James Braunegg
>>>>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
>>>>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
>>>>> W: www.micron21.com/ddos-protection T: @micron21
>>>>>
>>>>>
>>>>> <image001.jpg>
>>>>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>>>>>
>>>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>>>> Sent: Friday, August 01, 2014 5:14 AM
>>>>> To: Skylar MacMinn
>>>>> Cc: foundry-nsp@puck.nether.net
>>>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>>>
>>>>> Hi all,
>>>>>
>>>>> 560d is out :-)
>>>>>
>>>>> Y.
>>>>>
>>>>>
>>>>>
>>>>> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net>:
>>>>> Thanks for that update J
>>>>>
>>>>> We updated to 5.6.0.c and have been fine with sflow since. Thanks again to everyone who helped point out the issue J
>>>>>
>>>>> Cordially Yours,
>>>>>
>>>>> Skylar MacMinn
>>>>> www.crissic.net
>>>>> Crissic Solutions, LLC
>>>>>
>>>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>>>> Sent: Friday, July 18, 2014 8:43 AM
>>>>> To: Josh Galvez
>>>>>
>>>>> Cc: foundry-nsp@puck.nether.net
>>>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>>>
>>>>> Hi,
>>>>>
>>>>> Little update as 56d GA was postponed until July 31st.
>>>>>
>>>>> Best regards.
>>>>>
>>>>>
>>>>> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com>:
>>>>> Just an FYI, I've ran in to two rather annoying bugs it the 5.6 line of code, this on the XMR.
>>>>>
>>>>> in 5.6b (but fixed in 5.6c):
>>>>>
>>>>> Defect ID: DEFECT000502305
>>>>> Technical Severity: Medium Probability: High
>>>>> Product: Multi-Service IronWare Technology: Management
>>>>> Reported In Release: NI 05.6.00 Technology Area: SFLOW
>>>>> Closed In Release(s): NI 05.6.00c(Fixed)
>>>>> Symptom: An incorrect raw packet header length in the sFlow protocol is observed.
>>>>> Condition: Issue is seen while running L3 traffic along while enabling sFlow on an interface. sFlow enabled
>>>>> interfaces send sFlow data packets to an sFlow collector. At the collector the raw packet header
>>>>> length is less than what was originally sent.
>>>>>
>>>>> In 5.6c (not in 5.6b, no fix yet):
>>>>> Defect 505978
>>>>> BGPv6 neighborship not coming up over loopback interfaces as the ipv6 TCP cpnnection is in SYN-SENT state.
>>>>> It will occur if you peer using loopback address with /128 mask.
>>>>> It will be fixed in 5.6d which is not released yet.
>>>>> Current workaround would be to not use /128 mask or to downgrade your code.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 26, 2014 at 7:48 AM, James Braunegg <james.braunegg@micron21.com> wrote:
>>>>> Will be interesting to hear your feedback in a few months !!
>>>>>
>>>>> Was about to upgrade to 5.5 but maybe it’s worth the wait to see how 5.6d is !!
>>>>>
>>>>> Kindest Regards
>>>>>
>>>>> James Braunegg
>>>>> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
>>>>> E: james.braunegg@micron21.com | ABN: 12 109 977 666
>>>>> W: www.micron21.com/ddos-protection T: @micron21
>>>>>
>>>>>
>>>>> <image001.jpg>
>>>>> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>>>>>
>>>>> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Youssef Bengelloun-Zahr
>>>>> Sent: Monday, May 26, 2014 6:48 PM
>>>>>
>>>>> To: Wouter de Jong
>>>>> Cc: <foundry-nsp@puck.nether.net>
>>>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>>>
>>>>> Hi,
>>>>>
>>>>> I hope this one will be more mature and stable :-)
>>>>>
>>>>> Y.
>>>>>
>>>>>
>>>>>
>>>>> 2014-05-26 10:26 GMT+02:00 Wouter de Jong <wouter@widexs.nl>:
>>>>> Hi Youssef,
>>>>>
>>>>> OK, that is the same date I received :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Wouter
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr]
>>>>>> Sent: Sunday, May 25, 2014 22:16
>>>>>> To: Wouter de Jong
>>>>>> Cc: <foundry-nsp@puck.nether.net>
>>>>>> Subject: Re: [f-nsp] Netiron 5.6 feedbacks
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Answering my own post. Just heard from my SE, 56d GA is targeted for
>>>>>> July 16th.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Le 25 mai 2014 à 20:34, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit
>>>>>>> :
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Interesting... Did TAC give you 56d GA release date ?
>>>>>>>
>>>>>>> Y.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Le 25 mai 2014 à 12:57, Wouter de Jong <wouter@widexs.nl> a écrit :
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> (Apologies for not quoting, etc as I don't have the original email in my
>>>>>>>> mailbox)
>>>>>>>>
>>>>>>>> Too bad that 5.6 seems 'buggy' ... some of it's new features look nice,
>>>>>> and
>>>>>>>> I was planning to put it on a new box...
>>>>>>>> now I'm not so sure about that any longer...
>>>>>>>>
>>>>>>>>
>>>>>>>> Also interesting that you seem to run 5.5d without problems, as we
>>>>>> came
>>>>>>>> across a bug in 5.5 with regards
>>>>>>>> to the IPv6 route cache - DEFECT000500944
>>>>>>>>
>>>>>>>> Due to it's characteristics, my guess would be that we really can't be
>>>>>> the
>>>>>>>> only one that faced that problem ? :)
>>>>>>>>
>>>>>>>> The issue is that after a link between 2 MLXe's fails and the IGP selects a
>>>>>>>> different path ... it fails to update the IPv6 cache.
>>>>>>>> However, it updates the RIB, etc correctly .... so IPv6 traffic transiting
>>>>>>>> through the router appears to keep working without issue and
>>>>>>>> everything _seems_ correctly (even from looking at CAM), only traffic
>>>>>>>> originated from the router itself (eg. loopback) is still pointing
>>>>>>>> to the wrong interface, which for example affected IPv6 iBGP sessions
>>>>>> in our
>>>>>>>> case.
>>>>>>>>
>>>>>>>> The provided method to resolve it is to manually clear the IPv6 cache
>>>>>> by
>>>>>>>> running "clear ipv6 cache"
>>>>>>>> (Note that 'cache' is hidden in the outout from "clear ipv6 ?" ...
>>>>>>>> DEFECT000503937)
>>>>>>>>
>>>>>>>>
>>>>>>>> According to TAC, this issue occurs in both 5.5.x and 5.6.x ... and both
>>>>>>>> with IS-IS and OSPF.
>>>>>>>> In our case, this was on MLXe-4's with 4x10G X-blades, running IS-IS, with
>>>>>>>> v5.5d and v5.5e
>>>>>>>> Fix should come in 5.6d .. not sure in what version 5.5 will be fixed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Just wondering if anyone else faced this as well ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Wouter
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> foundry-nsp mailing list
>>>>>>>> foundry-nsp@puck.nether.net
>>>>>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Youssef BENGELLOUN-ZAHR
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Youssef BENGELLOUN-ZAHR
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Youssef BENGELLOUN-ZAHR
>>>
>>>> _______________________________________________
>>>> 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

On 8/15/14 4:26 PM, Josh Galvez wrote:
> Is this only for particular line cards? Or are you seeing problems from
> all cards?
>
> I've not actually done a stare and compare of CLI/SNMP/SFLOW on 5.6.0c,
> it just appeared to be right. (5.6.0b most definitely was not)

It seems to affect all line cards. I spent some time today sifting
through a packet trace of the sFlow output from one of our routers
during an interval when Arbor Peakflow shows a ridiculously large
(~1Pb/s when our usual peaks are <10Gb/s) output traffic spike across
multiple interfaces. In the time I spent, I didn't see anything
obviously wrong in the sFlow data packet-by-packet, so I think I would
have to bring some automation to bear to explore and summarize the data
en masse. In fact, I wasn't even able to reproduce the previous example
of incorrect packet counter samples. My guess is that most sFlow records
are fine, and from time to time there are some that are corrupted somehow.

> On Thu, Aug 14, 2014 at 7:01 PM, John W. O'Brien <obrienjw@upenn.edu
> <mailto:obrienjw@upenn.edu>> wrote:
>
> On 8/12/14 4:25 AM, Youssef Bengelloun-Zahr wrote:
> > Hello,
> >
> > Has anyone tried it yet ? I was planning to do so when I come back
> next
> > week but any early feedbacks will be appreciated.
> >
> > Best regards.
>
> This week we upgraded five MLXe-16 routers in our core from 5.4.00d* to
> 5.6.00d. It looks like there is an sFlow export regression in this code
> that we didn't pick up during our lab validation. At least one obvious
> problem I've identified so far by looking at raw sFlow data is that the
> input and output packet counters are lower by about a factor of 3 than
> the corresponding counters in the CLI and in the SNMP ifXTable (which
> agree with each other). We've contacted Brocade and I would be glad to
> follow up here when we resolve the issue.
>
> I'm really hoping we can solve it without another hit-full code change.
>
> * Actually a CVR with a work-around for DEFECT000508412---the main
> reason we chose to upgrade---which is fixed in 5.6.00d.
>
> > Le 1 août 2014 à 02:09, James Braunegg
> <james.braunegg@micron21.com <mailto:james.braunegg@micron21.com>
> > <mailto:james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>>> a écrit :
> >
> >> Who wants to test it….
> >>
> >>
> >>
> >> Kindest Regards
> >>
> >>
> >>
> >> *James Braunegg
> >> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03) 9751 7616
> >>
> >> *E:* james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>
> >> <mailto:james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>> | *ABN:* 12 109 977 666
> <tel:12%20109%20977%20666>
> >> *W:* www.micron21.com/ddos-protection
> <http://www.micron21.com/ddos-protection>
> >> <http://www.micron21.com/ddos-protection> *T:* @micron21
> >>
> >>
> >>
> >>
> >> <image001.jpg>
> >> This message is intended for the addressee named above. It may
> contain
> >> privileged or confidential information. If you are not the intended
> >> recipient of this message you must not use, copy, distribute or
> >> disclose it to anyone other than the addressee. If you have received
> >> this message in error please return the message to the sender by
> >> replying to it and then delete the message from your computer.
> >>
> >>
> >>
> >> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
> <mailto:foundry-nsp-bounces@puck.nether.net>] *On
> >> Behalf Of *Youssef Bengelloun-Zahr
> >> *Sent:* Friday, August 01, 2014 5:14 AM
> >> *To:* Skylar MacMinn
> >> *Cc:* foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi all,
> >>
> >> 560d is out :-)
> >>
> >> Y.
> >>
> >>
> >>
> >> 2014-07-18 15:47 GMT+02:00 Skylar MacMinn <skylar@crissic.net
> <mailto:skylar@crissic.net>
> >> <mailto:skylar@crissic.net <mailto:skylar@crissic.net>>>:
> >>
> >> Thanks for that update J
> >>
> >>
> >>
> >> We updated to 5.6.0.c and have been fine with sflow since. Thanks
> >> again to everyone who helped point out the issue J
> >>
> >>
> >>
> >> Cordially Yours,
> >>
> >>
> >>
> >> Skylar MacMinn
> >>
> >> www.crissic.net <http://www.crissic.net> <http://www.crissic.net>
> >> Crissic Solutions, LLC
> >>
> >>
> >>
> >> *From:*foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net
> <mailto:foundry-nsp-bounces@puck.nether.net>
> >> <mailto:foundry-nsp-bounces@puck.nether.net
> <mailto:foundry-nsp-bounces@puck.nether.net>>] *On Behalf Of *Youssef
> >> Bengelloun-Zahr
> >> *Sent:* Friday, July 18, 2014 8:43 AM
> >> *To:* Josh Galvez
> >>
> >>
> >> *Cc:* foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi,
> >>
> >> Little update as 56d GA was postponed until July 31st.
> >>
> >> Best regards.
> >>
> >>
> >>
> >> 2014-06-20 21:29 GMT+02:00 Josh Galvez <josh@zevlag.com
> <mailto:josh@zevlag.com>
> >> <mailto:josh@zevlag.com <mailto:josh@zevlag.com>>>:
> >>
> >> Just an FYI, I've ran in to two rather annoying bugs it the 5.6
> >> line of code, this on the XMR.
> >>
> >>
> >>
> >> in 5.6b (but fixed in 5.6c):
> >>
> >>
> >>
> >> Defect ID: DEFECT000502305
> >>
> >> Technical Severity: Medium Probability: High
> >>
> >> Product: Multi-Service IronWare Technology: Management
> >>
> >> Reported In Release: NI 05.6.00 Technology Area: SFLOW
> >>
> >> Closed In Release(s): NI 05.6.00c(Fixed)
> >>
> >> Symptom: An incorrect raw packet header length in the sFlow
> >> protocol is observed.
> >>
> >> Condition: Issue is seen while running L3 traffic along while
> >> enabling sFlow on an interface. sFlow enabled
> >>
> >> interfaces send sFlow data packets to an sFlow collector. At the
> >> collector the raw packet header
> >>
> >> length is less than what was originally sent.
> >>
> >>
> >>
> >> In 5.6c (not in 5.6b, no fix yet):
> >>
> >> Defect 505978
> >> BGPv6 neighborship not coming up over loopback interfaces as the
> >> ipv6 TCP cpnnection is in SYN-SENT state.
> >> It will occur if you peer using loopback address with /128 mask.
> >> It will be fixed in 5.6d which is not released yet.
> >> Current workaround would be to not use /128 mask or to downgrade
> >> your code.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 26, 2014 at 7:48 AM, James Braunegg
> >> <james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>
> <mailto:james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>>>
> >> wrote:
> >>
> >> Will be interesting to hear your feedback in a few months !!
> >>
> >>
> >>
> >> Was about to upgrade to 5.5 but maybe it’s worth the
> wait to
> >> see how 5.6d is !!
> >>
> >>
> >>
> >> Kindest Regards
> >>
> >>
> >>
> >> *James Braunegg
> >> **P:* 1300 769 972 | *M:* 0488 997 207 | *D:* (03)
> 9751 7616
> >>
> >> *E:* james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>
> >> <mailto:james.braunegg@micron21.com
> <mailto:james.braunegg@micron21.com>> | *ABN:* 12 109 977
> >> 666 <tel:12%20109%20977%20666>
> >> *W:* www.micron21.com/ddos-protection
> <http://www.micron21.com/ddos-protection>
> >> <http://www.micron21.com/ddos-protection> *T:* @micron21
> >>
> >>
> >>
> >>
> >> <image001.jpg>
> >> This message is intended for the addressee named above.
> It may
> >> contain privileged or confidential information. If you
> are not
> >> the intended recipient of this message you must not use,
> copy,
> >> distribute or disclose it to anyone other than the addressee.
> >> If you have received this message in error please return the
> >> message to the sender by replying to it and then delete the
> >> message from your computer.
> >>
> >>
> >>
> >> *From:*foundry-nsp
> [mailto:foundry-nsp-bounces@puck.nether.net
> <mailto:foundry-nsp-bounces@puck.nether.net>
> >> <mailto:foundry-nsp-bounces@puck.nether.net
> <mailto:foundry-nsp-bounces@puck.nether.net>>] *On Behalf Of
> >> *Youssef Bengelloun-Zahr
> >> *Sent:* Monday, May 26, 2014 6:48 PM
> >>
> >>
> >> *To:* Wouter de Jong
> >> *Cc:* <foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> >> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>>
> >> *Subject:* Re: [f-nsp] Netiron 5.6 feedbacks
> >>
> >>
> >>
> >> Hi,
> >>
> >> I hope this one will be more mature and stable :-)
> >>
> >> Y.
> >>
> >>
> >>
> >> 2014-05-26 10:26 GMT+02:00 Wouter de Jong
> <wouter@widexs.nl <mailto:wouter@widexs.nl>
> >> <mailto:wouter@widexs.nl <mailto:wouter@widexs.nl>>>:
> >>
> >> Hi Youssef,
> >>
> >> OK, that is the same date I received :)
> >>
> >> Regards,
> >>
> >> Wouter
> >>
> >>
> >> > -----Original Message-----
> >> > From: Youssef Bengelloun-Zahr [mailto:youssef@720.fr
> <mailto:youssef@720.fr>
> >> <mailto:youssef@720.fr <mailto:youssef@720.fr>>]
> >>
> >> > Sent: Sunday, May 25, 2014 22:16
> >> > To: Wouter de Jong
> >> > Cc: <foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> >> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>>
> >> > Subject: Re: [f-nsp] Netiron 5.6 feedbacks
> >> >
> >>
> >> > Hi,
> >> >
> >> > Answering my own post. Just heard from my SE, 56d GA is
> >> targeted for
> >> > July 16th.
> >> >
> >> > Best regards.
> >> >
> >> >
> >> >
> >> > > Le 25 mai 2014 Ã 20:34, Youssef Bengelloun-Zahr
> >> <youssef@720.fr <mailto:youssef@720.fr>
> <mailto:youssef@720.fr <mailto:youssef@720.fr>>> a écrit
> >> > :
> >> > >
> >> > > Hi,
> >> > >
> >> > > Interesting... Did TAC give you 56d GA release date ?
> >> > >
> >> > > Y.
> >> > >
> >> > >
> >> > >
> >> > >> Le 25 mai 2014 Ã 12:57, Wouter de Jong
> <wouter@widexs.nl <mailto:wouter@widexs.nl>
> >> <mailto:wouter@widexs.nl <mailto:wouter@widexs.nl>>> a
> écrit :
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> (Apologies for not quoting, etc as I don't have the
> >> original email in my
> >> > >> mailbox)
> >> > >>
> >> > >> Too bad that 5.6 seems 'buggy' ... some of it's new
> >> features look nice,
> >> > and
> >> > >> I was planning to put it on a new box...
> >> > >> now I'm not so sure about that any longer...
> >> > >>
> >> > >>
> >> > >> Also interesting that you seem to run 5.5d without
> >> problems, as we
> >> > came
> >> > >> across a bug in 5.5 with regards
> >> > >> to the IPv6 route cache - DEFECT000500944
> >> > >>
> >> > >> Due to it's characteristics, my guess would be that we
> >> really can't be
> >> > the
> >> > >> only one that faced that problem ? :)
> >> > >>
> >> > >> The issue is that after a link between 2 MLXe's
> fails and
> >> the IGP selects a
> >> > >> different path ... it fails to update the IPv6 cache.
> >> > >> However, it updates the RIB, etc correctly .... so IPv6
> >> traffic transiting
> >> > >> through the router appears to keep working without
> issue and
> >> > >> everything _seems_ correctly (even from looking at CAM),
> >> only traffic
> >> > >> originated from the router itself (eg. loopback) is
> still
> >> pointing
> >> > >> to the wrong interface, which for example affected IPv6
> >> iBGP sessions
> >> > in our
> >> > >> case.
> >> > >>
> >> > >> The provided method to resolve it is to manually clear
> >> the IPv6 cache
> >> > by
> >> > >> running "clear ipv6 cache"
> >> > >> (Note that 'cache' is hidden in the outout from "clear
> >> ipv6 ?" ...
> >> > >> DEFECT000503937)
> >> > >>
> >> > >>
> >> > >> According to TAC, this issue occurs in both 5.5.x and
> >> 5.6.x ... and both
> >> > >> with IS-IS and OSPF.
> >> > >> In our case, this was on MLXe-4's with 4x10G X-blades,
> >> running IS-IS, with
> >> > >> v5.5d and v5.5e
> >> > >> Fix should come in 5.6d .. not sure in what version 5.5
> >> will be fixed.
> >> > >>
> >> > >>
> >> > >> Just wondering if anyone else faced this as well ?
> >> > >>
> >> > >>
> >> > >> Best regards,
> >> > >>
> >> > >> Wouter
> >> > >>
> >> > >> _______________________________________________
> >> > >> foundry-nsp mailing list
> >> > >> foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> >> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>
> >> > >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> foundry-nsp mailing list
> >> foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>
> <mailto:foundry-nsp@puck.nether.net
> <mailto:foundry-nsp@puck.nether.net>>
> >> http://puck.nether.net/mailman/listinfo/foundry-nsp
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >>
> >>
> >>
> >> --
> >> Youssef BENGELLOUN-ZAHR
> >>
> >
> >
> > _______________________________________________
> > foundry-nsp mailing list
> > foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
> >
>
>
> --
> John W. O'Brien
> Senior Network Engineer
> Information Systems and Computing
> University of Pennsylvania
> obrienjw@upenn.edu <mailto:obrienjw@upenn.edu> 215-898-9818
> <tel:215-898-9818>
> OpenPGP key ID: 0x155016CB
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net <mailto: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
>


--
John W. O'Brien
Senior Network Engineer
Information Systems and Computing
University of Pennsylvania
obrienjw@upenn.edu 215-898-9818
OpenPGP key ID: 0x155016CB

Hello Eldon,

Any news from BTAC ?

Best regards.



> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>
> Hello Eldon,
>
> Any news from BTAC ?
>
> Best regards.

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

I finally heard back today, not sure how long it will take them to fix
it:

DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling

I thought saw something about SNMP caching in the changelog... I'm
wondering if they did something wrong there.

--
Eldon Koyle
Information Technology
Utah State University

On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
> Hello Eldon,
>
> Any news from BTAC ?
>
> Best regards.
>
>
>
> > Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
> >
> > Hello Eldon,
> >
> > Any news from BTAC ?
> >
> > Best regards.
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hi,

This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?

I will ask my SE to look it up.

Thanks for the feedback.

Best regards.



> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>
> I finally heard back today, not sure how long it will take them to fix
> it:
>
> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
>
> I thought saw something about SNMP caching in the changelog... I'm
> wondering if they did something wrong there.
>
> --
> Eldon Koyle
> Information Technology
> Utah State University
>
>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
>> Hello Eldon,
>>
>> Any news from BTAC ?
>>
>> Best regards.
>>
>>
>>
>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>>>
>>> Hello Eldon,
>>>
>>> Any news from BTAC ?
>>>
>>> Best regards.
>>

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

I don't have any more information than that, sorry. They didn't need my
help to reproduce it, so I suspect others have reported the same issue.
FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
as extensively.

--
Eldon Koyle
Information Technology
Utah State University
--
For certain people, after fifty, litigation takes the place of sex.
-- Gore Vidal

On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
> Hi,
>
> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
>
> I will ask my SE to look it up.
>
> Thanks for the feedback.
>
> Best regards.
>
>
>
> > Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> >
> > I finally heard back today, not sure how long it will take them to fix
> > it:
> >
> > DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
> >
> > I thought saw something about SNMP caching in the changelog... I'm
> > wondering if they did something wrong there.
> >
> > --
> > Eldon Koyle
> > Information Technology
> > Utah State University
> >
> >> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
> >> Hello Eldon,
> >>
> >> Any news from BTAC ?
> >>
> >> Best regards.
> >>
> >>
> >>
> >>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
> >>>
> >>> Hello Eldon,
> >>>
> >>> Any news from BTAC ?
> >>>
> >>> Best regards.
> >>
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hello Eldon,

Any feedbacks from BTAC regarding that SNMP defect ?

Best regards.



> Le 8 sept. 2014 à 06:54, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>
> I don't have any more information than that, sorry. They didn't need my
> help to reproduce it, so I suspect others have reported the same issue.
> FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
> as extensively.
>
> --
> Eldon Koyle
> Information Technology
> Utah State University
> --
> For certain people, after fifty, litigation takes the place of sex.
> -- Gore Vidal
>
>> On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
>> Hi,
>>
>> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
>>
>> I will ask my SE to look it up.
>>
>> Thanks for the feedback.
>>
>> Best regards.
>>
>>
>>
>>> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>>
>>> I finally heard back today, not sure how long it will take them to fix
>>> it:
>>>
>>> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
>>>
>>> I thought saw something about SNMP caching in the changelog... I'm
>>> wondering if they did something wrong there.
>>>
>>> --
>>> Eldon Koyle
>>> Information Technology
>>> Utah State University
>>>
>>>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
>>>> Hello Eldon,
>>>>
>>>> Any news from BTAC ?
>>>>
>>>> Best regards.
>>>>
>>>>
>>>>
>>>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>>>>>
>>>>> Hello Eldon,
>>>>>
>>>>> Any news from BTAC ?
>>>>>
>>>>> Best regards.
>>

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

My SE says that defect was caused by using 32bit counters. So I'm rolling it out now.

First one looks ok.

/Tias


> 28 sep 2014 kl. 10:48 skrev Youssef Bengelloun-Zahr <youssef@720.fr>:
>
> Hello Eldon,
>
> Any feedbacks from BTAC regarding that SNMP defect ?
>
> Best regards.
>
>
>
>> Le 8 sept. 2014 à 06:54, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>
>> I don't have any more information than that, sorry. They didn't need my
>> help to reproduce it, so I suspect others have reported the same issue.
>> FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
>> as extensively.
>>
>> --
>> Eldon Koyle
>> Information Technology
>> Utah State University
>> --
>> For certain people, after fifty, litigation takes the place of sex.
>> -- Gore Vidal
>>
>>> On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
>>> Hi,
>>>
>>> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
>>>
>>> I will ask my SE to look it up.
>>>
>>> Thanks for the feedback.
>>>
>>> Best regards.
>>>
>>>
>>>
>>>> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>>>
>>>> I finally heard back today, not sure how long it will take them to fix
>>>> it:
>>>>
>>>> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
>>>>
>>>> I thought saw something about SNMP caching in the changelog... I'm
>>>> wondering if they did something wrong there.
>>>>
>>>> --
>>>> Eldon Koyle
>>>> Information Technology
>>>> Utah State University
>>>>
>>>>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
>>>>> Hello Eldon,
>>>>>
>>>>> Any news from BTAC ?
>>>>>
>>>>> Best regards.
>>>>>
>>>>>
>>>>>
>>>>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>>>>>>
>>>>>> Hello Eldon,
>>>>>>
>>>>>> Any news from BTAC ?
>>>>>>
>>>>>> Best regards.
>
> _______________________________________________
> 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

I gave up waiting on them. They claimed it was something with 32-bit
counters, but do they even have 64-bit error counters?

I ended up disabling SNMP caching (snmp-server cache disable), which has
eliminated the symptoms for us. I'm not sure what the other
ramifications of that change will be.

--
Eldon Koyle
Information Technology
Utah State University
--
BOFH excuse #192:
runaway cat on system.

On Sep 28 10:48+0200, Youssef Bengelloun-Zahr wrote:
> Hello Eldon,
>
> Any feedbacks from BTAC regarding that SNMP defect ?
>
> Best regards.
>
>
>
> > Le 8 sept. 2014 à 06:54, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> >
> > I don't have any more information than that, sorry. They didn't need my
> > help to reproduce it, so I suspect others have reported the same issue.
> > FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
> > as extensively.
> >
> > --
> > Eldon Koyle
> > Information Technology
> > Utah State University
> > --
> > For certain people, after fifty, litigation takes the place of sex.
> > -- Gore Vidal
> >
> >> On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
> >> Hi,
> >>
> >> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
> >>
> >> I will ask my SE to look it up.
> >>
> >> Thanks for the feedback.
> >>
> >> Best regards.
> >>
> >>
> >>
> >>> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> >>>
> >>> I finally heard back today, not sure how long it will take them to fix
> >>> it:
> >>>
> >>> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
> >>>
> >>> I thought saw something about SNMP caching in the changelog... I'm
> >>> wondering if they did something wrong there.
> >>>
> >>> --
> >>> Eldon Koyle
> >>> Information Technology
> >>> Utah State University
> >>>
> >>>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
> >>>> Hello Eldon,
> >>>>
> >>>> Any news from BTAC ?
> >>>>
> >>>> Best regards.
> >>>>
> >>>>
> >>>>
> >>>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
> >>>>>
> >>>>> Hello Eldon,
> >>>>>
> >>>>> Any news from BTAC ?
> >>>>>
> >>>>> Best regards.
> >>
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

In other news, I just had ssh stop working on 5 MLX routers, all running
5.6d:

$ ssh myrouter
invalid public DH value (1/1024)
Disconnecting: bad server public DH value
$

When will Brocade get their act together on their SSH implementation?
Does this really have to happen on every third firmware release?

--
Eldon Koyle
Information Technology
Utah State University
--
It is much easier to suggest solutions when you know nothing about the problem.

On Sep 29 11:40-0600, Eldon Koyle wrote:
> I gave up waiting on them. They claimed it was something with 32-bit
> counters, but do they even have 64-bit error counters?
>
> I ended up disabling SNMP caching (snmp-server cache disable), which has
> eliminated the symptoms for us. I'm not sure what the other
> ramifications of that change will be.
>
> --
> Eldon Koyle
> Information Technology
> Utah State University
> --
> BOFH excuse #192:
> runaway cat on system.
>
> On Sep 28 10:48+0200, Youssef Bengelloun-Zahr wrote:
> > Hello Eldon,
> >
> > Any feedbacks from BTAC regarding that SNMP defect ?
> >
> > Best regards.
> >
> >
> >
> > > Le 8 sept. 2014 à 06:54, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> > >
> > > I don't have any more information than that, sorry. They didn't need my
> > > help to reproduce it, so I suspect others have reported the same issue.
> > > FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
> > > as extensively.
> > >
> > > --
> > > Eldon Koyle
> > > Information Technology
> > > Utah State University
> > > --
> > > For certain people, after fifty, litigation takes the place of sex.
> > > -- Gore Vidal
> > >
> > >> On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
> > >> Hi,
> > >>
> > >> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
> > >>
> > >> I will ask my SE to look it up.
> > >>
> > >> Thanks for the feedback.
> > >>
> > >> Best regards.
> > >>
> > >>
> > >>
> > >>> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
> > >>>
> > >>> I finally heard back today, not sure how long it will take them to fix
> > >>> it:
> > >>>
> > >>> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
> > >>>
> > >>> I thought saw something about SNMP caching in the changelog... I'm
> > >>> wondering if they did something wrong there.
> > >>>
> > >>> --
> > >>> Eldon Koyle
> > >>> Information Technology
> > >>> Utah State University
> > >>>
> > >>>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
> > >>>> Hello Eldon,
> > >>>>
> > >>>> Any news from BTAC ?
> > >>>>
> > >>>> Best regards.
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
> > >>>>>
> > >>>>> Hello Eldon,
> > >>>>>
> > >>>>> Any news from BTAC ?
> > >>>>>
> > >>>>> Best regards.
> > >>
> >
> _______________________________________________
> 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

Are theese MLX or MLXe routers ? What kind of MPs running ?

Other unusual behavior ?

Best regards.

Y.



> Le 1 oct. 2014 à 00:42, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>
> In other news, I just had ssh stop working on 5 MLX routers, all running
> 5.6d:
>
> $ ssh myrouter
> invalid public DH value (1/1024)
> Disconnecting: bad server public DH value
> $
>
> When will Brocade get their act together on their SSH implementation?
> Does this really have to happen on every third firmware release?
>
> --
> Eldon Koyle
> Information Technology
> Utah State University
> --
> It is much easier to suggest solutions when you know nothing about the problem.
>
>> On Sep 29 11:40-0600, Eldon Koyle wrote:
>> I gave up waiting on them. They claimed it was something with 32-bit
>> counters, but do they even have 64-bit error counters?
>>
>> I ended up disabling SNMP caching (snmp-server cache disable), which has
>> eliminated the symptoms for us. I'm not sure what the other
>> ramifications of that change will be.
>>
>> --
>> Eldon Koyle
>> Information Technology
>> Utah State University
>> --
>> BOFH excuse #192:
>> runaway cat on system.
>>
>>> On Sep 28 10:48+0200, Youssef Bengelloun-Zahr wrote:
>>> Hello Eldon,
>>>
>>> Any feedbacks from BTAC regarding that SNMP defect ?
>>>
>>> Best regards.
>>>
>>>
>>>
>>>> Le 8 sept. 2014 à 06:54, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>>>
>>>> I don't have any more information than that, sorry. They didn't need my
>>>> help to reproduce it, so I suspect others have reported the same issue.
>>>> FWIW, I didn't notice this with 5.6c, but we didn't deploy that version
>>>> as extensively.
>>>>
>>>> --
>>>> Eldon Koyle
>>>> Information Technology
>>>> Utah State University
>>>> --
>>>> For certain people, after fifty, litigation takes the place of sex.
>>>> -- Gore Vidal
>>>>
>>>>> On Sep 05 21:18+0200, Youssef Bengelloun-Zahr wrote:
>>>>> Hi,
>>>>>
>>>>> This DEFECT isn't listed in the official Brocade KB. Can you tell us a little bit more about it (affected versions, etc.) ?
>>>>>
>>>>> I will ask my SE to look it up.
>>>>>
>>>>> Thanks for the feedback.
>>>>>
>>>>> Best regards.
>>>>>
>>>>>
>>>>>
>>>>>> Le 5 sept. 2014 à 21:08, Eldon Koyle <esk-puck.nether.net@esk.cs.usu.edu> a écrit :
>>>>>>
>>>>>> I finally heard back today, not sure how long it will take them to fix
>>>>>> it:
>>>>>>
>>>>>> DEFECT000527089: 000527089 Seeing unexpected traffic spikes/dips during SNMP IfInOctets Polling
>>>>>>
>>>>>> I thought saw something about SNMP caching in the changelog... I'm
>>>>>> wondering if they did something wrong there.
>>>>>>
>>>>>> --
>>>>>> Eldon Koyle
>>>>>> Information Technology
>>>>>> Utah State University
>>>>>>
>>>>>>> On Sep 04 21:14+0200, Youssef Bengelloun-Zahr wrote:
>>>>>>> Hello Eldon,
>>>>>>>
>>>>>>> Any news from BTAC ?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Le 18 août 2014 à 21:00, Youssef Bengelloun-Zahr <youssef@720.fr> a écrit :
>>>>>>>>
>>>>>>>> Hello Eldon,
>>>>>>>>
>>>>>>>> Any news from BTAC ?
>>>>>>>>
>>>>>>>> Best regards.
>> _______________________________________________
>> 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