Oh the joy of finding a completely new command line syntax...
I've used HP switches a good deal in the past, all manner of Procurve models, mostly modular ones as they were an inexpensive rack solution when dual power supplies were a requirement. These days top of rack switching is so normal every vendor makes 1U datacenter switches with dual power, and when someone asked me for a recommendation I surfed a little bit and suggested HP 5900 as a cost effective option for 48 gigabit ports and 12 ten gigabit ones. Little did I know they'd ask for my help configuring them - they are certainly very powerful, but it took me long enough to figure out how to enable SSH and basic layer 2 stuff and more features are being added to the Comware OS every few months it seems, including hardware VXLAN VTEP by the looks of it, though when/whether they will get that certified/supported is anyones guess.
On a Procurve I'd enable SSH with:
ip ssh
ip ssh filetransfer
no telnet-server
With the only caveat being that on the old switches I have in my home lab creating a self signed cert / RSA keys on the command line doesn't work, though it does in the GUI.
Back to the Comware based switch:
It expects you to have an enterprise RADIUS system to authenticate against and it took a lot of figuring out to create a self contained config.
system-view
public key local create rsa
ssh server enable
sftp server enable
ssh user simon service-type all authentication-type password
user-interface vty 0 15
authentication-mode scheme
protocol inbound ssh
There's a free ebook available from HP that may be helpful too,
https://h30590.www3.hp.com/product/HP+Networking+and+Cisco+CLI+Reference+Guide+-+Version+2-PDF-8407
now updated for version 7 of Comware.
The usual necessities:
dns domain sjhwilkes.local
dns server 10.206.3.5
dns server 10.206.3.17
ntp-service enable
ntp-service unicast-server 10.206.3.1
It took me ages to stop typing show and use display instead, and likewise no becomes undo in order to remove lines from the config.
On my (ESXi) host facing ports I have:
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 10 to 11 15 101 to 102 150 254
Which hardcodes them to be dot1q trunks with a selection of VLANs permitted and VLAN 1 native (though I don't actually use it for anything, force of habit as it was a security recommendation many moons (years) ago)
I'm not doing LACP to my hosts, the amount of messing I do with difference versions of NSX and vSphere it's easier to stick with failover/manual.
I experimented with LACP to my old NetApp 2020, which looked like:
interface Bridge-Aggregation10
description laxnas01
port link-type trunk
port trunk permit vlan 1 15
link-aggregation mode dynamic
lacp edge-port
Then on the constituent ports:
port link-mode bridge
description laxnas01-e0a
port link-type trunk
port trunk permit vlan 1 15
port link-aggregation group 10
I'd still like to figure out if I can put the management interface into it's own VRF and have some sort of back door into the rack - difficult without springing for another circuit of some kind though.
I've used HP switches a good deal in the past, all manner of Procurve models, mostly modular ones as they were an inexpensive rack solution when dual power supplies were a requirement. These days top of rack switching is so normal every vendor makes 1U datacenter switches with dual power, and when someone asked me for a recommendation I surfed a little bit and suggested HP 5900 as a cost effective option for 48 gigabit ports and 12 ten gigabit ones. Little did I know they'd ask for my help configuring them - they are certainly very powerful, but it took me long enough to figure out how to enable SSH and basic layer 2 stuff and more features are being added to the Comware OS every few months it seems, including hardware VXLAN VTEP by the looks of it, though when/whether they will get that certified/supported is anyones guess.
On a Procurve I'd enable SSH with:
ip ssh
ip ssh filetransfer
no telnet-server
With the only caveat being that on the old switches I have in my home lab creating a self signed cert / RSA keys on the command line doesn't work, though it does in the GUI.
Back to the Comware based switch:
It expects you to have an enterprise RADIUS system to authenticate against and it took a lot of figuring out to create a self contained config.
system-view
public key local create rsa
ssh server enable
sftp server enable
ssh user simon service-type all authentication-type password
user-interface vty 0 15
authentication-mode scheme
protocol inbound ssh
There's a free ebook available from HP that may be helpful too,
https://h30590.www3.hp.com/product/HP+Networking+and+Cisco+CLI+Reference+Guide+-+Version+2-PDF-8407
now updated for version 7 of Comware.
The usual necessities:
dns domain sjhwilkes.local
dns server 10.206.3.5
dns server 10.206.3.17
ntp-service enable
ntp-service unicast-server 10.206.3.1
It took me ages to stop typing show and use display instead, and likewise no becomes undo in order to remove lines from the config.
On my (ESXi) host facing ports I have:
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 10 to 11 15 101 to 102 150 254
Which hardcodes them to be dot1q trunks with a selection of VLANs permitted and VLAN 1 native (though I don't actually use it for anything, force of habit as it was a security recommendation many moons (years) ago)
I'm not doing LACP to my hosts, the amount of messing I do with difference versions of NSX and vSphere it's easier to stick with failover/manual.
I experimented with LACP to my old NetApp 2020, which looked like:
interface Bridge-Aggregation10
description laxnas01
port link-type trunk
port trunk permit vlan 1 15
link-aggregation mode dynamic
lacp edge-port
Then on the constituent ports:
port link-mode bridge
description laxnas01-e0a
port link-type trunk
port trunk permit vlan 1 15
port link-aggregation group 10
I'd still like to figure out if I can put the management interface into it's own VRF and have some sort of back door into the rack - difficult without springing for another circuit of some kind though.
To silence log messages about non-H3C transceivers (which work anyway):
transceiver phony-alarm-disable
No comments:
Post a Comment