NFSv4でマウントするとrootがnobodyになる

NetApp ONTAP 9.7ファイルサーバを作る時にNFS v3.0/v4.0/v4.1を有効にして、CentOS7からNFSマウントしてみた。

[root@centos7 ~]# mount 172.17.44.108:/ /mnt
[root@centos7 ~]# ls -l /mnt
合計 4
drwxr-xr-x. 11 nobody nobody 4096  8月 31 16:07 testvol
[root@centos7 ~]# ls -l /mnt/testvol/
合計 36
drwxrwxrwx. 2 nobody nobody 4096  8月 31 16:07 ntfs-test1
drwxrwxrwx. 4 nobody nobody 4096  7月 17 14:08 test
drwxr-xr-x. 3 nobody nobody 4096  8月 28 15:59 test1
drwxr-xr-x. 2 nobody nobody 4096  7月 17 14:08 test2
drwxr-xr-x. 2 nobody nobody 4096  8月 28 15:16 test3
drwxr-xr-x. 2 nobody nobody 4096  8月 28 15:16 test4
drwxr-xr-x. 2 nobody nobody 4096  8月 28 15:16 test5
drwxr-xr-x. 2 nobody nobody 4096  8月 28 15:08 testtere
drwxr-xr-x. 2 nobody nobody 4096  7月 31 17:46 testvm
[root@centos7 ~]# cat /proc/mounts |grep mnt
172.17.44.108:/ /mnt nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.108 0 0
172.17.44.108:/testvol /mnt/testvol nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.108 0 0
[root@centos7 ~]#

rootユーザで作成したはずの所有者が「nobody / nobody」で表示されている。

この時、/var/log/messages には以下のログが出ていた。

Aug 31 17:13:54 centos7 kernel: FS-Cache: Loaded
Aug 31 17:13:54 centos7 kernel: FS-Cache: Netfs 'nfs' registered for caching
Aug 31 17:13:54 centos7 kernel: Key type dns_resolver registered
Aug 31 17:13:55 centos7 kernel: NFS: Registering the id_resolver key type
Aug 31 17:13:55 centos7 kernel: Key type id_resolver registered
Aug 31 17:13:55 centos7 kernel: Key type id_legacy registered
Aug 31 17:13:55 centos7 nfsidmap[1748]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'adosakana.local'
Aug 31 17:13:55 centos7 nfsidmap[1750]: nss_name_to_gid: name 'root@defaultv4iddomain.com' does not map into domain 'adosakana.local'
Aug 31 17:13:55 centos7 kernel: nfs4filelayout_init: NFSv4 File Layout Driver Registering...

関連する用語は「idmapd」

RedHat NFSv4 マウントで、すべてのファイルの所有者が nobody:nobody と誤って表示される
SUSE NFS4 mount shows all ownership as “nobody” or 4294967294
Solaris10 nfsmapid デーモン でNFS v4マウント時のいろいろについて詳細解説されている
Solaris11 nfsmapidデーモン

上記資料だとNFSサーバとして動作させる話も入っている。

CentOS7でNFSクライアントとして使う場合に気にする必要があるのは、/etc/idmapd.conf の「[General]」セクションに「Domain = NFS V4 IDドメイン」の設定を行う、ということのみ。

rpcidmapd.service / nfs-idmapd.service / nfs-idmap.service の起動状態について気にする必要は無く、ただたんに/etc/idmapd.conf を編集してからマウントすればOKだった。

ただし、試した限りでは、一度NFS v4でマウントし、nobodyとして認識されてしまうとキャッシュか何かが残っているようで、OS再起動する必要があった。

Linuxの場合、nfsidmapコマンドを実行すると現状認識しているドメイン名の確認ができ、また、キャッシュの削除を行うことができた。

現状のNFS v4デフォルトドメイン確認が「nfsidmap -d」で、キャシュクリアが「nfsidmap -c」となる。

# nfsidmap -d
adosakana.local
# nfsidmap -c
#

今回は、NetAppのデフォルトNFS V4 IDドメイン「defaultv4iddomain.com」を使用しているので、/etc/idmapd.conf には「Domain = defaultv4iddomain.com」と設定した

この状態でマウントしてみると下記の様になり、期待通りにrootユーザが認識された。

[root@centos7 ~]# mount 172.17.44.108:/ /mnt
[root@centos7 ~]# ls -l /mnt/
合計 4
drwxr-xr-x. 11 root root 4096  8月 31 16:07 testvol
[root@centos7 ~]# ls -l /mnt/testvol/
合計 36
drwxrwxrwx. 2 root root 4096  8月 31 16:07 ntfs-test1
drwxrwxrwx. 4 root root 4096  7月 17 14:08 test
drwxr-xr-x. 3 root root 4096  8月 28 15:59 test1
drwxr-xr-x. 2 root root 4096  7月 17 14:08 test2
drwxr-xr-x. 2 root root 4096  8月 28 15:16 test3
drwxr-xr-x. 2 root root 4096  8月 28 15:16 test4
drwxr-xr-x. 2 root root 4096  8月 28 15:16 test5
drwxr-xr-x. 2 root root 4096  8月 28 15:08 testtere
drwxr-xr-x. 2 root root 4096  7月 31 17:46 testvm
[root@centos7 ~]# tail /var/log/messages
Aug 31 17:19:06 centos7 systemd: Created slice User Slice of root.
Aug 31 17:19:06 centos7 systemd-logind: New session 1 of user root.
Aug 31 17:19:06 centos7 systemd: Started Session 1 of user root.
Aug 31 17:19:12 centos7 kernel: FS-Cache: Loaded
Aug 31 17:19:12 centos7 kernel: FS-Cache: Netfs 'nfs' registered for caching
Aug 31 17:19:12 centos7 kernel: Key type dns_resolver registered
Aug 31 17:19:12 centos7 kernel: NFS: Registering the id_resolver key type
Aug 31 17:19:12 centos7 kernel: Key type id_resolver registered
Aug 31 17:19:12 centos7 kernel: Key type id_legacy registered
Aug 31 17:19:12 centos7 kernel: nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[root@centos7 ~]#
[root@centos7 ~]# cat /proc/mounts |grep mnt
172.17.44.108:/ /mnt nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.108 0 0
172.17.44.108:/testvol /mnt/testvol nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.108 0 0
[root@centos7 ~]#

lsで該当領域を見た後、キャッシュが残っている間であれば「nfsidmap -l」(小文字L」を実行すると、その時点で使ったユーザ名認識を表示してくれる。

# nfsidmap -l
2 .id_resolver keys found:
  uid:root@adosakana.local
  gid:root@adosakana.local
#

CentOS5をNFSクライアントとしてマウントしてみたところ、CentOS5は「mount -t nfs4 ~」でマウントする必要があること、nfsidmapコマンドは存在しないことがわかりました。


CentOS7環境で、一般ユーザがNFS v3で書くとちゃんとNFSv4側でもユーザが認識されるけど、NFS v4で書くと認識されない、という現象が発生して悩んだ。

# grep /mnt /proc/mounts
172.17.44.82:/sharevol /mnt nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=null,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.82 0 0
172.17.44.82:/sharevol /mnt2 nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.17.44.82,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=172.17.44.82 0 0
#

いろいろためした結果、上記の/proc/mounts から失敗が読み取れることが分かった。

NFS v4マウント側で「sec=null」となっている!

CentOS7でマウントオプション指定無しでマウントするとこの設定だった。

このため、「-o sec=sys」オプションを指定してマウントしたところ、期待通りに動作になった。

# mount -o sec=sys 172.17.44.82:/sharevol /mnt
# grep /mnt /proc/mounts
172.17.44.82:/sharevol /mnt2 nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.17.44.82,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=172.17.44.82 0 0
172.17.44.82:/sharevol /mnt nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.17.44.103,local_lock=none,addr=172.17.44.82 0 0
#

標準設定でのマウントには注意が必要なようです


Solaris 11クライアントで確認する場合の例

「sharectl get nfs」か「sharectl get -p nfsmapid_domain nfs」でドメイン名を確認できる。

また、「/system/volatile/nfs4_domain」の値にも設定される(NFS Version 4 のドメインを確認する)

(Solaris 11.4側をNFSサーバにしてみた環境だと、”nfsmapid_domain=”は値設定なしだが、/system/volatile/nfs4_domain には値が入っている、という例があった。)

マウント状況は「nfsstat -m」で確認

root@solaris11:~# sharectl get nfs
servers=1024
lockd_listen_backlog=32
lockd_servers=1024
lockd_retransmit_timeout=5
grace_period=90
server_versmin=2
server_versmax=4
client_versmin=2
client_versmax=4
server_delegation=on
nfsmapid_domain=defaultv4iddomain.com
max_connections=-1
protocol=ALL
listen_backlog=32
device=
showmount_info=full
server_authz_cache_refresh=600
netgroup_refresh=600
resvport=false
root@solaris11:~# sharectl get -p nfsmapid_domain nfs
nfsmapid_domain=defaultv4iddomain.com
root@solaris11:~# cat /system/volatile/nfs4_domain
defaultv4iddomain.com
root@solaris11:~# nfsstat -m
/mnt from 172.17.44.226:/
 Flags:         vers=4,proto=tcp,sec=sys,hard,intr,link,symlink,rsize=65536,wsize=65536,retrans=5,timeo=600
 Attr cache:    acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

root@solaris11:~#

HuaweiのCentOS派生 Euler OSとopenEuler

Huaweiの作ったIoT向けOS LiteOS (github)、Android代替OSのHarmonyOS(鴻蒙OS)について調べていたらHuaweiがx86_64/ARMサーバ向けにEuler OSというのを出していることを知った。

公式: EulerOS

EulerOS Introductionによれば「ARM64完全対応」「セキュリティ強化」「キャリアで採用されるレベルの安定性」「Linuxコンテナ推し」らしい

DownloadリンクHuawei Mirrorsリンクを見るとインストール用ISOが入手可能となっている。

で、このEuler OSのベースは何かな、と調べて見るとopenEulerが出てくる。ちゃんとHuaweiが日本での商標を確保しているようだ。

openEuler自体はCentOSをベースとしており、このopenEulerからさらに派生しているOSがあると

中国科学院软件研究所 EulixOS
まだ生きていた TurboLinux
普华软件 isoft-linux
HopeEDGE

さて、openEule自体は3月から、2年ごとのLTSバージョンと半年リリースバージョンの2種類で出るようになったらしい(openEuler community release rule and life cycle management)

いま出ているopenEuler 20.03 LTSは長期サポートバージョンということになる。

このバージョンはCentOS8をベースとしているが、CentOS8 20.04よりパッケージバージョンがちょっと古い、という構成になっていた。

そして、CentOS8と比べるとパッケージがいくつか存在していなかったりした。例えば、open-vm-toolsとかが入っていない。

デスクトップ系の利用は考慮されていないようで、パッケージグループのインストールを行おうとすると、パッケージがない、というエラーになるものが結構ある。(パッケージリストの精査が行われておらず、CentOSにはあるがopenEulerには存在しないパッケージを指定している)

インストールしてみよう

openEuler 20.03 LTSのISOで仮想マシンを起動してみる
(セキュアブート非対応な点に注意)

画像

CentOS8の時とほぼ同じ感じです

画像

言語選択が「English」と「中文」しかない、というのが大きな違いですかね

画像

2021/04/19追記: openEuler 20.03-LTS-SP1ではRHEL8/CentOS8のパスワード設定とユーザ作成画面統合が反映されていました

ソフトウェアの選択も大きく違いますね。

標準選択が「Minimal Install」となっていて、「Server」と「Virtualization Host」が選べるという形です。(ただ、インストール後、dnf groups install Serverを実行するとエラーになるという…)

CentOS8だと簡単なパスワードでも設定できたのですが、openEulerだと断固として拒否してきました。

起動するとkernel 4.19.90-2003.4.0.0036.oe1で動作していました。(2021/04/19追記 20.03LTS SP1では 4.19.90-2012.5.0.0054.oe1 でした)

また、驚くべき事に、何もレポジトリが登録されておらず、アップデートも何もできない状態だという…(2021/04/19追記 20.03LTS SP1ではちゃんとアップデートできました)

画像

openEulerのマニュアル「Using the DNF to Manage Software Packages」に/etc/yum.repos.d/openEuler_aarch64.repo のサンプルがあったのでそれをマネしてx86_64用に書いてみる。「Installing the OS Release Package」にupdateレポジトリも載っていたので下記の様に書いてみた。

[root@openeuler ~]# cat /etc/yum.repos.d/openEuler_x86_64.repo
#Copyright (c) [2019] Huawei Technologies Co., Ltd.
#generic-repos is licensed under the Mulan PSL v1.
#You can use this software according to the terms and conditions of the Mulan PSL v1.
#You may obtain a copy of Mulan PSL v1 at:
#    http://license.coscl.org.cn/MulanPSL
#THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR
#IMPLIED, INCLUDING BUT NOT LIMITED TO NON-INFRINGEMENT, MERCHANTABILITY OR FIT FOR A PARTICULAR
#PURPOSE.
#See the Mulan PSL v1 for more details.
[osrepo]
name=osrepo
baseurl=https://repo.openeuler.org/openEuler-20.03-LTS/OS/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://repo.openeuler.org/openEuler-20.03-LTS/OS/x86_64/RPM-GPG-KEY-openEuler

[update]
name=update
baseurl=https://repo.openeuler.org/openEuler-20.03-LTS/update/x86_64/
enabled=1
gpgcheck=0
[EPOL]
name=EPOL
baseurl=https://repo.openeuler.org/openEuler-20.03-LTS/EPOL/x86_64/
enabled=1
gpgcheck=0
[root@openeuler ~]#

これを設定することで「yum update -y」でパッケージアップデートが完了した。

なお、アップデート後はレポジトリファイルがちゃんと設定されて、以下のようになった。

[root@openeuler ~]# cat /etc/yum.repos.d/openEuler.repo
#generic-repos is licensed under the Mulan PSL v2.
#You can use this software according to the terms and conditions of the Mulan PSL v2.
#You may obtain a copy of Mulan PSL v2 at:
#    http://license.coscl.org.cn/MulanPSL2
#THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR
#IMPLIED, INCLUDING BUT NOT LIMITED TO NON-INFRINGEMENT, MERCHANTABILITY OR FIT FOR A PARTICULAR
#PURPOSE.
#See the Mulan PSL v2 for more details.

[OS]
name=OS
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/OS/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/OS/$basearch/RPM-GPG-KEY-openEuler

[everything]
name=everything
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/everything/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/everything/$basearch/RPM-GPG-KEY-openEuler

[EPOL]
name=EPOL
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/EPOL/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/OS/$basearch/RPM-GPG-KEY-openEuler

[debuginfo]
name=debuginfo
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/debuginfo/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/debuginfo/$basearch/RPM-GPG-KEY-openEuler

[source]
name=source
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/source/
enabled=1
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/source/RPM-GPG-KEY-openEuler

[update]
name=update
baseurl=http://repo.openeuler.org/openEuler-20.03-LTS/update/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://repo.openeuler.org/openEuler-20.03-LTS/OS/$basearch/RPM-GPG-KEY-openEuler
[root@openeuler ~]#

上記のレポジトリファイル、注意が必要な点として「updateレポジトリが有効になっていない」というものがある。(2021/04/19追記 20.03LTS SP1でもupdateレポジトリは有効になっていません)

「dnf config-manager –enable update」を実行して有効にする必要がある。

[root@openeuler ~]# dnf repolist --all
repo id                             repo name                           status
EPOL                                EPOL                                enabled
OS                                  OS                                  enabled
debuginfo                           debuginfo                           enabled
everything                          everything                          enabled
source                              source                              enabled
update                              update                              disabled
[root@openeuler ~]# dnf config-manager --enable update
[root@openeuler ~]# dnf repolist --all
repo id                             repo name                            status
EPOL                                EPOL                                 enabled
OS                                  OS                                   enabled
debuginfo                           debuginfo                            enabled
everything                          everything                           enabled
source                              source                               enabled
update                              update                               enabled
[root@openeuler ~]#

よく分からないのが「dnf group list」で表示されるグループを指定してインストールするとエラーになるという事象..(2021/04/19追記 20.03LTS SP1ではこの現象は解消していました)

画像

インストール時に「Server」を選択していた場合はちゃんとインストールできている。

どちらもレポジトリファイル自体は同じなのでよく分からない…それどころか、Serverでインストールされている環境で「dnf group install Server」を実行しても、同じパッケージが無い、と言われ、またインストールもされていない。という状態

現状、Minimal Install以外の選択肢は正常に動作していない恐れが…

とりあえず、ひとしきり見てみた感じではCentOS8でパッケージ構成がちょっと違うバージョンという雰囲気だった。

デスクトップ(X-Window)の利用はあまり考えられていないようで、パッケージがぼろぼろと足らないので注意。

また、vSphere環境用のopen-vm-toolsも用意されていない。

Euler OS 2.0 SP5の場合

ソフトウェアの選択肢が異なっており、「Base System」「Developer Mode」「Cloud Server」「Server with GUI」となっていた。標準選択はBase System

パスワードの複雑性要求はopenEuler 20.03LTSと同じレベルでした。

再起動するとkernel 3.10.0-862.14.1.0.h209.eulerosv2r7で起動してきた。レポジトリの登録は無し

Euler OS公式のMirror Listを見ていくと「/mirrors_os2/euler/2.5/os/x86_64/」というのがあり、そこにはupdatesディレクトリとアップデートされたらしきパッケージもあるので、ここをレポジトリとして指定してみる。

# cat /etc/yum.repos.d/euleros.repo
[OS]
name=OS
baseurl=https://mirrors.huaweicloud.com/euler/2.5/os/$basearch/
enabled=1
gpgcheck=0

updateレポジトリ相当の内容は上記レポジトリに含まれている模様。

アップデート後のkernelは3.10.0-862.14.1.5.h442.eulerosv2r7 になった。

なお、何故かEuler OS 2.0 SP5の初期状態ではsshからのrootユーザログインが”パスワードが違う”というエラーでログインできなかった。アップデート後は正常にsshログインが可能となった。

[root@euleros ~]# df
Filesystem               1K-blocks    Used Available Use% Mounted on
/dev/mapper/euleros-root  36357632 1492596  32988456   5% /
devtmpfs                   3983580       0   3983580   0% /dev
tmpfs                      3996440       0   3996440   0% /dev/shm
tmpfs                      3996440    9048   3987392   1% /run
tmpfs                      3996440       0   3996440   0% /sys/fs/cgroup
/dev/sda2                   999320  157676    772832  17% /boot
/dev/sda1                   204580    8596    195984   5% /boot/efi
/dev/mapper/euleros-home  17745188   45080  16775644   1% /home
tmpfs                       799288       0    799288   0% /run/user/0
[root@euleros ~]# uname -a
Linux euleros 3.10.0-862.14.1.5.h442.eulerosv2r7.x86_64 #1 SMP Fri May 15 22:01:58 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@euleros ~]# yum grouplist
Loaded plugins: fastestmirror
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
Loading mirror speeds from cached hostfile
Available Environment Groups:
   Base System
   Developer Mode
   Cloud Server
   Server with GUI
Available Groups:
   Compatibility Libraries
   Development Tools
   Security Tools
   Smart Card Support
Done
[root@euleros ~]#

とりあえず「yum groupinstall “Server with GUI”」でパッケージを追加して再起動。

「1」を選んで

「2」を選んで

「c」と「c」で進めると普通のログイン画面に到達

rootでログインしたあと「init 5」して起動する画面はCentOSと変わりは無い

ログイン完了すると、EulerOSの壁紙デスクトップに到着。

「systemctl set-default graphical.target」でログイン画面自体をGUIにした場合は下記の様になる。

また、EulerOS2.0だとopen-vm-toolsがあった。

HPE 5700 スイッチのコマンド

以前にHPE5700スイッチの設定をした際、「HPE 5700 スイッチの日付設定」という記事を書いた。

今回はもっといくつか設定が必要になったので、いろいろメモ書きとして残しておく。

参考にしたもの
HPEスイッチ(旧H3C)シリーズ 設定別コマンド早見表
HPEスイッチ 基本コマンド&初期設定例 ~VLAN/リンクアグリゲーション(LACP), ssh, snmp, ntp, syslog等の管理設定,debug~

2022/04/14追記
HPE 5940スイッチの設定をする際に探したら HPE japanの純正ドキュメント「HPE FLEXFABRIC & FLEXNETWORK スイッチ基本操作ガイド V1.1」を発見した
普通使う設定の範囲は概ね含んでいるので、まずはコレを読むと良い。(2023/03/29に確認したらv1.1からv1.3にアップデートしていた)

上記の配布元URLは「[Switch] HPE FlexFabric / FlexNetwork スイッチ基本操作ガイド」で、他に「Aruba CXスイッチ基本操作ガイド」と「ArubaOSスイッチ基本操作ガイド」があった。(2023/03/29時点では ARUBA CX スイッチ 基本操作ガイド V3.0とARUBA OS スイッチ 基本操作ガイド V1.6)

基本

・特権モードに入る

「system」「system-view」(“sys”でもOK)

・設定の確認

現在の設定確認「display current-configuration」
保存されている設定確認「display saved-configuration」

なお、「display」はCisco風に「show」でも動く

・設定確認とかの際に「More」を表示させない

「screen-length disable」を非特権モードで実行する。

・設定したものを保存

「save」

・設定を入れたものを消すとき

「undo 各コマンド」(Ciscoの”no 各コマンド”に相当)

ポートの状態確認

「display interface brief」

「display link-aggregation summary」
「display link-aggregation port」
「display link-aggregation member-port」

スイッチの個体設定

・スイッチのホスト名設定

「sysname ホスト名」

・現在時刻表示

「show clock」

・タイムゾーン設定

「clock timezone Tokyo add 09:00:00」

・手動で時刻を設定する場合

まず特権モードで「clock protocol none」
次に非特権モードで「clock datetime 21:09:00 2020/07/26」

・NTP設定をする場合

「clock protocol ntp」でNTPプロトコルを指定したあと
「ntp-service unicast-server xxx.xxx.xx.xx」

NTPサーバが複数ある場合は、サーバ毎に「ntp-service unicast-server ~」を実行する。

また、NTP通信に使用するインタフェースを指定する場合は「ntp-service source M-GigabitEthernet 0/0/0」とか「ntp-service source Vlan-interface1」という形で指定する

NTPの動作状況は「show ntp-service sessions」と「show ntp-service status」

・管理用IPアドレス

HPE5710背面にある管理用(MGMT)インタフェース(MGE0/0/0)に管理用IPアドレスを割り当てる場合

interface M-GigabitEthernet0/0/0
ip address 172.17.44.227 255.255.0.0
no dhcp client identifier
<interface Vlanから抜けたあと>
ip route-static 0.0.0.0 0.0.0.0 172.17.0.1

Vlan-interface1に管理用IPアドレスを割り当てる場合

interface Vlan-interface1
ip address 172.17.44.1 255.255.0.0
<interface Vlanから抜けたあと>
ip route-static 0.0.0.0 0.0.0.0 172.17.0.1

・管理用ユーザ作成

「admin」というユーザをパスワード「password」で作成する場合

local-user admin
password simple password
authorization-attribute user-role network-admin
service-type ssh https

作成したローカルユーザの確認「display local-user」

・リモートログインへの権限割り当て

vtyの0~4にsshでログインする権限を与える。
なお、下記はuser-roleとしてnetwork-adminとnetwork-operatorの2つが書かれているが実際は「user-role network-admin」を追加するだけで、自動的にnetwork-operatorも追加された。

line vty 0 4
authentication-mode scheme
user-role network-admin
user-role network-operator
protocol inbound ssh
idle-timeout 30 5

・リモートログインの許可

ssh有効設定「ssh server enable」
状態確認「display ssh server status」

・Web管理画面有効化

httpsを有効にする場合「ip https enable」
現在の設定状況確認「display ip https」

VLAN関連

「display vlan brief」

Link-aggregation設定

Link-aggregation/Trunk/トランク/LACP/IEE 802.3ad設定について

VMware KB「ESXi/ESX および Cisco/HP スイッチによる EtherChannel/リンク集約コントロール プロトコル (LACP) のサンプル構成 (1004048)

ジャンボフレーム関連

layer-2向け設定とlayer-3向け設定がある模様

interfaceの下で「mtu 9000」と設定するか、「jumboframe enable」と設定するか?

jumboframeの方はlayer-2/layer-3の両方で記載があったが、mtuの方はlayer-3のみ記載があった

jumboframe enableにすると10000のジャンボフレームが使えるようになる。「jumboframe enable 数値」でも可でその場合は1536~10000が指定できる

mtuの場合は「mtu 数値」で指定する。数値は128~9008