<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div><br></div><div><br><div><div>On Jul 29, 2013, at 1:25 PM, Josh Galvez <<a href="mailto:josh@zevlag.com">josh@zevlag.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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.<div>
<br></div><div>Has anyone had any problems or concerns doing this?</div><div><br></div><div>-Josh</div></div>
_______________________________________________<br>foundry-nsp mailing list<br><a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>http://puck.nether.net/mailman/listinfo/foundry-nsp</blockquote></div><br></div></body></html>