HOS 2.X LACPを使用したPXEブート
2016-01-27
Machine-translated — the English original is authoritative.
今日は、すべてのサーバーで bonded なネットワークインターフェースカード（NIC）を使用するインストール作業を行っていました。デュアルポートの10Gbネットワークインターフェースは、以下の設定でHP59XXスイッチ上でLACPを使用してボンディングされていました：
[GJL-HP5900-1-Bridge-Aggregation2]display link-aggregation verbose Bridge-Aggregation2
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I -- Individual
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired
Aggregate Interface: Bridge-Aggregation2
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, aaaa-bbbb-cccc
Local:
Port Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
XGE1/0/3 S 32768 2 {ACDEFG}
XGE1/0/4 U 32768 2 {ACG}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
--------------------------------------------------------------------------------
XGE1/0/3 0 32768 0 0x8000, 0000-0000-0000 {DEF}
XGE1/0/4 0 32768 0 0x8000, 0000-0000-0000 {EF}
しかし、すべてのサーバーがPXEブートできませんでした。
サーバーのコンソールを確認したところ、PXEブートを試みているものの、デプロイヤーからの応答が得られていないようでした。
Helion Lifecycle Manager 上の設定を素早く確認したところ、すべて正しく設定されていることがわかりました。
- /etc/dhcp/dhcpd.conf に正しいサーバーのMACアドレスが設定されていることを確認する
graham@helion-cp1-c1-m1-mgmt:/etc/dhcp$ cat dhcpd.conf | more
# ******************************************************************
# Cobbler managed dhcpd.conf file
# generated from cobbler dhcp.conf template (Mon Jan 18 14:32:10 2016)
# Do NOT make changes to /etc/dhcpd.conf. Instead, make your changes
# in /etc/cobbler/dhcp.template, as /etc/dhcpd.conf will be
# overwritten.
# ******************************************************************
ddns-update-style interim;
allow booting;
allow bootp;
ignore client-updates;
set vendorclass = option vendor-class-identifier;
option pxe-system-type code 93 = unsigned integer 16;
subnet 172.16.60.0 netmask 255.255.255.0 {
option routers 172.16.60.10;
option domain-name-servers 172.16.60.10;
option subnet-mask 255.255.255.0;
deny unknown-clients;
default-lease-time 21600;
max-lease-time 43200;
next-server 172.16.60.10;
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
if option pxe-system-type = 00:02 {
filename "ia64/elilo.efi";
} else if option pxe-system-type = 00:06 {
filename "grub/grub-x86.efi";
} else if option pxe-system-type = 00:07 {
filename "grub/grub-x86_64.efi";
} else {
filename "pxelinux.0";
}
}
}
# group for Cobbler DHCP tag: default
group {
host generic7 {
hardware ethernet 8c:dc:d4:b5:ce:80;
fixed-address 172.16.60.14;
option host-name "compute2";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic5 {
hardware ethernet 8c:dc:d4:b5:c9:74;
fixed-address 172.16.60.12;
option host-name "controller3";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic1 {
hardware ethernet 8c:dc:d4:b5:c9:00;
fixed-address 172.16.60.13;
option host-name "compute1";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic6 {
hardware ethernet 8c:dc:d4:b5:c6:40;
fixed-address 172.16.60.11;
option host-name "controller2";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic4 {
hardware ethernet 5c:b9:01:8d:6b:68;
fixed-address 172.16.60.15;
option host-name "osd1";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic3 {
hardware ethernet 5c:b9:01:8d:73:dc;
fixed-address 172.16.60.17;
option host-name "osd3";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
host generic2 {
hardware ethernet 5c:b9:01:8d:70:0c;
fixed-address 172.16.60.16;
option host-name "osd2";
option routers 172.16.60.10;
next-server 172.16.60.10;
}
}
- HLMデプロイヤーノード上のDHCPサービスがポート67でリスニングしていることを確認する
$ netstat -an | fgrep -w 67
udp 0 0 0.0.0.0:67 0.0.0.0:*
- TFTPサービスがポート68でリスニングしていることを確認する
netstat -an | fgrep -w 69
udp 0 0 0.0.0.0:69 0.0.0.0:*
- DHCP Discoveryリクエストについてsyslogファイルを確認する
sudo grep -i dhcp /var/log/syslog
- TCPDUMPを使用して、HLMデプロイヤー上のインターフェースを通過するDHCPトラフィックを確認する
tcpdump -n -i any port 67 or port 68 or port 69
これらのチェックにより、デプロイヤーノードのサービスは稼働しているが、DHCPDISCOVERリクエストがそのインターフェースに到達していないことがわかりました。
これは管理ネットワークのブロードキャストドメインに関する根本的な問題を指しています。PXEブロードキャストリクエストはサーバーから送信されていますが、同じネットワーク上のHLMノードには到達していません。
管理VLANがネイティブVLANであり、すべてのポートが正しく設定されていることを確認するために、基本的なスイッチ構成を見直しました。すべて正しく見えました。
次にLACP構成を削除したところ、PXEブートプロセスが正常に動作し始めました。TCPDUMPにより、DHCPDISCOVERリクエストが正常に受信されていることが確認できました。
HP5900のLACPに関連するPXEの問題についてGoogleで検索したところ、根本原因がわかりました。詳細はこちらをご覧ください。ありがとうございます、Peter Debruyneさん。
解決策：PXEブートのように、最初に個別のネットワークインターフェースカードとしてブートするノードでLACPを使用する場合、LACPタイプを「edge-port」として以下のように設定する必要があります：
[GJL-HP5900-1-Bridge-Aggregation2]lacp edge-port
[GJL-HP5900-1-Bridge-Aggregation2]display link-aggregation verbose Bridge-Aggregation2
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I -- Individual
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired
Aggregate Interface: Bridge-Aggregation2
Aggregation Mode: Dynamic
Loadsharing Type: Shar
System ID: 0x8000, aaaa-bbbb-cccc
Local:
Port Status Priority Oper-Key Flag
--------------------------------------------------------------------------------
XGE1/0/3 I 32768 2 {AG}
XGE1/0/4 I 32768 2 {AG}
Remote:
Actor Partner Priority Oper-Key SystemID Flag
--------------------------------------------------------------------------------
XGE1/0/3 0 32768 0 0x8000, 0000-0000-0000 {DEF}
XGE1/0/4 0 32768 0 0x8000, 0000-0000-0000 {EF}
[NEO-HP5900-1-Bridge-Aggregation2]
新しく構成されたLACPポートは、PXEブート時に個別のネットワークインターフェースとして正常に動作するようになりました。
以下の画像は、PXEブート時に正しく構成されたシステムがどのように見えるかを示しています。
Originally published on allthingscloud.eu (2016-01-27).