08-23-2010 10:56 AM
As data centers are consolidated and new applications are added, the scale of the data center is growing. What are your plans to reduce complexity within the data center and still support this expanding scale?
08-23-2010 02:03 PM
The pressure is for ever higher speed, and greater fault tolerance. Fault tolerance makes everything more complicated... Redundant data centers, redundant core switches, redundant trunks, etc. We are still trying to figure out how to "Sniff" a 10Gb pipe for troubleshooting. And don't get me started with blade centers. When will Juniper ship some decent switches to go in the back of IBM or HP blade centers. The Alteon switches IBM uses are abysmal. Poor trunking, poor layer3, etc.
Thank God our server folks are happy with Fiber Channel. I shutter to think of the complexity of FCoE and loss-less ethernet.
Then we have VMWare, and the mystery of which blade and switch a given VM server is running on. Or how bout the network, where a small BGP change could cause a data center outage.
We would very much like the Inservice Software Upgrade and enhanced GRES features so that our core switches could be upgraded without a data center shutdown (On the EX8200s, not the MX)
An automated upgrade facility for the EX4200s would be nice as well. And snapshot, though I think this is running in the newer JUNOS versions.
08-23-2010 03:02 PM
These are really great suggestions! We will definitely give a serious consideration in supporting these high availability features on EX platforms.
BTW, another feature called Automatic software download enables network administrators to easily upgrade the EX switches using the DHCP message exchange process to download and install software packages. Users simply configure the automatic software download feature on switches acting as DHCP clients and establish a path to the server where the software package file is installed. The server then communicates the path to the software package file through DHCP server messages.
When the automatic software download feature is enabled, the DHCP client (the switch) compares the software package name in the DHCP server message to the name of the software package that booted the switch. If the names are different, the EX switch downloads and installs the software package specified in the DHCP server message.
Find more information on this feature at http://www.juniper.net/techpubs/en_US/junos10.3/to
08-23-2010 04:00 PM
I've done similar using DHCP Options 66 and 67. On other devices, option 67 points to the config file instead of the OS file. Is there a way to DHCP the config file?
Using DHCP to upgrade the OS is a little scarey. Procurves do something called Auto-tftp. It's a config file setting (auto-tftp 10.150.175.2 "Q_11_xx.swi"). When the switch boots, it checks the tftp server for the firmware designated in the command. It begins downloading, and checks the header info of the file for version. If the version is the same or older, it abandons the download and continues booting. If the version is newer, it downloads the code, then reboots onto the new code. These switches have a primary and secondary boot location, so if the new code does not boot it will boot on the secondary code.
The docs for your implemenation says that it will discover the new version, download it, and reboot "at any time as part of the DHCP message exchange process". Yikes.
I think I would rather do a manual download of the new code, then schedule a reboot for off hours.
Also, talking about DHCP options. Do you support Option 82? This is pretty handy since the device hooked to the same port will get the same IP and same config without needing to update the MAC address in the DHCP server. Great for doing a switch RMA replacement. Again, assuming the DHCP can download the device config.
As we all know, all bets are off when the connection upstream to the DHCP is VLAN tagged/trunked when trying to do an RMA.
Another option is to allow the switch to boot on a USB flash if one is available. In this scenario, the config is saved onto the flash routinely. To replace/RMA a switch, you boot the new switch with the USB flash drive from the old switch installed, and the boot process uses the flash config to boot the switch. Hirschmann industrial ethernet devices work like that (and do the DHCP 66/67/82 options).
08-23-2010 04:05 PM - edited 08-23-2010 04:10 PM
(Sorry, misread the question...the below is for DHCP options to upstream clients, not for the EX Switch itself...let me check on that)
Yes, option 82 has been supported since JUNOS 9.3. Here is the output of the DHCP option configuration section in the CLI. You can configure options 1 through 255 and specific many possible catagories for each option.
[edit system services dhcp]
admin@ex-switch# set option ?
<option-identifier-code> DHCP option identifier code (1..255)
[edit system services dhcp]
admin@ex-switch# set option 82 ?
<[Enter]> Execute this command
> array Array of values
byte Unsigned 8-bit value
byte-stream Stream of unsigned 8-bit values within quotes
flag Boolean flag value
integer Signed 32-bit numeric value
ip-address IP address value
short Signed 16-bit numeric value
string Character string value
unsigned-integer Unsigned 32-bit numeric value
unsigned-short Unsigned 16-bit numeric value
| Pipe through a command
08-23-2010 04:09 PM
EX 3200/4200 switches (I've not personally checked other models) allow the entire device to be operated from a USB key installed in the external USB slot. Additionally the internal flash can be snapshot to an external USB flash device as a backup measure.
For example I have a customer running all their EX Switches from External USB flash drives.....they have some backup/spare EX4200's in storage pre-configured to operate from the USB slot. So during a failure event they take one of the shelf, move the USB over an power it on. This is great for installations where you don't have experienced network engineers
08-24-2010 02:33 AM
We are desperate for the promised holy grail: ISSU.
As long as we don't have that, we need to have extra hardware to not have to put the DC down for maintenance.
Beside from the extra hardware we cannot make L2 failover between two EX4200 VC's, and the EX8200 VC is ... well... not very elegant to put it euphemistically.
ISSU! ISSU! ISSU! ;-)