10-12-2016 07:35 AM - edited 03-01-2019 04:32 AM
Hi All,
I am having a bit of trouble getting a stack of 3850's configured via PnP. I initially tested with just a single switch and it worked great, but since I introduced a second switch into the stack it no longer seems to register in APIC.
If I look at the logs on the serial I get "Redundant RPs - Simultaneous configs not allowed:locked from console" I don't recall seeing this output on a single switch. also If I do a "show pnp trace" I see HA, config safe check [NOT OK]. Is the PnP server trying to configure the switch before the stack is fully functional?
[10/12/16 12:45:39.771 UTC C0 335] pnp_resp_data: Server : Jetty(9.0.z-SNAPSHOT)
[10/12/16 12:45:39.771 UTC C1 335] pnp_resp_data: Data has not been cached
[10/12/16 12:45:39.771 UTC C2 335] pnp_http_resp_data_free: pnp response data freed
[10/12/16 12:45:39.771 UTC C3 440] pnp_httpc_send_get: HTTP send success()
[10/12/16 12:45:39.772 UTC C4 440] send_work_req: HTTP SEND GET REQUEST SUCCESS
[10/12/16 12:45:39.772 UTC C5 440] HA registry indicates presence of standby
[10/12/16 12:45:39.772 UTC C6 440] HA, config safe check [NOT OK], for configuring[try:0]
[10/12/16 12:45:39.772 UTC C7 440] HA, config safe check [NOT OK], for configuring[try:1]
[10/12/16 12:45:39.772 UTC C8 440] configure_profile: after parse configure rc is 1
[10/12/16 12:45:39.772 UTC C9 440] pnpa_dhcp_discovery:PnP profile config unsuccessful
I'm looking to see if there is a delay setting anywhere.
I have tried with 2960x switches with no issue.
Cheers
Ant
Solved! Go to Solution.
10-15-2016 02:54 PM
BTW, what you are seeing is normal. There is a builtin check while stack is coming up. the PnP process retries as you can see in my example.
3650-dhcp#show pnp trace | inc pnpa_dhcp_discovery
[10/15/16 21:26:47.992 UTC 2A 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:26:48.005 UTC 4D 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:28:37.112 UTC 9D 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:28:37.118 UTC C0 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:30:28.180 UTC 10F 458] pnpa_dhcp_discovery:Configured pnp profile
3650-dhcp#show pnp trace | inc HA
[10/15/16 21:26:47.992 UTC 27 458] HA registry indicates presence of standby
[10/15/16 21:26:47.992 UTC 28 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:26:47.992 UTC 29 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:26:48.005 UTC 4A 458] HA registry indicates presence of standby
[10/15/16 21:26:48.005 UTC 4B 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:26:48.005 UTC 4C 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:28:37.112 UTC 9A 458] HA registry indicates presence of standby
[10/15/16 21:28:37.112 UTC 9B 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:28:37.112 UTC 9C 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:28:37.118 UTC BD 458] HA registry indicates presence of standby
[10/15/16 21:28:37.118 UTC BE 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:28:37.118 UTC BF 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:30:26.137 UTC 10D 458] HA registry indicates presence of standby
[10/15/16 21:30:28.180 UTC 10E 458] HA, config safe check [OK], for configuring[try:0]
[10/15/16 21:31:01.421 UTC 114 350] HA registry indicates presence of standby
[10/15/16 21:31:02.017 UTC 115 350] HA, config safe check [OK], for configuring[try:0]
[10/15/16 21:31:02.936 UTC 116 166] HA registry indicates presence of standby
[10/15/16 21:31:04.962 UTC 117 166] HA, config safe check [OK], for configuring[try:0]
10-15-2016 01:16 PM
Hi Anthony,
I have been testing 3650 stacks (successfully) over the past few days.
What version of IOS are you running?
You need to have a stack rule in PnP app too.
Adam
10-15-2016 02:54 PM
BTW, what you are seeing is normal. There is a builtin check while stack is coming up. the PnP process retries as you can see in my example.
3650-dhcp#show pnp trace | inc pnpa_dhcp_discovery
[10/15/16 21:26:47.992 UTC 2A 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:26:48.005 UTC 4D 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:28:37.112 UTC 9D 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:28:37.118 UTC C0 458] pnpa_dhcp_discovery:PnP profile config unsuccessful
[10/15/16 21:30:28.180 UTC 10F 458] pnpa_dhcp_discovery:Configured pnp profile
3650-dhcp#show pnp trace | inc HA
[10/15/16 21:26:47.992 UTC 27 458] HA registry indicates presence of standby
[10/15/16 21:26:47.992 UTC 28 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:26:47.992 UTC 29 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:26:48.005 UTC 4A 458] HA registry indicates presence of standby
[10/15/16 21:26:48.005 UTC 4B 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:26:48.005 UTC 4C 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:28:37.112 UTC 9A 458] HA registry indicates presence of standby
[10/15/16 21:28:37.112 UTC 9B 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:28:37.112 UTC 9C 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:28:37.118 UTC BD 458] HA registry indicates presence of standby
[10/15/16 21:28:37.118 UTC BE 458] HA, config safe check [NOT OK], for configuring[try:0]
[10/15/16 21:28:37.118 UTC BF 458] HA, config safe check [NOT OK], for configuring[try:1]
[10/15/16 21:30:26.137 UTC 10D 458] HA registry indicates presence of standby
[10/15/16 21:30:28.180 UTC 10E 458] HA, config safe check [OK], for configuring[try:0]
[10/15/16 21:31:01.421 UTC 114 350] HA registry indicates presence of standby
[10/15/16 21:31:02.017 UTC 115 350] HA, config safe check [OK], for configuring[try:0]
[10/15/16 21:31:02.936 UTC 116 166] HA registry indicates presence of standby
[10/15/16 21:31:04.962 UTC 117 166] HA, config safe check [OK], for configuring[try:0]
10-21-2016 07:26 AM
Hi Adam,
Thanks for getting back to me. Out of the box the installed image is 3.6.5 and as mentioned on its own worked great. I have a rule which has 2 switches in the stack.
It's good to know that what I thought was an issue is correct behaviour.
Unfortunately it looks like I've managed to trash the switches now by upgrading to version 16. They are now in a Linux boot screen in a constant loop. I will update the PnP issue once I manage to get them to boot again.
Cheers
Ant
10-21-2016 07:45 AM
Hi Ant,
thanks for the follow up. did you use PnP to upgrade to 16.3?
Adam
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide