Header Only - DO NOT REMOVE - Extreme Networks

ZTP+ Switch not showing up in EMC


Userlevel 5
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 [i] 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

10 replies

Userlevel 7
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?
Userlevel 5
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
Userlevel 7
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

please, upgrade to 8.1.3.65 when using EXOS 22.5. I'd let XMC do the upgrade via ZTP+, btw.
Userlevel 5
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

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 🙂
Userlevel 5
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.
Userlevel 7
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...
Userlevel 5
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
Userlevel 5
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 🙂
Hi Martin,

getting similar results although using newer version of XMC, EXOS and using Fabric Attach...

When you say it was already in the EMC DB, you mean under 'Networks > Devices' ?

Kind regards
Userlevel 5
Hi Jasper,

If I remember correctly, that’s right. Deleted it from there and that sorted.

Thanks

Martin

Reply