Currently our WAN interfaces go directly into our VSS 6509 chassis. We purchased a pair of Palo Alto 5250's to sit between the WAN and 6509 chassis. The setup is a pair of 10gig interfaces in a Port channel up to the Palo's, which is all configured and works fine.
Yesterday we tried migrating the 6509's and WAN onto the PAN's by moving the patch leads from the 6509's to the PAN's and changing the gateway of last resort. Traffic is being forwarded correctly and everything seems to be working fine. This is the second attempt at completing this.
The issues we have is that we can no longer SSH to the switch or console to it, it brings up the login prompt as expected but then after entering the login the password prompt takes ages to come up and when you enter the password it almost immediately comes up Access Denied whether you use a TACACS account or the local admin account.
Thankfully the first time we attempted this I didn't save the config on the 6509 and rebooting changed the gateway of last resort back to what it was previously and we could SSH and console to them. We also moved the WAN interfaces back.
This time around I did the same thing and didn't save the config so rebooting them will resolve the issue but before I do that I want to see if the community can give us any ideas why this may be occuring or what to look for?
Any help would be much appreciated.
First question, From where you try SSH to Switch. and where is the TACACS located. in the network ( it would be nice to have some network topology to understand the setup)
Also post the Switch config to have a look, before and after.
Do you see any logs in Palo ? and have enough routing and acces rules.
First of all simple solution is to remove the aaa configuration from the console until you fix the issue. I'm suspecting it's using different interface as a source to reach TACACS server and its get dropped or something else in between, however in order to provide the solution please provide following outputs;
1) Configuration from the device.
2) would you please share the logs from the TACACS server of failed login attempts.
It seems to suggest the PAs are not allowing tacacs correctly -
what you can do has suggested @balaji.bandi is to check the logging/monitoring on the fws but you can also at the same time test the ttacacs from the switch
Now on ASA fws you can inject a simulation packet to test the connectivity but no so sure you can do this on PA Fws
So to test aaa tacacs whilst it still activated you can use the rotary line feature with a new aaa profile to negate aaa tacacs on this single vty line so you can gain access using local database authentication instead and then test tacacs from the switch
This test will produce results not only from the switch itself and obviously allow you access to that switch when it’s deFault is vi the FWs but the logging/monitoring from the Fws also should provide a good insight into what is prohibiting connectivity and you won’t have a need to revert your change.