Within the past six months my employer opened a new 1 million square foot distribution facility here in southeastern Pennsylvania. It’s been an exciting challenge for me personally. One of the bigger challenges has been getting the wireless network tuned in since the building opened essentially empty and now almost 4 months later is filled to the gills with product as we prepare for the upcoming holiday season. It’s about 45′ to the ceiling framing joists so I had our integrator mount the APs (Cisco AP 2702e) to 6′ of electrical conduit hanging from the ceiling. This way the APs are a little closer to the intended coverage space yet they are high enough to avoid being hit by the many fork lifts and other vehicles that traverse the distribution center.

Weekly I review the power settings and RF coverage as the building literally fills up with product…which attenuates the signal from the wireless APs little by little. The majority of my WiFi experience is in hospitals, very old buildings and corporate office space where the RF signal only covers about 40-50′ at max and sometimes much smaller (hospitals). The biggest surprise in this facility is the propagation of the RF signal, there’s literally too much RF signal. I’ve had to turn off quite a few AP radios especially in the 2.4Ghz (802.11b/g) band to keep the channel interference to a minimum.

While RF coverage issues are no surprise to anyone working in the industry I have had an interesting time tracking down an idle timeout issue between the Motorola handheld scanners and the IBM AS400 host which runs our warehouse inventory system. The default idle user timeout on the Cisco WLC 5508 is 5 minutes, so I had to changed that parameter to 43200 seconds (12 hours). I also changed the session timeout to 86400 seconds (24 hours). Our employee shifts run 10 hours so these settings looked like they would work – and they do work, except they didn’t work for everyone. In my initial testing I found that I could login from one side of the distribution center, walk to the other side of the distribution center (6 minute walk – it’s that big) and I could pickup my session where I left off without issue even with the handheld going to sleep as I physically moved through the distribution center. I thought the problem was solved and moved onto other issues only to eventually hear that some users were still reporting that they were being “kicked out” – but not everyone.

It was a very specific set of users… those working the receiving dock and the wholesale racking. What was the common denominator? These users would occasionally put down their Motorola handhelds for upwards of 10-15 minutes as they unloaded a truck or prepared to put away a pallet. When they tried to use the handheld it would prompt that their AS400 session had ended and they would need to log in again.

I ran a few tests from the office space in the distribution center and quickly determined that if I was idle longer than 12 minutes I would generally get disconnected from my AS400 session. Was this issue coming from the wireless network or the AS400 host itself? I setup a quick and easy control test. I enabled telnet on one of my Linux jump boxes and established a connection from my test MC9190. After logging into my Linux jumpbox I sat the device on my desk for 25 minutes with no input from me. The Motorola MC9190 went to sleep in about 30 seconds, 25 minutes later I picked up the device, waited for it to power up and connect to the network and found my telnet session still working without issue so this test essentially eliminated the wireless network.

It turns out that the AS400 uses a TCP keepalive to determine if a user is still connected to the system. I’m guessing that since the handheld is sleeping it’s not responding to the keepalive packets so the host system is eventually closing the connection to the handheld. I have some inquires into our AS400 team and IBM to validate my theory.

Cheers!

Update: Sunday October 25, 2015

We were able to update the session keep-alive parameter on the IBM AS400 host. This value defaults to 10 minutes. So every 10 minutes the host will check if the session is still valid by sending a keep-alive packet. If the IBM AS400 host doesn’t get a response to the check it will logoff the session. We increased this value to 20 minutes and that’s helped greatly.

The credit for the workaround goes entirely to @MatzeKS.

Cheers!

Thankfully you can configure an idle timeout for CLI sessions in Junos.

We don’t use the default root account but instead create an admin account for the day to day management and configuration changes. Here are the steps we use to create that admin account;

set system login user admin full-name Administrator
set system login user admin uid 100
set system login user admin class super-user
set system login user admin authentication plain-text-password password

That leaves us with the following configuration;

user admin {
    full-name Administrator;
    uid 100;
    class super-user;
    authentication {
        encrypted-password "*****************************"; ## SECRET-DATA
    }
}

Since the idle-timeout value is set per user class and we can’t modify the default super-user class we had to create a new class called super-user-local. After setting the idle-timeout and permissions we add the user admin to that user class.

set system login class super-user-local idle-timeout 10
set system login class super-user-local super-user-local permissions all
set system login user admin class super-user-local

If we look at the configuration after those changes we should be able to see the new user class.

class super-user-local {
    idle-timeout 10;
    permissions all;
}
user admin {
    full-name Administrator;
    uid 100;
    class super-user-local;
    authentication {
        encrypted-password "********************************"; ## SECRET-DATA
    }
}

And now lets test it…

[root@linux ~]# telnet vpn-testlab
Trying 10.101.203.1...
Connected to vpn-testlab (10.1.1.1).
Escape character is '^]'.

vpn-testlab (ttyp0)

login: admin
Password:

--- JUNOS 10.4R9.2 built 2012-02-02 08:09:42 UTC
admin@vpn-testlab> 

Warning: session will be closed in 5 minutes if there is no activity
Warning: session will be closed in 1 minute if there is no activity
Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session

Connection closed by foreign host.

With that change any CLI sessions that are idle for 10 minutes will be automatically logged out.

I mentioned creating a few screencasts so here’s my first “public” attempt. I’ve created a few private screencasts for my employer from time to time but nothing ever public. Have a look below, feel free to leave any feedback even constructive criticism is welcome. I know that I need to work on my microphone volume and settup. I don’t smoke but you’d never know that by listening to the video with my heaving breathing. Any if you decide to watch why not have a go at counting the number of uhms or ahs?

Cheers!

The bulletin advises users to re-configure the VLACP timeout from a default value of 3 to 5.

5520-48T-PWR(config)#interface fastEthernet 5-6
5520-48T-PWR(config-if)#vlacp timeout-scale 5
5520-48T-PWR(config-if)#show vlacp interface 5-6
===============================================================================
VLACP Information
===============================================================================
PORT ADMIN OPER HAVE FAST SLOW TIMEOUT TIMEOUT ETH MAC
ENABLED ENABLED PARTNER TIME TIME TYPE SCALE TYPE ADDRESS
-------------------------------------------------------------------------------
5 true true yes 500 30000 short 5 8103 00:00:00:00:00:00
6 true true yes 500 30000 short 5 8103 00:00:00:00:00:00

The bulletin also refers to a software fix in ERS 2500 v4.2.1, ERS4500 v5.2.1 and ERS5500/5600 v6.0.2 or later maintenance releases.

We really only use VLACP as a means of detecting FEFI when the switch equipment doesn’t support autonegotiation (example; Nortel Ethernet Switch 470 doesn’t support autonegotiation on the 1000Mbps uplinks).

Cheers!

Update: Friday February 13, 2009

It seems that Nortel has released software 6.0.3 for the Ethernet Routing Switch 5500/5600 series switches. This release is suppose to resolve the VLACP issues that were reported in the earlier bulletin. Here’s an excerpt from the release notes;

A feature enhancement (Q01645430) that changed the VLACP interoperability behavior with Passport 8600 was removed. For further details, please see the Technical Support Bulletin ID. 2008009238, Rev 1, published on 2008-12-12.

Cheers!