BR350 Bridges on PtoP link running 12.02T1 trying to EAP auth remote bridge

[dsidley]

After setting the necessay params on both root and remote to enable the remote to EAP -Auth thru our ACS server, the remote is restarted.

Within 1:20 secs after reload the log on the root shows the remote eap-authenticating successfully, yet the remote then appears to "zone-out" for another 1:30 secs (all LED's out) and layer-3 access is still not up.

Once the remote appears to finish loading, layer-3 will still not come up until the next scheduled eap-auth (as configured on the ACS server)

Anyone else experiencing these symptoms, and if so have you found a work-around. (Cisco's TAC doesn't appear to have a solution as Yet)

Dave Sidley

Enterprise Network Support

City of Winnipeg

[derwin]

Hi Dave,

For a bridge link you really need to use 12.03T

There was a previous problem that has been widely discussed on here in lots of other posts that causes connection problems between 2 br350's but firmware 12.03T fixes that.

If you dont have a stable link then you will see EAP problems like you described

[dsidley]

Thanks for your response.

The Cisco TAC recommended the same thing. I am a little hesitant to upgrade the production 350 bridges to 12.03T because upon checking out the release notes the following was the first open caveat for this release...

"The following caveats have not been resolved for VxWorks firmware version 12.03T:

• CSCea04960—Packet loss, LEAP failure, and possible memory leak issue.

This caveat is being investigated.

I have a test link going in our lab and 12.03T currently appears stable though.

One other question if you will, on power-up or restart the bridge (while watching the vxworkds load via a console session) gets to the stage of "adding two symbols for stand-alone" and then all LED's go out and it appears the bridge is waiting for something to happen. We don't use dhcp. A Cisco TAC person told us that this is when the bridge does it's POST (we kind of chuckled over that one, must have been a new guy).

Do you have any idea what is happening during this stage as it adds approximately 1:20 to 1:30 seconds to the boot process??

Thanks again.

Dave Sidley

[derwin]

Dave

Well the TAC is right to recommend that in this case.

CSCea04960, reading some more details on this I would not be overly concerned about it, it has only been seen by one customer which happened to be our own IT department and could not be reproduced in the lab, Since they upgraded to fix another issue it has not been seen again but they are still monitoring as it takes 2 months to see the problem, they have gone past this 2 months but will give it about 6 months just to make sure. In short it is not a show stopper for you.

The reason you need to move to 12.03T is to get the fix for CSCdz03100 this will cause the link to flap in which case then you WILL see problems with leap, kinda like saying CHAP fails on a ppp serial link when you see lots of interface resets, CHAP is where you see the problem but is not the problem.

"adding two symbols for stand-alone" I will look into that and get back to you, the only reference I could find was on AP340's it is part of the boot up cycle but what for I will let you know

Do you see it on all BR's or only on a set firmware ? or a set config ?? Do you have the ethernet cable plugged in at the time you see it anything else you know about it What the case number if the details are in there I will look that over for you

David

[dsidley]

Thanks again,

Case E213268 (I uploaded both root and remote .ini's) if they are still there that is.

We have both root and remote end plugged into catalyst switches set to (auto speed/auto duplex) The reason we leave it at auto is because most of the remote end sites require us to use a hub so as to get layer 3 access on our laptops...

The "adding two symbols for stand-alone" shows up on every bridge and also 350 Access Points and as far as I know is part of the boot procedure. Also, at this stage of the boot the eth int is already up and has accepted it's ip address. Believe it or not, watching a console session on the root end I have a perfect RF link and can intitiate a linktest to this remote while it's sitting in this "no-man's land" state.

Your explanation regarding 12.03T makes absolutely good sense.

Dave Sidley

[derwin]

Dave,

Got an answer on the symbols for you

All that message means is that there are only two public symbols in the customer-build VxWorks symbol table (specifically, the symbols for the console browser). The effort at adding those symbols is done by the time the message is printed; the delay the customer is seeing results from some other operation. One possibility is DHCP -- it has about a two-minute max-timeout. If the customer's DHCP server is slow responding, that could be inducing the "hang" (while the AP/BR is waiting for an IP address). I know you said you dont use DHCP but this is one example plus it is possible to configure the AP/BR with a static address and for DHCP at the same time maybe this is what you have what is the configuration server set to for static IP it should be set to 'none'

http://www.cisco.com/univercd/cc/td/doc/product/wireless/airo_350/accsspts/ap350scg/ap350ch3.htm#1016885

[dsidley]

Thanks for the symbol explanation.

Yes we have the config server set to "none" and we use static ip's...

Once again this morning I gave in to the Cisco TAC's recommendation to upgrade the 350 bridge to 12.03T.

I had a browser session going to the remote and upgraded the image. The remote never did come back. I upgraded the image on the root then drove over to the remote site. On arrival the log on the remote showed a successful association to the root and a prestine RF connection... (72% to and 78% from station) linktests showed 100 at 11Mbps with no retrans, yet I had no layer 3 (could not ping the root).

I then drove over to the root site and restarted the root bridge and within 3 minutes the link was up and layer 3 functioning normal. At this point in time it's driving me nuts.

[derwin]

So what is not working right now ??

sounds like you have it all fixed since the upgrade ??

[schalm]

We have experienced the exact same issues, Layer 3 seems to come back to life after several minutes. TAC has always told me to be patient. I have not found a work around.