Ansible開発環境のセットアップ

はじめに

Ansibleで構成管理を変更する際には事前に動作確認をします。実際に運用されている環境に合わせて検証するために、手元の環境を運用環境に合わせます。PythonやAnsibleのバージョンで異なる組み合わせを用意する場合、venvではなくpyenv1を利用します。また、pyenv-virtualenv2プラグインで特定のPythonバージョンを元にAnsible実行環境を用意します。
今回は、Ansibleの開発環境を用意するために自分のメモ用として残しつつ、他の方にもためになるようならば嬉しい限りです。

環境構築

pyenvのインストール

早速、pyenvをインストールしていきます。
手順は、GitHubのREADME3に記載されていますので、そちらも確認してみてください。

$ cd $HOME
$ curl -fsSL https://pyenv.run | bash

pyenv用にシェル環境を設定します。
一部のシステムでは手順が異なるようですので、ご注意ください。

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
$ echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(pyenv init - bash)"' >> ~/.bashrc

シェルの再起動をします。

$ exec "$SHELL"

pyenvのwiki4を参照し、Pythonのビルド依存関係をインストールします。
Python3.14 以降では、"libzstd-dev"もインストールする必要があるそうです。

$ sudo apt update; sudo apt install make build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev curl git \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

インストールしたpyenvのバージョンを確認をします。

$ pyenv --version
pyenv 2.6.12

pyenvの動作確認

実際に、pyenvがどのように動くのかを見てみます。
以下のコマンドでpyenvにインストール可能なリストを表示します。出力結果が多いため一部省略しています。

$ pyenv install --list
  3.11.12
  3.11.13  #<--インストール対象
  3.11.14
  3.12.10
  3.12.11
  3.12.12  #<--インストール対象

例として、Python 3.11.13Python 3.12.12をインストールします。手元の環境に合わせて必要なパッケージをインストールしてください。

$ pyenv install 3.11.13
Downloading Python-3.11.13.tar.xz...
-> https://www.python.org/ftp/python/3.11.13/Python-3.11.13.tar.xz
Installing Python-3.11.13...
Installed Python-3.11.13 to /home/username/.pyenv/versions/3.11.13

$ pyenv install 3.12.12
Downloading Python-3.12.12.tar.xz...
-> https://www.python.org/ftp/python/3.12.12/Python-3.12.12.tar.xz
Installing Python-3.12.12...
Installed Python-3.12.12 to /home/username/.pyenv/versions/3.12.12

作業フォルダを作成します。
フォルダ名は任意で大丈夫です。

$ cd $HOME
$ mkdir pyenv-test

準備ができましたので、pyenvでPythonのバージョンがどのように変化するかを確認していきます。
まずは、グローバルのPythonバージョンを確認します。特に指定をしなければ、グローバルのバージョンが適用されることになります。 環境によってはPythonのバージョンが異なるかもしれませんが、以下の出力と異なる場合であっても問題ありません。

$ cd $HOME
$ python3 --version
Python 3.10.12

次は先ほどインストールしたPython 3.11.13に切り替えてみます。バージョンを切り替える際は、作業ディレクトリに移動してから実施します。

$ cd pyenv-test
$ pyenv local 3.11.13
$ python3 --version
Python 3.11.13

では、作業ディレクトリはそのままに、次はPython 3.12.12に切り替えてみます。

$ pyenv local 3.12.12
$ python3 --version
Python 3.12.12

pyenv-virtualenvでAnsible用環境を用意

Pythonのバージョンの切替が確認できたところで、次は特定のPythonのバージョンでAnsible専用環境を用意します。今回は、Python 3.11.13ansible [core 2.17.6]で環境を作成します。必要なコレクションがあればそちらもインストールしてください。リモートリポジトリにプロジェクトが存在する場合は、クローンすることで作業準備完了となります。

$ cd $HOME
### コマンドは、「pyenv virtualenv <インストールしたPythonのバージョン> <任意の名前>」で実行
$ pyenv virtualenv 3.11.13 ansible_pj_env_3-11
$ pyenv versions
* system (set by /home/username/.pyenv/version)
  3.11.13
  3.11.13/envs/ansible_pj_env_3-11
  3.12.12
  ansible_pj_env_3-11 --> /home/username/.pyenv/versions/3.11.13/envs/ansible_pj_env_3-11

$ cd pyenv-test
$ pyenv local ansible_pj_env_3-11
$ python3 --version
Python 3.11.13

$ python -m pip install --upgrade pip
$ pip install ansible-core==2.17.6
$ ansible --version
ansible [core 2.17.6]
  config file = None
  configured module search path = ['/home/username/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/username/.pyenv/versions/3.11.13/envs/ansible_pj_env_3-11/lib/python3.11/site-packages/ansible
  ansible collection location = /home/username/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/username/.pyenv/versions/ansible_pj_env_3-11/bin/ansible
  python version = 3.11.13 (main, Nov  1 2025, 18:59:08) [GCC 11.4.0] (/home/username/.pyenv/versions/3.11.13/envs/ansible_pj_env_3-11/bin/python)
  jinja version = 3.1.6
  libyaml = True

### 必要なコレクションをインストール
### git clone でブランチをダウンロード

ansible-core をインストールした環境(ansible_pj_env_3-11)からpyenv local --unsetで抜けてから、別環境に切り替えます。 すると、ansible-core がインストールされていない環境になったので、ansibleコマンドが見つかりませんと表示されました。ansible_pj_env_3-11にはansibleコマンドが存在することも記載されてますね。
このように、環境を汚さずに、バージョンによって環境を簡単に切替られるのはとても便利ですね。

$ pyenv local --unset
$ python3 --version
Python 3.10.12

$ pyenv local 3.12.12
$ python3 --version
Python 3.12.12
$ ansible --version
pyenv: ansible: command not found

The `ansible' command exists in these Python versions:
  3.11.13/envs/ansible_pj_env_3-11
  ansible_pj_env_3-11

Note: See 'pyenv help global' for tips on allowing both
      python2 and python3 to be found.

Proxmox-VE を bonding(Active-Backup)でネットワークの冗長化

はじめに

 前回の記事 では、Bonding(LACP)を試してみましたが、LACP対応スイッチが用意できない場合もあります。そのような場合について、Docsには以下のような記載があります。雑に訳すと、「LACP対応スイッチがないなら、Active-Backupを使用してな」ということ。今回は、LACPとは異なるActive-Backupを試してみようと思います。

If your switch supports the LACP (IEEE 802.3ad) protocol, then we recommend using the corresponding bonding mode (802.3ad). Otherwise you should generally use the active-backup mode.
引用元:Linux Bond1

LACPとActive-Backupの違いについて、比較は以下の通りになります。

比較項目 LACP Active-Backup
利用目的 負荷分散と冗長化 冗長化
LACP対応スイッチ 必要 不要
スイッチの設定 必要 不要
帯域 束ねたリンクの合計 単一リンク分

検証環境

Proxmox-VE 8.3(以降、Proxmox と記載) とLACP未対応スイッチを使用しており、相互を2本のLANケーブルで接続しています。
注意点として、今回記載した内容はリモートでの作業を想定していないので、実施の際は作業順序やコンソール接続可能な状態にしておくことを忘れないように。手順や順序を誤るとどこからも接続できなくなります。

設定(Proxmox)

/etc/network/interfaces を以下のように編集していきます。以下は例ですので、NICIPアドレスは環境に合わせて書き換えてください。

iface eno1 inet manual
iface eno2 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2 ### bondingとして扱う物理NIC
        bond-miimon 100 ### bondingのリンク状態を監視する間隔(ms)
        bond-mode active-backup ### active-backupとして動作

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.100/24 ### bridgeに割り当てるIPアドレス(ホストにアクセスするIPアドレス)
        gateway 192.168.1.254
        bridge-ports bond0 ### bridgeと紐づけるインターフェース
        bridge-stp off
        bridge-fd 0

状態確認(正常時)

すべてのインターフェースがUPしており、「/proc/net/bonding/bond0」の出力内容はLACPと少し異なり、比較的シンプルな内容で、これは面白い気づきになりました。

# ip link show eno1
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff
    altname enp5s0f0
# ip link show eno2
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:a9
    altname enp5s0f1

# ip link show bond0
9: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff

# ip link show vmbr0
10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: fault-tolerance (active-backup)   ###active-backupで動作
Primary Slave: None
Currently Active Slave: eno1  ###現在Activeなリンク
MII Status: up
MII Polling Interval (ms): 100 ###リンクの監視間隔
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Slave Interface: eno1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:a8
Slave queue ID: 0

Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:a9
Slave queue ID: 0

状態確認(異常時)

今回もケーブルを実際に抜線してどのように状態が変化するのかを見てます。事前の状態を見て、"eno1"がActiveなので、ここは"eno1"を抜線してみます。

# ip link show eno1
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff
    altname enp5s0f0
# ip link show eno2
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:a9
    altname enp5s0f1

# ip link show bond0
9: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff

# ip link show vmbr0
10: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:a8 brd ff:ff:ff:ff:ff:ff

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eno2 ###Activeなリンクが切り替わった(eno1→eno2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Slave Interface: eno1
MII Status: down ###Statusがdownに変化
Speed: Unknown ###状態がUnknownになった
Duplex: Unknown ###状態がUnknownになった
Link Failure Count: 1 ###カウントが上がった
Permanent HW addr: aa:aa:aa:aa:aa:a8
Slave queue ID: 0

Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:a9
Slave queue ID: 0

動作確認(断時間の計測)

前回同様、pingを打ち続けてケーブルを抜線した際の断時間を計ります。抜線するケーブルはbond内のActiveな状態の方を抜線します。
結果は、やはり1秒以内で疎通が復旧しているので、今回もデフォルトで問題ないかもしれません。気になるのは、LACPで計測した時より、断時間が0.2秒ほど短い点です。スイッチ側との兼ね合いもあっての断時間なのかもしれません。内容はともあれ、良い気づきになりました。

・0.1秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.100 ping statistics ---
500 packets transmitted, 497 received, 0.6% packet loss, time 51905ms
rtt min/avg/max/mdev = 0.185/0.468/0.506/0.039 ms

・0.01秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.100 ping statistics ---
500 packets transmitted, 475 received, 5% packet loss, time 8009ms
rtt min/avg/max/mdev = 0.177/0.460/0.493/0.037 ms

Proxmox-VE を LACP + bonding でネットワークの冗長化

はじめに

巷で話題のProxmox-VEと呼ばれる仮想化プラットフォームを用意する際に、手元で用意してすぐに壊すのであれば、ネットワーク冗長化は不要ですが、直近で壊す予定がない場合は、ネットワーク冗長化はしておいて損はないと考えています。今回は、LACP (IEEE 802.3ad) を用いたbondingによる冗長化について記載していきます。

検証環境

Proxmox-VE 8.3(以降、Proxmox と記載) と Cisco Catalyst Switch(以降、Switch と記載) を使用しており、相互を2本のLANケーブルで接続しています。
注意点として、今回記載した内容はリモートでの作業を想定していないので、実施の際は作業順序やコンソール接続可能な状態にしておくことを忘れないように。手順や順序を誤るとどこからも接続できなくなります。

画像1.1.構成

冗長設定

それぞれ、ProxmoxとSwitchでの設定について記載します。

Proxmox

package

事前準備として、"ifupdown2"がインストールされていることを確認します。7.0以降ではデフォルトでインストールされているそうです。
"ifupdown2"をインストールすることで、GUIからネットワークの設定を反映する際に、再起動が不要になります。

With the recommended ifupdown2 package (default for new installations since Proxmox VE 7.0), it is possible to apply network configuration changes without a reboot.
If you change the network configuration via the GUI, you can click the Apply Configuration button. This will move changes from the staging interfaces.new file to /etc/network/interfaces and apply them live.
引用元:Live-Reload Network with ifupdown21

> apt list --installed | grep ifupdown2
ifupdown2/now 3.2.0-1+pmx11 all [installed,local]

configure

以下のようにProxmoxでbondingを利用する際、SwitchでLACP (IEEE 802.3ad) をサポートしている場合はこれを使用することを推奨しているため、LACP (IEEE 802.3ad) を使用します。またサポートしていない場合には、active-backupを使用しましょう。

If your switch supports the LACP (IEEE 802.3ad) protocol, then we recommend using the corresponding bonding mode (802.3ad). Otherwise you should generally use the active-backup mode.
引用元:Linux Bond2

/etc/network/interfaces を以下の通りに編集していきます。以下は例ですので、環境に合わせて書き換えてください。

auto lo  
iface lo inet loopback

# physical on-bording device
iface eno1 inet manual
iface eno2 inet manual

# virtual bonding device
auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2 # bondingとして扱う物理NIC
        bond-miimon 100 # bondingのリンク状態を監視する間隔(ms)
        bond-mode 802.3ad # LACPとして動作
        bond-xmit-hash-policy layer2+3

# virtual bridge device
auto vmbr0
iface vmbr0 inet static
        address 192.168.1.30/24 # bridgeに割り当てるIPアドレス(ホストにアクセスするIPアドレス)
        gateway 192.168.1.254
        bridge-ports bond0 # bridgeと紐づけるインターフェース
        bridge-stp off
        bridge-fd 0

"ifupdown2"をインストールすることで、GUIからネットワークの設定を反映する際に、再起動が不要になりますが、今回は、CUIでネットワーク設定を変更したので、以下のコマンドで設定を反映します。

If you made manual changes directly to the /etc/network/interfaces file, you can apply them by running ifreload -a
引用元:Live-Reload Network with ifupdown23

# ifreload -a

状態確認(正常時)

正常な状態の例を記載します。

### 物理NICの状態
# ip link show eno1
4: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
# ip link show eno2
5: eno2 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:4d

### bondの状態
# ip link show bond0
11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff

### ブリッジの状態
# ip link show vmbr0
14: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff

### bondの状態
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: aa:aa:aa:aa:aa:4c
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 9
        Partner Key: 67
        Partner Mac Address: bb:bb:bb:bb:bb:46

Slave Interface: eno1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4c
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: aa:aa:aa:aa:aa:4c
    port key: 9
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: bb:bb:bb:bb:bb:46
    oper key: 67
    port priority: 128
    port number: 3
    port state: 61

Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4d
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: aa:aa:aa:aa:aa:4c
    port key: 9
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: bb:bb:bb:bb:bb:46
    oper key: 67
    port priority: 128
    port number: 4
    port state: 61

状態確認(異常時)

ここでは2本のLANケーブルのうち(eno1側)を抜線後の状態を記載していまので、参考にしてください。
抜線した物理NICは、DOWNしていますが、仮想インターフェースはUPのままになっています。bond状態確認では、スレーブインターフェースとしての抜線したポートがdownしています。

### 物理NICの状態
# ip link show eno1
4: eno1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
# ip link show eno2
5: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:4d

### bondの状態
# ip link show bond0
11: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff

### ブリッジの状態
# ip link show vmbr0
14: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff

### bondの状態
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: aa:aa:aa:aa:aa:4c
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 9
        Partner Key: 67
        Partner Mac Address: bb:bb:bb:bb:bb:46

Slave Interface: eno1
MII Status: down <--リンクダウン検知で"down"に変化
Speed: Unknown <--リンクダウン検知で"Unknown"に変化
Duplex: Unknown <--リンクダウン検知で"Unknown"に変化
Link Failure Count: 1 <--リンクダウン検知でカウンタが増加
Permanent HW addr: aa:aa:aa:aa:aa:4c
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: aa:aa:aa:aa:aa:4c
    port key: 0
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: bb:bb:bb:bb:bb:46
    oper key: 67
    port priority: 128
    port number: 3
    port state: 61

Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4d
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
    system priority: 65535
    system mac address: aa:aa:aa:aa:aa:4c
    port key: 9
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: bb:bb:bb:bb:bb:46
    oper key: 67
    port priority: 128
    port number: 4
    port state: 61

Switch

コンフィグを以下の通りに記載します。こちらも例ですので、環境に合わせて書き換えてください。

!
interface Port-channel2
 switchport access vlan 10
 switchport mode access
!
!
interface GigabitEthernet1/0/3
 switchport access vlan 10
 switchport mode access
 channel-protocol lacp
 channel-group 2 mode active
!
interface GigabitEthernet1/0/4
 switchport access vlan 10
 switchport mode access
 channel-protocol lacp
 channel-group 2 mode active
!

動作確認

冗長化したそれぞれのProxmoxノード間でpingを打ち続けた状態でLANケーブルを抜線した際の影響を確認してみました。結果を見ると、当然のことながら間隔が短い方はパケットロス率が高いことが分かります。検証で利用する分には問題なく、あくまで疎通がこれくらいの影響というだけで、実際にVMLinuxコンテナ上でアプリケーションを動作させた場合の影響は環境によると思われます。また、外部ストレージを利用する場合はどのような影響があるのか検証してみる必要がありそうです。

・0.1秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 496 received, 0.8% packet loss, time 51919ms
rtt min/avg/max/mdev = 0.166/0.448/0.696/0.059 ms

・0.01秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 444 received, 11.2% packet loss, time 8005ms
rtt min/avg/max/mdev = 0.166/0.439/0.491/0.063 ms

おまけ

bond-miimon の監視間隔を短くした場合の断時間

以下の結果より、bond-miimon のパラメータを"10"に変更し、0.01秒間隔でpingを打った場合に多少変化はありましたが、それ以外は大きな変化はありませんでした。いずれの場合においても、疎通断から1秒以内に復活しているため、このパラメータが運用において大きな役割を果たしているとは言えないと感じました。bond-miimon のパラメータを小さくすることで多少リソースが消費されてしまうこと考えると、無理に小さくせずに公式の例にあるように、"100"で問題ないと思いました。

bond-miimon のパラメータを"100"から"10"に変更

・0.1秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 496 received, 0.8% packet loss, time 51901ms
rtt min/avg/max/mdev = 0.169/0.426/0.512/0.076 ms

・0.01秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 475 received, 5% packet loss, time 8011ms
rtt min/avg/max/mdev = 0.184/0.429/0.495/0.054 ms

bond-miimon のパラメータを"100"から"50"に変更

・0.1秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 491 received, 1.8% packet loss, time 51907ms
rtt min/avg/max/mdev = 0.172/0.460/0.534/0.051 ms

・0.01秒間隔でpingを打ち続けた場合の影響

--- 192.168.1.30 ping statistics ---
500 packets transmitted, 443 received, 11.4% packet loss, time 7990ms
rtt min/avg/max/mdev = 0.176/0.447/0.518/0.052 ms

Nutanix CE 2.1 AOS 6.8.1 aCLIでLACPを設定

はじめに

前回に続き、今回は Nutanix CE の初期構築時にCLIでLACPの設定をしていきます。前回の記事では、リンクは1本で繋いでいることを想定しています。しかし、リンクを2本繋いでいる場合では、LACPの設定なしに接続はできません。
Nutanix CE では10GbEリンクを使用することを推奨していますが、手元に1GbEしかない場合や環境を用意することが面倒な場合(私ですね)は、リンクを束ねて帯域を増やすことを推奨しています。

If 10 GbE or faster uplinks are available, Nutanix recommends that you use them instead of 1 GbE uplinks.
If you must use only 1GbE uplinks, add them into a bond to increase bandwidth and use the balance-TCP (LACP) or balance-SLB bond mode.
引用元:AHV 6.8 - Host Network Management1

環境

シンプルにスイッチ1台とサーバ1台間を2本の1GbEリンクで束ねていきます。スイッチはCiscoCatalystを使用しています。

設定(サーバ側)

設定はCVMで実施しますので、AHVからCVMへSSHしておきます。また、aCLIコマンドを使用するため Acropolis が起動している必要があります。クラスタが起動していれば Acropolis も起動しているので作業の際はクラスタを起動しておきます。
以下の出力のように初期構築時に作成される vs0 にはすべてのNIC(例:eth0~eth5)が紐づいています。手元の環境でLACPとして扱うインターフェースを絞ります。設定後は、vs0 に紐づく uplink_list が少なくなっていることが分かります。

### 設定前の状態
nutanix@CVM$ acli net.get_virtual_switch vs0
config {
  cluster_configuration_list {
    cluster_uuid: "00062254-83be-d3da-1b06-************"
    default_uplink_grouping: "kMixed"
    host_configuration_list {
      config_failed: False
      host_uuid: "2e178a51-916c-408c-bcf4-************"
      internal_bridge: "br0"
      route_table: 1000
      uplink_list: "eth0"
      uplink_list: "eth1"
      uplink_list: "eth2"
      uplink_list: "eth3"
      uplink_list: "eth4"
      uplink_list: "eth5"
    }
  }
  default: True
  description: "Default Virtual Switch"
  lacp_config {
    lacp: False
  }
  logical_timestamp: 1
  mtu: 1500
  name: "vs0"
  nic_team_policy: "kActiveBackup"
  partially_done: False
  vswitch_uuid: "229028f8-4c09-4dd4-abd7-************"
}

### 設定コマンド(acli net.update_virtual_switch vs0 host_uplink_config="{<host_uuid>:[<NIC>,<NIC>]}")
nutanix@CVM$ acli net.update_virtual_switch vs0 host_uplink_config="{2e178a51-916c-408c-bcf4-************:[eth0,eth1]}"

### 設定後の状態
nutanix@CVM$ acli net.get_virtual_switch vs0
config {
  cluster_configuration_list {
    cluster_uuid: "00062254-83be-d3da-1b06-************"
    default_uplink_grouping: "kMixed"
    host_configuration_list {
      config_failed: False
      host_uuid: "2e178a51-916c-408c-bcf4-************"
      internal_bridge: "br0"
      route_table: 1000
      uplink_list: "eth0"
      uplink_list: "eth1"
    }
  }
  default: True
  description: "Default Virtual Switch"
  lacp_config {
    lacp: False
  }
  logical_timestamp: 1
  mtu: 1500
  name: "vs0"
  nic_team_policy: "kActiveBackup"
  partially_done: False
  vswitch_uuid: "229028f8-4c09-4dd4-abd7-************"
}

vs0 に紐づくNICの絞り込み後は、net.update_virtual_switchでLACPの設定を行います。

### vs0 のLACP設定
nutanix@CVM$ acli net.update_virtual_switch vs0 bond_type=kBalanceTcp lacp_fallback=true lacp_timeout=kFast

nutanix@CVM$ acli net.get_virtual_switch vs0
config {
  cluster_configuration_list {
    cluster_uuid: "00062254-83be-d3da-1b06-************"
    default_uplink_grouping: "kMixed"
    host_configuration_list {
      config_failed: False
      host_uuid: "2e178a51-916c-408c-bcf4-************"
      internal_bridge: "br0"
      route_table: 1000
      uplink_list: "eth0"
      uplink_list: "eth1"
    }
  }
  default: True
  description: "Default Virtual Switch"
  lacp_config {
    lacp: True
    lacp_fallback: True
    lacp_timeout: "kFast"
  }
  logical_timestamp: 5
  mtu: 1500
  name: "vs0"
  nic_team_policy: "kBalanceTcp"
  partially_done: False
  update_in_progress: False
  vswitch_uuid: "229028f8-4c09-4dd4-abd7-************"
}

設定(スイッチ側)

スイッチのコンフィグを記載しておきます。設定する際は、AHVノードに接続する推奨構成があるようで、Cisco Catalyst では以下のように記載されています。

Cisco Catalyst:
no port-channel standalone-disable
**Fallback mode is enabled by default
引用元:How to Enable, Disable, and Verify LACP on AHV hosts2

!
interface Port-channel1
 switchport access vlan 10
 switchport mode access
 no port-channel standalone-disable
!
!
interface GigabitEthernet1/0/1
 switchport access vlan 10
 switchport mode access
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet1/0/2
 switchport access vlan 10
 switchport mode access
 channel-protocol lacp
 channel-group 1 mode active
!

正常に接続できていることを確認します。手元のPCからCVMへPingを打ってみたり、SSHやブラウザからWeb管理画面にログインをしてみてください。

#show etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

        A - formed by Auto LAG


Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP        Gi1/0/1(P)      Gi1/0/2(P)

#show etherchannel port-channel
Port-channel: Po1    (Primary Aggregator)

------------

Age of the Port-channel   = 0d:0h:23m:58s
Logical slot/port   = 12/1          Number of ports = 1
HotStandBy port = null
Port state          = Port-channel Ag-Inuse
Protocol            =   LACP
Port security       = Disabled
Standalone          = Enabled (independent mode)

Ports in the Port-channel:

Index   Load   Port        EC state        No of bits
------+------+------+------------------+-----------
  0     00     Gi1/0/1     Active             0
  0     00     Gi1/0/2     Active             0

Time since last port bundled:    0d:00h:29m:21s    Gi1/0/1
Time since last port Un-bundled: 0d:0h:53m:46s    Gi1/0/2

追記(2024/11/10)

設定コマンドを実行した際に設定が反映されるまでに少し時間がかかります。その際にタスク状況が確認できるコマンドを以下に記載しています。

### タスク実行状況確認
nutanix@CVM$ ecli task.list include_completed=false
Task UUID       Parent Task UUID        Component       Sequence-id     Type    Status  Creation Time(UTC)        Completion Time(UTC)

参考資料

  1. AOS 6.8 - Acropolis Command-Line Interface (aCLI)
  2. Nutanix CE よろず相談所

Nutanix CE 2.1 AOS 6.8.1 インストールのメモ

1. はじめに

 以前、Nutanix Meetup に参加した際にHCI(ハイパーコンバージドインフラストラクチャー)がどのようなものかやその良さを伺う機会があり、自宅でも環境構築を試みましたが、途中でつまずいてそれっきりになっていました。。。 今回、会社の検証環境でリソースが不足した際に簡単に環境を拡張できるものはないかと考えた際に Nutanix Meetup で聞いた内容を思い出し、HCI製品の Nutanix なら実現できるのではないかと思いました。 後、ご自宅でヤギを飼っている方ともお話をさせていただいた際に、「自宅で試してみます!」と言ったのにやっていなかったことに罪悪感を持っていたので、再挑戦することにしました。

2. 環境

 今回は、 以下の手元の環境で Nutanix CE 2.1 をシングルクラスタで構築します。シングルクラスターで構築した場合、既存クラスタから3ノードや4ノードへ拡張することができないことに留意ください。 ストレージは4枚のうち、2枚はRAID1、残り2枚は非RAID構成で、すべてRAIDコントローラに接続した状態です。 ストレージは注意点があり、ハードウェア要件 の「Storage devices, Hot Tier Flash」で 少なくとも1枚の200GB以上の非NVNe SSDが必要と記載があります。

  • CPU:Intel(R) Xeon(R) 4コア

  • メモリ:64GB

  • ストレージ1(データ用):SATA HDD 2TB (RAID1)

  • ストレージ2(ハイパーバイザー用):SAS HDD 300GB

  • ストレージ3(CVM用):SATA SSD 500GB

  • NIC:1Gbps

3. 事前準備

3-1. アカウント作成

 Nutanix CE はコミュニティ版としてお試しで提供されており、利用するには My Nutanix のアカウントが必要です。公式サイト の右上にあるログインからアカウントを作成します。 アカウント作成でも注意点があり、登録するメールアドレスはGメールやYahoo!メールなどのアドレスは使用できないため、独自に用意したメールアドレスを登録する必要があります。

3-2. Nutanix CE イメージのダウンロード

 アカウント作成で登録したメールアドレスを このサイト で入力し、メールアドレスに届いたリンクからイメージダウンロードのページへアクセスします。 「Installer ISO」の下にあるリンクをクリックして、イメージをダウンロードします。

3-3. ブートUSBメモリの作成

 RufusでブートUSBメモリを作成します。中のデータを書き換えても問題ないUSBメモリを用意して、ダウンロードしたイメージをUSBメモリに焼きます。イメージは6GBちょっとあるので、8GBのUSBメモリがあれば問題ないと思います。下の画像のように、デバイスUSBメモリ、ブートの種類を右の選択をクリックして、ダウンロードしたイメージを指定します。

画像3.1.Rufus

4. インストール

4-1. 起動順序の変更

 BIOSから起動順序をUSBメモリが一番になるように変更します。BIOSへの入り方は機器によって異なるため手元の環境を調べたうえで作業をしてみてください。

4-2. 初期設定

 インストール先の指定やハイパーバイザーとCVMのネットワーク設定を行います。設定項目を移動する際はTabキー、設定項目をすべて埋めて次のページへ移動する際は「Next Page」へ移動して、Spaceキーで決定します。Enterキーではありません!Spaceキーを押してください!ここでEnterキーを押してしまうと、最初の起動からやり直しなので注意してください。
検証として利用する分にはディスク選択はデフォルトのままでもOKだと思いますが、ハードウェア要件 に沿って選択するなら以下の通りになると思います。

  • Hypervisor Boot:32GB以上の SATA DOM または M.2 SSD または SATA SSD/HDD

  • CVM Boot:200GB以上の非NVNe SSD

  • Data:500GB以上のHDDまたはSSD

ハイパーバイザーとCVMのネットワーク設定は、ホスト(以降、AHVと記載)とCVMのIPアドレスが同じセグメントかつインターネットに接続できるセグメントであるポイントを押さえていれば問題ありません。DNSの設定がないことに疑問を持つかもしれませんが、後で設定するタイミングがありますので、安心してください。

画像4.1.初期設定

4-3. ライセンスへの同意

 CE EULA の内容を十字キーで操作し、最後まで移動&確認する必要があります。最後まで移動&確認できていない場合、インストールできません。 内容に同意できれば、Tabキーで移動し、「I accept the end user license agreement. 」にチェックをします。
最後に「Start」に移動して、Spaceキーを押してください。Enterキーではありません!Spaceキーを押してください!

画像4.2.ライセンス画面

4-4. インストールと再起動

 インストール後にブートUSBメモリを外してから、「Y」を入力&Enterキーで再起動を実施します。

画像4.3.再起動

再起動後、以下の画像のようにログイン画面が表示されるとインストール完了です。 インストール完了後、初回は localhost と表示されますが、以降は NTNX-****** と表示されます。原因は不明ですが、どちらもAHVへログインすることに変わりはありません。

画像4.4.ログイン画面

5. クラスタの作成と設定(シングル)

 ここでは、公式の Get Started に沿って記載しますので、不明点や分かりにくい場合は公式サイトを確認ください。それでも解決の糸口が見つからない場合は、コミュニティで質問すると専門の方が問題解決に向けて助けてくださると思います。

5-1. CVMへログイン

 手元のPCからTeraTermPuTTyなどでCVMへSSHやコンソールからAHVへログイン後にCVMへSSHしてログインする方法のどちらかで接続します。 ログインする際は、AHVとCVMでそれぞれ以下の通りとなり、ユーザ名が異なる点に留意してください。

  • AHV ユーザ名:root、パスワード:nutanix/4u

  • CVM ユーザ名:nutanix、パスワード:nutanix/4u

5-2. クラスタの作成

 今回はシングルクラスタで構成するため「--redundancy_factor=1」が必要となり、複数ノードで構成する場合は不要です。CVMのIPアドレスは、インストール時の初期設定した値を入力してください。

$ cluster -s <CVM_IPアドレス> --redundancy_factor=1 create

5-3. クラスタの設定

 クラスタの名前やIPアドレスDNS、NTPを設定していきます。
初めにクラスタの名前を設定します。こちらは任意の名前で問題ありません。

$ ncli cluster edit-params new-name=<クラスタ名>

DNSの設定をします。このDNSはインターネットに接続した際に名前解決を行うフルリゾルバまたはキャッシュDNSサーバを指します。デフォルトで、Googleの提供するパブリックキャッシュDNSサーバ「8.8.8.8」と「8.8.4.4」が設定されていますので、必須設定ではありません。手元にDNSサーバがあり、デフォルト設定を削除したい場合のコマンドも一緒に記載します。

### DNSサーバの追加 ###
$ ncli cluster add-to-name-servers servers=<DNSサーバ>
### DNSサーバの削除 ###
$ ncli cluster remove-from-name-servers servers=8.8.8.8,8.8.4.4

クラスタIPアドレスはインストール時に設定したAHVとCVMのIPアドレスと同じセグメント内のIPアドレスを使用します。当然ですが、他のIPアドレスと重複しないようにしてください。

$ ncli cluster set-external-ip-address external-ip-address=<クラスタ_IPアドレス>

NTPの設定は、デフォルトで NTP Pool Project の「1.pool.ntp.org」と「0.pool.ntp.org」が設定されています。DNS同様、手元にNTPサーバがあり、デフォルト設定を削除したい場合のコマンドも一緒に記載します。

### NTPサーバの追加 ###
$ ncli cluster add-to-ntp-servers servers=<NTPサーバ>
### NTPサーバの削除 ###
$ ncli cluster remove-from-ntp-servers servers=0.pool.ntp.org,1.pool.ntp.org

5-4. クラスタの起動

$ cluster start

クラスタを削除する場合

### クラスタの停止 ###
$ cluster stop

This operation will stop the Nutanix storage services and any VMs using Nutanix storage will become unavailable. Do you want to proceed? (I agree/[N]): I agree <--「I agree」を入力

### クラスタが停止していることを確認
The state of the cluster: stop

### クラスタが停止コマンドによって停止していることを確認
2024-09-21 10:36:01,475Z INFO MainThread cluster:2193 Cluster has been stopped via 'cluster stop' command, hence stopping all services.
2024-09-21 10:36:01,475Z INFO MainThread cluster:3465 Success!

### クラスタの削除 ###
$ cluster destroy

This operation will completely erase all data and all metadata, and each node will no longer belong to a cluster. Do you want to proceed? (Y/[N]): Y <--「Y」を入力

### クラスタが削除成功したことを確認
2024-09-21 11:00:33,856Z INFO MainThread cluster:3465 Success!

5-4. Webコンソール接続

 ブラウザを開いて、「 https://<CVMのIPアドレス>:9440 」にアクセスします。SSL証明書の警告が表示されますが、確認してアクセスします。初回ログイン時は、ユーザ名:admin、パスワード:nutanix/4u でログインします。

画像5.1.Webコンソールログイン画面

ログイン後、初期パスワードを変更するように求めらます。変更後のパスワードは 画像5.2. の下に青文字で記載されている要件に沿ったものを設定します。

画像5.2.初期パスワード変更画面

初期パスワード変更ができると、再度ログイン画面に遷移するので、変更後のパスワードでログインします。

画像5.3.初期パスワード変更後のWebコンソールログイン画面

事前準備で作成した My Nutanix アカウントの情報を入力します。NEXT username は、My Nutanix アカウントを作成した際に登録したメールアドレスを入力します。この時、CVMからインターネットに接続できる状態であることを確認してください。

画像5.4.Nutanixアカウント認証画面

ホーム画面が表示されるとインストールは完了です。

画像5.5.ホーム画面

参考資料

STPにおけるMACアドレス比較のポイント

1. はじめに

 STPでルートブリッジ、ルートポートや指定ポートを決定する基準の中でブリッジプライオリティとMACアドレスを合わせて構成されたブリッジIDを比較して選定することがあります。
デフォルトの設定から変更してない場合、ブリッジプライオリティが同じである可能性は十分あり、MACアドレスを比較することになります。 そんな時、「MACアドレスってどうやって比較するんだ?」となり、検索した際にYahoo!知恵袋で以下の回答が記載されていました。

(一部抜粋)
001dは同じなので省きます。
9とcですが、10進数に治すと9はそのまま9で、cは12です。

既に5桁目でcの方が大きいので上の方が小さいです。
引用元:すみません質問です今CCNA対策でSTPのところをやってまして1

そこで実際にこの回答が正しいことを「Packet Tracer2」を使用して調査したので、その内容と結果を記載していきます。 気になる方は実際に手元の自分の環境で本当に同じようになるのか試してみてください。

2. 構成

 今回は、Packet Tracer でL2SW(2960-24TT)3台を輪(以降、ループと記載)になるように結線します。 論理構成図を少し変わった書き方をしましたが、物理構成図と一緒に載せましたので、参考にしていただければと思います。

画像2.1.STP検証_Packet Tracer

画像2.2.STP検証_物理構成

画像2.3.STP検証_論理構成

3. 内容

3.1 準備

 実際に機器設定も含めて検証してみた内容を記載をしていきます。今回は、STPでルートブリッジを選定する際のプロセスで解説します。
まず設定について、3台のL2SWへの設定ですが、3台とも以下のコンフィグで検証をしています。特に複雑な設定は行わず、VLANインターフェース作成とVLANを物理ポート割り当てる以外は、デフォルトのままで実施しました。

(省略)
!
spanning-tree mode pvst
spanning-tree extend system-id
!
interface FastEthernet0/1
 switchport access vlan 10
!
interface FastEthernet0/2
 switchport access vlan 10
!
(省略)
!
interface Vlan10
 no ip address
!
(省略)

設定後は、L2SWをループするように画像2.2. のようにケーブルで接続します。SW同士を接続するので使用するケーブルは、「copper crossover cable(銅クロスケーブル)」を使用します。なぜ、クロスケーブルを使用するのかはここでは説明を省きます。気になる方は、MDIとMDI-Xについて調べてみてください。

3.2 ルートブリッジの選定

 STPではツリー構造となる起点のSWを選定し、これをルートブリッジと呼びます。ルートブリッジの選定には、ブリッジID(ブリッジプライオリティ+MACアドレス)を比較し、最も小さいSWがルートブリッジになります。ブリッジプライオリティは、デフォルト値が「32768」となっており、すべてのSWがデフォルト値である場合、次の比較対象としてMACアドレスを見ていきます。
各L2SWに設定したVLANに割り当てられたMACアドレスを確認します。コマンドは「show interfaces vlan <VLAN番号>」を実行し、以下の画像3.1. のように表示されたMACアドレスを確認します。ここでの注意点は、物理ポートのMACアドレスではなく、VLANのMACアドレスを確認します(画像3.2. )。

画像3.1.MACアドレスの確認

画像3.2.物理ポートとVLANインターフェースのMACアドレス

各SWのMACアドレスを確認できたら、実際に比較していきます。比較対象は「SW0:0000.0c27.6801」、「SW1:0002.17a9.2601」、「SW2:000a.f33a.dc01」になります。画像3.3. にあるようにMACアドレスは左から比較していきます。左から見ていくと、左から3つは同じ「0」が並んでおり、4つ目から値に差分があります。よって、「SW0:0」、「SW1:2」、「SW2:a」を比較していきます。

画像3.3.MACアドレスの比較

MACアドレスは16進数で構成されており、アルファベットが含まれますが、数字とアルファベットの比較をどのように行うのか説明します。
比較対象を絞るために「SW0:0」と「SW1:2」を最初に見ていきます。数字の比較はどちらが小さいのかは言うまでもなく、「SW0:0」になります。
続いてアルファベットが含まれている「SW0:0」と「SW2:a」を比較します。比較するには、16進数で表現された「SW2:a」を10進数に変換します。10進数変換後は、「SW2:10」になります。これで数字の比較が可能になり、「SW0:0」と「SW2:10」のどちらの値が小さいかというと「SW0:0」になりますので、SW0がルートブリッジに決定されます。SW0が実際にルートブリッジになっていることを確認します(画像3.4.)。

画像3.4.ルートブリッジの確認

4. 結果

 結論、最初の記事であった回答が正しいことがわかりました。本記事とは別に3回ほど環境を変えて試してみましたが、結果はすべて想定通りになりました。MACアドレスの比較では16進数から10進数に変換してから比較することでどちらが対象になるのか判明します。今回は、STPのルートブリッジ選定まででしたが、ルートポートや指定ポートを選定する際にもブリッジIDを元にMACアドレスの比較をすることがあります。気になる方は、この後の流れについても確認してみてください。

参考資料

デフォルトゲートウェイ冗長化における仮想MACアドレスとグループ番号の関係

1. はじめに

 デフォルトゲートウェイ冗長化するプロトコルとして、「HSRP」「VRRP」「GLBP」の3つが挙げられ、これらをまとめて「FHRP」と呼ばれます。
デフォルトゲートウェイ冗長化する場合、対象機器で仮想IPアドレスを設定します。また、仮想MACアドレスは設定されたグループ番号によって自動で割り振られます。振り分けられる際は、10進数で設定したグループ番号を16進数に変換した結果によって決定されます。今回は、そんな仮想MACアドレスとグループ番号の関係について書いていきます。
※今回の記事で記載しているHSRPは、バージョン1を示しています。

2. HSRPとVRRP

 HSRPとVRRPを一緒に紹介するのは、設定する際にグループ番号の使用できる範囲が「0 ~ 255」で同じという点で共通点があるためです。
仮想MACアドレスについては、それぞれ以下のようなパラメータになり、「XX」はグループ番号によって変化します。例として、グループ番号が「10」と「20」の場合で、HSRPとVRRPでどのような仮想MACアドレスになるのか記載します。「10」の場合は、10進数から16進数に変換後は「0A」になり、「20」の場合は、10進数から16進数に変換後は「14」になります。そして、これらの16進数変換後の値がMACアドレスの後ろに入り、仮想MACアドレスが決定します。
CCNAの試験でグループ番号から仮想MACアドレスを推測する問題が出題される可能性もあるので、グループ番号と仮想MACアドレスの関係を覚えておきたいです。

プロトコル 仮想MACアドレスの型 グループ番号が「10」の仮想MACアドレス グループ番号が「20」の仮想MACアドレス
HSRP 0000.0C07.ACXX 0000.0C07.AC0A 0000.0C07.AC14
VRRP 0000.5E00.01XX 0000.5E00.010A 0000.5E00.0114

画像1.1.HSRPの構成例

画像1.2.HSRPの構成(グループ番号:10)

HSRPとVRRPで設定可能なグループ番号が「0 ~ 255」である点も併せて解説していきます。
先ほど、グループ番号を10進数から16進数に変換した値が仮想MACアドレスの後ろに入ると記載しました。よって、16進数の最大値がグループ番号の最大値になります。 2桁の16進数で最大値は「FF」になります。これを10進数に変換すると、「255」になります。これが、グループ番号として利用できる範囲が「0 ~ 255」である理由になります。もし、グループ番号の利用範囲に「256」が範囲に含まれると、HSRPの場合は仮想MACアドレスが「0000.0C07.A100」となり、あらかじめ仮想MACアドレスとして決まっているパラメータの「0000.0C07.ACXX」から逸れてしまいます。

HSRPにはバージョン2(以降、HSRPv2と記載)があり、利用可能なグループ番号がバージョン1とは異なり、「0 ~ 4095」となっています。グループ番号で利用できる範囲が広がるということは、仮想MACアドレスも変化します。HSRPv2の仮想MACアドレスは「0000.0C9F.FXXX」になります。そして、3桁の16進数で最大値は「FFF」となり、10進数に変換すると「4095」になるので、グループ番号の範囲が「0 ~ 4095」である理由です。

Q. HSRPバージョン2とHSRPバージョン1の違いは何ですか。
バージョン 1 のグループ番号は 0 ~ 255 の範囲に制限されます。HSRP バージョン 2 では、グループ番号の範囲が 0 ~ 4095 に拡大されています。たとえば、新しいMACアドレス範囲0000.0C9F.Fyyyを使用できます。yyy = 000-FFF(0 ~ 4095)です。
引用元:ホットスタンバイルータプロトコル(HSRP)に関するFAQを確認する1

3. GLBP

 GLBPは、1つのグループに含められるメンバーの最大値は4つであり、HSRPやVRRPのような Active-Stanby 構成とは異なり、Active-Active 構成によるデフォルトゲートウェイの冗長と負荷分散を行います。そのため、グループに含まれるメンバーにそれぞれ仮想MACアドレスが設定されます。グループ番号の使用できる範囲が「0 ~ 1023」、プライオリティの使用できる範囲が「1 ~ 255(デフォルト:100)」です。仮想MACアドレスについては、後ろの「YY」はプライオリティ、「X.XX」はグループ番号によって変化します。

プロトコル 仮想MACアドレスの型 グループ番号が「10」の仮想MACアドレス グループ番号が「20」の仮想MACアドレス
GLBP 0007.B40X.XXYY 0007.B400.0A01 0007.B400.1401

画像1.3.GLBPの構成例

画像1.4.GLBPの構成(グループ番号:10)

プライオリティの設定可能な値は「1 ~ 255(デフォルト:100)」であり、仮想MACアドレスに用いられる際は、これまでのようにプライオリティの値を16進数に変換するのではなく、単純にプライオリティが大きい機器順で「01>02>03>04」が使用されます。例として、画像[画像01-04_GLBPの構成(グループ番号:10)]の環境では各ルータでプライオリティをRT01は「105」、RT02は「100」を設定しました。すると、RT01は「01」、RT01は「02」が仮想MACアドレスに設定されます。

GLBP ゲートウェイ プライオリティ
また、GLBP ルータがバックアップ仮想ゲートウェイとして機能するかどうかや、現在の AVG の機能が停止したときに AVG になる順序を決定するのもプライオリティです。 glbp priority コマンドを使用して 1 ~ 255 の値を設定し、各バックアップ仮想ゲートウェイのプライオリティを設定できます。
引用元:GLBP の設定 [Cisco IOS 15.1S]2

GLBPで設定可能なグループ番号が「0 ~ 1023」である理由のソースが見つけられなかったため、私個人の憶測で記載しています。
HSRPやVRRPでは、仮想MACアドレスの変化する桁が2つであることから「256(= 16 x 16)」となり、ここから「1」を引くことで、グループ番号の最大値「255」となります。GLBPでは、仮想MACアドレスの変化する桁が3つであることから「4096(= 16 x 16 x 16)」となります。ただ、GLBPでは1つのグループに対して最大で4つの仮想MACアドレスを使用します。そのため、「4096」から1つのグループに対して設定可能な仮想MACアドレスの最大値である「4」で割り、「1024」となった後で、「1」を引くと「1023」がGLBPで使用できるグループ番号の最大値であると思います。

画像1.5.仮想MACアドレスと16進数

画像1.6.仮想MACアドレスと16進数

追記

(2024/05/11)
[3. GLBP]における記載内容に誤り
誤: プライオリティの設定可能な値は「1 ~ 255(デフォルト:100)」であり、仮想MACアドレスに用いられる際は、これまでのようにプライオリティの値を16進数に変換するのではなく、単純にプライオリティが大きい機器順で「01>02>03>04」が使用されます。
正:
プライオリティの設定可能な値は「1 ~ 255(デフォルト:100)」であり、仮想MACアドレスに用いられる際は、これまでのようにグループ番号の値を16進数に変換するのではなく、単純にプライオリティが大きい機器順で「01>02>03>04」が使用されます。

(2025/06/09) [3. GLBP]における説明不足
GLBPで使用できるグループ番号の最大値が、「1024」から「1」を引いた「1023」と記載しているが、なぜ「1」を引いたのか理由が記載できていませんでした。
結論から言うと、グループ番号が「0」から始まるためです。グループ番号が「0」から始まる場合だと、グループ番号として利用できる総数が「1024」なため、「1024」から「1」を引いた値である「1023」がGLBPで使用可能な最大のグループ番号となります。

参考資料