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

[M_Nees]

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

[Erik_Auerswald]

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. 😞

[Erik_Auerswald]

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.

[Erik_Auerswald]

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

[jeronimo]

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.

[jeronimo]

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)...