[j-nsp] Code upgrade to 10.4R4.5
cra at WPI.EDU
Thu May 12 08:29:31 EDT 2011
On Thu, May 12, 2011 at 04:27:55AM -0400, Jeff Wheeler wrote:
> syntax changes to "preprovisioned" (no hyphen), yet this is not caught
> by "verify." The box will be unusable after it upgrades. EX boxes,
> and their spectacular upgrade failures, have justified my OOB
> facilities many times over in the past couple of years.
> Always have a "rain plan." OOB network, remote hands, let router be
> down until you can dispatch an employee, whatever.
I've traditionally been more fond of modular chassis-based switches
rather than stackable/virtual-chassis switches. A few years ago
before EX8200 existed we made the choice to go with EX4200
virtual-chassis, but some cons we thought of were related to the need
for lots of extra cabling and OOB resources:
1. 18 power cords vs. 4
2. 9 OOB console server ports vs. 2
3. 9 OOB ethernet ports vs. 2
The last two are particularly troubling, because if you don't have OOB
console access to every member of a virtual-chassis, it is impossible
to recover from a situation like above remotely. We've already
experienced this a couple times, once related to flash corruption on a
line-card member, and another time when a software issue crashed
line-cards with uplink-modules.
I hope vendors would consider these types of issues when designing
stackable-type switch architectures. It would be nice to have some
built-in way to aggregate/interconnect the console ports (in such a
way that didn't require the switch's software or flash disk to be
functioning correctly for the consoles to be accessable across the
"daisy chain" console connections.) It gets expensive providing
console server ports for every 48-port member switch. Maybe an RS-485
serial console bus would work?
More information about the juniper-nsp