Michael McNamara

technology, networking, virtualization and IP telephony

Juniper SRX JUNOS Software Upgrade 10.1R1.8

by

Juniper SRX650 ImageWe recently purchased two Juniper SRX 650s to replace our aging Nortel VPN Routers (formerly Contivity Extranet Switches). We finally have both gateways/routers/firewalls racked and connected to the network and we started working our way through the JUNOS configuration and command line interface. The SRX650 we received from our reseller came with 10.0R8 so we decided to upgrade them to 10.1R1.8 based on some feedback we had received from Juniper concerning the slow response from the Web GUI while evaluating the SRX platform a few months ago.

You can find the release notes for JUNOS 10.1 on the Juniper website.

We started by placing the software (junos-srxsme-10.1R1.8-domestic.tgz) on an internal web server (10.1.20.1).

The upgrade itself took at least 5 minutes and the reboot took at least another 5 minutes, you definitely need to be patient when upgrading the SRX. It took a really long time compared to anything else I’ve upgraded in the past.

root> request system software add http://10.1.20.1/junos-srxsme-10.1R1.8-domestic.tgz reboot
/var/tmp/incoming-package.1145                        1500 kB 1500 kBps
Package contains junos-10.1R1.8.tgz ; renaming ...
NOTICE: Validating configuration against junos-10.1R1.8.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
Formatting alternate root (/dev/ad0s2a)...
/dev/ad0s2a: 631.0MB (1292236 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 157.75MB, 10096 blks, 20224 inodes.
super-block backups (for fsck -b #) at:
32, 323104, 646176, 969248
** /dev/altroot
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 317928 free (24 frags, 39738 blocks, 0.0% fragmentation)
Checking compatibility with configuration
Initializing...
Verified manifest signed by PackageProduction_10_0_0
Verified junos-10.0R1.8-domestic signed by PackageProduction_10_0_0
Using junos-10.1R1.8-domestic from /altroot/cf/packages/install-tmp/junos-10.1R1.8-domestic
Copying package ...
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-10.1R1.8.tgz
veriexec: cannot update veriexec for /cf/var/validate/chroot/junos/etc/voip/musiconhold.conf: No such file or directory
Verified manifest signed by PackageProduction_10_1_0
Hardware Database regeneration succeeded
Validating against /config/juniper.conf.gz
cp: /cf/var/validate/chroot/var/etc/resolv.conf and /etc/resolv.conf are identical (not copied).
cp: /cf/var/validate/chroot/var/etc/hosts and /etc/hosts are identical (not copied).
Port based Network Access Control: rtslib: ERROR kernel does not support all messages: expected 95 got 94,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg gencfg: expected 104 got 103,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg gencfg-stats: expected 104 got 103,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg fc fabric: expected 97 got 84,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: ERROR kernel does not support all messages: expected 95 got 94,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg gencfg: expected 104 got 103,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg gencfg-stats: expected 104 got 103,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: WARNING version mismatch for msg fc fabric: expected 97 got 0,a reboot or software upgrade may be required
Port based Network Access Control:
Port based Network Access Control: rtslib: ERROR IDL IDR Decode Error -1(Garbled Message)
Link Layer Discovery Protocol: rtslib: ERROR kernel does not support all messages: expected 95 got 94,a reboot or software upgrade may be required
Link Layer Discovery Protocol:
Link Layer Discovery Protocol: rtslib: WARNING version mismatch for msg gencfg: expected 104 got 103,a reboot or software upgrade may be required
Link Layer Discovery Protocol:
Link Layer Discovery Protocol: rtslib: WARNING version mismatch for msg gencfg-stats: expected 104 got 103,a reboot or software upgrade may be required
Link Layer Discovery Protocol:
Link Layer Discovery Protocol: rtslib: WARNING version mismatch for msg fc fabric: expected 97 got 0,a reboot or software upgrade may be required
Link Layer Discovery Protocol:
mgd: commit complete
Validation succeeded
Installing package '/altroot/cf/packages/install-tmp/junos-10.1R1.8-domestic' ...
Verified junos-boot-srxsme-10.1R1.8.tgz signed by PackageProduction_10_1_0
Verified junos-srxsme-10.1R1.8-domestic signed by PackageProduction_10_1_0
Saving boot file package in /var/sw/pkg/junos-boot-srxsme-10.1R1.8.tgz
JUNOS 10.1R1.8 will become active at next reboot
Saving package file in /var/sw/pkg/junos-10.1R1.8 ...
cp: /altroot/cf/packages/install-tmp/junos-10.1R1.8-domestic is a directory (not copied).
Saving state for rollback ...
Rebooting ...
shutdown: [pid 1888]
Shutdown NOW!

*** FINAL System shutdown message from root@ ***
System going down IMMEDIATELY

I hope to post some additional information as we move forward with the Juniper SRX platform.

Cheers!

Ethernet Routing Switch 8600 Software Release v5.1.2.0

by

Update Friday April 16, 2010: The software is now available on the Nortel/Avaya support website. I’ve also posted a copy of the updated release notes, ERS8600_5_1_2_0_01.02_Release_Notes.pdf

Avaya has released v5.1.2.0 software for the Ethernet Routing Switch 8600. I know there were quite a few users waiting for this release. Please feel free to post back here to let us all know how your making out with 5.1.2.0 if you happen to deploy it.

You can find a copy of the release notes here but you’ll obviously need to visit the Avaya/Nortel site to download the software.

Here are some of the bullet points from the release notes;

Switch management

  • The SNMP trap for rcIpBgpPeerLastError will now be sent with a proper byte string length such that the last bye will no longer be lost. This could previously cause operational issues with some SNMP management stations. (Q02092718)
  • ERS 8600 will no longer observe system instability associated with configuration changes to switch parameters involving SNMP settings. (Q02094258)
  • Previously the ERS 8600 was applying a local Access Policy to IPv6 routed SSH packets. Now the system will route these packets and apply Access Policies to only local destination policy type (SSH, Telnet, HTTP) IPv6 packets. This will no longer cause inappropriate connection issues to remote hosts. (Q02070640-01)
  • ERS8600 has been modified to now allow proper communication with NetQOS Management Device. (Q02049612-01)

Platform

  • With both filtering and ingress mirroring enabled on the ERS8600, system instability could be seen under certain traffic conditions. This is now resolved. (Q02078239-01)
  • For non-routed VLANs, SLPP will now use a source MAC address equal to the Base Mac Address of the ERS8600 plus the ID of the VLAN. This will ensure that received SLPP packets are processed against the correct non-routed VLAN when a loop is present in the network and avoid erroneous warning messages. (Q02081719)
  • IP fix traffic from the switch to an external collector will no longer be sent with an improper QoS marking of QOS=7, but instead sent with QOS=0, now placing these packets into the proper default egress queue. Previously this traffic could potentially interfere with other system management traffic leading to the potential for system instability when IPFix was enabled. (Q02044640-01)
  • High CPU utilization on an I/O line card co-processor will no longer result in a loss of messaging synchronization with the SSF CPU, which previously could have led to system instability. (Q02085085)
  • ERS 8600 will no longer show instability in tLogger task while writing to the PCMCIA card with clilogging enabled. (Q02006689-01)
  • ERS 8600 R and RS module card ports will now initialize multicast and broadcast bandwidth limiting values properly when these features are enabled. (Q02074960)
  • ERS 8600 will now properly handle any broadcast destination MAC IPX packets of type RIP or SAP. Previously this could cause and issue for routing IPX for E/M modules (R/RS modules do not support IPX Routing). (Q01997486-04)
  • Packet throughput performance for jumbo frames at line rate has been improved for the 8612XLRS modules. (Q02075673)
  • Filter pattern definitions for HTTP packet streams will no longer impact other protocol traffic. (Q02089688)
  • Users will now be able to connect to an ERS 8600 using Secure Copy (SCP) with access-level rwa when access-strict true is also configured. Previously SSH worked, but SCP did not. (Q01767930-01)
  • ERS 8600 will no longer encounter link flapping upon reboot of an OM1400 edge device running SFFD when connected to 8630GBR ports. (02014236-01)
  • ERS8600 will now properly forward DHCP packets with the DHCP-relay agent configured as the VRRP virtual IP when the DHCP request has the broadcast flag set. Best practice recommendation still continues to be to configure the DHCP-relay agent IP address as the VLAN physical address and not the VRRP IP address. (Q02059607-01)
  • Reliability of R and RS series line card recovery after CPU resets (normally seen during switch software upgrades) has been improved due to enhancements in SSF CPU to I/O module co-processor message communication and synchronization. (Q02091485/ Q01997485)
  • ERS 8600 will no longer silently drop packets when the number of ACEs with debug count enabled is such that system resources are at their maximum, but instead the filters will now all function properly. (Q02045086)

RSTP/MSTP

  • Enhanced MSTP/RSTP logging information which was previously added in release 4.1.3.0 was not present in any 5.x code. This functionality has now been properly added. Q02053232)
  • The VLAN interface on an ERS8600 in RSTP/MSTP mode will no longer be brought up unless a port first becomes active in the VLAN. This matches the existing VLAN interface behavior in STP mode. (Q02083039)
  • Packet loss on an MLT with RSTP enabled will no longer been seen after a CPU reset/switchover with HA mode enabled or after a complete switch re-boot. (Q02003158-01)
  • ERS 8600 will properly retain the MLT path-cost configuration over reboots when configured for RSTP/MSTP mode. (Q02048253)
  • ERS8600 will now properly show the MSTP CIST port pathcost info when “show port info mstp” is executed. (Q02048252)

IP Unicast

  • The configured filter action is now properly observed for ACL’s configured to match UDP source and destination port ranges between 32752 and 32767. (Q02076252-01)

Static Routes

  • ERS 8600 will no longer encounter system (DRAM) memory exhaustion with DHCP-relay configured on a Layer 2 VLAN or at the port level for a non-brouter port. (Q02076879)

BGP

  • ERS 8600 will now properly learn the default routes from eBGP peers even after the failover or toggling of the physical port connection. (Q02094999)

IP Multicast

  • ERS 8600 will no longer observe periods of sustained high CPU utilization associated with the forwarding of multicast traffic. (Q02067852)
  • ERS 8600 will now properly recover its DVMRP status for an ATM interface when a Port/Fiber Fault occurs, and is then restored. (Q02041428)

MLT / SMLT

  • Connectivity to NLB servers single homed to one ERS8600 in an IST pair will now function properly for SMLT connected devices when using an nlb-mode of unicast or with arp multicast-mac-flooding enabled. Configurations using nlb-mode of multicast were not affected. (Q02037778-01)
  • SLPP will now disable the correct SMLT port when a loop is detected on an SMLT link where the smlt-id configured is not the same as the mlt-id value configured. (Q02089994)
  • On ERS8600, FDB and ARP entries will point correctly to SMLT after IST peer reboots. Previously entries learnt on SMLT ports could very occasionally point incorrectly to the IST. (Q02091486)

RSMLT

  • With ICMP redirect enabled on RSMLT peer switches, packets destined to the RSMLT-peer’s MAC address will now be forwarded correctly and not dropped as ICMP-redirect packets. (Q02091034)
  • In RSMLT environments, ERS8600 will no longer add the RSMLT-peer’s MAC address to its Router MAC table. This will result in packets destined to the IP interface of RSMLT-peer to forward properly. (Q02091350)

VLACP

  • ERS 8600 will now always bring down a port via VLACP within the configured timeout value when its VLACP peer goes down. Previously one end of the link would take an extra timeout cycle before downing the port in some scenarios. (Q02088710)
  • In scenarios where a port was taken down by VLACP and then the far end switch is rebooted or VLACP recovered to recover the port, Persistent VLACP port flapping will no longer occur. (Q02088709)
  • On E-mode enabled switches in full mesh SMLT topologies, protocol traffic will now flow properly on the second MLT link when the first MLT link is disabled. (Q02089615)

VRRP

  • Disabling and re-enabling the IST session on an IST switch pair with VRRP configured between them will no longer result in both switches reporting VRRP mastership. (Q02104773)

Cheers!

Avaya and Nortel: is the honeymoon over?

by

Last week I spent a day up in Basking Ridge, NJ at the Avaya’s global headquarters. The purpose of the visit was to delve deeper into the product roadmap (details man, details!) and talk about the recently announced PASS program that Avaya and it’s voice resellers are implementing on July 1, 2010 regarding voice maintenance and support contracts.

While the discussions were covered by a non-disclosure agreement there wasn’t a lot of information that hasn’t already been disclosed in either the product roadmap presentations or other material released by Avaya. With that said there were some technical details on how Avaya plans to integrate the CS1000 with their Aura platform. Unfortunately I can’t really go into the details… especially since a few of the Avaya presenters actually mentioned this blog in my discussions with them. I’m not sure if that’s a good thing or not? I guess so far so good, and I haven’t yet received any DMCA take down notices.

In any case I thought I would give my opinion on the current state of the Avaya/Nortel marriage. In general I try to avoid posting articles based solely on opinion. I’m much more comfortable basing my discussions on facts and theories that can be proven or dis-proven rather than just subjecture and assumptions. It’s almost expected that in any large acquisition there are bound to be bumps in the road… to date I haven’t seen any as a former Nortel customer. There haven’t been any product supply or support issues and the pricing and discount models  (post Avaya) have remained virtually unchanged. In fact last week we just stood up another CS1000E with 500+ IP phones and 36 Ethernet Routing Switch 5520s with a single Ethernet Routing Switch 8600 at the core at a newly constructed corporate office. So it would appear that it’s definitely business as usual when working with Avaya to procure Nortel hardware and support. Unfortunately not everything has been all roses. I learned last week that Avaya had it’s first round of employee cuts where it eliminated some redundant positions that came about through the Nortel acquisition.

In my opinion it’s seems that Avaya is on the right course and is dedicated to retaining the existing Nortel user base and even growing that user base. The next critical step is in the actual integration of the different product offerings… how will a Nortel CS1000 communicate with the Avaya Aura platform and how will Avaya leverage the existing Nortel investment? Having sat through those presentations last week I’m fairly confident that Avaya won’t let their Nortel customers down.

Let me know what you think?

Has the transition been seamless for you and your organization?

Are you on board with the Nortel/Avaya product roadmap or have you already decided to jump ship? (I think I see a good poll question in that last one)

Cheers!

Nortel ERS 5500 Software 6.0.5 Available

by

Nortel has released software 6.0.5 for the Nortel Ethernet Routing Switch 5000 series switches.

Here’s the list of added features;

  • Total system uptime in days since first power up
  • Support for DDI SFPs
  • Improved 802.1AB detection to work with Avaya Ip Handsets (Q02109202)
  • Shared port enhancement

Here’s the list of bug fixes;

  • Radius Accounting Configuration is not saved after upgrade (Q01995703).
  • ERS55xx/6.0.3-keeps sending re-authentication when radius VLAN Assignment NEAP (Q01994731)
  • Static routes getting disabled, after link to next hop is broken (Q02002640)
  • 8 sec impact on traffic through base unit when non-base is reset (Q01997338) –
  • SLPP packets loop over 55xx MLT ports during VLACP link flap on the BS (Q01926412-01)
  • Port Names Are Missing When Upgrading From 6.0.1.0 to 6.0.3.0 (Q02019044)
  • Auth Status not properly returned in JDM/SNMP for Port Security (Q02011169-01)
  • Running Security scans by using Qualys tools caused switch crashes (Q02004709-01)
  • RSTP MLT ports seen as forwarding but actually blocking (Q02011420-01)
  • Data Exception type: Data Access Task Name “tIdt” (Q02024889)
  • EAPoL is properly functional only when Radius server is reachable with ICMP (Q02025072)
  • The switch is not relaying DHCP larger than 590 byte (Q02042427-03)
  • Some Layer-2 packets are not properly forwarded (Q02032738-01)
  • Intermittent traffic loss over DMLT connections to 8600 (Q02045069-02)
  • IfAdminStatus and IfOperStatus Show Interface As Being Down (Q02073525)
  • 5520 6.0.2 Transmit BPDUs After STP Is Disabled Causing MLT Port Blocking (Q02082301)
  • VLAN creation causes switch to wedge (repeatable) (Q02039074)
  • Filter on Multicast Traffic drops OSPF control traffic (Q02103672)
  • Switch Locks Up When OSPF Interface Is Brought Up (Q02075419-01)
  • Certain DHCP clients don’t have an entry in the binding table (Q02084318-01)
  • Switch failed to respond to DoS attack (Q02009674-01)
  • Re-booting edge switch triggers SLPP loop on core switch uplink port (Q02045991)

I believe the issue below was reported by a few readers and perhaps even in the discussion forums. In any case the release notes offer two workarounds and suggest the problem is not evident in 6.1.2 software.

With SMLT configured, the default route was learned on an incorrect port after core stack reboot (Q02123318)
Is issue is only partially fixed in 6.0.5, not reproducible with 6.1.2. There are two workarounds:
– clear the arp-cache
– Configure VLACP on the IST ports.

As always I would strongly suggest you review the release notes for yourself.

Cheers!

Ethernet Routing Switch 5500 NVRAM Flash memory wear

by

Avaya/Nortel has released a technical support bulletin documenting an issue that may arise regarding the NVRAM (flash memory) on the Ethernet Routing Switch 5500.

Apparently the auto-save feature may be exhausting the number of writes that the physical flash memory is capable of. If the switch is configured with MAC address security, a feature that could possibility be causing the auto-save feature to write the configuration hundreds if not thousands of times, the flash memory may surfer from extreme “memory wear” and cease functioning properly.

Thankfully there is a “second” NVRAM flash block available.

I would highly suggest that everyone review the bulletin for themselves.

It might be wise to disable the auto-save feature and have the technicians/engineers manually save any configuration changes when necessary (similar to how Cisco switches/routers work).

Cheers!

Recent Posts

Categories

SUBSCRIBE BY EMAIL