[prev in list] [next in list] [prev in thread] [next in thread] 

List:       foundry-nsp
Subject:    Re: [f-nsp] Loading code on XMR before reload
From:       Jethro R Binks <jethro.binks () strath ! ac ! uk>
Date:       2013-07-31 8:55:42
Message-ID: alpine.BSF.2.02.1307310950350.14248 () qrswnz ! pp ! fgengu ! np ! hx
[Download RAW message or body]

I've also seen issues where simply uploading the software causes 
connectivity issues.

The XMR platform, to my mind, seems particularly prone to CPU congestion.  
I've dealt with issues relating to SSH, SNMP and multicast all causing CPU 
exhaustion, with the result that MRPs and OSPF peerings suffer instability  
as a result (some discussed previously on the list).

Some of these issues have been addressed over the last couple of years in 
software, but mcast still causes me problems with cpu spikes and MRP/OSPF 
flaps -- unfortunately that's partly my own fault by passing through too 
many L2 wireless vlans with very chatty mobile devices (UPnP et al) 
(medium-term plan to migrate those away).  There was a recent short thread 
about this, which I wasn't able to contribute much to beyond saying "me 
too".

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.



On Tue, 30 Jul 2013, Brad Fleming wrote:

> I did this exact process late last week on our 14 XMRs. We moved from 
> 5.1.00b to 5.4.00d. I've uploaded new code a few hours early on our 
> previous 5-6 software updates and never had an issue. This time I made 
> it through the first two nodes with no problems by on the 3rd the node 
> became unresponsive and stopped forwarding traffic when uploading the LP 
> Boot image. After that we waited to upload any more software until the 
> actual maintenance window. In the end, 11 of the 14 nodes experienced 
> some kind of data, control, and/or management plane forwarding problem 
> while uploading software. In our case all but one of those problems were 
> observed while uploading the LP Boot image specifically; FPGAs gave us 
> no issues. It's very strange. We tested the upgrade process for nearly 3 
> weeks with 5.4.00c and 5.4.00d using two spare XMR nodes with JDSU test 
> sets connected and never saw any problems.
> 
> 
> 
> On Jul 29, 2013, at 1:25 PM, Josh Galvez <josh@zevlag.com> wrote:
> 
> > I'm upgrading from 5.1 to 5.4 and I would like to perform the upgrade procedure \
> > and load the code on my XMR's several hours or even a day or two before I \
> > actually perform the reload to start running this new code.  That way instead of \
> > the 20 minute long TFTP process at midnight, I have just the 2 minute reload. 
> > Has anyone had any problems or concerns doing this?
> > 
> > -Josh
> > _______________________________________________
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]