ZTP+ Switch not showing up in EMC

  • 0
  • 1
  • Question
  • Updated 3 months ago
  • Answered
  • (Edited)
Hi,

In the process of configuring ZTP+. 

The switch has been set to 'unconfigure switch all' and seems to be obtaining an IP address.

After a while I've logged into the switch and I see that the ZTP connector has started:

06/25/2018 15:26:36.83 <Info:System.userComment> Zero Touch Provisioning: Starting cloud_connector version 1.1.14.36

Show vlan default:

* X440G2-48p-10G4.1 # show vlan Default
VLAN Interface with name Default created by user
    Admin State:         Enabled     Tagging:   802.1Q Tag 1
    Description:         None
    Virtual router:      VR-Default
    IPv4 Forwarding:     Disabled
    IPv4 MC Forwarding:  Disabled
    Primary IP:          192.168.0.30/24

Current version is 22.4.1.4 patch1-2

When I take a look at the cc_logs I get these messages, first for state_machine.txt:

2018-06-25 15:47:17,650:DEBUG:ExpyRunner:ccsm_logger:start.1426:: == STATE MACHINE ==============================
In UPGRADE state
2018-06-25 15:47:17,701:DEBUG:ExpyRunner:ccsm_logger:send_message.702:: == UPGRADE MESSAGE ==============================
PUT: https://extremecontrol:8443/Clients/device/v1/switch/1622N-43729/imageupgrade
DATA:
{
  "apPropertyBlock": {
    "bpWiredMacaddr": "00:04:96:9B:50:F2", 
    "ruSwVersion": "22.4.1.4", 
    "ruModel": "X440G2-48p-10G4", 
    "ruSerialNumber": "1622N-43729"
  }, 
  "assets": [
    {
      "assetName": "xos", 
      "assetVersion": "22.4.1.4 patch1-2", 
      "assetType": "FIRMWARE"
    }, 
    {
      "assetName": "cloud_connector", 
      "assetVersion": "1.1.14.36", 
      "assetType": "XMOD"
    }
  ]
}

Then for ztp_plus.txt the following keeps repeating:

2018-06-25 15:45:14,533:DEBUG:ExpyRunner:exos_log:device_is_ztp_enabled.1105:: Called
2018-06-25 15:45:14,554:DEBUG:ExpyRunner:exos_log:device_is_ztp_enabled.1126:: Row 0 opStatus 1 opMsg [] field_values OrderedDict([(u'autoProvConfigStatus', '1'), (u'enable', '1'), (u'vr', 'VR-Mgmt')])
2018-06-25 15:45:14,582:DEBUG:ExpyRunner:exos_log:device_is_ztp_enabled.1126:: Row 0 opStatus 1 opMsg [] field_values OrderedDict([(u'autoProvConfigStatus', '1'), (u'enable', '1'), (u'vr', 'VR-Default')])

One thing I noticed is the url to EMC, it shoud read:

https://extremecontrol.ingleby.co.uk:8443, where ingleby.co.uk is obviously the domain. But the URL in the log is:

https://extremecontrol:8443/

Which doesn't resolve as its missing the domain element, whereas https://extremecontrol.ingleby.co.uk:8443 resolves fine

In the DHCP scope the domain has been entered correctly.

I think this might be at fault, but I'm not sure what I can do to correct it?

Many thanks in advance
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb

Posted 3 months ago

  • 0
  • 1
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 13,348 Points 10k badge 2x thumb
Hi,
in the rest of the logs, do you see url with the expected IP address? Any other message?
do you have CC 3.0 latest in XMC?what version of XMC?
what happens with 22.5, if you can test?
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb
Hi Stephane,

Thanks for posting a reply.

The URL is only displayed as shown in the logs above, I don't see any IP address, just the name extremecontrol, and not the FQDN of extremecontrol.ingleby.co.uk that works OK. The logs do show other information but its pretty much all the same with the switch trying to communicate with the EMC using just https://extremecontrol:8443 instead of https://extremecontrol.ingleby.co.uk:8443

See nslookup below and screenshot from correct URL:

nslookup extremecontrol.ingleby.co.uk

Server:  UnKnown
Address:  192.168.200.110
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.

Name:    extremecontrol.ingleby.co.uk
Address:  192.168.123.100



Pretty sure the URL used to say extremecontrol.extremenetworks.com until I added the domain name of Ingleby.co.uk into the DHCP options, now the domain element of the FQDN seems to be missing?






I have the latest Cloud Connector uploaded to Extreme Control:




The version of EMC is 8.1.2.59 - its for a POC, hence why running such a new version.

I will trying running the switch on version 22.5 and also take a packet capture to see what that reveals.

Will post back any results.

Thanks
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 13,348 Points 10k badge 2x thumb
please, upgrade to 8.1.3.65 when using EXOS 22.5. I'd let XMC do the upgrade via ZTP+, btw.
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb
Ok, will do. Also done a quick packet capture and filtered on the IP the switch received and its seems the DNS server 192.168.200.110 is returning the correct resolution to the switch:



Just for the info, I only attach the console cable after I've given it a chance to connect, as I know one of the requirements is that one shouldn't be connected :)
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb
Upgraded all the appliances to version 8.1.3.65 and EXOS 22.5, now I have a new problem in that the DHCP process on the switch keeps repeating through a Discover, Offer then starts all over again?



So it actually gets an IP (192.168.0.8), but just stops there and starts all over again:



This is the output from the ztpdhcp.txt file on the switch

2018-06-26 12:16:22,082:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,116:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,117:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,154:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,156:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,199:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,201:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,226:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,227:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,262:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,270:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,279:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,281:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,356:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,357:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,380:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,400:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47
2018-06-26 12:16:22,422:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:923: DHCP OFFER received
2018-06-26 12:16:22,425:DEBUG:ztpdhcp.py:dhcp_recv_packet_callback:899: found vid 1 on slot/port 47


Going to try a different DHCP server, after that I'm not sure what else I can do?

Any thoughts? Many thanks.
Photo of Doug Hyde

Doug Hyde, Technical Support Manager

  • 20,514 Points 20k badge 2x thumb
I would suggest reaching out to the GTAC and opening a ticket for help.  https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-contact-Extreme-Networks-Global-Tec...
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb
Thanks Doug. Have raised a case 01704426

Ended up rolling back to version 22.4.1.4 patch1-2 and it got an IP straightaway but wont show up in Discovered items. If I run it on 22.5.1.7 it refuses to get an IP?

When back on 22.4.1.4 I did a packet capture and notice it was communicating to EMC, so turned on the ZTP+ log in EMC and got the following message:

2018-06-26 17:16:02,762 INFO [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] Do not give other assets to early connector versions
2018-06-26 17:16:02,786 WARN [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] doImageUpgradePut : {
"action" : "PUT",
"method" : "doImageUpgradePut",
"status" : "Not Acceptable",
"message" : "Connector must be upgraded",
"timestamp" : "06/26/2018 17:16:02"
}


So I manually upgraded the CC connector to the latest version 3, and now get the following:


2018-06-26 17:22:09,101 DEBUG [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] UPGRADE RESPONSE: 1622N-43729 : 192.168.0.6 : {
"imageUpgradeBlock" : [ {
"upgrade" : false,
"uri" : "",
"timeout" : 600,
"assetName" : "xos",
"assetVersion" : "22.4.1.4 patch1-2",
"assetType" : "FIRMWARE"
}, {
"upgrade" : false,
"uri" : "",
"timeout" : 600,
"assetName" : "cloud_connector",
"assetVersion" : "3.0.34.54",
"assetType" : "XMOD"
} ]
}
2018-06-26 17:22:09,101 INFO [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] doImageUpgradePut : 1622N-43729 : OK


Looking at the logs its looking a bit better. I think its tried to configure the switch but something in the config it applied it didn't like, so think I just need to work through that bit... although its still not showing up in the discovered items:


2018-06-26 17:31:02,090 INFO [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] doConnectPut : 1622N-43729 : OK
2018-06-26 17:31:02,282 INFO [com.enterasys.netsight.server.webapps.monitor.ezConfig.ZtpPlusDeviceDispatcher] doEventPost : 1622N-43729
2018-06-26 17:31:02,292 DEBUG [com.enterasys.netsight.server.webapps.monitor.ezConfig.MsgDispatcher] EVENT REQUEST: 1622N-43729 : 192.168.0.6 : {
"apPropertyBlock" : {
"bpWiredMacaddr" : "00:04:96:9B:50:F2",
"ruModel" : "X440G2-48p-10G4",
"ruSerialNumber" : "1622N-43729",
"ruSwVersion" : "22.4.1.4"
},
"event" : [ {
"type" : 519,
"severity" : "major",
"timestamp" : "2018-06-26 16:33:55.931228",
"target" : "Controller",
"description" : "Device rebooted due to lack of network connectivity after configuration was applied"
} ],
"configAck" : {
"status" : "fail",
"timestamp" : "2018-06-26 16:33:55.931303",
"bpRequestId" : 2,
"appliance" : null,
"dot1x" : null,
"extremeFabric" : null,
"lacp" : null,
"license" : null,
"lldp" : null,
"logins" : null,
"macAuth" : null,
"mlag" : null,
"mgmtAccess" : null,
"mvrp" : null,
"poe" : null,
"ports" : null,
"radiusServers" : null,
"snmp" : null,
"spanningTree" : null,
"stacking" : null,
"syslog" : null,
"vlans" : null,
"vxlan" : null
}
}

Thanks
Photo of Martin Flammia

Martin Flammia

  • 6,190 Points 5k badge 2x thumb
Going to own up to this just in case someone does something as silly as me.

After spending ages on this and looking through the server.log, it dawned on me that the switch I was using was already in the EMC DB. When I deleted it, bang!, it popped straight in... doh!

Anyway, lesson learnt :)