How to connect the Management Port to the network

  • 0
  • 2
  • Question
  • Updated 3 years ago
  • Answered
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 ? 
Photo of Alex Joda

Alex Joda

  • 200 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 2
Photo of Bill Stritzinger

Bill Stritzinger, Alum

  • 6,016 Points 5k badge 2x thumb
You are correct in saying that the management port is independent of the vr-default, but the condition you are experiencing is due to the fact the switch has a single mac address.  The condition you are experiencing is not a L2 loop in the true sense but because you are connecting them to the same switch,with the same mac address, you then loose connectivity.  In the true sense of "out of band", the two networks would never touch one another.  Let me know if that is clear or you need more information.
Photo of Alex Joda

Alex Joda

  • 200 Points 100 badge 2x thumb
Hi Bill,

that sounds like a good reason for this ! So if we are not using the same switch that we uplinking to it should not give us any problems...If there is only one additional switch we might use the inband VLAN to manage it....Thanks a lot for the help !

Alex
Photo of Alex Joda

Alex Joda

  • 200 Points 100 badge 2x thumb
Hi Bill,

today we changed our management to inband and gave the default network an IP-address. At the moment we have done that the the management port was only partly available and even the new inband IP was not stable. This stops only after we removed the cable from the management port.

In this case the the management port was not directly linked to the same switch as the uplink ! It was only in the same network through another switch in between. The the problem with the same mac address seems to exist even if the switches are not connected directly....So we are very careful now using this management port. It looks like you can use them only if the networks are totally separated.  

The only problem now is that we are not able to configure the uplinks of the switches any more without connecting directly with a notebook to the local switch itself. This is very annoying on a big campus or if you only have remote access to the site. Do you have a solution for that ? 
Photo of Paul Russo

Paul Russo, Alum

  • 9,694 Points 5k badge 2x thumb
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
Photo of Alex Joda

Alex Joda

  • 200 Points 100 badge 2x thumb
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.
Photo of Robert Weiler

Robert Weiler

  • 92 Points 75 badge 2x thumb
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.
Photo of Daniel Flouret

Daniel Flouret, Employee

  • 7,470 Points 5k badge 2x thumb
Alex, Robert,

If your objective is to be able to survive configuration mistakes, this can only be done if you have completelly separated management and production environments.

Here, management of the switch will continue no matter what happens with the production network (green).


If you connect the management network to the switch you will be, probably, propagating it back to the core through the same uplink as the production networks. Any problem with the production networks (either you misconfigured the switch and broke that link, or you created a broadcast storm that completely saturates it) and you'll lose management of the switch.

If the switch is in a remote site, there's no way of having separate links back to HQ, but you can still have separate networks connecting to the router.

Finally, from a security standpoint, an isolated management network will protect you from attacks originating from the production

Connecting the management port to the same switch is the same as managing it inband through one of the user-side networks, but comes with some side effects. So, why bother? Create an administration vlan in vr-Default and exclude regular users from it.
Photo of Alex Joda

Alex Joda

  • 200 Points 100 badge 2x thumb
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...
Photo of Daniel Flouret

Daniel Flouret, Employee

  • 7,470 Points 5k badge 2x thumb
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.
Photo of Paul Russo

Paul Russo, Alum

  • 9,694 Points 5k badge 2x thumb
Daniel thanks I was trying to make that point as well.

Alex and Robert the reason the management port have different VRs is because if the switch is DoSed and the VR-D tables are messed up you can still get to the switch via the out of band management port as it has different L3 tables.  If you turn it back into the switch you are negating that purpose.  The port is more than just an extra port.

I think your best approach is a full out of band network.

P