Header Only - DO NOT REMOVE - Extreme Networks

EXOS specifiy source interface for sntp, download image or download url


Userlevel 6
We have a X450-G2 with 16.1.3.6.

This switch is the router of a branch. Unfortunately the router-transfer nentwork is not part of VPN IPSec SA. So we have several problems with services which using the route-based source interface to reach some services.

For syslog, radius and snmp it is possible to define the correct source interface ip.

But sntp is current not possible.

Another problem is bringing firmware update to this switch - download image and download url NOR "tftp get" supports specifying a source interface.Last change to use a local PC for update. Maybe other or smarter suggestions ?

16.1.x Web interface does also not support a firmware update. (21.x. support that - but patch level is to low for me needs regarding system stability)

So any ideas to get sntp running or bringing a new firmware to that switch ?

Regards,
Matthias

17 replies

Userlevel 5
This doesn't address the networking problem but you can use the old school method of upgrading a switch via USB memory stick.
E.g.
Copy an EXOS .xos image on a FAT32 USB memory stick

download url file:///usr/local/ext/summitX-16.1.3.6.xos
Userlevel 6
Dave Hammers wrote:

This doesn't address the networking problem but you can use the old school method of upgrading a switch via USB memory stick.
E.g.
Copy an EXOS .xos image on a FAT32 USB memory stick

download url file:///usr/local/ext/summitX-16.1.3.6.xos

Hi Dave,

today i try a second run.

I could copy the new firmware files via WinSCP to the switch:
[/code]SW-XX.8 # ls
-rw-rw-rw- 1 root root 462213 Dec 16 11:01 SW-XX-2016-12-16--V16-1.cfg
-rw-rw-rw- 1 root root 382696 Nov 9 10:46 backup.cfg
drw-r--r-- 2 root root 1024 Jan 8 2016 lost+found
-rw-r--r-- 1 admin admin 25512 Apr 27 2016 nms.xsf
-rw-r--r-- 1 admin admin 9876 Nov 18 13:36 non_stacking_config_convert.py
-rw-rw-rw- 1 root root 462213 Nov 25 10:04 primary.cfg
-rw-r--r-- 1 root root 71960061 Dec 16 11:02 summitX-21.1.1.4-patch1-5.xos
drwxr-xr-x 2 root root 1024 Oct 6 11:01 vmt

[/code]Unfortunately using the download url file command failed:

SW-XX.9 # download url file:///config/summitX-21.1.1.4-patch1-5.xos
Note: The inactive partition (secondary) will be used for installation.
Do you want to install image after downloading? (y - yes, n - no, - cancel) Yes

Downloading to SwitchError: Failed to download image - Error: File could not be unwrapped.

SW-XX.10 #[/code]Currently i use EXOS 16.1.3.6 patch 1-11

Any ideas to get the firmware installed on that switch manually ?
Userlevel 7
Dave Hammers wrote:

This doesn't address the networking problem but you can use the old school method of upgrading a switch via USB memory stick.
E.g.
Copy an EXOS .xos image on a FAT32 USB memory stick

download url file:///usr/local/ext/summitX-16.1.3.6.xos

Perhaps you can use install image, see https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-upgrade-EXOS-using-SCP/.
Userlevel 6
Dave Hammers wrote:

This doesn't address the networking problem but you can use the old school method of upgrading a switch via USB memory stick.
E.g.
Copy an EXOS .xos image on a FAT32 USB memory stick

download url file:///usr/local/ext/summitX-16.1.3.6.xos

Hi Dave, Hi Eric,

i got a way:
Windows Client (Putty utility pscp.exe)
pscp summitX-22.1.1.5.xos admin@IP-of-Switch:/scratch/summitX-22.1.1.5.xos

EXOS Switch:
install image "summitX-22.1.1.5.xos"

Works ...
Userlevel 6
Hi Dave,

thanks for your reply.

The above described problem occuring again and again at some customer projects. In EOS i coulld address this with defining the host vlan.

Are there any plan to enhance EXOS with source-ip definition for sntp, firmware upload and configuration download services (within netsight).

Regards,
Matthias
Userlevel 7
It would be nice to have the configuration options suggested by Matthias.

A way to specify a default management interface/IP used as default source address for every IP communication started by the switch (this excludes ICMP messages in reaction to incoming packets) would go a long way. Adding a mechanism to override this per service (e.g. SNTP) or command (e.g. download) would be appreciated as well.

Erik
Userlevel 7
Just to add a little background info...

The functionality requested by Matthias is available on the S-Series and similar EOS devices by specifying a default management interface. The SecureStacks variant of EOS received individual source interface configuration options after customer requests. If those customers would want to migrate to EXOS, they would need this feature.

Layer 3 switches of other vendors, e.g. Cisco, support setting the source interface for every management service.
Userlevel 7
BTW the source IP feature is needed for the scp2 and ssh2 clients as well.
Userlevel 2
I didn't think there was this much of a mess. The internal services to the switch should always and only be using the Mgmt-VR. It is a pain if internal services tie into the production VRs, especially if firewalls are in play (which don't like asymmetric routing)...
Userlevel 7
Hello jeronimo,

it is not always possible or desirable to use the management port. In the example given by Matthias in his question on top, at least another port on the VPN gateway would be needed. If more than one switch is needed at the branch, at least one additional switch is needed for the out-of-band management. And how do you manage the out-of-band management?

Enterasys added source interface/IP configuration to the SecureStacks EOS for this use case (a small site, LAN routing on LAN switch instead of provider router, remote management needed). Enterasys implemented the default management IP for CoreFlow EOS to keep the existing networks working despite the unified IP stack of EOS version 7 and later.

EOS customers might want to replace some of their switches with EXOS devices, but they can only do so if the EXOS switch can be made to work similarly to the EOS switch.

Cisco IOS implements source interface/IP configuration seemingly since forever. Routers and multilayer switches are usually managed through a loopback interface. I have not seen one customer using the out-of-band management port on Cisco Catalyst 2k or 3k switches. Many Cisco routers do not have a management port at all.

I have seen EXOS customers use the management port, but I have not yet seen a network exclusively using out-of-band management, there have always been some switches configured for in-band management (not just the out-of-band management network devices, which need to be managed in-band as well). Many EXOS customer installations do not use the management port at all.

Best regards,
Erik
Userlevel 2
Erik Auerswald wrote:

Hello jeronimo,

it is not always possible or desirable to use the management port. In the example given by Matthias in his question on top, at least another port on the VPN gateway would be needed. If more than one switch is needed at the branch, at least one additional switch is needed for the out-of-band management. And how do you manage the out-of-band management?

Enterasys added source interface/IP configuration to the SecureStacks EOS for this use case (a small site, LAN routing on LAN switch instead of provider router, remote management needed). Enterasys implemented the default management IP for CoreFlow EOS to keep the existing networks working despite the unified IP stack of EOS version 7 and later.

EOS customers might want to replace some of their switches with EXOS devices, but they can only do so if the EXOS switch can be made to work similarly to the EOS switch.

Cisco IOS implements source interface/IP configuration seemingly since forever. Routers and multilayer switches are usually managed through a loopback interface. I have not seen one customer using the out-of-band management port on Cisco Catalyst 2k or 3k switches. Many Cisco routers do not have a management port at all.

I have seen EXOS customers use the management port, but I have not yet seen a network exclusively using out-of-band management, there have always been some switches configured for in-band management (not just the out-of-band management network devices, which need to be managed in-band as well). Many EXOS customer installations do not use the management port at all.

Best regards,
Erik

My post may have been confusing. I did not actually mean the predefined Mgmt-VR (sorry for that) or the OOB Mgmt Port per se. What I meant to say was that
1) You should at least be able to create some VR, lets call it "admin-VR" in order not to generate more confusion
2) Assign internal services of the switch (and whatever else you may need to administer them, like VPNs) to that admin-VR
3) The admin-VR should have to do nothing at all with any other "production" VR carrying user traffic
From what I get point 2) is the weak spot... Well, next time we're going to base our buying decision on capabilities like that which have forever gotten on my nerves...

BTW As far as EOS is concerned: you can specify a host vlan etc but the default gateway defined on the non-routing host interface has no effect when the router part of the switch is actually used.... Things like that cause all amounts of pain.
Userlevel 7
Erik Auerswald wrote:

Hello jeronimo,

it is not always possible or desirable to use the management port. In the example given by Matthias in his question on top, at least another port on the VPN gateway would be needed. If more than one switch is needed at the branch, at least one additional switch is needed for the out-of-band management. And how do you manage the out-of-band management?

Enterasys added source interface/IP configuration to the SecureStacks EOS for this use case (a small site, LAN routing on LAN switch instead of provider router, remote management needed). Enterasys implemented the default management IP for CoreFlow EOS to keep the existing networks working despite the unified IP stack of EOS version 7 and later.

EOS customers might want to replace some of their switches with EXOS devices, but they can only do so if the EXOS switch can be made to work similarly to the EOS switch.

Cisco IOS implements source interface/IP configuration seemingly since forever. Routers and multilayer switches are usually managed through a loopback interface. I have not seen one customer using the out-of-band management port on Cisco Catalyst 2k or 3k switches. Many Cisco routers do not have a management port at all.

I have seen EXOS customers use the management port, but I have not yet seen a network exclusively using out-of-band management, there have always been some switches configured for in-band management (not just the out-of-band management network devices, which need to be managed in-band as well). Many EXOS customer installations do not use the management port at all.

Best regards,
Erik

Hi jeronimo,

using a separate VR for management is a possible solution, but this still needs an additional logical interface on the VPN gateway. This might be a problem if you are buying a VPN service from a provider who accepts just an untagged transfer VLAN.

As Ronald writes in https://community.extremenetworks.com/extreme/topics/recommendation-for-configuration-of-management-..., you can connect the management port to a front port and layer 2 switch from/to it, but I do not think that you can use that to route on a switch to its own management port, because the switch has just one MAC address.

The SecureStack EOS host VLAN should not be used at all if the switch is used as a layer 3 device.

The N-Series switches had two IP stacks, one for managing the switch, one for routing. The host VLAN, IP, and gateway were used by the switch IP stack, and a router interface in the same VLAN on the same switch could be used for routed access to the switch management IP. This changed in CoreFlow EOS version 7.

The two EOS switch product lines (Broadcom based and CoreFlow based) have quite different operating systems. [The line has been blurred by the 7100 series, which is Broadcom based but uses the same EOS as the S-Series.]

Br,
Erik
Userlevel 7
Erik Auerswald wrote:

Hello jeronimo,

it is not always possible or desirable to use the management port. In the example given by Matthias in his question on top, at least another port on the VPN gateway would be needed. If more than one switch is needed at the branch, at least one additional switch is needed for the out-of-band management. And how do you manage the out-of-band management?

Enterasys added source interface/IP configuration to the SecureStacks EOS for this use case (a small site, LAN routing on LAN switch instead of provider router, remote management needed). Enterasys implemented the default management IP for CoreFlow EOS to keep the existing networks working despite the unified IP stack of EOS version 7 and later.

EOS customers might want to replace some of their switches with EXOS devices, but they can only do so if the EXOS switch can be made to work similarly to the EOS switch.

Cisco IOS implements source interface/IP configuration seemingly since forever. Routers and multilayer switches are usually managed through a loopback interface. I have not seen one customer using the out-of-band management port on Cisco Catalyst 2k or 3k switches. Many Cisco routers do not have a management port at all.

I have seen EXOS customers use the management port, but I have not yet seen a network exclusively using out-of-band management, there have always been some switches configured for in-band management (not just the out-of-band management network devices, which need to be managed in-band as well). Many EXOS customer installations do not use the management port at all.

Best regards,
Erik

Henrique mentioned in the other thread (https://community.extremenetworks.com/extreme/topics/recommendation-for-configuration-of-management-...) that the management port has its own MAC address, different from the switch. If this is the case, a cable from the management port to a front port might enable a routed connection from VR-Default to the management port, which can be given an IP routed in the WAN. This would need 2 IP addresses (one in VR-Default, one in VR-Mgmt) for management of the switch, but would enable to only use the Mgmt VLAN IP, similar to the Enterasys N-Series up to firmware version 6.
Userlevel 7
Erik Auerswald wrote:

Hello jeronimo,

it is not always possible or desirable to use the management port. In the example given by Matthias in his question on top, at least another port on the VPN gateway would be needed. If more than one switch is needed at the branch, at least one additional switch is needed for the out-of-band management. And how do you manage the out-of-band management?

Enterasys added source interface/IP configuration to the SecureStacks EOS for this use case (a small site, LAN routing on LAN switch instead of provider router, remote management needed). Enterasys implemented the default management IP for CoreFlow EOS to keep the existing networks working despite the unified IP stack of EOS version 7 and later.

EOS customers might want to replace some of their switches with EXOS devices, but they can only do so if the EXOS switch can be made to work similarly to the EOS switch.

Cisco IOS implements source interface/IP configuration seemingly since forever. Routers and multilayer switches are usually managed through a loopback interface. I have not seen one customer using the out-of-band management port on Cisco Catalyst 2k or 3k switches. Many Cisco routers do not have a management port at all.

I have seen EXOS customers use the management port, but I have not yet seen a network exclusively using out-of-band management, there have always been some switches configured for in-band management (not just the out-of-band management network devices, which need to be managed in-band as well). Many EXOS customer installations do not use the management port at all.

Best regards,
Erik

I have tried this last week, but the management port uses the same MAC addresses as every other SVI on the switch (tested with X670G2 switches), thus the above idea does not work. 😞
Userlevel 4
Matthias,

i found the correct way to make it,

use scp/ winscp and copy the exos file to the file system from your switch.
the config/ folder is the link to /usr/local/cfg which has the file located.
with that known, start download the url as below

#
##
###

BAstian.175 # download url file:///usr/local/cfg/summitX-22.1.0.36.xos
01/10/2017 14:51:33.35 [i] 134.141.136.138 (telnet) admin: download url file:///usr/local/cfg/summitX-22.1.0.36.xos
Note: The inactive partition (secondary) will be used for installation.
Do you want to install image after downloading? (y - yes, n - no, - cancel) Yes

Downloading to Switch01/10/2017 14:51:35.52 Download image from hostname ip address file name file:///usr/local/cfg/summitX-22.1.0.36.xos VR VR-Mgmt
......................................................................................................................................................
01/10/2017 14:52:00.58 Download of image finished with status success; Image integrity check passed.
Installing to secondary partition!

Installing to Switch01/10/2017 14:52:01.08 Upgrade status Start upgrade timer
......................................................................................................................................................................
01/10/2017 14:53:29.81 Image installation finished with status success.
Image installed successfully
This image will be used only after rebooting the switch!
BAstian.176 #

#
I have tested the problem with an older firmware version because I broke that for a customer. I have now the 16.1.3.6patch1-9 on run and would like to update on summitX-16.1.3.6-patch1-11.

The file I have copied with WinSCP but do not get run:

Firmware-Test.8 # download url file:///usr/local/cfg/summix-16.1.3.5... VR VR-Mgmt
Note: The inactive partition (secondary) will be used for installation.
Do you want to install image after downloading? (y - yes, n - no, - cancel) Yes

Downloading to SwitchError: Failed to download image - Error: File could not be unwrapped.

Firmware-Test.10 # ls
drw-r--r-- 2 root root 1024 Mar 15 09:53 dhcp
drw-r--r-- 2 root root 1024 Mar 15 09:52 lost+found
-rw-rw-rw- 1 root root 376968 Mar 21 09:11 primary.cfg
-rw-r--r-- 1 root root 65782864 Mar 21 09:12 summitX-16.1.3.6-patch1-11.xos
drwxr-xr-x 2 root root 1024 Mar 20 09:57 vmt

1K-blocks Used Available Use%
181576 70530 111046 39%

In the log I see only

03/23/2017 10:27:38.64 Download of image finished with status failure - Error: File could not be unwrapped.

03/23/2017 10:27:38.60 Upgrade failed, script: Can not validate image
03/23/2017 10:27:38.03 Download image from hostname ip address file name file:///usr/local/cfg/summix-16.1.3.5... VR VR-Mgmt

Someone an idea?

Thank you for reply
Userlevel 5
Hello,

according to the GTAC "download url file://" for upgrades is only supported with 16.2 and newer versions. Therefore an update via winscp is not available with version 16.1

Regards
Stephan

Reply