cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

How to connect the Management Port to the network

How to connect the Management Port to the network

Alex_Joda
New Contributor II
We always thought that the Management Port of the Summit Switches are totally independent from the switch ports, with an own VLAN and own Router interface. Because of this we choose the Management Port to connect the switches permanently to the central network for example to monitor them with RidgeLine and to configure the uplinks.
If we connect the Management Port to the same switch to where the Uplink goes the Management Port becomes unstable with periodic disconnects until the a warm restart of the switch. This behaves a little like a loop although the Management Port should behave like a second independent switch. Can somebody explain that ?
12 REPLIES 12

Alex,

Life's not perfect! Best practies are what we think is best. But they're not mandatory.

You can't always prevent ALL problems. But if you know your weak spots you can take that into account in your contingency plan.

Alex_Joda
New Contributor II
Danial,
these are some nice illustrations. In our case we have normally floor cabinets with more than one switch and each is connected to two MLAGed cores with separated LWL uplinks for each switch. So if we connect the Management port to another switch in the cabinet it should behave like the example in picture 1 (if the box "MGMT" is meant as a switch).

The only problem we have are stacked switches in a cabinet with no additional switch nearby and with the Management ports of the cores itself, because every switch is connected directly to the cores. In this cases we have no chance to use the Management ports because there will be always be a parallel connection of the Management net and the uplink without a intermittent switch and we will have the mac address problem again. There is only a limited number of LWL lines to the cores so it is not so easy to establish a completely separated Management network...

Robert_Weiler
New Contributor
To catch up on this: We have seen the same issue in our environment and it is actually quite a bummer that the Mgmt port uses the same MAC address as the rest of the switch. The reasons why we would like to use the Mgmt port and in-band mgmt at the same time are quite exactly the same like Alex' by the way.

I would really like to see different MAC addresses on Extreme switches, even if it is just one for the Mgmt port and another for all other ports.

Paul_Russo
Extreme Employee
Hey Alex

The management port is completely separate from the other ports and uses a separate Virtual routing instance from the other ports, VR-MGMT versus VR-Default

Not sure why you are seeing what you are seeing unless there is more to the configuration like managing the switch from both the MGMT VLAN and a inband VLAN.

The question is why are you looping the management VLAN into the switch? the management port is meant to used with a completely out of band management network. it should plug into a network that is separated from the user data through a FW.

What you are doing is no different then just managing the switch with an inband VLAN like default or another one you create. I would recommend using the inband VLANs and controlling management access to those IP addresses using Access-Profiles before doing what you are currently trying to do

If you want to still use the mgmt port then I would recommend calling GTAC and having them look at the config.

P

Hi Paul,

it seems that Bill hit the spot with the mac address problem. The reason why we would like to use the OOB management network is that we want to be able to configure every aspect of the switch including the Uplink ports, LACP, LAG and so on without risking to get disconnected from the switch. If we do that with the inband VLAN we are connected to the same Uplinks the we would like to configure.

Even if something goes wrong with a firmware update or if the configuration has some problems the connection with Management VLAN is still working most of the time. The management could not be "part of the problem" and this gives us a little more confidence, especially because we are doing support from a remote site and are not so quick on location.
GTM-P2G8KFN