Mailing List Archive: nsp: foundry

XMR Software Upgrade Path from 4.0.1a

Index | Next | Previous | View Threaded

gk at ax

Jan 11, 2011, 3:24 AM

Post #1 of 19 (2537 views)
Permalink

XMR Software Upgrade Path from 4.0.1a

Hi,

we have some XMRs in production, all with the older 4.0.1a code. The
Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
the moment.
We plan to upgrade the systems with an newer software release and I
wondering if there exist any arguments against using the latest 5.1 code?

Cheers,
--
Gerald (ax/tc)
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

ccosta at cenic

Jan 11, 2011, 7:13 AM

Post #2 of 19 (2502 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

I believe your IronWare upgrade to 5.0 will have to include upgrading FPGA images as well:

Mgmt Modules:
- Requires MBRIDGE, Rev 32

Interface Modules:
- PBIFSP2.bin, Rev 3.21
- XPPSP2.bin, Rev 6.03

Chris

On Jan 11, 2011, at 3:24 AM, Gerald Krause wrote:

> Hi,
>
> we have some XMRs in production, all with the older 4.0.1a code. The
> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
> the moment.
> We plan to upgrade the systems with an newer software release and I
> wondering if there exist any arguments against using the latest 5.1 code?
>
> Cheers,
> --
> Gerald (ax/tc)
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

gk at ax

Jan 11, 2011, 2:17 PM

Post #3 of 19 (2485 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Hi Chris,

yes, looks like that I have to upgrade the FPGAs as well. But I'm a
little bit more interested in opinions concerning the 5.1 software in
general. How does it feel in the real - does anybody use this train in
production currently at all?

The main reason for the decision to upgrade our systems is that we
observed some (rare) FIB issues in the past, e.g. "IPv4/Pv6 route exist
but no corresponding record is in th FIB" or the other way around - we
saw "records in the FIB without a matching IPv4/IPv6 route".

I've checked nearly all release notes since 4.0.1a and every notes for a
newer version has make think "oh my good, don't use the former one" and
so I'm simply end up in 5.1 ;-).

--
Gerald (ax/tc)

Am 11.01.11 16:13, schrieb Chris Costa:
> I believe your IronWare upgrade to 5.0 will have to include upgrading FPGA images as well:
>
> Mgmt Modules:
> - Requires MBRIDGE, Rev 32
>
> Interface Modules:
> - PBIFSP2.bin, Rev 3.21
> - XPPSP2.bin, Rev 6.03
>
>
> Chris
>
>
> On Jan 11, 2011, at 3:24 AM, Gerald Krause wrote:
>
>> Hi,
>>
>> we have some XMRs in production, all with the older 4.0.1a code. The
>> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
>> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
>> the moment.
>> We plan to upgrade the systems with an newer software release and I
>> wondering if there exist any arguments against using the latest 5.1 code?
>>
>> Cheers,
>> --
>> Gerald (ax/tc)
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp [at] puck
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Jan 11, 2011, 7:49 PM

Post #4 of 19 (2513 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

We use 5.0 and are planning to upgrade to 5.1 soon-ish. The main
reason is the "cross chassis trunking" or MCT (like Arista's mLAG).
Basically you can do what amounts to stacking MLX/XMR units. We
wanted that code version to get some mileage on it first and wanted to
wait until there were a couple of bugfix releases. They are at
5.1.00b currently though I don't know how many are using the MCT
function so can't get a feel for how much that feature has been
exercised.

The data center where we need to deploy that was actually engineered
with that feature in mind. The topology is pretty close to that shown
in Fig. 1 on page 3 of this document:

http://www.brocade.com/downloads/documents/white_papers/Brocade_Multi-Chassis_Trunking_WP.pdf

Except we use Arista 7100 switches instead of the CES shown (basically
because the 7100's are 10G switches and the Brocade TurboIron doesn't
support MCT).

Is anyone here using the MCT feature on MLX/XMR ?

On Tue, Jan 11, 2011 at 2:17 PM, Gerald Krause <gk [at] ax> wrote:
> Hi Chris,
>
> yes, looks like that I have to upgrade the FPGAs as well. But I'm a
> little bit more interested in opinions concerning the 5.1 software in
> general. How does it feel in the real - does anybody use this train in
> production currently at all?
>
> The main reason for the decision to upgrade our systems is that we
> observed some (rare) FIB issues in the past, e.g. "IPv4/Pv6 route exist
> but no corresponding record is in th FIB" or the other way around - we
> saw "records in the FIB without a matching IPv4/IPv6 route".
>
> I've checked nearly all release notes since 4.0.1a and every notes for a
> newer version has make think "oh my good, don't use the former one" and
> so I'm simply end up in 5.1 ;-).
>
> --
> Gerald � (ax/tc)
>
> Am 11.01.11 16:13, schrieb Chris Costa:
>> I believe your IronWare upgrade to 5.0 will have to include upgrading FPGA images as well:
>>
>> Mgmt Modules:
>> - Requires MBRIDGE, Rev 32
>>
>> Interface Modules:
>> - PBIFSP2.bin, Rev 3.21
>> - XPPSP2.bin, Rev 6.03
>>
>>
>> Chris
>>
>>
>> On Jan 11, 2011, at 3:24 AM, Gerald Krause wrote:
>>
>>> Hi,
>>>
>>> we have some XMRs in production, all with the older 4.0.1a code. The
>>> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
>>> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
>>> the moment.
>>> We plan to upgrade the systems with an newer software release and I
>>> wondering if there exist any arguments against using the latest 5.1 code?
>>>
>>> Cheers,
>>> --
>>> Gerald � (ax/tc)
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp [at] puck
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

cmarlatt at rxsec

Jan 12, 2011, 4:18 AM

Post #5 of 19 (2488 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

On 01/11/2011 10:49 PM, George B. wrote:
> Is anyone here using the MCT feature on MLX/XMR ?

We just deployed our first pair of CES switches using MCT and they're
running great so far. They're doing OSPF, VRRPE, etc - however no BGP.

We'll be deploying a pair of core level MLX's using MCT (along with
pairs of CES's also running MCT) sometime this month. Our testing has
been quite positive with even some better than expected behaviour on a
simulated portion of our network that will need to continue to run PVST.

It is still a new technology on Brocade gear but so far it seems stable
enough to take a chance and reap the benefits.

Regards,

Chris
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

jbrashea at Brocade

Jan 12, 2011, 5:53 AM

Post #6 of 19 (2479 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

In the last deployment I did involving MCT(it was a 2-level MCT config on the MLX platform as well as between MLX & CES platforms) we used 5.1.00b and it worked quite well. The technology has a little bit of a learning curve(at least it did for me), but once it's up it runs like a champ.

Jonathan Brashear
Brocade Resident Consultant, Americas BRCs, Advanced Services
jbrashea [at] brocade
Office: 214-887-7719
Cell: 214-850-5986
www.brocade.com

-----Original Message-----
From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Chris Marlatt
Sent: Wednesday, January 12, 2011 6:18 AM
To: George B.
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a

On 01/11/2011 10:49 PM, George B. wrote:
> Is anyone here using the MCT feature on MLX/XMR ?

We just deployed our first pair of CES switches using MCT and they're
running great so far. They're doing OSPF, VRRPE, etc - however no BGP.

We'll be deploying a pair of core level MLX's using MCT (along with
pairs of CES's also running MCT) sometime this month. Our testing has
been quite positive with even some better than expected behaviour on a
simulated portion of our network that will need to continue to run PVST.

It is still a new technology on Brocade gear but so far it seems stable
enough to take a chance and reap the benefits.

Regards,

Chris
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

The information contained in this transmission may contain privileged and confidential information.
It is intended only for the use of the person(s) named above. If you are not the intended
recipient, you are hereby notified that any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original message.
To reply to our email administrator directly, please send an email to postmaster [at] sbsplanet

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

georgeb at gmail

Jan 12, 2011, 8:50 AM

Post #7 of 19 (2487 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

"but once it's up"

Yeah, that's the problem. Where we need it is on a production network
that is serving customers who are very sensitive to downtime. We are
close enough to Brocade that maybe I will see if I can run through the
upgrade process in their Proof of Concept Lab first before we do it in
that particular network. I think we can configure a couple of MLX to
the same configuration we have in production and run through the
upgrade process a couple of times in the lab first.

On Wed, Jan 12, 2011 at 5:53 AM, Jonathan Brashear <jbrashea [at] brocade> wrote:
> In the last deployment I did involving MCT(it was a 2-level MCT config on the MLX platform as well as between MLX & CES platforms) we used 5.1.00b and it worked quite well. �The technology has a little bit of a learning curve(at least it did for me), but once it's up it runs like a champ.
>
> Jonathan Brashear
> Brocade Resident Consultant, Americas BRCs, Advanced Services
> jbrashea [at] brocade
> Office: 214-887-7719
> Cell: 214-850-5986
> www.brocade.com
>
> -----Original Message-----
> From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Chris Marlatt
> Sent: Wednesday, January 12, 2011 6:18 AM
> To: George B.
> Cc: foundry-nsp [at] puck
> Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a
>
> On 01/11/2011 10:49 PM, George B. wrote:
>> Is anyone here using the MCT feature on MLX/XMR ?
>
> We just deployed our first pair of CES switches using MCT and they're
> running great so far. They're doing OSPF, VRRPE, etc - however no BGP.
>
> We'll be deploying a pair of core level MLX's using MCT (along with
> pairs of CES's also running MCT) sometime this month. Our testing has
> been quite positive with even some better than expected behaviour on a
> simulated portion of our network that will need to continue to run PVST.
>
> It is still a new technology on Brocade gear but so far it seems stable
> enough to take a chance and reap the benefits.
>
> Regards,
>
> Chris
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> The information contained in this transmission may contain privileged and confidential information.
> It is intended only for the use of the person(s) named above. If you are not the intended
> recipient, you are hereby notified that any review, dissemination, distribution or
> duplication of this communication is strictly prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the original message.
> To reply to our email administrator directly, please send an email to postmaster [at] sbsplanet
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

gk at ax

Jan 12, 2011, 8:50 AM

Post #8 of 19 (2482 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Just FYI: as a summary of all on- and off-list receivend responses I'll
go for the 5.1 train. Thx!

--
Gerald (ax/tc)

Am 11.01.2011 12:24, schrieb Gerald Krause:
> Hi,
>
> we have some XMRs in production, all with the older 4.0.1a code. The
> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
> the moment.
> We plan to upgrade the systems with an newer software release and I
> wondering if there exist any arguments against using the latest 5.1 code?
>
> Cheers,
> --
> Gerald (ax/tc)
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Vinny_Abello at dell

Jan 17, 2011, 10:13 AM

Post #9 of 19 (2442 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Hi Gerald,

Just wondering if you happened to upgrade to 5.1. We're actually running pre
4.x code on our XMR's and would like to upgrade to fix a few bugs and gain
features. There are specific features only introduced in 5.1 that are very
attractive to me. Wondering if you've pulled the trigger yet and how 5.1 is
running in your environment.

I also am wondering if there are any Hurricane Electric engineers on this
list. I know their backbone is largely based (if not entirely) on the XMR
platform, both from what I've read and having actually seen one of their
core routers in a cage we are both in. I was curious as to what code
revision they might be running as I'm sure they have extensive experience
with the XMR on their dual stack v4/v6 backbone. Plus I've rarely heard of
or have seen any major issues with Hurricane Electric so I'd assume they're
relatively happy with the code revision they are running. I might just ask
our Brocade rep if they'd be willing to find out and share that information
with us if possible.

Vinny Abello
Network Engineer
Dell | Physician Services
office +1 973 940 6125
mobile +1 973 868 0610
vinny_abello [at] dell

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of Gerald Krause
Sent: Wednesday, January 12, 2011 11:51 AM
To: foundry-nsp [at] puck
Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a

Just FYI: as a summary of all on- and off-list receivend responses I'll
go for the 5.1 train. Thx!

--
Gerald (ax/tc)

Am 11.01.2011 12:24, schrieb Gerald Krause:
> Hi,
>
> we have some XMRs in production, all with the older 4.0.1a code. The
> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
> the moment.
> We plan to upgrade the systems with an newer software release and I
> wondering if there exist any arguments against using the latest 5.1 code?
>
> Cheers,
> --
> Gerald (ax/tc)
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Attachments:

smime.p7s (4.88 KB)

gk at ax

Jan 17, 2011, 12:29 PM

Post #10 of 19 (2447 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Hi Vinny,

our first upgrade will take place on thursday morning, this week. So at
the moment I can't say anything but I'am curious about the result.

--
Gerald (ax/tc)

Am 17.01.11 19:13, schrieb Abello, Vinny:
> Hi Gerald,
>
> Just wondering if you happened to upgrade to 5.1. We're actually running pre
> 4.x code on our XMR's and would like to upgrade to fix a few bugs and gain
> features. There are specific features only introduced in 5.1 that are very
> attractive to me. Wondering if you've pulled the trigger yet and how 5.1 is
> running in your environment.
>
> I also am wondering if there are any Hurricane Electric engineers on this
> list. I know their backbone is largely based (if not entirely) on the XMR
> platform, both from what I've read and having actually seen one of their
> core routers in a cage we are both in. I was curious as to what code
> revision they might be running as I'm sure they have extensive experience
> with the XMR on their dual stack v4/v6 backbone. Plus I've rarely heard of
> or have seen any major issues with Hurricane Electric so I'd assume they're
> relatively happy with the code revision they are running. I might just ask
> our Brocade rep if they'd be willing to find out and share that information
> with us if possible.
>
> Vinny Abello
> Network Engineer
> Dell | Physician Services
> office +1 973 940 6125
> mobile +1 973 868 0610
> vinny_abello [at] dell
>
> -----Original Message-----
> From: foundry-nsp-bounces [at] puck
> [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Gerald Krause
> Sent: Wednesday, January 12, 2011 11:51 AM
> To: foundry-nsp [at] puck
> Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a
>
> Just FYI: as a summary of all on- and off-list receivend responses I'll
> go for the 5.1 train. Thx!
>
> --
> Gerald (ax/tc)
>
> Am 11.01.2011 12:24, schrieb Gerald Krause:
>> Hi,
>>
>> we have some XMRs in production, all with the older 4.0.1a code. The
>> Systems are doing mainly L3 things like OSPF, BGP and VRRP within an
>> IPv4/IPv6 dualstack environment but no *PLS or special L2 services at
>> the moment.
>> We plan to upgrade the systems with an newer software release and I
>> wondering if there exist any arguments against using the latest 5.1 code?
>>
>> Cheers,
>> --
>> Gerald (ax/tc)
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp [at] puck
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

foundry-nsp at ergens

Jan 17, 2011, 1:02 PM

Post #11 of 19 (2438 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Hi,

We at Oxilion, dutch based hosting provider, are running 4.0.0a for
about 2 years now without any problems. Basic functions like OSPF,
BGP, IPv4/IPv6 dualstack etc.

No need to upgrade to 5.1 here yet.

regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Vinny_Abello at dell

Jan 18, 2011, 2:46 PM

Post #12 of 19 (2427 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Thanks for the input, Igor.

We specifically have issues with path-mtu-discovery being broken in IPv6 due
to the XMR not responding with icmp unreachables with IPv6. This is a known
issue according to Brocade and is fixed in later releases.

We also recently had a very odd failure on two of four XMR's running the
same code within a couple of hours of each other, thousands of miles apart.
I unfortunately wasn't able to get enough information about what caused the
failure when it was happening, but the XMR's RP seemed to stay alive yet
line cards stopped forwarding traffic and some routing protocols were
flapping causing churn. For the most part, the IGP and iBGP sessions stayed
established which was really weird. No access to the devices were possible
via any means including connecting from an adjacent device. A hard reboot
brought them back online again. It's odd we saw that issues on two of them
within hours of each other but no others were affected. This also happened
early on January 1st which is a little weird.

NSF support (or whatever Brocade calls it) on IS-IS is a new feature in 5.1
that I'd like to have support for. It would complement my Cisco's already
supporting this for quite some time now and make an RP failover much less
noticeable.

Vinny Abello
Network Engineer
Dell | Physician Services
office +1 973 940 6125
mobile +1 973 868 0610
vinny_abello [at] dell

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of Igor Ybema
Sent: Monday, January 17, 2011 4:02 PM
To: foundry-nsp [at] puck
Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a

Hi,

We at Oxilion, dutch based hosting provider, are running 4.0.0a for
about 2 years now without any problems. Basic functions like OSPF,
BGP, IPv4/IPv6 dualstack etc.

No need to upgrade to 5.1 here yet.

regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Attachments:

smime.p7s (4.88 KB)

foundry-nsp at ergens

Jan 19, 2011, 6:37 AM

Post #13 of 19 (2415 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Hi,

> We specifically have issues with path-mtu-discovery being broken in IPv6 due
> to the XMR not responding with icmp unreachables with IPv6. This is a known
> issue according to Brocade and is fixed in later releases.

Didn't knew this. We do use IPv6 but haven't stumbled on a problem yet
with it. In which case should I see a problem with the
path-mtu-discovery not working?

regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Vinny_Abello at dell

Jan 19, 2011, 1:35 PM

Post #14 of 19 (2412 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

You'd see this if your IP MTU's are dissimilar across your network anywhere.
This bit us because our links can vary in MTU size depending on the provider
of the circuit or link type. On our Cisco devices, they by default try to
use path-mtu-discovery to optimize the iBGP communication. This resulted in
MTU blackholes and stalled/flapping iBGP sessions on IPv6 between Cisco
routers where an XMR was in the path. It could affect many things depending
on your topology, configuration and applications, or you might not see it at
all.

Vinny Abello
Network Engineer
Dell | Physician Services
office +1 973 940 6125
mobile +1 973 868 0610
vinny_abello [at] dell

-----Original Message-----
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Wednesday, January 19, 2011 9:37 AM
To: Abello, Vinny
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a

Hi,

> We specifically have issues with path-mtu-discovery being broken in IPv6
due
> to the XMR not responding with icmp unreachables with IPv6. This is a
known
> issue according to Brocade and is fixed in later releases.

Didn't knew this. We do use IPv6 but haven't stumbled on a problem yet
with it. In which case should I see a problem with the
path-mtu-discovery not working?

regards, Igor

Attachments:

smime.p7s (4.88 KB)

dunc.lockwood at thebunker

Jan 27, 2011, 2:04 PM

Post #15 of 19 (2351 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Igor,

Have you tried to do an ACL for v6 SSH access? I just tried to do it,
and it doesn't seem to exist in 4.0.1b. I have the docco for version 4.1
here which says it's there, so I'm wondering if I've been unlucky enough
to be /just/ behind where it was introduced.

Weirdly our RXes which are running much older code (I know it's
different code, but we've had it for years now) are happy to restrict v6
SSH.

Cheers,

Dunc

On 17/01/11 21:02, Igor Ybema wrote:
> Hi,
>
> We at Oxilion, dutch based hosting provider, are running 4.0.0a for
> about 2 years now without any problems. Basic functions like OSPF,
> BGP, IPv4/IPv6 dualstack etc.
>
> No need to upgrade to 5.1 here yet.
>
> regards, Igor
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

- --
Duncan Lockwood
Principal Network Engineer

The Bunker Secure Hosting Limited
Ash Radar Station
Marshborough Road
Sandwich
Kent CT13 0PL
UNITED KINGDOM

t: 01304 814 800
f: 01304 814 899
e: dunc [at] thebunker
w: www.thebunker.net
PGP on Key Servers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk1B6/QACgkQOZKi9YO9TB7jzwCdH4cUpoFV2eYjqscwwUi+xQkS
1S4An2gwvYLQxuSf80AWhe23ujUt21O9
=G2uS
-----END PGP SIGNATURE-----
________________________________
This email and any attachments it may contain is confidential and solely intended for the use of the named addressee(s) only. Any views or opinions presented are solely those of the author and do not necessarily represent those of The Bunker. If you are not the intended recipient, be advised that you have received this email in error and that you should not rely on it or take any action based on it. You should not publish, use, disseminate, print, forward or copy this email as it is strictly prohibited. Please contact the sender if you have received this email in error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Vinny_Abello at dell

Feb 2, 2011, 8:40 AM

Post #16 of 19 (2326 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

I'm running 3.9.x currently on the XMR 4000's and filter SSH/telnet on IPv6 using ipv6 access-lists just fine. I'm applying it with "ipv6 access-class" in the global configuration.

-Vinny

-----Original Message-----
From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Dunc
Sent: Thursday, January 27, 2011 5:05 PM
To: foundry-nsp [at] puck
Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Igor,

Have you tried to do an ACL for v6 SSH access? I just tried to do it, and it doesn't seem to exist in 4.0.1b. I have the docco for version 4.1 here which says it's there, so I'm wondering if I've been unlucky enough to be /just/ behind where it was introduced.

Weirdly our RXes which are running much older code (I know it's different code, but we've had it for years now) are happy to restrict v6 SSH.

Cheers,

Dunc

On 17/01/11 21:02, Igor Ybema wrote:
> Hi,
>
> We at Oxilion, dutch based hosting provider, are running 4.0.0a for
> about 2 years now without any problems. Basic functions like OSPF,
> BGP, IPv4/IPv6 dualstack etc.
>
> No need to upgrade to 5.1 here yet.
>
> regards, Igor
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

- --
Duncan Lockwood
Principal Network Engineer

The Bunker Secure Hosting Limited
Ash Radar Station
Marshborough Road
Sandwich
Kent CT13 0PL
UNITED KINGDOM

t: 01304 814 800
f: 01304 814 899
e: dunc [at] thebunker
w: www.thebunker.net
PGP on Key Servers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk1B6/QACgkQOZKi9YO9TB7jzwCdH4cUpoFV2eYjqscwwUi+xQkS
1S4An2gwvYLQxuSf80AWhe23ujUt21O9
=G2uS
-----END PGP SIGNATURE-----
________________________________
This email and any attachments it may contain is confidential and solely intended for the use of the named addressee(s) only. Any views or opinions presented are solely those of the author and do not necessarily represent those of The Bunker. If you are not the intended recipient, be advised that you have received this email in error and that you should not rely on it or take any action based on it. You should not publish, use, disseminate, print, forward or copy this email as it is strictly prohibited. Please contact the sender if you have received this email in error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

dunc.lockwood at thebunker

Feb 3, 2011, 2:11 AM

Post #17 of 19 (2319 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oooh, I hadn't spotted that before. So does that filter traffic to the
control plane?

Cheers,

Dunc

On 02/02/11 16:40, Abello, Vinny wrote:
> I'm running 3.9.x currently on the XMR 4000's and filter SSH/telnet on IPv6 using ipv6 access-lists just fine. I'm applying it with "ipv6 access-class" in the global configuration.
>
> -Vinny
>
> -----Original Message-----
> From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Dunc
> Sent: Thursday, January 27, 2011 5:05 PM
> To: foundry-nsp [at] puck
> Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a
>
> Hi Igor,
>
> Have you tried to do an ACL for v6 SSH access? I just tried to do it, and it doesn't seem to exist in 4.0.1b. I have the docco for version 4.1 here which says it's there, so I'm wondering if I've been unlucky enough to be /just/ behind where it was introduced.
>
> Weirdly our RXes which are running much older code (I know it's different code, but we've had it for years now) are happy to restrict v6 SSH.
>
>
> Cheers,
>
> Dunc
>
>
> On 17/01/11 21:02, Igor Ybema wrote:
>> Hi,
>
>> We at Oxilion, dutch based hosting provider, are running 4.0.0a for
>> about 2 years now without any problems. Basic functions like OSPF,
>> BGP, IPv4/IPv6 dualstack etc.
>
>> No need to upgrade to 5.1 here yet.
>
>> regards, Igor
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp [at] puck
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
________________________________
This email and any attachments it may contain is confidential and
solely intended for the use of the named addressee(s) only. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of The Bunker. If you are not the intended recipient, be
advised that you have received this email in error and that you should
not rely on it or take any action based on it. You should not publish,
use, disseminate, print, forward or copy this email as it is strictly
prohibited. Please contact the sender if you have received this email in
error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

- --
Duncan Lockwood
Principal Network Engineer

The Bunker Secure Hosting Limited
Ash Radar Station
Marshborough Road
Sandwich
Kent CT13 0PL
UNITED KINGDOM

t: 01304 814 800
f: 01304 814 899
e: dunc [at] thebunker
w: www.thebunker.net
PGP on Key Servers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Kf0MACgkQOZKi9YO9TB7RtACfY3laYvlKgj/nig3ta/lLzEIW
rhUAnjqDdGZ2rkGsnCGJmc7Li4WDddvu
=+i8m
-----END PGP SIGNATURE-----
________________________________
This email and any attachments it may contain is confidential and solely intended for the use of the named addressee(s) only. Any views or opinions presented are solely those of the author and do not necessarily represent those of The Bunker. If you are not the intended recipient, be advised that you have received this email in error and that you should not rely on it or take any action based on it. You should not publish, use, disseminate, print, forward or copy this email as it is strictly prohibited. Please contact the sender if you have received this email in error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

dunc.lockwood at thebunker

Feb 3, 2011, 2:32 AM

Post #18 of 19 (2313 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah, the docs suggest that this only affects access on the management
port. I need to do this for all ports.

Vinny, can you confirm if this just works for the management port for
you or all interfaces?

Cheers,

Dunc

On 03/02/11 10:11, Dunc wrote:
> Oooh, I hadn't spotted that before. So does that filter traffic to the
> control plane?
>
>
> Cheers,
>
> Dunc
>
>
> On 02/02/11 16:40, Abello, Vinny wrote:
>> I'm running 3.9.x currently on the XMR 4000's and filter SSH/telnet on IPv6 using ipv6 access-lists just fine. I'm applying it with "ipv6 access-class" in the global configuration.
>
>> -Vinny
>
>> -----Original Message-----
>> From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Dunc
>> Sent: Thursday, January 27, 2011 5:05 PM
>> To: foundry-nsp [at] puck
>> Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a
>
>> Hi Igor,
>
>> Have you tried to do an ACL for v6 SSH access? I just tried to do it, and it doesn't seem to exist in 4.0.1b. I have the docco for version 4.1 here which says it's there, so I'm wondering if I've been unlucky enough to be /just/ behind where it was introduced.
>
>> Weirdly our RXes which are running much older code (I know it's different code, but we've had it for years now) are happy to restrict v6 SSH.
>
>
>> Cheers,
>
>> Dunc
>
>
>> On 17/01/11 21:02, Igor Ybema wrote:
>>> Hi,
>
>>> We at Oxilion, dutch based hosting provider, are running 4.0.0a for
>>> about 2 years now without any problems. Basic functions like OSPF,
>>> BGP, IPv4/IPv6 dualstack etc.
>
>>> No need to upgrade to 5.1 here yet.
>
>>> regards, Igor
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp [at] puck
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
> ________________________________
> This email and any attachments it may contain is confidential and
> solely intended for the use of the named addressee(s) only. Any views or
> opinions presented are solely those of the author and do not necessarily
> represent those of The Bunker. If you are not the intended recipient, be
> advised that you have received this email in error and that you should
> not rely on it or take any action based on it. You should not publish,
> use, disseminate, print, forward or copy this email as it is strictly
> prohibited. Please contact the sender if you have received this email in
> error and destroy it.
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
________________________________
This email and any attachments it may contain is confidential and
solely intended for the use of the named addressee(s) only. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of The Bunker. If you are not the intended recipient, be
advised that you have received this email in error and that you should
not rely on it or take any action based on it. You should not publish,
use, disseminate, print, forward or copy this email as it is strictly
prohibited. Please contact the sender if you have received this email in
error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

- --
Duncan Lockwood
Principal Network Engineer

The Bunker Secure Hosting Limited
Ash Radar Station
Marshborough Road
Sandwich
Kent CT13 0PL
UNITED KINGDOM

t: 01304 814 800
f: 01304 814 899
e: dunc [at] thebunker
w: www.thebunker.net
PGP on Key Servers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk1KhCUACgkQOZKi9YO9TB6zQgCfRdbroDae7AU/5smhZgr1Vnng
s8sAnjoJfMXeEudNvJbb08fA4ULT8J4T
=xu0W
-----END PGP SIGNATURE-----
________________________________
This email and any attachments it may contain is confidential and solely intended for the use of the named addressee(s) only. Any views or opinions presented are solely those of the author and do not necessarily represent those of The Bunker. If you are not the intended recipient, be advised that you have received this email in error and that you should not rely on it or take any action based on it. You should not publish, use, disseminate, print, forward or copy this email as it is strictly prohibited. Please contact the sender if you have received this email in error and destroy it.

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Vinny_Abello at dell

Feb 15, 2011, 8:28 PM

Post #19 of 19 (2265 views)
Permalink

Re: XMR Software Upgrade Path from 4.0.1a [In reply to]

Dunc,

This limits ipv6 telnet/ssh traffic to the device on any interface/ip address in my network.

-Vinny

On Feb 3, 2011, at 5:32 AM, Dunc wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ah, the docs suggest that this only affects access on the management
> port. I need to do this for all ports.
>
> Vinny, can you confirm if this just works for the management port for
> you or all interfaces?
>
>
> Cheers,
>
> Dunc
>
>
> On 03/02/11 10:11, Dunc wrote:
>> Oooh, I hadn't spotted that before. So does that filter traffic to the
>> control plane?
>>
>>
>> Cheers,
>>
>> Dunc
>>
>>
>> On 02/02/11 16:40, Abello, Vinny wrote:
>>> I'm running 3.9.x currently on the XMR 4000's and filter SSH/telnet on IPv6 using ipv6 access-lists just fine. I'm applying it with "ipv6 access-class" in the global configuration.
>>
>>> -Vinny
>>
>>> -----Original Message-----
>>> From: foundry-nsp-bounces [at] puck [mailto:foundry-nsp-bounces [at] puck] On Behalf Of Dunc
>>> Sent: Thursday, January 27, 2011 5:05 PM
>>> To: foundry-nsp [at] puck
>>> Subject: Re: [f-nsp] XMR Software Upgrade Path from 4.0.1a
>>
>>> Hi Igor,
>>
>>> Have you tried to do an ACL for v6 SSH access? I just tried to do it, and it doesn't seem to exist in 4.0.1b. I have the docco for version 4.1 here which says it's there, so I'm wondering if I've been unlucky enough to be /just/ behind where it was introduced.
>>
>>> Weirdly our RXes which are running much older code (I know it's different code, but we've had it for years now) are happy to restrict v6 SSH.
>>
>>
>>> Cheers,
>>
>>> Dunc
>>
>>
>>> On 17/01/11 21:02, Igor Ybema wrote:
>>>> Hi,
>>
>>>> We at Oxilion, dutch based hosting provider, are running 4.0.0a for
>>>> about 2 years now without any problems. Basic functions like OSPF,
>>>> BGP, IPv4/IPv6 dualstack etc.
>>
>>>> No need to upgrade to 5.1 here yet.
>>
>>>> regards, Igor
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp [at] puck
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>> ________________________________
>> This email and any attachments it may contain is confidential and
>> solely intended for the use of the named addressee(s) only. Any views or
>> opinions presented are solely those of the author and do not necessarily
>> represent those of The Bunker. If you are not the intended recipient, be
>> advised that you have received this email in error and that you should
>> not rely on it or take any action based on it. You should not publish,
>> use, disseminate, print, forward or copy this email as it is strictly
>> prohibited. Please contact the sender if you have received this email in
>> error and destroy it.
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp [at] puck
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
> ________________________________
> This email and any attachments it may contain is confidential and
> solely intended for the use of the named addressee(s) only. Any views or
> opinions presented are solely those of the author and do not necessarily
> represent those of The Bunker. If you are not the intended recipient, be
> advised that you have received this email in error and that you should
> not rely on it or take any action based on it. You should not publish,
> use, disseminate, print, forward or copy this email as it is strictly
> prohibited. Please contact the sender if you have received this email in
> error and destroy it.
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
> - --
> Duncan Lockwood
> Principal Network Engineer
>
> The Bunker Secure Hosting Limited
> Ash Radar Station
> Marshborough Road
> Sandwich
> Kent CT13 0PL
> UNITED KINGDOM
>
> t: 01304 814 800
> f: 01304 814 899
> e: dunc [at] thebunker
> w: www.thebunker.net
> PGP on Key Servers
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1KhCUACgkQOZKi9YO9TB6zQgCfRdbroDae7AU/5smhZgr1Vnng
> s8sAnjoJfMXeEudNvJbb08fA4ULT8J4T
> =xu0W
> -----END PGP SIGNATURE-----
> ________________________________
> This email and any attachments it may contain is confidential and solely intended for the use of the named addressee(s) only. Any views or opinions presented are solely those of the author and do not necessarily represent those of The Bunker. If you are not the intended recipient, be advised that you have received this email in error and that you should not rely on it or take any action based on it. You should not publish, use, disseminate, print, forward or copy this email as it is strictly prohibited. Please contact the sender if you have received this email in error and destroy it.
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp [at] puck
> http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads