This is an odd one but figure Id give you guys a crack at it before calling TAC.
I have an ASA Im about to deploy. Its been on my desk for a while and has been configured several different ways for labbing. I blew out the config (wr mem) and loaded a backed up config I created a while back for this deployment and rebooted. When I created the config and through-out my labbing the ASA functioned normally.
After the ASA came back online the Gi0/0 interface showed down/down but Gi0/1 showed up/up. No clue why as they both should have been up/up.
After a ton of troubleshooting I noticed that interfaces listed in the CLI are off-set by 1. So if I plug into gi0/1, the CLI will show Gi0/2 goes up/up. Plug into Gi0/0 and Gi0/1 come up.
Any clue what is going on here?
I have wiped the config and started with a blank config but still same issue. I have rebooted and pulled power multiple time and nothing.
I've seen this happen on hardware with *nix kernels. After a wipe, the underlying *nix assigns the g0/0 to the first port that initializes on the motherboard, which may or may not be the one labeled g0/0 on the box exterior. On one vendor's hardware (ForeScout CounterACT), I could do a ethernet flash test where the base OS would flash the light on the port and say what port it thought it was. If it was right, on to the next port. If wrong, I could reassign the port number and move on to the next.
I don't know how to get to the base *nix under the ASA, but I know it's there and I know that it might very well be able to do a flash test/reassignment if you can get to it.
Or you could call TAC and have them either fix it or get an RMA set up.
I haven't seen it, but it's not surprising because the ASA's have had a lot of interface numbering bugs - but they're usually when in a clustered mode.
So I finally got pissed enough pulled the power and left for about 15+ minutes. Came back booted it up and bam all works fine.
Odd that a general power off/on wouldnt fix it as I left the power unplugged for 1-2 minutes.
Oh well its up and functioning now, I guess thats all that matters.
Thanks guys for the feedback!
Quote from: that1guy15 on February 03, 2015, 04:49:42 PM
So I finally got pissed enough pulled the power and left for about 15+ minutes. Came back booted it up and bam all works fine.
Odd that a general power off/on wouldnt fix it as I left the power unplugged for 1-2 minutes.
Oh well its up and functioning now, I guess thats all that matters.
Thanks guys for the feedback!
The difference is simple. You can't solve a problem simply by cycling the power over and over. You have to *understand* the problem, then cycle the power.
:itcrowd:
Quote from: deanwebb on February 03, 2015, 02:32:11 PM
I don't know how to get to the base *nix under the ASA, but I know it's there and I know that it might very well be able to do a flash test/reassignment if you can get to it.
I can't open it because of our security policy at work, but the following link should be a presentation given at Ruxcon called "Breaking Bricks and Plumbing Pipes" The presentation was awesome, and even just reading the slides is great. It includes a stupid simple way to get to the underlying OS if you already have priv-15. You may have to down grade the OS on the ASA to a vulnerable version first. I did it on one of ours as a demo to management. One of these days I will play with the other vulnerabilities in the presentation.
https://ruxcon.org.au/assets/2014/slides/Breaking%20Bricks%20Ruxcon%202014.pdf
-Otanx