Michael McNamara

I recently started having a problem launching Nortel’s Java Device Manager on my Windows XP desktop. Upon launching the application nothing would appear on my desktop but I could see the “java.exe” process in Task Manager.

I tried uninstalling the application but the uninstall appeared to hang toward the end as it was cleaning out the registry, I eventually had to kill the uninstall process. I even tried installing the latest and greatest version only to be denied at every turn. Then I recalled that the application liked to keep a list of recently accessed switches and settings somewhere on the hard disk.

I found the location under “C:\Documents and Settings\<USER_ID>\jdm” although be warned that the folder is hidden so you’ll need to make sure that you can see hidden files (Tools -> Folder Options -> View -> Show hidden files and folders). I deleted the folder and bang I was back in business again.

I was fearing the dreaded Windows re-install, thank god I didn’t have to go through that!

Cheers!

I thought I would take a break from my usual material and post something a little different. Please forgive me as this article bares little technical value but I just felt like posting anyway. Like every company out there we’ve been involved in evaluating the dizzying array of Thin Client and Virtual Desktop solutions on the market today.

I recently had the opportunity to evaluate the Sun Ray 270 Virtual Display Client solution from Sun Microsystems. It’s a really clean all in one solution that features a 17″ display with an integrated Smart Card reader. The solution required the use of a Sun Solaris x86 server to act as the middleware between either a Microsoft Terminal Server or Citrix Metaframe Server. Users sessions were initiated by the insertion of a Smart Card and the solution excelled at hotdesking, allowing a user to remove their Smart Card and go to another Sun Ray and pickup exactly where they left off from the previous session by simply inserting their Smart Card and entering their password (if it was configured to prompt for a password).

The Sun Ray client located the Sun Solaris servers within the same local network by use of a broadcast packet. When the Sun Ray client was outside the local network we had to configure special DHCP options which enabled the Sun Ray to “locate” to the back-end Sun Solaris servers.

We did have some interoperability issues with Windows 2008 Terminal Services Session Broker that Sun hopes to have resolved sometime in the coming year.

The only real feature the device was missing was an integrated 802.11 wireless solution. The reseller did point out that the Sun Ray can be paired with a few 802.11 bridges to provide wireless connectivity.

While we didn’t actually select the Sun Ray for the project we were evaluating I was really impressed with the solution and would advise anyone looking at thin client solutions to give their nearest Sun reseller a call. If your interested in hotdesking and/or Smart Card support in a thin client then you should definitely check out this solution.

Cheers!

With the recent surge in gas prices many employers and employees have taken to telecommuting. The surge has given rise to an avalanche of trouble tickets and support calls from folks trying to use their employers virtual private network solution from their home personal computers and broadband connections.

One typical problem that some users might encounter when using the Nortel VPN client is the “Checking for banner text” message. During the initial stage of connecting the Nortel VPN client will display the “Checking for banner text” message and then either become unresponsive or report to the user that the connection was lost.

Let me paraphrase from the Nortel documentation:

A common reason for the banner message to stop responding is a firewall or router, placed somewhere along the path from the remote computer to the gateway, which blocks ESP or Authentication Header (AH) traffic. The firewall can be a personal firewall installed on the remote computer, a firewall or router at the Internet Service Provider (ISP), or a corporate firewall. In this situation, IPsec Internet Security and Key Management Protocol (ISAKMP) traffic that negotiates the tunnel establishment goes through the tunnel, but the ESP- or AH-encapsulated traffic inside the tunnel does not get through. When the banner text is retrieved through the established tunnel, the banner message or other traffic secured by the ESP or AH never reaches the client and the Nortel VPN Client continues to wait for a response from the gateway until a timeout period is reached. To resolve this issue, ensure the following traffic is allowed to pass through the firewalls along the path:

UDP protocol (17) port 500, both inbound and outbound
ESP protocol (50), both inbound and outbound
AH protocol (51), both inbound and outbound

The same scenario occurs as in the previous section if Network Address Translation Transversal (NAT-T) is configured and the firewall blocks the UDP port selected for NAT-T along the path. To resolve this issue, you’ll need to ensure the port that is being utilized can pass through the firewalls on a personal, corporate, or ISP level. You’ll need to contact whomever is managing the VPN router to determine which UDP port you might need to open.

Cheers!

I wrote a Perl script a long time ago to backup the binary configuration files for all our Nortel Ethernet and Ethernet Routing Switches (including BayStack 350 and 450s, Ethernet Switch 460 and 470s, Ethernet Routing Switch 4500s and Ethernet Routing Switch 5500s, Ethernet Routing Switch 1600 and 8600s along with Motoroal WS5100 and RFS7000s and HP GbE2s). The Perl script was very simple and straightforward. The problem was that the Nortel configuraiton files were binary files that we as engineers were unable to review or analyze. There were no tools (at least not that I’m aware of) that could allow us to review those configurations. If we had a question about the configuration stored in the binary file we had to restore the configuration to a mock up switch(s) in our testlab in order to be able to review the actually configuration. It seems that Nortel finally heard our cries for help and added a new feature in v3.7.x (ES460/ES470) and v5.1.x (ERS5500) software that would allow us to TFTP upload the ASCII configuration from the ACG.

There was one problem though… the SNMP OID has yet to be documented in the Nortel SNMP MIBS. I had to run a packet trace against Nortel’s Device Manager to determine the OID that Device Manager was using to initiate the manual config upload. I found that the OID was ”
1.3.6.1.4.1.45.1.6.4.4.19.0″

I took my existing script and created a new subroutine and had everything working within about 30 minutes.

Here’s some of the code I wrote;

############################################################################
# Subroutine baystack_tftp_config_ascii
#
# Purpose: use SNMP to instruct BayStack switches to TFTP upload their
# ASCII configuration file to the central TFTP server
############################################################################
sub baystack_tftp_config_ascii {

#s5AgSysTftpServerAddress
#s5AgSysAsciiConfigFilename
#s5AgSysAsciiConfigManualUpload (NOT IN THE MIBS) USE 1.3.6.1.4.1.45.1.6.4.4.19.0
# snmpset -v2c -cprivate 10.1.1.100 1.3.6.1.4.1.45.1.6.4.4.19.0 i 4

   # Declare Local Variables
   my $setresult;

   $filename = "ascii/".$filename;

   my $sess = new SNMP::Session (  DestHost  => $snmphost,
                                   Community => $community,
                                   Version   => SNMPVER );

   my $vars = new SNMP::VarList(
                        ['s5AgSysTftpServerAddress', 0, "10.1.1.20",],
                        ['s5AgSysAsciiConfigFilename', 0, $filename,] );

   my $go = new SNMP::VarList(
                        ['.1.3.6.1.4.1.45.1.6.4.4.19', 0, 4, 'INTEGER'] );

   &check_filename($filename);

   # Set TFTP source and destination strings
   $setresult = $sess->set($vars);
   if ( $sess->{ErrorStr} ) {
      print "ERROR: {BayStack} problem setting the TFTP parameters (TFTP IP, FILENAME) for $snmphost\n";
      print "ERROR: {BayStack} sess->{ErrorStr} = $sess->{ErrorStr}\n";
   }

   # Start TFTP copy
   $setresult = $sess->set($go);
   if ( $sess->{ErrorStr} ) {
      print "ERROR: {BayStack} problem setting the TFTP action bit for $snmphost\n";
      print "ERROR: {BayStack} sess->{ErrorStr} = $sess->{ErrorStr}\n";
   }

   # Pause while the TFTP copy completes
   sleep $PAUSE;

   # Check to see if the TFTP copy completed
   $setresult = $sess->get('.1.3.6.1.4.1.45.1.6.4.4.19.0');
   if ( $sess->{ErrorStr} ) {
      print "ERROR: problem checking the TFTP result for $snmphost\n";
      print "ERROR: sess->{ErrorStr} = $sess->{ErrorStr}\n";
   }

   # If TFTP failed output error message
   if ($setresult != 1) {
        while ($setresult == 2) {
           print "DEBUG: config upload status = $setresult (waiting)\n" if (DEBUG);
           sleep $PAUSE;
           $setresult = $sess->get('.1.3.6.1.4.1.45.1.6.4.4.19.0');
        } #end while
   } #end if $test ne "success"

   # If the upload command failed let's try again
   if ($setresult == 3) {

      print "DEBUG: initial command returned $setresult\n" if (DEBUG);
      print "DEBUG: lets try the upload command again\n" if (DEBUG);

      # Let's pause here for a few seconds since the previous command failed
      sleep $PAUSE;

      # Start TFTP copy
      $setresult = $sess->set($go);
      if ( $sess->{ErrorStr} ) {
         print "ERROR: problem setting the TFTP action bit for $snmphost\n";
         print "ERROR: sess->{ErrorStr} = $sess->{ErrorStr}\n";
      }

      # Pause while the TFTP copy completes
      sleep $PAUSE;

      # Check to see if the TFTP copy completed
      $setresult = $sess->get('.1.3.6.1.4.1.45.1.6.4.4.19.0');
         if ( $sess->{ErrorStr} ) {
            print "ERROR: problem checking the TFTP result for $snmphost\n";
            print "ERROR: sess->{ErrorStr} = $sess->{ErrorStr}\n";
      }

      # If TFTP failed output error message
      if ($setresult != 1) {
         while ($setresult == 2) {
            print "DEBUG: config upload status = $setresult (waiting)\n" if (DEBUG);
            sleep $PAUSE;
            $setresult = $sess->get('.1.3.6.1.4.1.45.1.6.4.4.19.0');
         } #end while
      } #end if
   } #end if

   if ($setresult != 1) {
      print "DEBUG: $snmphost config upload *FAILED*!\n";
      print SENDMAIL "ERROR:$snmphost ($sysObjectID) config (ASCII) upload *FAILED*!
\n";
   } elsif ($setresult == 1) {
      print SENDMAIL "$snmphost ($sysObjectID) was successful (ASCII)
\n";
      print "DEBUG: $snmphost ($sysObjectID) was successful (ASCII)\n";
   } else {
      print "DEBUG: unknown error return = $setresult (ASCII)" if (DEBUG);
   } #end if

   print "DEBUG: upload config file results = $setresult (ASCII)\n" if (DEBUG);

   return 1;

} #end sub baystack_tftp_config_ascii

Cheers!

We just recently started replacing our legacy Motorola (formerly Symbol) WS5000/WS5100 Wireless LAN Switches with the Motorola RFS 7000 Wireless LAN Switch. I know quite a few organizations have jumped from Motorola over the past few years to Cisco, Aruba, Trapeze and Meru. While Motorola isn’t the easiest company to work with (who is these days) they really understand wireless and they have come through on a number of occasions involving highly technical problems. In short the product works and works well for our needs and fits in our budget. While Motorola may lack some of the bells and whistles of the other vendors mentioned above it’s stability is something we’ve come to enjoy.

The RFS7000 provides 4 10/100/1000 Cu/SFP Ethernet interfaces and can manage up to 256 802.11a/b/g Access Ports. We’ve long struggled managing some of our largest wireless environments where we needed 18 WS5000 switches (each WS5000 would only manage up to 48 802.11a/b/g Access Ports).The old WS5000 also required a one-to-one cold standby for redundancy and high-availability. The RFS7000 supports clustering and N+1 redundancy so we’re going to be using a lot less power and rack space not to mention all the configuration and cabling.

You can find the technical specifications for the RFS7000 here. And you can find the entire Motorola Wireless LAN portfolio here.

Let me provide a small example configuration. You’ll need to connect to the console interface (19200,8,N,1) and configure the Gigabit Ethernet interfaces. The default username is “admin” while the default password is “superuser”.

RFS7000 release 1.2.0.0-040R
Login as 'cli' to access CLI.
sw-wireless.mdc.mlhs.org login: cli

User Access Verification

Username: admin
Password:
Welcome to CLI
RFS7000>enable
RFS7000#config term
Enter configuration commands, one per line.  End with CNTL/Z.

We’ll be using the interface ‘ge1′ as the Layer 2 (AP VLAN) interface and ‘ge2′ will be our Layer 3 interface. We’ll trunk ge2 and leave ge1 as access. We’ll also use VLANS 29-32 in order to bridge our WLANs to our Nortel Ethernet Routing Switch 8600 core. VLAN 23 will be our Layer 2 AP VLAN where the Access Ports will be connected.

RFS7000(config)#interface ge1
RFS7000(config-if )# switchport access vlan 23
RFS7000(config-if)# exit
RFS7000(config)# interface ge2
RFS7000(config-if)# switchport mode trunk
RFS7000(config-if)# switchport trunk native vlan 200
RFS7000(config-if)# switchport trunk native tagged
RFS7000(config-if)# switchport trunk allowed vlan none
RFS7000(config-if)# switchport trunk allowed vlan add 29-32,200

We’ll shutdown VLAN 1 just to be careful, we don’t want any loops.

RFS7000(config)# interface vlan1 no ip address
RFS7000(config)# interface vlan1
RFS7000(config-if)# shutdown

I use VLAN 200 as my management VLAN and place all my network electronics in that VLAN.

RFS7000(config)# interface vlan200
RFS7000(config-if)# management
RFS7000(config-if)# interface vlan200 ip address 10.1.1.40/24
RFS7000(config-if)# exit
RFS7000(config)# ip route 0.0.0.0/0 10.1.1.1

At this point the Motorola RFS7000 should be online and reachable via the network. Let’s configure a single WLAN/ESSID called “PHILLIES” for WPA-TKIP with 802.1x EAP-PEAP authentication to a Microsoft Internet Authentication Server (IAS) so our Windows XP laptop can automatically pass our Windows Active Directory credentials for authentication.

RFS7000(config)#wireless
RFS7000(config-wirless)# manual-wlan-mapping enable
RFS7000(config-wirless)# wlan 1 enable
RFS7000(config-wirless)# wlan 1 description 80211a
RFS7000(config-wirless)# wlan 1 ssid PHILLIES
RFS7000(config-wirless)# wlan 1 vlan 30
RFS7000(config-wirless)# wlan 1 encryption-type tkip
RFS7000(config-wirless)# wlan 1 authentication-type eap
RFS7000(config-wirless)# wlan 1 radius server primary 10.1.1.100
RFS7000(config-wirless)# wlan 1 radius server primary radius-key 0 RaDiUsKeY
RFS7000(config-wirless)# wlan 1 radius server secondary 10.5.1.100
RFS7000(config-wirless)# wlan 1 radius server secondary radius-key 0 RaDiUsKeY
RFS7000(config-wirless)# wlan 1 radius authentication-protocol chap
RFS7000(config-wirless)# exit
RFS7000(config)#

I’m authenticating users against the RADIUS servers at 10.1.1.100 and 10.5.1.100 with the radius key of “RaDiUsKeY” using CHAP as the protocol. Those servers are actually Windows 2003 Domain Controllers running the Internet Authentication Service (IAS).

Since I’m manaully mapping the WLANs I need to make sure I map the WLAN to the default 802.11a radio configuration with the following command. I’ll also set the AP to indoor, the channel selection to ACS and the power to 20mW.

RFS7000(config)#wireless
RFS7000(config-wireless)# radio default-11a bss 1 1
RFS7000(config-wireless)# radio default-11a channel-power indoor acs 20

You’ll obviously need to have the the RADIUS servers setup and you’ll also need Microsoft’s Certificate Server in your Active Directory. The clients will use the trusted root certificate to authenticate the login request from the RADIUS server.

I don’t think there are may people that haven’t figured out how to-do this (it’s really ease) so I’m not going to really go into the topic. If you have questions please feel free to post a comment and I’ll do me best to respond.

That’s a little taste of the RFS700, hopefully you’ll find the information useful.

Cheers!

Nortel recently created a website, Nortel on Nortel, to host some of the best practices and experiences that Nortel’s own Information Technology department uses in day to day IT business. While the best practices and case study documents are nice additions it’s the tools section that has me excited.

The IT Tools site has a number of very useful tools that include;

- Nortel Configuration Converter
- CLI*manager
- MultiCast Hammer (MC Hammer)
- Nortel Icons Library
- Latency Manager

The Nortel Configuration Converter promises to convert any Cisco CatOS configuration file to a number of different Nortel product configurations. When I managed six Nortel Passport 6480 Switches I used CLI*manager extensively to help automated the provisioning and configuration and was extremely greatful to Brett Sinclair for his efforts. Multicast Hammer is a great tool that can be used to help map out any multicast configuration issues (although I still like using VLC). I’ve always struggled to find icon sets for both logical and physical diagrams so it’s nice to see Nortel finally stepping up to the plate with some decent icons. I have never seen the last tool, Latency Manager, but I’ll be interested to see if it’s really useful, I have considered deploying SmokePing by Tobi Oetiker in the past so I’ll definitely need to give this tool a try.

You can download each of the tools from the link provided above, the website only asks for your first name, last name and email address when you download the tool(s).

Cheers!