Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

3850 stack - Should console ports on all members provide console access?

We are testing a 3850 stack (active, standby and one member switch) running 3.6.0E.  Connecting the console cable to the active switch works fine.  When we connect the console cable to either the standby switch or the member switch, the messages "switch console in now available, press return to get started" are displayed.  Pressing return simply results in the same messages being repeated without access to the console.  Connecting the console cable back to the active switch restores console access.  Documentation states that the active console can be accessed via any of the console ports in the stack.  Here is the console port configuration:

line con 0
 exec-timeout 15 0
 media-type rj45 switch 1
 media-type rj45 switch 2
 media-type rj45 switch 3
 logging synchronous
 stopbits 1


Is there something else that needs to be enabled for the other console ports to work?

Reza Sharifi
Hall of Fame Expert

Try this command on the master

standby console enable

Then test again.


I tried:

service internal



      standby console enable


...but this did not solve the problem.  As a matter of fact, after I enter the commands, I find the "service internal" command in the configuration but do not find the "standby console enable" command anywhere in the config.


Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# standby console enable
Richard Primm
Cisco Employee



I can help you with this.  Im not aware of an issue in 3.6 that might prevent normal console operation.  Your config is correct, are you using the media-type command just as a precaution? 

When its not working what shows when you run a "show users" ?  There should be a few connections sourcing from a 192.168.x.x address (depending on how many switches in the stack).

Like its predecessor, the 3850 uses and internal VRF to connect the console ports in a stacked solution. This allows you the end user to plug into any console port and config as if we are connected to the master switch.  

I will have to test this in my lab and will let you know my findings.




Thank you..

Here is my "show users" when I physically connect to the third stack member:

Switch>show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:03:35
*  2 vty 0                idle                 00:00:00

I do not have the connections sourcing from 192.168.x.x.  But when I revert to 3.3.4SE, I do have the connections sourcing from 192.168.x.x and the console connection to member 3 gives me access to the console as expected.  We have opened a case with Cisco, as this appears to be a bug.



Hey Christine, 

It seems that I have the same issue when I configured a 2-switch stack. 

When I connect through console to active switch, everything works. When I use the console of standby switch, I just get the "Press RETURN to get started" message in a loop when I press anything.

Were you able to resolve your issue? What did you do?

The switch stacks use an internal VRF to connect the console ports in a stacked solution to the master switch. Adding the "vrf-also" keyword to the vty access-class command fixed it for us.

line vty 0 4
access-class 103 in vrf-also


I know this is an old post, but I faced the exact same issue recently while staging for an install.  When I had a 3 member stack in the lab, I hadn't enable any type of authentication on the console port, to allow ease of access.  Once I deployed the switchstack in production, I issued the "login authentication <NAME>" command on the con port.   The issue went away after I enabled login authentication & I was able to login to each stack member individually using local authentication.  

I haven't found anything yet in Cisco documentation stating that console authentication has to be enabled in order for the non-Active stack member console ports to be accessible, so I am not 100% that this was the solution.  I plan to lab up another stack to test out this theory, just to satisfy my curiosity.