How to connect the Management Port to the network
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎03-08-2015 07:43 PM
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 ?
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎03-09-2015 02:01 PM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-22-2019 06:56 PM
We are talking with a customer who does not want stacks, because they want to be able to ping every switch.
So they want to ping slot 1 slot 2 and so on.
I can give slot 2 its own IP, but only on the mgmt VLAN, which is of course in vr-mgmt.
Is there a viable option to ping each member of a stack?
So they want to ping slot 1 slot 2 and so on.
I can give slot 2 its own IP, but only on the mgmt VLAN, which is of course in vr-mgmt.
Is there a viable option to ping each member of a stack?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎02-22-2019 08:37 PM
I think this is what you're looking for, David: https://documentation.extremenetworks.com/exos_22.3/EXOS_21_1/Stacking/t_configure-an-alternate-ip-address-and-gateway.shtml
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎03-09-2015 01:50 PM
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.
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.
