Aspect is hosting a webinar on Tuesday, March 9th at 11:00AM EST / 8:00AM PST hoping to discuss with current and future potential customers how the integration of the Nortel and Avaya product lines might affect them.

Aspect is a well known provider of large contact center solutions. I hope to personally listen in and see what Aspect has to say. I’d be curious if/how Aspect will also be pushing their Unified Communications solutions.

Cheers!

• Windows 7: Home Basic, Home Premium, Professional, Enterprise and Ultimate
• Vista: Home Basic, Home Premium, Business, Enterprise, and Ultimate
• XP: Home, Professional, and Tablet

There are quite a few resolved bugs in this release and quite a few known issues. I would advise everyone to read the release notes thoroughly before spending too much time troubleshooting.

You can find the actual NVC (Nortel VPN Client) on the Nortel/Avaya website and the release notes here.

Cheers!

• 0621C7D for 2007 IP Deskphone,
• 0623C7J, 0624C7J, 0625C7J, 0627C7J and 0626C7J for 1110, 1120E, 1140E, 1150E and 1165E IP Deskphones respectively and
• 062AC7J for 1200 Series IP Deskphones

UNIStim 4.1 adds the following features;

• UNIStim 4.0 functionality delivered onto the 1165E IP Deskphone
• Quality improvements to Secure Signaling using DTLS
• Adjustable open-microphone warning tone during Zone Paging
• UNIStim VPN client interoperability extended to include Avaya VPN Gateways

The two product bulletins covering the software release can be found here and here.

Notice any formatting differences between the two bulletins?

Cheers!

In any event if you are ordering/deploying any new AP5131 or AP300s you’ll need to be mindful of this change and ensure that you are running the appropriate software releases and/or you have applied the specific patches.

You can find the release notes concerning the AP5131 right here.

You can find the release notes concerning the AP300 right here.

Cheers!

It seems that Nortel/Avaya are starting to get their ducks in a row as a draft version of the release notes hit Nortel’s support website over the past few days.

Here’s one known issue that grabbed my eye while browsing the release notes;

MLT/SMLT limitation(s)

Q01971344
In the case of a full-mesh SMLT configuration between 2 Clusters running OSPF (more likely an RSMLT configuration) because of the way that MLTs work in regards to CP generated traffic, it is highly recommended that the MLT port (or ports) that form the square leg of the mesh (versus the cross connect) be placed on lowered number slot/port, than the cross  connections. The reason for this is because CP generated traffic is always sent out on the lowered numbered ports en active. Using this recommendation will keep some OSPF adjancey up if all the links of the IST fail. Otherwise the switches which have a failed IST could lose complete OSPF adjancey to both switches in the other Cluster and therefore become isolated.

Cheers!

In case you haven’t heard the Avaya Integrated Avaya-Nortel Roadmap in Philadelphia has been canceled yet again due to the impending snow storm.

The event has been rescheduled for Tuesday, March 9th.

Who wants to bet that we’ll have yet another snow storm, blizzard even, on March 9th?

Cheers!

You might recall that I wrote about software release 6.5R2 back in December 2009, detailing our troubles with the 6.5R1 software release and our hope that Juniper could save the day.

Thankfully I’m hear to tell that software release 6.5R2 for the Juniper Secure Access SSL VPN appliances appears to be a winner!

About six days ago I upgraded a pair of SA4000s running 6.5R1 to 6.5R2. The primary goal was to resolve the compatibility issues that were introduced in 6.5R1 and finally provide support for both Windows Vista 64-bit and Windows 7 64-bit. The actually upgrade of the appliances was pretty straight forward and the initial testing didn’t reveal any issues. Unfortunately there’s no amount of testing can always predict how things will go when working with home personal computers and the myriad of software available. We waited nervously for the first few days… thankfully the calls never came. While we had one or two users that needed some hand holding during the software upgrade/installation process, the majority of our 800+ users didn’t seem to have any issues whatsoever.

Let me congratulate Juniper Networks on a job well done!

I’ve created discussion forum for anyone that would like to discuss the Juniper Secure Access SSL VPN appliances. If you have a question or would like to make a comment why not join the discussion?

Cheers!

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!

The event has been rescheduled for Thursday, February 25th.

Cheers!

Let me focus the attention on the three recent vulnerabilities in Internet Explorer, Adobe Reader, Adobe Flash and Adobe AIR;

Microsoft Internet Explorer Vulnerability MS10-002 (Cyber Security Alert SA10-021A)

Adobe Reader and Acrobat Vulnerability APSB10-02 (Cyber Security Alert SA10-013A)

Adobe Flash Player and Adobe AIR APSB09-19 (Cyber Security Alert SA09-343A)

Any of these vulnerabilities can be remotely exploited when the user visits a poisoned web site/page or by opening a poisoned Adobe PDF document. Once the vulnerability is exploited additional software is usually installed on the personal computer which can disable antivirus solutions and begin harvesting user names and passwords including banking information.

What should I do?

You need to make sure that you have the latest and greatest software and security patches applied to your personal computer. You should make sure that you have turned on Microsoft Windows Update; this will update Internet Explorer automatically. You can also confirm that Internet Explorer is up-to-date by manually visiting the Microsoft Windows Update website. You should also update/install the latest and greatest versions of Adobe AIR 1.5.3, Adobe Reader 9.3 and Adobe Flash 10.0.42.34.

If you haven’t already updated your home (or work) computers recently you might want to invest some time in the task. It might save you from a lot of problems and headaches later down the road.

Cheers!

References;

SANS Top Cyber Security Risks
Symantec Internet Security Threat Report 2008
What To Expect In Security In 2010