Mailing List Archive

NetIron 5.8f feedbacks
All,

It came out à few weeks ago and seems it to be the lucky charm... At least for us. It was also designated as the new official target path.

Any feedbacks from out there ? Any head acks in perspective ?

Thank you.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
Hi Youssef,

The 5800 code train has been working well for us over the last couple of
months. We weren't impacted by the IPsec packet linecard crash bug that
was introduced and fixed a couple of letter releases ago since we had
already locked everything down with receive ACL's to begin with. But
other than that, smooth sailing!

Best regards,
Martijn

On 12/16/2016 06:42 PM, Youssef Bengelloun-Zahr wrote:
> All,
>
> It came out à few weeks ago and seems it to be the lucky charm... At least for us. It was also designated as the new official target path.
>
> Any feedbacks from out there ? Any head acks in perspective ?
>
> Thank you.
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
Curious if there are any new cam profiles available? Ideally to max out ipv4 + ipv6 but leave room for one VRF (mgmt).

Thanks if anyone knows

On 12/16/16, 1:14 PM, "foundry-nsp on behalf of i3D.net - Martijn Schmidt" <foundry-nsp-bounces@puck.nether.net on behalf of martijnschmidt@i3d.net> wrote:

Hi Youssef,

The 5800 code train has been working well for us over the last couple of
months. We weren't impacted by the IPsec packet linecard crash bug that
was introduced and fixed a couple of letter releases ago since we had
already locked everything down with receive ACL's to begin with. But
other than that, smooth sailing!

Best regards,
Martijn

On 12/16/2016 06:42 PM, Youssef Bengelloun-Zahr wrote:
> All,
>
> It came out à few weeks ago and seems it to be the lucky charm... At least for us. It was also designated as the new official target path.
>
> Any feedbacks from out there ? Any head acks in perspective ?
>
> Thank you.
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
@David : No new CAM profiles. I too need to resize in order to accomodate IPv6 DFZ growth.

@Martijn : yep, the nasty IPSec bug was corrected, with a couple others we were impacted by. Need to lab it a bit, but I think it's the one.

BR.



> Le 16 déc. 2016 à 19:20, David Hubbard <dhubbard@dino.hostasaurus.com> a écrit :
>
> Curious if there are any new cam profiles available? Ideally to max out ipv4 + ipv6 but leave room for one VRF (mgmt).
>
> Thanks if anyone knows
>
> On 12/16/16, 1:14 PM, "foundry-nsp on behalf of i3D.net - Martijn Schmidt" <foundry-nsp-bounces@puck.nether.net on behalf of martijnschmidt@i3d.net> wrote:
>
> Hi Youssef,
>
> The 5800 code train has been working well for us over the last couple of
> months. We weren't impacted by the IPsec packet linecard crash bug that
> was introduced and fixed a couple of letter releases ago since we had
> already locked everything down with receive ACL's to begin with. But
> other than that, smooth sailing!
>
> Best regards,
> Martijn
>
>> On 12/16/2016 06:42 PM, Youssef Bengelloun-Zahr wrote:
>> All,
>>
>> It came out à few weeks ago and seems it to be the lucky charm... At least for us. It was also designated as the new official target path.
>>
>> Any feedbacks from out there ? Any head acks in perspective ?
>>
>> Thank you.
>> _______________________________________________
>> 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
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
Hi,

does
NI-XMR-10Gx4
still boot and run under 5.8?

Jörg

On 16 Dec 2016, at 20:14, Youssef Bengelloun-Zahr wrote:

> @David : No new CAM profiles. I too need to resize in order to
> accomodate IPv6 DFZ growth.
>
> @Martijn : yep, the nasty IPSec bug was corrected, with a couple
> others we were impacted by. Need to lab it a bit, but I think it's the
> one.
>
> BR.
>
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
Hi Jörg,

That SKU is a Gen1 module so it's no longer supported as of 5700 and onwards. BR-MLX-10Gx4-X is a Gen1.1 module and should still work in 5800, but I haven't tested it since it'd block the MLXe chassis from running its switching fabrics in turbo mode - which in turn is needed to achieve wirespeed throughput rates on some of the newer high density linecards.

Please note you'll also need MR2 management modules to run >5700 firmware.

Best regards,
Martijn Schmidt

On 19 December 2016 13:04:22 CET, "Jörg Kost" <jk@ip-clear.de> wrote:
>Hi,
>
>does
>NI-XMR-10Gx4
>still boot and run under 5.8?
>
>Jörg
>
>On 16 Dec 2016, at 20:14, Youssef Bengelloun-Zahr wrote:
>
>> @David : No new CAM profiles. I too need to resize in order to
>> accomodate IPv6 DFZ growth.
>>
>> @Martijn : yep, the nasty IPSec bug was corrected, with a couple
>> others we were impacted by. Need to lab it a bit, but I think it's
>the
>> one.
>>
>> BR.
>>
>>
>
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: NetIron 5.8f feedbacks [ In reply to ]
Hello,

I am currently running the annoying issue with 5.8f, that I cant paste
large ip prefix-lists via ssh into the router anymore. The session will
hang and I have already opened a ticket down at Brocade. Somebody can
verify this? E.g. try to paste the the content of
http://pastebin.com/YEf6c1aT several times into the shell.

Also I am seeing some LACP out of sync errors randomly popping out since
the upgrade, however I still investigate if there is some other (faulty)
reason for this ones:

Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
FORWARD
Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
aggregate
Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
LACP-BLOCKED
Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
DOWN
Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
aggregate (reason: peer is out of sync)

Jörg

On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:

> All,
>
> It came out à few weeks ago and seems it to be the lucky charm... At
> least for us. It was also designated as the new official target path.
>
> Any feedbacks from out there ? Any head acks in perspective ?
>
> Thank you.
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
Hello

I've found that most versions have had this issue for me, I tend to do them
via TFTP or using the "paste slowly" command in iTerm. I was actually
pasting in a load of VPLS config but the effect was the same.



On 24 January 2017 at 12:13, Jörg Kost <jk@ip-clear.de> wrote:

> Hello,
>
> I am currently running the annoying issue with 5.8f, that I cant paste
> large ip prefix-lists via ssh into the router anymore. The session will
> hang and I have already opened a ticket down at Brocade. Somebody can
> verify this? E.g. try to paste the the content of
> http://pastebin.com/YEf6c1aT several times into the shell.
>
> Also I am seeing some LACP out of sync errors randomly popping out since
> the upgrade, however I still investigate if there is some other (faulty)
> reason for this ones:
>
> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
> FORWARD
> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
> aggregate
> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
> LACP-BLOCKED
> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
> DOWN
> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
> aggregate (reason: peer is out of sync)
>
> Jörg
>
>
> On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:
>
> All,
>>
>> It came out à few weeks ago and seems it to be the lucky charm... At
>> least for us. It was also designated as the new official target path.
>>
>> Any feedbacks from out there ? Any head acks in perspective ?
>>
>> Thank you.
>> _______________________________________________
>> 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
>
Re: NetIron 5.8f feedbacks [ In reply to ]
Dear Jörg,

I'm more concerned (surprised !?!) about the LACP flaps you've been
noticing as 5.8f seems to be really mature.

Have you been able to pinpoint to root cause ? Is it related to the OS
version or a local issue ?

Best regards.



2017-01-24 13:15 GMT+01:00 Wayne Lee via foundry-nsp <
foundry-nsp@puck.nether.net>:

> Hello
>
> I've found that most versions have had this issue for me, I tend to do
> them via TFTP or using the "paste slowly" command in iTerm. I was actually
> pasting in a load of VPLS config but the effect was the same.
>
>
>
> On 24 January 2017 at 12:13, Jörg Kost <jk@ip-clear.de> wrote:
>
>> Hello,
>>
>> I am currently running the annoying issue with 5.8f, that I cant paste
>> large ip prefix-lists via ssh into the router anymore. The session will
>> hang and I have already opened a ticket down at Brocade. Somebody can
>> verify this? E.g. try to paste the the content of
>> http://pastebin.com/YEf6c1aT several times into the shell.
>>
>> Also I am seeing some LACP out of sync errors randomly popping out since
>> the upgrade, however I still investigate if there is some other (faulty)
>> reason for this ones:
>>
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> FORWARD
>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>> aggregate
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>> LACP-BLOCKED
>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> DOWN
>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>> aggregate (reason: peer is out of sync)
>>
>> Jörg
>>
>>
>> On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:
>>
>> All,
>>>
>>> It came out à few weeks ago and seems it to be the lucky charm... At
>>> least for us. It was also designated as the new official target path.
>>>
>>> Any feedbacks from out there ? Any head acks in perspective ?
>>>
>>> Thank you.
>>> _______________________________________________
>>> 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
>
Re: NetIron 5.8f feedbacks [ In reply to ]
Hi,

i will replace optics and fibre on the affected circuits and let you
know. It is (was) a long time stable short distance (<1m) port channel
with 10G SR-optics and I have never seen the error before on this lines.
But this could mean all or nothing ;)

Jörg

On 25 Jan 2017, at 9:16, Youssef Bengelloun-Zahr wrote:

> Dear Jörg,
>
> I'm more concerned (surprised !?!) about the LACP flaps you've been
> noticing as 5.8f seems to be really mature.
>
> Have you been able to pinpoint to root cause ? Is it related to the OS
> version or a local issue ?
>
> Best regards.
>
>
>
> 2017-01-24 13:15 GMT+01:00 Wayne Lee via foundry-nsp <
> foundry-nsp@puck.nether.net>:
>
>> Hello
>>
>> I've found that most versions have had this issue for me, I tend to
>> do
>> them via TFTP or using the "paste slowly" command in iTerm. I was
>> actually
>> pasting in a load of VPLS config but the effect was the same.
>>
>>
>>
>> On 24 January 2017 at 12:13, Jörg Kost <jk@ip-clear.de> wrote:
>>
>>> Hello,
>>>
>>> I am currently running the annoying issue with 5.8f, that I cant
>>> paste
>>> large ip prefix-lists via ssh into the router anymore. The session
>>> will
>>> hang and I have already opened a ticket down at Brocade. Somebody
>>> can
>>> verify this? E.g. try to paste the the content of
>>> http://pastebin.com/YEf6c1aT several times into the shell.
>>>
>>> Also I am seeing some LACP out of sync errors randomly popping out
>>> since
>>> the upgrade, however I still investigate if there is some other
>>> (faulty)
>>> reason for this ones:
>>>
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED
>>> to
>>> FORWARD
>>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate
>>> ->
>>> aggregate
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>>> LACP-BLOCKED
>>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED
>>> to
>>> DOWN
>>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate ->
>>> not
>>> aggregate (reason: peer is out of sync)
>>>
>>> Jörg
>>>
>>>
>>> On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:
>>>
>>> All,
>>>>
>>>> It came out à few weeks ago and seems it to be the lucky charm...
>>>> At
>>>> least for us. It was also designated as the new official target
>>>> path.
>>>>
>>>> Any feedbacks from out there ? Any head acks in perspective ?
>>>>
>>>> Thank you.
>>>> _______________________________________________
>>>> 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
>>
Re: NetIron 5.8f feedbacks [ In reply to ]
Sure, hence me asking ;-)

Y.



2017-01-26 9:58 GMT+01:00 Jörg Kost <jk@ip-clear.de>:

> Hi,
>
> i will replace optics and fibre on the affected circuits and let you know.
> It is (was) a long time stable short distance (<1m) port channel with 10G
> SR-optics and I have never seen the error before on this lines. But this
> could mean all or nothing ;)
>
> Jörg
>
> On 25 Jan 2017, at 9:16, Youssef Bengelloun-Zahr wrote:
>
> Dear Jörg,
>
> I'm more concerned (surprised !?!) about the LACP flaps you've been
> noticing as 5.8f seems to be really mature.
>
> Have you been able to pinpoint to root cause ? Is it related to the OS
> version or a local issue ?
>
> Best regards.
>
>
>
> 2017-01-24 13:15 GMT+01:00 Wayne Lee via foundry-nsp <
> foundry-nsp@puck.nether.net>:
>
>> Hello
>>
>> I've found that most versions have had this issue for me, I tend to do
>> them via TFTP or using the "paste slowly" command in iTerm. I was actually
>> pasting in a load of VPLS config but the effect was the same.
>>
>>
>>
>> On 24 January 2017 at 12:13, Jörg Kost <jk@ip-clear.de> wrote:
>>
>>> Hello,
>>>
>>> I am currently running the annoying issue with 5.8f, that I cant paste
>>> large ip prefix-lists via ssh into the router anymore. The session will
>>> hang and I have already opened a ticket down at Brocade. Somebody can
>>> verify this? E.g. try to paste the the content of
>>> http://pastebin.com/YEf6c1aT several times into the shell.
>>>
>>> Also I am seeing some LACP out of sync errors randomly popping out since
>>> the upgrade, however I still investigate if there is some other (faulty)
>>> reason for this ones:
>>>
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>> FORWARD
>>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>>> aggregate
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>>> LACP-BLOCKED
>>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>> DOWN
>>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>>> aggregate (reason: peer is out of sync)
>>>
>>> Jörg
>>>
>>>
>>> On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:
>>>
>>> All,
>>>>
>>>> It came out à few weeks ago and seems it to be the lucky charm... At
>>>> least for us. It was also designated as the new official target path.
>>>>
>>>> Any feedbacks from out there ? Any head acks in perspective ?
>>>>
>>>> Thank you.
>>>> _______________________________________________
>>>> 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
>>
>
>
Re: NetIron 5.8f feedbacks [ In reply to ]
Do you see any errors on any of the ports involved?

--
Eldon

On Thu, Jan 26, 2017 at 1:58 AM, Jörg Kost <jk@ip-clear.de> wrote:
> Hi,
>
> i will replace optics and fibre on the affected circuits and let you know.
> It is (was) a long time stable short distance (<1m) port channel with 10G
> SR-optics and I have never seen the error before on this lines. But this
> could mean all or nothing ;)
>
> Jörg
>
> On 25 Jan 2017, at 9:16, Youssef Bengelloun-Zahr wrote:
>
> Dear Jörg,
>
> I'm more concerned (surprised !?!) about the LACP flaps you've been noticing
> as 5.8f seems to be really mature.
>
> Have you been able to pinpoint to root cause ? Is it related to the OS
> version or a local issue ?
>
> Best regards.
>
>
>
> 2017-01-24 13:15 GMT+01:00 Wayne Lee via foundry-nsp
> <foundry-nsp@puck.nether.net>:
>>
>> Hello
>>
>> I've found that most versions have had this issue for me, I tend to do
>> them via TFTP or using the "paste slowly" command in iTerm. I was actually
>> pasting in a load of VPLS config but the effect was the same.
>>
>>
>>
>> On 24 January 2017 at 12:13, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> Hello,
>>>
>>> I am currently running the annoying issue with 5.8f, that I cant paste
>>> large ip prefix-lists via ssh into the router anymore. The session will hang
>>> and I have already opened a ticket down at Brocade. Somebody can verify
>>> this? E.g. try to paste the the content of http://pastebin.com/YEf6c1aT
>>> several times into the shell.
>>>
>>> Also I am seeing some LACP out of sync errors randomly popping out since
>>> the upgrade, however I still investigate if there is some other (faulty)
>>> reason for this ones:
>>>
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>> FORWARD
>>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>>> aggregate
>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>>> LACP-BLOCKED
>>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>> DOWN
>>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>>> aggregate (reason: peer is out of sync)
>>>
>>> Jörg
>>>
>>>
>>> On 16 Dec 2016, at 18:42, Youssef Bengelloun-Zahr wrote:
>>>
>>>> All,
>>>>
>>>> It came out à few weeks ago and seems it to be the lucky charm... At
>>>> least for us. It was also designated as the new official target path.
>>>>
>>>> Any feedbacks from out there ? Any head acks in perspective ?
>>>>
>>>> Thank you.
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
Also I am seeing some LACP out of sync errors randomly popping out since
the upgrade, however I still investigate if there is some other (faulty)
reason for this ones:

Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
FORWARD
Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
aggregate
Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
LACP-BLOCKED
Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
DOWN
Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
aggregate (reason: peer is out of sync)

Jörg

---

Sorry for the 20 questions but:
Are you seeing this on slow timers or fast timers? Do you use observium? What line card are you using (8x10g)?

Thanks
-Tim.
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
5.8 is about as stable as a disgruntled postal worker. I wish they'd keep
going with 5.6.

On Thu, Jan 26, 2017 at 5:39 PM, Tim Warnock <timoid@timoid.org> wrote:

> Also I am seeing some LACP out of sync errors randomly popping out since
> the upgrade, however I still investigate if there is some other (faulty)
> reason for this ones:
>
> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
> FORWARD
> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
> aggregate
> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
> LACP-BLOCKED
> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
> DOWN
> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
> aggregate (reason: peer is out of sync)
>
> Jörg
>
> ---
>
> Sorry for the 20 questions but:
> Are you seeing this on slow timers or fast timers? Do you use observium?
> What line card are you using (8x10g)?
>
> Thanks
> -Tim.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

--

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
Re: NetIron 5.8f feedbacks [ In reply to ]
Care to elaborate please ?

Y.



> Le 27 janv. 2017 à 18:22, Daniel Schmidt <daniel.schmidt@wyo.gov> a écrit :
>
> 5.8 is about as stable as a disgruntled postal worker. I wish they'd keep going with 5.6.
>
>> On Thu, Jan 26, 2017 at 5:39 PM, Tim Warnock <timoid@timoid.org> wrote:
>> Also I am seeing some LACP out of sync errors randomly popping out since
>> the upgrade, however I still investigate if there is some other (faulty)
>> reason for this ones:
>>
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> FORWARD
>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>> aggregate
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>> LACP-BLOCKED
>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> DOWN
>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>> aggregate (reason: peer is out of sync)
>>
>> Jörg
>>
>> ---
>>
>> Sorry for the 20 questions but:
>> Are you seeing this on slow timers or fast timers? Do you use observium? What line card are you using (8x10g)?
>>
>> Thanks
>> -Tim.
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> E-Mail to and from me, in connection with the transaction
> of public business, is subject to the Wyoming Public Records
> Act and may be disclosed to third parties.
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
I use the new 10x20 10G cards, which require 5.8. The cards are not stable
for us, they crash periodically. And, we had one or two mlx reboot for no
reason. Things were better when we ran 5.6. Of course, perhaps 5.8 would
be more stable without the cards so a grain of proverbial salt applies.

On Fri, Jan 27, 2017 at 11:23 AM, Youssef Bengelloun-Zahr <
bengelly@gmail.com> wrote:

> Care to elaborate please ?
>
> Y.
>
>
>
> Le 27 janv. 2017 à 18:22, Daniel Schmidt <daniel.schmidt@wyo.gov> a
> écrit :
>
> 5.8 is about as stable as a disgruntled postal worker. I wish they'd keep
> going with 5.6.
>
> On Thu, Jan 26, 2017 at 5:39 PM, Tim Warnock <timoid@timoid.org> wrote:
>
>> Also I am seeing some LACP out of sync errors randomly popping out since
>> the upgrade, however I still investigate if there is some other (faulty)
>> reason for this ones:
>>
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> FORWARD
>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>> aggregate
>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>> LACP-BLOCKED
>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>> DOWN
>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>> aggregate (reason: peer is out of sync)
>>
>> Jörg
>>
>> ---
>>
>> Sorry for the 20 questions but:
>> Are you seeing this on slow timers or fast timers? Do you use observium?
>> What line card are you using (8x10g)?
>>
>> Thanks
>> -Tim.
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
>
> E-Mail to and from me, in connection with the transaction
> of public business, is subject to the Wyoming Public Records
> Act and may be disclosed to third parties.
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>

--

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
Re: NetIron 5.8f feedbacks [ In reply to ]
Help Daniel,

Thank you for the clarifications.

We are not in the same hardware setup as we don't use those LPs. From what I've been reading in the latest release notes, those seem to pretty instable indeed.

Let's hope for your sake (and ours someday) they will stabilize.

Best of luck.

Y.



> Le 28 janv. 2017 à 02:04, Daniel Schmidt <daniel.schmidt@wyo.gov> a écrit :
>
> I use the new 10x20 10G cards, which require 5.8. The cards are not stable for us, they crash periodically. And, we had one or two mlx reboot for no reason. Things were better when we ran 5.6. Of course, perhaps 5.8 would be more stable without the cards so a grain of proverbial salt applies.
>
>> On Fri, Jan 27, 2017 at 11:23 AM, Youssef Bengelloun-Zahr <bengelly@gmail.com> wrote:
>> Care to elaborate please ?
>>
>> Y.
>>
>>
>>
>>> Le 27 janv. 2017 à 18:22, Daniel Schmidt <daniel.schmidt@wyo.gov> a écrit :
>>>
>>> 5.8 is about as stable as a disgruntled postal worker. I wish they'd keep going with 5.6.
>>>
>>>> On Thu, Jan 26, 2017 at 5:39 PM, Tim Warnock <timoid@timoid.org> wrote:
>>>> Also I am seeing some LACP out of sync errors randomly popping out since
>>>> the upgrade, however I still investigate if there is some other (faulty)
>>>> reason for this ones:
>>>>
>>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>>> FORWARD
>>>> Jan 23 10:40:23:I:LACP: Port 2/4 mux state transition: not aggregate ->
>>>> aggregate
>>>> Jan 23 10:40:23:W:LACP: ethernet 2/4 state changes from DOWN to
>>>> LACP-BLOCKED
>>>> Jan 23 10:40:22:W:LACP: ethernet 2/4 state changes from LACP-BLOCKED to
>>>> DOWN
>>>> Jan 23 10:40:22:I:LACP: Port 2/4 mux state transition: aggregate -> not
>>>> aggregate (reason: peer is out of sync)
>>>>
>>>> Jörg
>>>>
>>>> ---
>>>>
>>>> Sorry for the 20 questions but:
>>>> Are you seeing this on slow timers or fast timers? Do you use observium? What line card are you using (8x10g)?
>>>>
>>>> Thanks
>>>> -Tim.
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp@puck.nether.net
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>>
>>>
>>> E-Mail to and from me, in connection with the transaction
>>> of public business, is subject to the Wyoming Public Records
>>> Act and may be disclosed to third parties.
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> E-Mail to and from me, in connection with the transaction
> of public business, is subject to the Wyoming Public Records
> Act and may be disclosed to third parties.
Re: NetIron 5.8f feedbacks [ In reply to ]
Hello Daniel,

On Fri, 2017-01-27 at 18:04 -0700, Daniel Schmidt wrote:
> I use the new 10x20 10G cards, which require 5.8. The cards are not stable
> for us, they crash periodically. And, we had one or two mlx reboot for no
> reason. Things were better when we ran 5.6. Of course, perhaps 5.8 would
> be more stable without the cards so a grain of proverbial salt applies.

Did the TAC advised you something ? I am running 5.8.00ec on MLXe with
BR-MLX-10Gx20 cards with no specific issues. The previous versions used
to have a known bug with some ipsec packets which could crash the
system. have a look there: TSB 2016-242-A & defect 617836

I previously talked about this defect on this mailing list, on
22-Sep-2016 12:18:22 (+2)

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
2017-01-28 11:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:

> Hello Daniel,
>
> On Fri, 2017-01-27 at 18:04 -0700, Daniel Schmidt wrote:
> > I use the new 10x20 10G cards, which require 5.8. The cards are not
> stable
> > for us, they crash periodically. And, we had one or two mlx reboot for
> no
> > reason. Things were better when we ran 5.6. Of course, perhaps 5.8
> would
> > be more stable without the cards so a grain of proverbial salt applies.
>
> Did the TAC advised you something ? I am running 5.8.00ec on MLXe with
> BR-MLX-10Gx20 cards with no specific issues. The previous versions used
> to have a known bug with some ipsec packets which could crash the
> system. have a look there: TSB 2016-242-A & defect 617836
>
> I previously talked about this defect on this mailing list, on
> 22-Sep-2016 12:18:22 (+2)
>
>
I have a dozen routers with 10Gx20, both -X2 and -M, running without issues.
I would prefer to keep it that way so any updates on your situation would
be appreciated.

Regards Tony
Re: NetIron 5.8f feedbacks [ In reply to ]
I am applying 05800fa in hopes of fixing it. I will let you know, but it
will be couple weeks before I know.

On Sat, Jan 28, 2017 at 7:50 AM, Tony Sarendal <tony@polarcap.org> wrote:

>
> 2017-01-28 11:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:
>
>> Hello Daniel,
>>
>> On Fri, 2017-01-27 at 18:04 -0700, Daniel Schmidt wrote:
>> > I use the new 10x20 10G cards, which require 5.8. The cards are not
>> stable
>> > for us, they crash periodically. And, we had one or two mlx reboot for
>> no
>> > reason. Things were better when we ran 5.6. Of course, perhaps 5.8
>> would
>> > be more stable without the cards so a grain of proverbial salt applies.
>>
>> Did the TAC advised you something ? I am running 5.8.00ec on MLXe with
>> BR-MLX-10Gx20 cards with no specific issues. The previous versions used
>> to have a known bug with some ipsec packets which could crash the
>> system. have a look there: TSB 2016-242-A & defect 617836
>>
>> I previously talked about this defect on this mailing list, on
>> 22-Sep-2016 12:18:22 (+2)
>>
>>
> I have a dozen routers with 10Gx20, both -X2 and -M, running without
> issues.
> I would prefer to keep it that way so any updates on your situation would
> be appreciated.
>
> Regards Tony
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

--

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
Re: NetIron 5.8f feedbacks [ In reply to ]
On a side note, I find the process of upgrading an MLX to be tedious, slow
and error-prone even with the manifest file. Certainly, much smarter
people than me are here - has anybody written a multi-threaded SCP way of
upgrading several MLX? I started on something but, really, I can't
multi-thread none too guud.

On Sat, Jan 28, 2017 at 9:49 PM, Daniel Schmidt <daniel.schmidt@wyo.gov>
wrote:

> I am applying 05800fa in hopes of fixing it. I will let you know, but it
> will be couple weeks before I know.
>
> On Sat, Jan 28, 2017 at 7:50 AM, Tony Sarendal <tony@polarcap.org> wrote:
>
>>
>> 2017-01-28 11:08 GMT+01:00 Clement Cavadore <clement@cavadore.net>:
>>
>>> Hello Daniel,
>>>
>>> On Fri, 2017-01-27 at 18:04 -0700, Daniel Schmidt wrote:
>>> > I use the new 10x20 10G cards, which require 5.8. The cards are not
>>> stable
>>> > for us, they crash periodically. And, we had one or two mlx reboot
>>> for no
>>> > reason. Things were better when we ran 5.6. Of course, perhaps 5.8
>>> would
>>> > be more stable without the cards so a grain of proverbial salt applies.
>>>
>>> Did the TAC advised you something ? I am running 5.8.00ec on MLXe with
>>> BR-MLX-10Gx20 cards with no specific issues. The previous versions used
>>> to have a known bug with some ipsec packets which could crash the
>>> system. have a look there: TSB 2016-242-A & defect 617836
>>>
>>> I previously talked about this defect on this mailing list, on
>>> 22-Sep-2016 12:18:22 (+2)
>>>
>>>
>> I have a dozen routers with 10Gx20, both -X2 and -M, running without
>> issues.
>> I would prefer to keep it that way so any updates on your situation would
>> be appreciated.
>>
>> Regards Tony
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>

--

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
Re: NetIron 5.8f feedbacks [ In reply to ]
On 01/31/2017 06:01 PM, Daniel Schmidt wrote:
> I find the process of upgrading an MLX to be tedious, slow and
> error-prone even with the manifest file. Certainly, much smarter people
> than me are here - has anybody written a multi-threaded SCP way of
> upgrading several MLX?

You might look into using ClusterSSH (which can use either SSH or
telnet). It allows you to connect to multiple devices at once. The
commands you type go to all of the devices simultaneously.

--
Richard
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: NetIron 5.8f feedbacks [ In reply to ]
SCP based upgrade is possible, my SE confirmed that some time ago.

It has been introduced officially as a feature in release 6.1, look at the release notes.

HTH..



> Le 1 févr. 2017 à 05:02, Richard Laager <rlaager@wiktel.com> a écrit :
>
>> On 01/31/2017 06:01 PM, Daniel Schmidt wrote:
>> I find the process of upgrading an MLX to be tedious, slow and
>> error-prone even with the manifest file. Certainly, much smarter people
>> than me are here - has anybody written a multi-threaded SCP way of
>> upgrading several MLX?
>
> You might look into using ClusterSSH (which can use either SSH or
> telnet). It allows you to connect to multiple devices at once. The
> commands you type go to all of the devices simultaneously.
>
> --
> Richard
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
Hello,

good point with timers. I changed all transceivers but the issue still
exists. I turned on debugging mode and noticed that the problem only
exists on ethernet 2/4. That interface is part of a lag spanning 2x
BR-MLX-10Gx4-X, using default-mode. The other side is a Brocade VDX with
all interfaces on long-mode, like it was recommended by some Brocade
document.

The lacp-counters are exploding on that 2/4 interfaces also. There are
no framing, crc - errors visible on MLXE or VDX.

MLXE-side:

====LAG "core10" ID 2 ====

Port Role Sys Port Oper
[Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope][Port]
Pri Pri Key
Num

2/3 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
Ope 51
2/3 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
Ope 5124
2/4 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
Ope 52
2/4 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
Ope 5123
3/3 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
Ope 99
3/3 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
Ope 5636
3/4 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
Ope 100
3/4 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
Ope 5635

Actor System MAC cxxx.xxxx.xxxx

Port Partner MP LACP LP LACP MP LACP LP LACP MP LACP
LP LACP MP MARKER LP MARKER
System MAC Rx Count Rx Count Tx Count Tx Count Err Count
Err Count Rx Count Rx Count
2/3 01e0.5200.xxxx 76112 76112 76116 76116 0
0 0 0
2/4 01e0.5200.xxxx 1814178 1814178 1874205 1874205 0
0 0 0
3/3 01e0.5200.xxxx 76112 76112 76116 76116 0
0 0 0
3/4 01e0.5200.xxxx 76111 76111 76116 76116 0
0 0 0

VDX-Side:
core-10# show port-channel 10
LACP Aggregator: Po 10 (vLAG)
Aggregator type: Standard
Ignore-split is enabled
Member rbridges:
rbridge-id: 10 (2)
rbridge-id: 11 (2)
Admin Key: 0010 - Oper Key 0010
Partner Oper Key 0100
Member ports on rbridge-id 10:
Link: Te 10/0/3 (0xA18018002) sync: 1
Link: Te 10/0/4 (0xA18020003) sync: 1

Member ports on rbridge-id 11:
Link: Te 11/0/3 (0xB18018002) sync: 1
Link: Te 11/0/4 (0xB18020003) sync: 1 *

core-10# show running-config interface TenGigabitEthernet 10/0/3
interface TenGigabitEthernet 10/0/3
no fabric isl enable
no fabric trunk enable
channel-group 10 mode active type standard
lacp timeout long
no shutdown
!
core-10# show running-config interface TenGigabitEthernet 10/0/4
interface TenGigabitEthernet 10/0/4
no fabric isl enable
no fabric trunk enable
channel-group 10 mode active type standard
lacp timeout long
no shutdown
!
core-10# show running-config interface TenGigabitEthernet 11/0/4
interface TenGigabitEthernet 11/0/4
no fabric isl enable
no fabric trunk enable
channel-group 10 mode active type standard
lacp timeout long
no shutdown
!
core-10# show running-config interface TenGigabitEthernet 11/0/3
interface TenGigabitEthernet 11/0/3
no fabric isl enable
no fabric trunk enable
channel-group 10 mode active type standard
lacp timeout long
no shutdown

Debug output for lacp for any other interface is almost silent, but for
2/4 it is every second complaining:

Feb 3 11:30:13 MLXE Feb 3 11:30:13.255 Ticks45671481: Lacp restrict_tx
timer started for port 2/4 (timeout = 1000 ms)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 LACP: RX on 2/4
A<8000:01e0.5200.xxxx:000a:8000:1402:A.ASCD..>P<0001:cxxx.xxx.xxx:0064:0001:0033:ATAS....>
Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 rx_machine:Port2/4: event = 7
(Lac_received), current state = 105 (CURRENT)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 rxm_current:Port2/4: old state
= 105 (CURRENT)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
tx_scheduler timer started for port 2/4 (timeout = 100 ms)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 select_aggregator:Port2/4:
select aggregator 3761f200
[Aport2/3,Key0064,LAG[(0001,cxxx.xxx.xxx,0064),(8000,01e0.5200.xxxx,000a)]]
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 rxm_current:Port2/4: stop
current_while_timer (handle 1686)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
current_while timer stopped for port 2/4
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
current_while timer started for port 2/4 (timeout = 90000 ms)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 mux_machine:Port2/4: event = 8
(Lac_new_info), current state = 305 (DISTRIBUTING)
Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 Ticks45671501: Lacp
tx_scheduler timer expired for port 2/4
Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 LACP: TX on 2/4
A<0001:cxxx.xxx.xxx:0064:0001:0033:A.ASCD..>P<8000:01e0.5200.xxxx:000a:8000:1402:A.ASCD..>
Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 Ticks45671501: Lacp restrict_tx
timer expired for port 2/4

When i disable and re-enable that port 2/4 by editing the
lag-configuration, things will look fine for an amount of time and the
LACP messages will go silent like all the other ports. I tried this
several times, but forgot to configure the debug output right to capture
the messages.

So currently I am logging the debug LACP outputs to an external
destination and I am looking forward that the interface will go nuts
again.

Any idea so far?

Jörg

On 27 Jan 2017, at 1:39, Tim Warnock wrote:

> ---
>
> Sorry for the 20 questions but:
> Are you seeing this on slow timers or fast timers? Do you use
> observium? What line card are you using (8x10g)?
>
> Thanks
> -Tim.
> _______________________________________________
> 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
Re: NetIron 5.8f feedbacks [ In reply to ]
Whoops, messed up the output.

MLXE:
LACP System Priority / ID :1 / cxxx.xxxx.xxxx
LACP Long timeout :90, default: 90
LACP Short timeout :3, default: 3

=== LAG "vdx-core" ID 2 (dynamic Deployed) ===
LAG Deployment: Trunk ID 2, Active Primary 3/3, base fid: 0x0800

Port Link Port-State Dupl Speed Trunk Tag Priori MAC
Name Type
2/3 Up Forward Full 10G 2 Yes level0 cxxx.xxxx.xxxx
ten/10/0/4 default-port
2/4 Up Forward Full 10G 2 Yes level0 cxxx.xxxx.xxxx
ten/10/0/3 default-port
3/3 Up Forward Full 10G 2 Yes level0 cxxx.xxxx.xxxx
ten/11/0/4 default-port
3/4 Up Forward Full 10G 2 Yes level0 cxxx.xxxx.xxxx
ten/11/0/3 default-port

Actor System MAC cxxx.xxxx.xxxx

Port Partner MP LACP LP LACP MP LACP LP LACP MP LACP
LP LACP MP MARKER LP MARKER
System MAC Rx Count Rx Count Tx Count Tx Count Err Count
Err Count Rx Count Rx Count
2/3 01e0.5200.xxxx 76180 76180 76184 76184 0
0 0 0
2/4 01e0.5200.xxxx 1814762 1814762 1874805 1874805 0
0 0 0
3/3 01e0.5200.xxxx 76180 76180 76184 76184 0
0 0 0
3/4 01e0.5200.xxxx 76179 76179 76184 76184 0
0 0 0

VDX:
#core 10 show port-channel detail
LACP Aggregator: Po 10 (vLAG)
Aggregator type: Standard
Ignore-split is enabled
Member rbridges:
rbridge-id: 10 (2)
rbridge-id: 11 (2)
Actor System ID - 0x8000,01-e0-52-00-XX-XX
Admin Key: 0010 - Oper Key 0010
Receive link count: 4 - Transmit link count: 4
Individual: 0 - Ready: 1
Partner System ID - 0x0001,cc-xx-xx-xx-xx-xx
Partner Oper Key 0100
Member ports on rbridge-id 10:
Link: Te 10/0/3 (0xA18018002) sync: 1
Link: Te 10/0/4 (0xA18020003) sync: 1

Member ports on rbridge-id 11:
Link: Te 11/0/3 (0xB18018002) sync: 1
Link: Te 11/0/4 (0xB18020003) sync: 1 *

core-10# show lacp counter 10
Traffic statistics
Port LACPDUs Marker Pckt err
Sent Recv Sent Recv Sent Recv
Aggregator Po 10
Te 10/0/3 2536875 2596833 0 0 0 0
Te 10/0/4 930152 930202 0 0 0 0
Aggregator Po 10
Te 11/0/3 794762 794736 0 0 0 0
Te 11/0/4 930140 930203 0 0 0 0


On 3 Feb 2017, at 11:55, Jörg Kost wrote:

> Hello,
>
> good point with timers. I changed all transceivers but the issue still
> exists. I turned on debugging mode and noticed that the problem only
> exists on ethernet 2/4. That interface is part of a lag spanning 2x
> BR-MLX-10Gx4-X, using default-mode. The other side is a Brocade VDX
> with all interfaces on long-mode, like it was recommended by some
> Brocade document.
>
> The lacp-counters are exploding on that 2/4 interfaces also. There are
> no framing, crc - errors visible on MLXE or VDX.
>
> MLXE-side:
>
> ====LAG "core10" ID 2 ====
>
> Port Role Sys Port Oper
> [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope][Port]
> Pri Pri Key
> Num
>
> 2/3 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
> Ope 51
> 2/3 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
> Ope 5124
> 2/4 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
> Ope 52
> 2/4 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
> Ope 5123
> 3/3 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
> Ope 99
> 3/3 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
> Ope 5636
> 3/4 ACTR 1 1 100 Yes L Agg Syn Col Dis No No
> Ope 100
> 3/4 PRTR 32768 32768 10 Yes L Agg Syn Col Dis No No
> Ope 5635
>
> Actor System MAC cxxx.xxxx.xxxx
>
> Port Partner MP LACP LP LACP MP LACP LP LACP MP LACP
> LP LACP MP MARKER LP MARKER
> System MAC Rx Count Rx Count Tx Count Tx Count Err Count
> Err Count Rx Count Rx Count
> 2/3 01e0.5200.xxxx 76112 76112 76116 76116 0
> 0 0 0
> 2/4 01e0.5200.xxxx 1814178 1814178 1874205 1874205 0
> 0 0 0
> 3/3 01e0.5200.xxxx 76112 76112 76116 76116 0
> 0 0 0
> 3/4 01e0.5200.xxxx 76111 76111 76116 76116 0
> 0 0 0
>
> VDX-Side:
> core-10# show port-channel 10
> LACP Aggregator: Po 10 (vLAG)
> Aggregator type: Standard
> Ignore-split is enabled
> Member rbridges:
> rbridge-id: 10 (2)
> rbridge-id: 11 (2)
> Admin Key: 0010 - Oper Key 0010
> Partner Oper Key 0100
> Member ports on rbridge-id 10:
> Link: Te 10/0/3 (0xA18018002) sync: 1
> Link: Te 10/0/4 (0xA18020003) sync: 1
>
> Member ports on rbridge-id 11:
> Link: Te 11/0/3 (0xB18018002) sync: 1
> Link: Te 11/0/4 (0xB18020003) sync: 1 *
>
> core-10# show running-config interface TenGigabitEthernet 10/0/3
> interface TenGigabitEthernet 10/0/3
> no fabric isl enable
> no fabric trunk enable
> channel-group 10 mode active type standard
> lacp timeout long
> no shutdown
> !
> core-10# show running-config interface TenGigabitEthernet 10/0/4
> interface TenGigabitEthernet 10/0/4
> no fabric isl enable
> no fabric trunk enable
> channel-group 10 mode active type standard
> lacp timeout long
> no shutdown
> !
> core-10# show running-config interface TenGigabitEthernet 11/0/4
> interface TenGigabitEthernet 11/0/4
> no fabric isl enable
> no fabric trunk enable
> channel-group 10 mode active type standard
> lacp timeout long
> no shutdown
> !
> core-10# show running-config interface TenGigabitEthernet 11/0/3
> interface TenGigabitEthernet 11/0/3
> no fabric isl enable
> no fabric trunk enable
> channel-group 10 mode active type standard
> lacp timeout long
> no shutdown
>
> Debug output for lacp for any other interface is almost silent, but
> for 2/4 it is every second complaining:
>
> Feb 3 11:30:13 MLXE Feb 3 11:30:13.255 Ticks45671481: Lacp
> restrict_tx timer started for port 2/4 (timeout = 1000 ms)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 LACP: RX on 2/4
> A<8000:01e0.5200.xxxx:000a:8000:1402:A.ASCD..>P<0001:cxxx.xxx.xxx:0064:0001:0033:ATAS....>
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 rx_machine:Port2/4: event = 7
> (Lac_received), current state = 105 (CURRENT)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.160 rxm_current:Port2/4: old
> state = 105 (CURRENT)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
> tx_scheduler timer started for port 2/4 (timeout = 100 ms)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 select_aggregator:Port2/4:
> select aggregator 3761f200
> [Aport2/3,Key0064,LAG[(0001,cxxx.xxx.xxx,0064),(8000,01e0.5200.xxxx,000a)]]
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 rxm_current:Port2/4: stop
> current_while_timer (handle 1686)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
> current_while timer stopped for port 2/4
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 Ticks45671499: Lacp
> current_while timer started for port 2/4 (timeout = 90000 ms)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.161 mux_machine:Port2/4: event =
> 8 (Lac_new_info), current state = 305 (DISTRIBUTING)
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 Ticks45671501: Lacp
> tx_scheduler timer expired for port 2/4
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 LACP: TX on 2/4
> A<0001:cxxx.xxx.xxx:0064:0001:0033:A.ASCD..>P<8000:01e0.5200.xxxx:000a:8000:1402:A.ASCD..>
> Feb 3 11:30:14 MLXE Feb 3 11:30:14.254 Ticks45671501: Lacp
> restrict_tx timer expired for port 2/4
>
> When i disable and re-enable that port 2/4 by editing the
> lag-configuration, things will look fine for an amount of time and the
> LACP messages will go silent like all the other ports. I tried this
> several times, but forgot to configure the debug output right to
> capture the messages.
>
> So currently I am logging the debug LACP outputs to an external
> destination and I am looking forward that the interface will go nuts
> again.
>
> Any idea so far?
>
> Jörg
>
> On 27 Jan 2017, at 1:39, Tim Warnock wrote:
>
>> ---
>>
>> Sorry for the 20 questions but:
>> Are you seeing this on slow timers or fast timers? Do you use
>> observium? What line card are you using (8x10g)?
>>
>> Thanks
>> -Tim.
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

1 2  View All