3750X Out-Of-Band Management Port

[mikegrous]

What is the point of it? It is not a remote console. If i reboot the switch i cannot get back to the out of band management port unless the switch is fully running. Is this only for security purposees? so all telnet/ssh is from an Out of band network?

[Jon Marshall]

mikegrous wrote:
What is the point of it? It is not a remote console. If i reboot the switch i cannot get back to the out of band management port unless the switch is fully running. Is this only for security purposees? so all telnet/ssh is from an Out of band network?

Mike

You say "is it only for security purposes" but that is a big thing for a lot of companies. If you have a completely different path into your switch stack that is not via the main network that can be a life saver in certain situations. Mind you if you simply connect it back to an port on on your other production switches you have lost a lot of the advantage.

Basically it is indeed for this purpose although the full list of supported protocols etc. on the port is -

Supported Features on the Ethernet Management Port

The Ethernet management port supports these features:

•Express Setup (only in switch stacks)

•Network Assistant

•Telnet with passwords

•TFTP

•Secure Shell (SSH)

•DHCP-based autoconfiguration

•SMNP (only the ENTITY-MIB and the IF-MIB)

•IP ping

•Interface features

–Speed—10 Mb/s, 100 Mb/s, and autonegotiation

–Duplex mode—Full, half, and autonegotiation

–Loopback detection

•Cisco Discovery Protocol (CDP)

•DHCP relay agent

•IPv4 and IPv6 access control lists (ACLs)

•Routing protocols

so obviously you could use it to send SNMP and use it for saving and uploading configs etc.

Jon

[mikegrous]

Gotcha. Just was seeing if there are other uses out there for this port. Too bad it isn't like the Nexus Sup cmp- mgmt ports. Now that'd be great.

[Collin Clark]

Standfast! The CMP ports are coming on some of the chassis based switches.

[mikegrous]

I want them on the 3750x. Actually i want them on every switch. 

[Collin Clark]

The firewalls desperately need them.

[kabaldwin]

I notice that in your list you do not include IOS upgrade of the 3750-X through the archive command set.

Question: Is this a supported feature?

My guess is that it is not, as the switches OOB Management Port would go off line on the switch in question due to the fact that it is not a true CMP port, and that the micro code changes on the switch during the upgrade. This would affect the EOOB port.

Could you clarify?

[gatlin007]

You bring up a really good point.  Most networking professionals understand the importance of 'out of band' management in regard to an rs-232 connection that provides the ultimate in knowing what the heck is going on during a failure situation.  If they don't they are only one disaster away from an education.

Several networking devices have an Ethernet management port.  Certainly it's not the same as our trusty console port.  Not much has been written on how to properly utilize Ethernet ports for management.  I'm sure a lot of us have our own ideas but I haven't seen an official document from Cisco.  What I usually see is 'this port should be used for management and not for forwarding network traffic.'  I Haven't seen an architecture document that depicts the utopian management network.

Lot's of good design info here:

http://www.cisco.com/en/US/netsol/ns742/networking_solutions_program_category_home.html

Perhaps a 'netowrk management' section is in order.


Chris

[Collin Clark]

Great points. Unfortunately the EOOB port is worthless in most of the products. It shares the global routing table and/or you can not put it in its own VRF. Once those pain points have been eliminated a design doc can be created and we can start to truly manage our devices over Ethernet and in a secure fashion!

[gatlin007]

Worthless seems rather strong.  I've worked with clever network engineers that have leveraged these ports well.  I doesn't take a unique routing table (VRF).  It does take a rock solid foundation in networking.


Chris

[Collin Clark]

Depends on the security policy. For the requirements of the government, the port is worthless, no matter how clever you are. I guess since I don't understand networking, all of this it moot. Thanks for straightening me out. I hope you have a solid foundation in understanding sarcasm.

[Jon Marshall]

gatlin007 wrote:
Worthless seems rather strong.  I've worked with clever network engineers that have leveraged these ports well.  I doesn't take a unique routing table (VRF).  It does take a rock solid foundation in networking.


Chris

Chris

Be interested to hear how it was done ?

Jon

[Jon Marshall]

Collin_Clark wrote:
Great points. Unfortunately the EOOB port is worthless in most of the products. It shares the global routing table and/or you can not put it in its own VRF. Once those pain points have been eliminated a design doc can be created and we can start to truly manage our devices over Ethernet and in a secure fashion!

Collin

I see what you mean here. We have actually been referring i think to 2 different things. I was thinking primarily about a network that is subjected to a virus for example and so the path from your management PC to the device could be unuseable. It was in that sense i was saying VRF's are useless.

Whereas i think you were referring to restricing access to the OOB by using a dedicated vrf wtih only restricted access.

Sorry for being a bit slow on the uptake.

Both i think are relevant considerations and need to be addressed.

Jon

[Jon Marshall]

Chris / Collin

I agree that it is an area not covered in great detail.

The key as far as i see it is you need a completely separate network and i mean completely separate from production. So the path from your PC to the OOB port never crosses any physical equipment on production. Even vrfs wouldn't help here. However something like the Nexus would where you can allocate virtual switches within the same chassis and allocate resources to each switch that are not shared. I say would help but it does depend on just what is shared and what isn't.

Trouble obviously is it gets expensive. I've done it within a DC where we had a separate ADSL link into the DC so we were not using the WAN links. But it's not a solution that generally scales without the cost becoming prohibitive.

The other alternative is to use QOS to guarantee some bandwidth but this can be hit and miss to say the least.

Jon

[Collin Clark]

At the last place I worked, we had to manage all of out network devices OOB. Even a separate WAN as no management traffic could be on the same network as the production data network. It stinks!