RFC 3074を読んでみた話
RFC 3074 - DHC Load Balancing Algorithm
RFC3074はDHCPのロードバランシングアルゴリズムについての手法が書かれたものである. keaのHA構成について調べてるところ,RFCを読んでみたくなり,和訳してみたので載せてみます.特に意味はありませんが,何か参考になればと思います.
概要
この文章ではロードバランシングのアルゴリズムを提案します.これは,はじめの設定以外の情報交換を必要とせずに,複数のサーバのうちのどれがクライアントに対して応答するかを決定するものです.
このサーバ選択アルゴリズムは,複数のDHCPサーバがクライアントにサービス提供を行う際,サーバで計算するクライアントのMACアドレスのハッシュをもとにします.この提案手法は,複数のDHCPサーバがネットワーク上で動作する時,既存のDHCPクライアントになんの変更の必要もなしに,効率的なサーバ選択を提供します.同様の手法はBOOTP relayのような転送エージェントを利用する場合に,ターゲットサーバを選択する場合にも提案されています.
1. 序論
このプロトコルはもともと,DHCP Failoverプロトコルのうち,特にロードバランシング最適化のために生まれました.著者らはのちに,冗長化されたDHCPサーバと,それらにパケットを転送するBOOTP relay agentの動作を最適化するために利用できることに気がつきました. この提案では,それぞれのサーバでクライアントの負荷割合をあらかじめ設定することができます. これは,決定論的ハッシュアルゴリズムを用いて行われ,似た特性を持つ他のプロトコルに容易に適用できます.
2. 用語
このセクションでは,多くのIETFプロトコル使用で共通な一般的な必要用語と,この文章で導入される用語の両方について議論します.
2.1 必要用語
"MUST", "MUST NOT", "REQUIERD", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"のキーワードについては,RFC 2119に記載されている通りに解釈します.
2.2 ロードバランシング用語
このドキュメントでは下記の用語について紹介します.
- Service Delay, SD
- ロードバランシングのパラメータの一つで,クライアントを無視する代わりにロードバランシングに参加しているサーバによる遅延サービスを許可する遅延時間.
- Hask Bucket Assignments, HBA
- ロードバランシングスキームに参加するサーバに一連のHack Backet値を割り当てる構成ディレクティブ.
- Server ID, SID
- Service Transaction, ST
- サーバがクライアントにサービス提供もしくは拒否をする一連の情報交換.例: DHCPサーバとクライアントで交換される,DISCOVER/OFFER/REQUEST/ACK メッセージはService Transactionである.
- Service Transaction ID, STID
- ロードバランシングに利用される個別のクライアントリクエストの属性.
3. バックグラウンドと外部要件
DHCPクライアントはDHCPサーバにコンタクトするためにUDP broadcastを利用するため,クライアントのDHCPDISCOVERメッセージは1台以上のサーバで受信される可能性があります.ブロードキャストを受け取った全てのサーバはクライアントに応答し,クライアントにどのサーバを利用するかを選ばせるでしょう.
BOOTP relay agentを利用する場合,クライアントのブロードキャストは一般にすべての設定されたサーバに転送,もしくは再ブロードキャストされるという同様の非効率性が存在します.
後述の最適化により,それぞれのトランアクションに対して,"サービスする"/"サービスしない"振る舞いをすることでサーバを選択することができます. 転送エージェントは転送先を決定するために同様の計算で動作できます.
いずれのケースでも,どちらが応答するかネゴシエーションすることなくサーバの選択がおこなわれます.
どのクライアントが次にリクエストをするかを予測することはほぼ不可能であるため,このアプローチは本質的には確率的なものです.短時間のうちにおいては,実際のところ特定のサーバによってサービスされるクライアントの割合は指定した割合から逸脱する可能性は十分あります.リクエストの数が上昇すると,それぞれのサーバで処理される実際の負荷の割合は設定された割合に近づくでしょう.
4. 概要
DHCPサーバはClient Identifierが存在する場合はそれを必ずSTIDとして利用します.もしClient Identifierオプションがない場合,DHCPパケットのhlenフィールドはハッシュ化されたデータの長さのために利用し,chaddrはハッシュ化されたデータでなければなりません.Client Identifierもしくはchaadrの最も始めの16bytesが利用されます.
この手案はこのSTIDをsection 6に示す関数を用いてハッシュ化した値に対応させます.そして,結果のハッシュ値を使って,どのサーバがリクエストに応答するべきか,もしくは転送するべきターゲットを決定する必要があります.
このハッシュ関数は0-255のハッシュ値を生成し,ランダムなSTIDや,パターン性のあるSTIDシーケンスにかなり均等なHack Backet分布を生成します. リソースアロケーションはそれぞれのサーバに特定のハッシュ値セットを割り当てることで実現します.
リクエストのSTIDハッシュが自身に割り当てられたハッシュ値セットのうちにマッチした場合にのみ,サーバはリクエストに応答します.
どのサーバに割り当てされていないHack Backetは一部のクライアントSTは完全に無視されることになります(いくつかの状況では,これは好ましい結果になるかもしれません).STIDはユニークである必要はありませんが,負荷を各サーバに分散するために十分ばらけているべきです.
HBAは他のプロトコルでカプセル化されて送信されるかもしれません.例: e-mail, DHCP Failover protocol option.
DHCPサーバの実装では,ロードバランシングは行われているがレスポンスが不可能であるもしくは十分なアドレスがないサーバを扱うための設定をオプションで設定することができます.
もし,client requestのsecsフィールドの値が0でなければ,この機能を提供するDHCPサーバはこの値を利用するべきです.いくつかのクライアントはこのsecsフィールドの実装が正しくないため,DHCPサーバは,通常は応答しないクライアントトランザクションのはじめのインスタンスを見続ける場合があります. もしサーバが過去に記録されたリクエストと同様のトランザクションIDをもったリクエストを受信した場合,もしくは2番目のpacketのsecsフィールドが0の場合,DHCPサーバは,最初とその次のクライアントリクエストまでの経過時間をsecsフィールドの代わりに利用することができます.
5. 動作
5.1 設定
この設定のステップは利用可能なサーバにハッシュ値を割り当てることから成ります.これは一つ以上のHBAが提供されていることで実現します.それらは,設定ファイルや,Windows NTレジストリ,EEPROMなどから構成されます.あるいは,HBAは決められたアルゴリズムを利用して割り当てることもできます.例: 奇数はserverA, 偶数はserverBが応答するなど.
5.2 サーバ向けのHBA
あるサーバを設定する時,32オクテットのシンプルなビットマップ形式を利用するべきです. HBAビットマップはじめのオクテットは0-7のHBA値で表現され,次は8-15,のように表現され,第32オクテットで248-255の値を表現します.それぞれのオクテットで,LSBはそのオクテットの最小のHBA値を表現します.
それぞれのHBAのビットは一つの取りうるハッシュ値にひもづきます.もしあるビットがビットマップにセットされていたら,それはSTIDのハッシュ値に対応して生成されたそれぞれのクライアントリクエストに応答しなければならないことを意味します.
たとえば,もしサーバには下記のような32オクテットのHBAが設定されていた場合,
FF FF FF FF FF FF 00 00 ( 0 - 63 ) FF FF FF FF FF FF FF FF ( 64 - 127 ) 00 00 00 00 00 00 00 00 (128 - 191 ) 00 00 00 00 00 00 00 00 (192 - 255 )
そのサーバはSTIDのハッシュがHack Backetの0-47,と64-127の値のであるあらゆるクライアントリクエストに対して応答しなければなりません.
5.3 遅延サービスパラメータ
遅延サービスパラメータはオプションです.
もしパラメータが設定されていない場合,HBAは厳格に"サービスする"/"サービスしない"というポリシを構成します.
もしパラメータが設定されていた場合,HBAやSTID hashに基づく特定のリクエストに対して応答することになっていないサーバが,クライアントのはじめの試行から, S 秒間経過したのちに応答することを許可します.
サーバはBOOTPヘッダのsecsフィールドをサービスを利用しようとした時からの経過時間として利用しても構いませんし,他の手法で繰り返しのリクエストを追跡しても構いません.
5.4 フォワーダ向けのHBA
BOOTP relayといった転送エージェントを設定する際,Server-IDとHack Backet値のペアからなるHBAが利用できます.
ここで,Server ID(SID)は特定のHack Backetを担うサーバを指定します.その転送エージェントはSTIDが特定のハッシュ値を生成した各クライアントリクエストを,SIDで指定されたサーバに転送します.このサーバIDは何らかのユニークなサーバ属性(例: IP address, DNS nameなど)が利用でき,リレーエージェントの動作上,意味があるものです.
フォワーダは1つ以上のサーバにパケットを転送するように設定されているかもしれません.たとえば,BOOTP relayは互いでDHCP Failover Protocolが動作している2つのprimary-backupサーバペアの間で負荷を分割するように設定さえうります.
このありがちな転送エージェント(例: BOOTP realy)の設定ファイルとして,下記のようなものがあります
192.33.43.11 192.33.43.12: 0..24; 192.33.43.13: 25..55; 192.33.43.15: 56..128; 192.33.43.16: 129 130 131 200..202;
上の設定は4つのHBAからなっています.はじめのHBAの例は次のように読み取れます: "STIDのハッシュ値が0-24となるすべてのクライアントリクエストは192.133.43.11と192.33.43.12の両方のサーバに転送されます"
6. ロードバランシング用ハッシュ関数
下記のハッシュ関数はピアソンハッシュとして知られるアルゴリズムのC言語の実装です.このピアソンハッシュアルゴリズムはもともと[PEARSON: The Communications of the ACM Vol.33, No. 6 (June 1990), pp. 677-680.] で公開されました.
このハッシュ関数はそれぞれのキーバイトに配列検索とXOR演算を必要とし,計算機的に軽量なものです.この提案を使うためには,相互運用性のあるすべての実装はこのハッシュ関数を使用する必要があります.ミキシングテーブルの値のセットを下記に示します:
/* A "mixing table" of 256 distinct values, in pseudo-random order. */ unsigned char loadb_mx_tbl[256] ={ 251, 175, 119, 215, 81, 14, 79, 191, 103, 49, 181, 143, 186, 157, 0, 232, 31, 32, 55, 60, 152, 58, 17, 237, 174, 70, 160, 144, 220, 90, 57, 223, 59, 3, 18, 140, 111, 166, 203, 196, 134, 243, 124, 95, 222, 179, 197, 65, 180, 48, 36, 15, 107, 46, 233, 130, 165, 30, 123, 161, 209, 23, 97, 16, 40, 91, 219, 61, 100, 10, 210, 109, 250, 127, 22, 138, 29, 108, 244, 67, 207, 9, 178, 204, 74, 98, 126, 249, 167, 116, 34, 77, 193, 200, 121, 5, 20, 113, 71, 35, 128, 13, 182, 94, 25, 226, 227, 199, 75, 27, 41, 245, 230, 224, 43, 225, 177, 26, 155, 150, 212, 142, 218, 115, 241, 73, 88, 105, 39, 114, 62, 255, 192, 201, 145, 214, 168, 158, 221, 148, 154, 122, 12, 84, 82, 163, 44, 139, 228, 236, 205, 242, 217, 11, 187, 146, 159, 64, 86, 239, 195, 42, 106, 198, 118, 112, 184, 172, 87, 2, 173, 117, 176, 229, 247, 253, 137, 185, 99, 164, 102, 147, 45, 66, 231, 52, 141, 211, 194, 206, 246, 238, 56, 110, 78, 248, 63, 240, 189, 93, 92, 51, 53, 183, 19, 171, 72, 50, 33, 104, 101, 69, 8, 252, 83, 120, 76, 135, 85, 54, 202, 125, 188, 213, 96, 235, 136, 208, 162, 129, 190, 132, 156, 38, 47, 1, 7, 254, 24, 4, 216, 131, 89, 21, 28, 133, 37, 153, 149, 80, 170, 68, 6, 169, 234, 151 }; unsigned char loadb_p_hash( const unsigned char *key, /* The key to be hashed */ const int len ) /* Key length in bytes */ { unsigned char hash = len; int i; for (i=len ; i > 0 ; ) hash = loadb_mx_tbl [ hash ^ key[ --i ] ]; return( hash ); } int accept_service_request( const unsigned char HBA[32], /* The hash bucket bitmap */ const unsigned char *key, /* The service transaction id*/ const int len ) /* length of the above */ { unsigned char hash = loadb_p_hash(key,len); int index = (hash >> 3) & 31; int bitmask = 1 << (hash & 7); /* return 1 if we should service this transaction */ return((HBA[index] & bitmask) != 0); }
7. セキュリティの考察
この提案の内容とそれ自身は,セキュリティを提供せず,既存のセキュリティに影響を与えることもありません.もし,HBAの内容がいずれかのサーバを構成するプロセスの一部としてネットワークに送信されることがある場合,このアルゴリズムを利用するサーバは,そのメッセージの改ざんの脅威から守る責任があります.HBAの改ざんによって,いくつかもしくはすべてのクライアントへのサービスの提供不可を招くためです.
8. 参考
[FAILOVR] Kinnear, K,, Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S. and B. Volz, "DHCP Failover Protocol", Work in Progress.
[PEARSON] The Communications of the ACM Vol.33, No. 6 (June 1990), pp. 677-680.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
9. 謝辞
ピアソンハッシュの著者であるPeter K. Pearsonに感謝します.彼は何の制約なしに彼のアルゴリズムを利用することを快く許可してくれました.
この提案は1999年2月,CISCO Systemsで開かれたFailover Protocolの会議中にTed LemonがMAC Addressを1ビットにハッシュ化する独特のアイディアが肝となっています.Rob StevensはFailover Protocolの目的を超えて,このアルゴリズムの有用性を示唆しました.
議論中にコメントをいただいた,Ralph Droms,Kim Kinnear,Mark Stapp,Glenn Waters,Greg Rabil,Jack Wongらに多大なる感謝をいたします.
まとめ
- KeaのHAやISC DHCPのFailoverではRFC 3074 - DHC Load Balancing Algorithmが利用されているようなのでとりあえず和訳してみた.
- STIDからピアソンハッシュアルゴリズムに基づいて0-255のハッシュ値をとり,そのハッシュ値とHBA bitmapを照らし合わせ,その値とANDを取った時trueである場合,自らが応答するという仕組みになっている.
- このHBAは設定ファイルやその他の方法で,冗長化するサーバ同士で適切に構成する必要があるが,その手法はこのRFCには含まない.
References
Kea DHCPのHigh-Availabilityを検証する - (2)Act-ActのLoad-Balancing構成を組む
ゴール
Kea DHCPを用いてAct-ActのLoad-Balancing High-Availability構成を組み,動作させることができること.
Kea DHCPでLoad-BalancibngモードのHA構成を組む
Introduction
前回,Kea DHCPでhot-standby
構成のHA構成を組む方法について紹介をした.
今回はhot-standby
ではないもう一つの方法であるload-balancing
モードでのHA構成を組んでみる.
検証条件は前回と同様(dockerfile, IPアドレスや本記事で紹介しないconfigなどすべて)であるので,kea自体の紹介や,環境構築等については前回の記事を参照してほしい.
本記事ではhot-standby
とload-balancing
モードの違いについて特に焦点を当てて紹介する.
configuration
早速configを行なっていく.
load-balancing
モードの利用に伴い,mode
や 各peer config内のrole
が異なってくる.
load-balancing
モードでkea_1
をprimary
, kea_2
をsecondary
とする場合,configは下記のようになる.
this-server-name: kea_1 //(2台目は"kea_2") mode: load-balancing heartbeat-delay: 10000 max-response-delay: 60000 max-ack-delay: 10000 max-unacked-clients: 0 "peers": [ { "name": "kea_1", "url": "http://172.18.0.3:8080/", "role": "primary", "auto-failover": true }, { "name": "kea_2", "url": "http://172.18.0.2:8080/", "role": "secondary", "auto-failover": true } ]
上記を踏まえてconfigを作成し,各サーバに適用して動作を確認してみよう.
たとえば私の検証では下記のようなconfigをkea_1
に投入した.kea_2
もほぼ同様であるが,"this-server-name"
等を適切に変更する.
root@085fd121c5c6:~# cat /usr/local/etc/kea/kea-dhcp4.conf { "Dhcp4": { "interfaces-config": { "interfaces": ["eth0"], "dhcp-socket-type": "raw", "outbound-interface": "use-routing" }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp4-ctrl.sock" }, "lease-database": { "type": "memfile", "persist": true, "name": "/usr/local/etc/kea/kea-leases4.csv", "lfc-interval": 1800 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1200, "rebind-timer": 2400, "valid-lifetime": 3600, "option-data": [ { "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" }, { "name": "default-ip-ttl", "data": "0xf0" } ], "hooks-libraries": [ { "library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so", "parameters": { } }, { "library": "/usr/local/lib/hooks/libdhcp_ha.so", "parameters": { "high-availability": [ { "this-server-name": "kea_1", "mode": "load-balancing", "heartbeat-delay": 10000, "max-response-delay": 10000, "max-ack-delay": 5000, "max-unacked-clients": 5, "peers": [ { "name": "kea_1", "url": "http://172.18.0.3:8080/", "role": "primary", "auto-failover": true }, { "name": "kea_2", "url": "http://172.18.0.2:8080/", "role": "secondary", "auto-failover": true } ] } ] } } ], "reservation-mode": "disabled", "host-reservation-identifiers": [ "hw-address" ], "subnet4": [ { "id": 1, "subnet": "172.18.0.0/16", "pools": [ { "pool": "172.18.0.100 - 172.18.0.250" } ], "option-data": [ { "name": "routers", "data": "172.18.0.1" } ] } ] }, "Logging": { "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "/usr/local/var/log/kea-dhcp4.log", "maxver": 8, "maxsize": 204800, "flush": true } ], "severity": "DEBUG", "debuglevel": 99 } ] } }
まずはkea_1
でkeaを起動する.今回,起動にはkeactrl
コマンドを用いた.
起動後にRESTAPIでha-heartbeat
を送信していることと,それぞれのサーバのステータスを見てみよう.
# kea_1 root@085fd121c5c6:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.3:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to 172.18.0.3 port 8080: Connection refused root@085fd121c5c6:~# keactrl start INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.conf root@085fd121c5c6:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.3:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 191 100 138 100 53 34500 13250 --:--:-- --:--:-- --:--:-- 63666 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:56:46 GMT", "state": "waiting" }, "result": 0, "text": "HA peer status returned." } ] root@085fd121c5c6:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.3:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 196 100 143 100 53 11916 4416 --:--:-- --:--:-- --:--:-- 17818 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:56:50 GMT", "state": "partner-down" }, "result": 0, "text": "HA peer status returned." } ]
起動後,kea_1
はstateが waiting
から,partner-down
にシフトしていることが見受けられる.
kea_1
を起動し,kea_2
を起動していない場合,kea_1
はこの状態(partner-down)に収束する.
ここでkea_2
を起動する.
# kea_2 root@05e1a4a4476e:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.2:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to 172.18.0.2 port 8080: Connection refused root@05e1a4a4476e:~# keactrl start INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.conf root@05e1a4a4476e:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.2:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 100 191 100 138 100 53 46000 17666 --:--:-- --:--:-- --:--:-- 95500 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:57:12 GMT", "state": "waiting" }, "result": 0, "text": "HA peer status returned." } ] root@05e1a4a4476e:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.2:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 100 191 100 138 100 53 34500 13250 --:--:-- --:--:-- --:--:-- 63666 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:57:20 GMT", "state": "waiting" }, "result": 0, "text": "HA peer status returned." } ] root@05e1a4a4476e:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.2:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 100 189 100 136 100 53 12363 4818 --:--:-- --:--:-- --:--:-- 21000 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:57:32 GMT", "state": "ready" }, "result": 0, "text": "HA peer status returned." } ] root@05e1a4a4476e:~# curl -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http://172.18.0.2:8080/ | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 100 198 100 145 100 53 7250 2650 --:--:-- --:--:-- --:--:-- 9900 [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:57:36 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ]
ログを見てみる.
# kea_1 root@085fd121c5c6:/# grep INFO /usr/local/var/log/kea-dhcp4.log | grep ha-hooks 2019-11-20 06:56:39.814 INFO [kea-dhcp4.ha-hooks/387] HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully configured 2019-11-20 06:56:39.814 INFO [kea-dhcp4.ha-hooks/387] HA_INIT_OK loading High Availability hooks library successful 2019-11-20 06:56:39.884 INFO [kea-dhcp4.ha-hooks/387] HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the kea_1 is in the WAITING state 2019-11-20 06:56:39.884 INFO [kea-dhcp4.ha-hooks/387] HA_SERVICE_STARTED started high availability service in load-balancing mode as primary server 2019-11-20 06:56:50.323 INFO [kea-dhcp4.ha-hooks/387] HA_STATE_TRANSITION server transitions from WAITING to PARTNER-DOWN state, partner state is UNDEFINED 2019-11-20 06:56:50.323 INFO [kea-dhcp4.ha-hooks/387] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in PARTNER-DOWN state 2019-11-20 06:56:50.323 INFO [kea-dhcp4.ha-hooks/387] HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the kea_1 is in the PARTNER-DOWN state 2019-11-20 06:57:33.825 INFO [kea-dhcp4.ha-hooks/387] HA_STATE_TRANSITION server transitions from PARTNER-DOWN to LOAD-BALANCING state, partner state is READY 2019-11-20 06:57:33.825 INFO [kea-dhcp4.ha-hooks/387] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in LOAD-BALANCING state root@085fd121c5c6:/#
# kea_2 root@05e1a4a4476e:/# grep INFO /usr/local/var/log/kea-dhcp4.log | grep ha-hooks 2019-11-20 06:57:11.496 INFO [kea-dhcp4.ha-hooks/512] HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully configured 2019-11-20 06:57:11.496 INFO [kea-dhcp4.ha-hooks/512] HA_INIT_OK loading High Availability hooks library successful 2019-11-20 06:57:11.528 INFO [kea-dhcp4.ha-hooks/512] HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the kea_2 is in the WAITING state 2019-11-20 06:57:11.528 INFO [kea-dhcp4.ha-hooks/512] HA_SERVICE_STARTED started high availability service in load-balancing mode as secondary server 2019-11-20 06:57:23.295 INFO [kea-dhcp4.ha-hooks/512] HA_STATE_TRANSITION server transitions from WAITING to SYNCING state, partner state is PARTNER-DOWN 2019-11-20 06:57:23.295 INFO [kea-dhcp4.ha-hooks/512] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in SYNCING state 2019-11-20 06:57:23.295 INFO [kea-dhcp4.ha-hooks/512] HA_SYNC_START starting lease database synchronization with kea_1 2019-11-20 06:57:23.306 INFO [kea-dhcp4.ha-hooks/512] HA_LEASES_SYNC_LEASE_PAGE_RECEIVED received 0 leases from kea_1 2019-11-20 06:57:23.308 INFO [kea-dhcp4.ha-hooks/512] HA_SYNC_SUCCESSFUL lease database synchronization with kea_1 completed successfully in 12.135 ms 2019-11-20 06:57:23.308 INFO [kea-dhcp4.ha-hooks/512] HA_STATE_TRANSITION server transitions from SYNCING to READY state, partner state is PARTNER-DOWN 2019-11-20 06:57:23.308 INFO [kea-dhcp4.ha-hooks/512] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in READY state 2019-11-20 06:57:34.860 INFO [kea-dhcp4.ha-hooks/512] HA_STATE_TRANSITION server transitions from READY to LOAD-BALANCING state, partner state is LOAD-BALANCING 2019-11-20 06:57:34.860 INFO [kea-dhcp4.ha-hooks/512] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in LOAD-BALANCING state 2019-11-20 06:57:34.860 INFO [kea-dhcp4.ha-hooks/512] HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the kea_2 is in the LOAD-BALANCING state root@05e1a4a4476e:/#
これらをみてみると,起動直後,これらのHAは下記のような順序で状態遷移していることがわかる.
2019-11-20 06:56:39.884:: kea_1: waiting , kea_2: UNDEFINED 2019-11-20 06:56:50.323:: kea_1: partner-down, kea_2: UNDEFINED 2019-11-20 06:57:11.528:: kea_1: partner-down, kea_2: waiting 2019-11-20 06:57:23.295:: kea_1: partner-down, kea_2: syncing 2019-11-20 06:57:23.308:: kea_1: partner-down, kea_2: ready 2019-11-20 06:57:33.825:: kea_1: load-balancing, kea_2: ready 2019-11-20 06:57:34.860:: kea_1: load-balancing , kea_2: load-balancing
このそれぞれのstateの意味はkeaのdocumentを参照していただくのがbestだと思うが,前回の記事でも簡単に説明しているので参考になるかもしれない.
load-balancingモードでのDHCPリース動作
HA構成を組むことができていることが確認できたので,この状態でDHCPのアドレスリースを行い,HA構成に受けるアドレスリース時の振る舞いを確認していこうと思う.
DHCPリースを模擬するために,前回同様,dhtestを利用した.
load-balancingモードでHA構成が組まれたサーバ群が接続されているNW上に存在するdhtest用VMで,下記の通りコマンドを実行する.
./dhtest -i <interface> -m <mac_addr>
mac_addr
はdhtestホストから送出するDHCPパケットのchaddr
フィールドに入るMACアドレスと思えばよい.
これを数回繰り返し実施した時の振る舞いを見てみる.
dhtestホストでは下記のようにアドレスリースが模擬できているようである.
[root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:33 DHCP discover sent - Client MAC : 00:00:00:11:22:33 DHCP offer received - Offered IP : 172.18.0.100 DHCP request sent - Client MAC : 00:00:00:11:22:33 DHCP ack received - Acquired IP: 172.18.0.100 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:34 DHCP discover sent - Client MAC : 00:00:00:11:22:34 DHCP offer received - Offered IP : 172.18.0.101 DHCP request sent - Client MAC : 00:00:00:11:22:34 ADHCP ack received - Acquired IP: 172.18.0.101 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:35 DHCP discover sent - Client MAC : 00:00:00:11:22:35 DHCP offer received - Offered IP : 172.18.0.102 DHCP request sent - Client MAC : 00:00:00:11:22:35 DHCP ack received - Acquired IP: 172.18.0.102 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:36 DHCP discover sent - Client MAC : 00:00:00:11:22:36 DHCP offer received - Offered IP : 172.18.0.103 DHCP request sent - Client MAC : 00:00:00:11:22:36 DHCP ack received - Acquired IP: 172.18.0.103 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:37 DHCP discover sent - Client MAC : 00:00:00:11:22:37 DHCP offer received - Offered IP : 172.18.0.104 DHCP request sent - Client MAC : 00:00:00:11:22:37 DHCP ack received - Acquired IP: 172.18.0.104 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:38 DHCP discover sent - Client MAC : 00:00:00:11:22:38 DHCP offer received - Offered IP : 172.18.0.105 DHCP request sent - Client MAC : 00:00:00:11:22:38 DHCP ack received - Acquired IP: 172.18.0.105 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:39 DHCP discover sent - Client MAC : 00:00:00:11:22:39 DHCP offer received - Offered IP : 172.18.0.106 DHCP request sent - Client MAC : 00:00:00:11:22:39 DHCP ack received - Acquired IP: 172.18.0.106 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:40 DHCP discover sent - Client MAC : 00:00:00:11:22:40 DHCP offer received - Offered IP : 172.18.0.107 DHCP request sent - Client MAC : 00:00:00:11:22:40 DHCP ack received - Acquired IP: 172.18.0.107 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:41 DHCP discover sent - Client MAC : 00:00:00:11:22:41 DHCP offer received - Offered IP : 172.18.0.108 DHCP request sent - Client MAC : 00:00:00:11:22:41 DHCP ack received - Acquired IP: 172.18.0.108 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:42 DHCP discover sent - Client MAC : 00:00:00:11:22:42 DHCP offer received - Offered IP : 172.18.0.109 DHCP request sent - Client MAC : 00:00:00:11:22:42 DHCP ack received - Acquired IP: 172.18.0.109 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:43 DHCP discover sent - Client MAC : 00:00:00:11:22:43 DHCP offer received - Offered IP : 172.18.0.110 DHCP request sent - Client MAC : 00:00:00:11:22:43 DHCP ack received - Acquired IP: 172.18.0.110 [root@a50202e240fb dhtest-master]#
この時,kea_1
とkea_2
ホストでパケットキャプチャを行うと.
## kea_1 root@085fd121c5c6:/# tcpdump -i eth0 port 67 or port 68 -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^[[O06:59:13.512449 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:33 (oui Ethernet), length 251, xid 0x2960582c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:13.552499 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:33 (oui Ethernet), length 263, xid 0x2960582c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.100 Server-ID Option 54, length 4: kea_2.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:18.869778 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:34 (oui Ethernet), length 251, xid 0x31c40ac1, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:18.871641 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 085fd121c5c6.bootps > 172.18.0.101.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x31c40ac1, Flags [none] Your-IP 172.18.0.101 Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 085fd121c5c6 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:18.872159 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:34 (oui Ethernet), length 263, xid 0x31c40ac1, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.101 Server-ID Option 54, length 4: 085fd121c5c6 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:19.878008 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 085fd121c5c6.bootps > 172.18.0.101.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x31c40ac1, Flags [none] Your-IP 172.18.0.101 Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 085fd121c5c6 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:22.559720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:35 (oui Ethernet), length 251, xid 0x4c120d1c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:22.563249 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:35 (oui Ethernet), length 263, xid 0x4c120d1c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.102 Server-ID Option 54, length 4: kea_2.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:26.252357 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:36 (oui Ethernet), length 251, xid 0x671e7d0f, Flags [none] Client-Ethernet-Address 00:00:00:11:22:36 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:26.265846 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:36 (oui Ethernet), length 263, xid 0x671e7d0f, Flags [none] Client-Ethernet-Address 00:00:00:11:22:36 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.103 Server-ID Option 54, length 4: kea_2.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:38.855959 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:40 (oui Ethernet), length 251, xid 0x16e71cb, Flags [none] Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:38.857611 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 085fd121c5c6.bootps > 172.18.0.107.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x16e71cb, Flags [none] Your-IP 172.18.0.107 Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 085fd121c5c6 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:38.857778 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:40 (oui Ethernet), length 263, xid 0x16e71cb, Flags [none] Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.107 Server-ID Option 54, length 4: 085fd121c5c6 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:39.859876 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 085fd121c5c6.bootps > 172.18.0.107.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x16e71cb, Flags [none] Your-IP 172.18.0.107 Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 085fd121c5c6 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:41.995310 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:41 (oui Ethernet), length 251, xid 0x44f61b6e, Flags [none] Client-Ethernet-Address 00:00:00:11:22:41 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:41.996738 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 085fd121c5c6.bootps > 172.18.0.108.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x44f61b6e, Flags [none] Your-IP 172.18.0.108 Client-Ethernet-Address 00:00:00:11:22:41 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 085fd121c5c6 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:46.075757 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:42 (oui Ethernet), length 251, xid 0x4da855db, Flags [none] Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:46.078611 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:42 (oui Ethernet), length 263, xid 0x4da855db, Flags [none] Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.109 Server-ID Option 54, length 4: kea_2.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:49.416302 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:43 (oui Ethernet), length 251, xid 0x39e5fa04, Flags [none] Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:49.418794 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:43 (oui Ethernet), length 263, xid 0x39e5fa04, Flags [none] Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.110 Server-ID Option 54, length 4: kea_2.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server ^C 20 packets captured 32 packets received by filter 12 packets dropped by kernel root@085fd121c5c6:/#
## kea_2 root@05e1a4a4476e:/# tcpdump -i eth0 port 67 or port 68 -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:59:13.512513 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:33 (oui Ethernet), length 251, xid 0x2960582c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:13.551115 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.100.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x2960582c, Flags [none] Your-IP 172.18.0.100 Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:13.552540 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:33 (oui Ethernet), length 263, xid 0x2960582c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.100 Server-ID Option 54, length 4: 05e1a4a4476e Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:14.559982 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.100.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x2960582c, Flags [none] Your-IP 172.18.0.100 Client-Ethernet-Address 00:00:00:11:22:33 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:18.869813 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:34 (oui Ethernet), length 251, xid 0x31c40ac1, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:18.872189 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:34 (oui Ethernet), length 263, xid 0x31c40ac1, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.101 Server-ID Option 54, length 4: kea_1.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:22.559775 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:35 (oui Ethernet), length 251, xid 0x4c120d1c, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:22.561696 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.102.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x4c120d1c, Flags [none] Your-IP 172.18.0.102 Client-Ethernet-Address 00:00:00:11:22:35 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:38.856100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:40 (oui Ethernet), length 251, xid 0x16e71cb, Flags [none] Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:38.857816 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:40 (oui Ethernet), length 263, xid 0x16e71cb, Flags [none] Client-Ethernet-Address 00:00:00:11:22:40 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.107 Server-ID Option 54, length 4: kea_1.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:41.995354 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:41 (oui Ethernet), length 251, xid 0x44f61b6e, Flags [none] Client-Ethernet-Address 00:00:00:11:22:41 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:41.996990 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:41 (oui Ethernet), length 263, xid 0x44f61b6e, Flags [none] Client-Ethernet-Address 00:00:00:11:22:41 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.108 Server-ID Option 54, length 4: kea_1.kea-mng Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:46.075816 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:42 (oui Ethernet), length 251, xid 0x4da855db, Flags [none] Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:46.077736 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.109.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x4da855db, Flags [none] Your-IP 172.18.0.109 Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:46.078692 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:42 (oui Ethernet), length 263, xid 0x4da855db, Flags [none] Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.109 Server-ID Option 54, length 4: 05e1a4a4476e Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:47.091865 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.109.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x4da855db, Flags [none] Your-IP 172.18.0.109 Client-Ethernet-Address 00:00:00:11:22:42 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:49.416473 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:43 (oui Ethernet), length 251, xid 0x39e5fa04, Flags [none] Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:49.418437 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.110.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x39e5fa04, Flags [none] Your-IP 172.18.0.110 Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:59:49.418845 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:00:00:11:22:43 (oui Ethernet), length 263, xid 0x39e5fa04, Flags [none] Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.0.110 Server-ID Option 54, length 4: 05e1a4a4476e Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:59:50.424369 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 05e1a4a4476e.bootps > 172.18.0.110.bootpc: BOOTP/DHCP, Reply, length 290, xid 0x39e5fa04, Flags [none] Your-IP 172.18.0.110 Client-Ethernet-Address 00:00:00:11:22:43 (oui Ethernet) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: dns.google,dns.google Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 05e1a4a4476e RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 ^C 20 packets captured 34 packets received by filter 14 packets dropped by kernel root@05e1a4a4476e:/#
これら2つのパケットキャプチャをみて理解できるとおり,
kea_1
でもkea_2
でも,はクライアントからのDHCP要求(DISCOVERY
, REQUEST
)において,クライアントに対してOFFER
, ACK
を返していることがわかる.
これはHAモードのうち,両方のサーバがDHCPに応答するload-balancing
の動作となっていることがわかる.
ただし,kea_1
とkea_2
が完全に1回ごとに交互にリース動作をするのではなく,複数回同じserverが連続して応答することもあることが見て取れる.
これはKea DHCPのload-balancingがRFC3074に基づいて実装されているからであるように見受けられる.
RFC3074によると,DHCPDISCOVERパケットのある値からハッシュを取り,その値は0-255の値をとる.ロードバランシング構成がとられたそれぞれのサーバではあるテーブルをもつ.それは自分が応答するべき値が1となるように構成された32bytesのテーブルである(32 * 8 = 256).この256ビットのテーブルと,DHCPDISCOVERパケットから計算されたハッシュ値を比較し,自分が応答すべき場合にのみDHCPOFFERパケットを送付して応答するロジックとなっているようだ.そのため,マクロ的,長期的にみると設計された負荷分散率となるが,ミクロ的,短時間的にみると偏りが生まれる可能性は十分に考えられる.今回繰り返して同一のサーバが応答したこともこの特徴的なアルゴリズムの振る舞いによるものだと考えることができるだろう.
- 追記: RFC3074を和訳しました.RFC 3074を読んでみた話 - JP7FKFの備忘録
- ref: Kea High Availability vs ISC DHCP Failover - Kea DHCP
またこの時のlease-update
を見てみよう.
## kea_1 06:59:13.558097 IP (tos 0x0, ttl 64, id 5427, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x1fc4), seq 124:477, ack 255, win 321, options [nop,nop,TS val 7878270 ecr 7878004], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236753, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:33", "ip-address": "172.18.0.100", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:13.568131 IP (tos 0x0, ttl 64, id 176, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x5eef), seq 255:411, ack 477, win 235, options [nop,nop,TS val 7878271 ecr 7878270], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:13 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:13.568225 IP (tos 0x0, ttl 64, id 5428, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x2781), ack 411, win 329, options [nop,nop,TS val 7878271 ecr 7878271], length 0 06:59:17.049416 IP (tos 0x0, ttl 64, id 24059, offset 0, flags [DF], proto TCP (6), length 176) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x7191), seq 124:248, ack 255, win 312, options [nop,nop,TS val 7878620 ecr 7877403], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:17.053342 IP (tos 0x0, ttl 64, id 6822, offset 0, flags [DF], proto TCP (6), length 306) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x594e (incorrect -> 0xdb0c), seq 255:509, ack 248, win 227, options [nop,nop,TS val 7878620 ecr 7878620], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:17 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:17 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:17.053369 IP (tos 0x0, ttl 64, id 24060, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xf4b4), ack 509, win 321, options [nop,nop,TS val 7878620 ecr 7878620], length 0 06:59:18.874313 IP (tos 0x0, ttl 64, id 24061, offset 0, flags [DF], proto TCP (6), length 405) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xe230), seq 248:601, ack 509, win 321, options [nop,nop,TS val 7878802 ecr 7878620], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236758, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:34", "ip-address": "172.18.0.101", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:18.877715 IP (tos 0x0, ttl 64, id 6823, offset 0, flags [DF], proto TCP (6), length 208) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x28ac), seq 509:665, ack 601, win 235, options [nop,nop,TS val 7878802 ecr 7878802], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:18 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:18.877843 IP (tos 0x0, ttl 64, id 24062, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xf143), ack 665, win 329, options [nop,nop,TS val 7878802 ecr 7878802], length 0 06:59:22.561975 IP (tos 0x0, ttl 64, id 5429, offset 0, flags [DF], proto TCP (6), length 176) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x9a95), seq 477:601, ack 411, win 329, options [nop,nop,TS val 7879171 ecr 7878271], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:22.563407 IP (tos 0x0, ttl 64, id 177, offset 0, flags [DF], proto TCP (6), length 306) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x594e (incorrect -> 0x0f55), seq 411:665, ack 601, win 235, options [nop,nop,TS val 7879171 ecr 7879171], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:22 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:22 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:22.563509 IP (tos 0x0, ttl 64, id 5430, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x1ef7), ack 665, win 337, options [nop,nop,TS val 7879171 ecr 7879171], length 0 06:59:22.574735 IP (tos 0x0, ttl 64, id 5431, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x1127), seq 601:954, ack 665, win 337, options [nop,nop,TS val 7879172 ecr 7879171], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236762, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:35", "ip-address": "172.18.0.102", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:22.584285 IP (tos 0x0, ttl 64, id 178, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x5365), seq 665:821, ack 954, win 243, options [nop,nop,TS val 7879173 ecr 7879172], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:22 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:22.628444 IP (tos 0x0, ttl 64, id 5432, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x1ce8), ack 821, win 346, options [nop,nop,TS val 7879178 ecr 7879173], length 0 06:59:26.274709 IP (tos 0x0, ttl 64, id 5433, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x07ad), seq 954:1307, ack 821, win 346, options [nop,nop,TS val 7879542 ecr 7879173], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236766, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:36", "ip-address": "172.18.0.103", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:26.327869 IP (tos 0x0, ttl 64, id 179, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x4e73), seq 821:977, ack 1307, win 252, options [nop,nop,TS val 7879547 ecr 7879542], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:26 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:26.328036 IP (tos 0x0, ttl 64, id 5434, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x17fc), ack 977, win 354, options [nop,nop,TS val 7879547 ecr 7879547], length 0 06:59:28.296754 IP (tos 0x0, ttl 64, id 24063, offset 0, flags [DF], proto TCP (6), length 176) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x642a), seq 601:725, ack 665, win 329, options [nop,nop,TS val 7879748 ecr 7878802], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:28.298602 IP (tos 0x0, ttl 64, id 6824, offset 0, flags [DF], proto TCP (6), length 306) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x594e (incorrect -> 0xccbb), seq 665:919, ack 725, win 235, options [nop,nop,TS val 7879748 ecr 7879748], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:28 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:28 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:28.298650 IP (tos 0x0, ttl 64, id 24064, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xe85d), ack 919, win 337, options [nop,nop,TS val 7879748 ecr 7879748], length 0 06:59:29.229170 IP (tos 0x0, ttl 64, id 5435, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xfe06), seq 1307:1660, ack 977, win 354, options [nop,nop,TS val 7879841 ecr 7879547], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236769, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:37", "ip-address": "172.18.0.104", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:29.230833 IP (tos 0x0, ttl 64, id 180, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x4a1a), seq 977:1133, ack 1660, win 260, options [nop,nop,TS val 7879841 ecr 7879841], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:29 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:29.230925 IP (tos 0x0, ttl 64, id 5436, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x13aa), ack 1133, win 363, options [nop,nop,TS val 7879841 ecr 7879841], length 0 06:59:32.314046 IP (tos 0x0, ttl 64, id 24065, offset 0, flags [DF], proto TCP (6), length 405) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xd2fc), seq 725:1078, ack 919, win 337, options [nop,nop,TS val 7880149 ecr 7879748], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236772, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:38", "ip-address": "172.18.0.105", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:32.317924 IP (tos 0x0, ttl 64, id 6825, offset 0, flags [DF], proto TCP (6), length 208) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x18ac), seq 919:1075, ack 1078, win 243, options [nop,nop,TS val 7880150 ecr 7880149], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:32 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:32.317973 IP (tos 0x0, ttl 64, id 24066, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xe333), ack 1075, win 346, options [nop,nop,TS val 7880150 ecr 7880150], length 0 06:59:33.319217 IP (tos 0x0, ttl 64, id 5437, offset 0, flags [DF], proto TCP (6), length 176) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x88a9), seq 1660:1784, ack 1133, win 363, options [nop,nop,TS val 7880250 ecr 7879841], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:33.322421 IP (tos 0x0, ttl 64, id 181, offset 0, flags [DF], proto TCP (6), length 306) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x594e (incorrect -> 0xfd5a), seq 1133:1387, ack 1784, win 260, options [nop,nop,TS val 7880250 ecr 7880250], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:33 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:33 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:33.322543 IP (tos 0x0, ttl 64, id 5438, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0ef6), ack 1387, win 371, options [nop,nop,TS val 7880250 ecr 7880250], length 0 06:59:35.557413 IP (tos 0x0, ttl 64, id 24067, offset 0, flags [DF], proto TCP (6), length 405) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc91f), seq 1078:1431, ack 1075, win 346, options [nop,nop,TS val 7880474 ecr 7880150], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236775, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:39", "ip-address": "172.18.0.106", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:35.559028 IP (tos 0x0, ttl 64, id 6826, offset 0, flags [DF], proto TCP (6), length 208) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x141a), seq 1075:1231, ack 1431, win 252, options [nop,nop,TS val 7880474 ecr 7880474], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:35 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:35.559069 IP (tos 0x0, ttl 64, id 24068, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xdea6), ack 1231, win 354, options [nop,nop,TS val 7880474 ecr 7880474], length 0 06:59:38.859078 IP (tos 0x0, ttl 64, id 24069, offset 0, flags [DF], proto TCP (6), length 405) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc98b), seq 1431:1784, ack 1231, win 354, options [nop,nop,TS val 7880804 ecr 7880474], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236778, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:40", "ip-address": "172.18.0.107", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:38.861084 IP (tos 0x0, ttl 64, id 6827, offset 0, flags [DF], proto TCP (6), length 208) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x0f7e), seq 1231:1387, ack 1784, win 260, options [nop,nop,TS val 7880804 ecr 7880804], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:38 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:38.861128 IP (tos 0x0, ttl 64, id 24070, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xda0c), ack 1387, win 363, options [nop,nop,TS val 7880804 ecr 7880804], length 0 06:59:39.860222 IP (tos 0x0, ttl 64, id 24071, offset 0, flags [DF], proto TCP (6), length 176) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x5041), seq 1784:1908, ack 1387, win 363, options [nop,nop,TS val 7880904 ecr 7880804], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:39.864235 IP (tos 0x0, ttl 64, id 6828, offset 0, flags [DF], proto TCP (6), length 306) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x594e (incorrect -> 0xba27), seq 1387:1641, ack 1908, win 260, options [nop,nop,TS val 7880904 ecr 7880904], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:39 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:39 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:39.864285 IP (tos 0x0, ttl 64, id 24072, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xd7c1), ack 1641, win 371, options [nop,nop,TS val 7880905 ecr 7880904], length 0 06:59:41.998380 IP (tos 0x0, ttl 64, id 24073, offset 0, flags [DF], proto TCP (6), length 405) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc81a), seq 1908:2261, ack 1641, win 371, options [nop,nop,TS val 7881118 ecr 7880904], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236781, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:41", "ip-address": "172.18.0.108", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:42.008824 IP (tos 0x0, ttl 64, id 6829, offset 0, flags [DF], proto TCP (6), length 208) kea_2.kea-mng.http-alt > 085fd121c5c6.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x088f), seq 1641:1797, ack 2261, win 269, options [nop,nop,TS val 7881119 ecr 7881118], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:42 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:42.008877 IP (tos 0x0, ttl 64, id 24074, offset 0, flags [DF], proto TCP (6), length 52) 085fd121c5c6.44216 > kea_2.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xd40f), ack 1797, win 379, options [nop,nop,TS val 7881119 ecr 7881119], length 0 06:59:45.015705 IP (tos 0x0, ttl 64, id 5439, offset 0, flags [DF], proto TCP (6), length 176) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x80fc), seq 1784:1908, ack 1387, win 371, options [nop,nop,TS val 7881420 ecr 7880250], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:45.022784 IP (tos 0x0, ttl 64, id 182, offset 0, flags [DF], proto TCP (6), length 306) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x594e (incorrect -> 0xeeba), seq 1387:1641, ack 1908, win 260, options [nop,nop,TS val 7881420 ecr 7881420], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:45 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:45 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:45.022912 IP (tos 0x0, ttl 64, id 5440, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0450), ack 1641, win 379, options [nop,nop,TS val 7881420 ecr 7881420], length 0 06:59:46.089643 IP (tos 0x0, ttl 64, id 5441, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xee12), seq 1908:2261, ack 1641, win 379, options [nop,nop,TS val 7881527 ecr 7881420], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236786, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:42", "ip-address": "172.18.0.109", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:46.100810 IP (tos 0x0, ttl 64, id 183, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x35f6), seq 1641:1797, ack 2261, win 269, options [nop,nop,TS val 7881528 ecr 7881527], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:46 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:46.101035 IP (tos 0x0, ttl 64, id 5442, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0172), ack 1797, win 388, options [nop,nop,TS val 7881528 ecr 7881528], length 0 06:59:49.422866 IP (tos 0x0, ttl 64, id 5443, offset 0, flags [DF], proto TCP (6), length 405) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xef52), seq 2261:2614, ack 1797, win 388, options [nop,nop,TS val 7881860 ecr 7881528], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236789, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:43", "ip-address": "172.18.0.110", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:49.430796 IP (tos 0x0, ttl 64, id 184, offset 0, flags [DF], proto TCP (6), length 208) 085fd121c5c6.http-alt > kea_2.kea-mng.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x3154), seq 1797:1953, ack 2614, win 277, options [nop,nop,TS val 7881861 ecr 7881860], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:49 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:49.430907 IP (tos 0x0, ttl 64, id 5444, offset 0, flags [DF], proto TCP (6), length 52) kea_2.kea-mng.47044 > 085fd121c5c6.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xfcd2), ack 1953, win 396, options [nop,nop,TS val 7881861 ecr 7881861], length 0
## kea_2 06:59:13.558062 IP (tos 0x0, ttl 64, id 5427, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x1fc4), seq 124:477, ack 255, win 321, options [nop,nop,TS val 7878270 ecr 7878004], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236753, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:33", "ip-address": "172.18.0.100", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:13.568183 IP (tos 0x0, ttl 64, id 176, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x5eef), seq 255:411, ack 477, win 235, options [nop,nop,TS val 7878271 ecr 7878270], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:13 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:13.568211 IP (tos 0x0, ttl 64, id 5428, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x2781), ack 411, win 329, options [nop,nop,TS val 7878271 ecr 7878271], length 0 06:59:17.049679 IP (tos 0x0, ttl 64, id 24059, offset 0, flags [DF], proto TCP (6), length 176) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x7191), seq 124:248, ack 255, win 312, options [nop,nop,TS val 7878620 ecr 7877403], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:17.053316 IP (tos 0x0, ttl 64, id 6822, offset 0, flags [DF], proto TCP (6), length 306) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x594e (incorrect -> 0xdb0c), seq 255:509, ack 248, win 227, options [nop,nop,TS val 7878620 ecr 7878620], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:17 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:17 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:17.053384 IP (tos 0x0, ttl 64, id 24060, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xf4b4), ack 509, win 321, options [nop,nop,TS val 7878620 ecr 7878620], length 0 06:59:18.874376 IP (tos 0x0, ttl 64, id 24061, offset 0, flags [DF], proto TCP (6), length 405) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xe230), seq 248:601, ack 509, win 321, options [nop,nop,TS val 7878802 ecr 7878620], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236758, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:34", "ip-address": "172.18.0.101", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:18.877454 IP (tos 0x0, ttl 64, id 6823, offset 0, flags [DF], proto TCP (6), length 208) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x28ac), seq 509:665, ack 601, win 235, options [nop,nop,TS val 7878802 ecr 7878802], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:18 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:18.877877 IP (tos 0x0, ttl 64, id 24062, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xf143), ack 665, win 329, options [nop,nop,TS val 7878802 ecr 7878802], length 0 06:59:22.561932 IP (tos 0x0, ttl 64, id 5429, offset 0, flags [DF], proto TCP (6), length 176) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x9a95), seq 477:601, ack 411, win 329, options [nop,nop,TS val 7879171 ecr 7878271], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:22.563444 IP (tos 0x0, ttl 64, id 177, offset 0, flags [DF], proto TCP (6), length 306) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x594e (incorrect -> 0x0f55), seq 411:665, ack 601, win 235, options [nop,nop,TS val 7879171 ecr 7879171], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:22 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:22 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:22.563492 IP (tos 0x0, ttl 64, id 5430, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x1ef7), ack 665, win 337, options [nop,nop,TS val 7879171 ecr 7879171], length 0 06:59:22.574582 IP (tos 0x0, ttl 64, id 5431, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x1127), seq 601:954, ack 665, win 337, options [nop,nop,TS val 7879172 ecr 7879171], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236762, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:35", "ip-address": "172.18.0.102", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:22.584353 IP (tos 0x0, ttl 64, id 178, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x5365), seq 665:821, ack 954, win 243, options [nop,nop,TS val 7879173 ecr 7879172], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:22 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:22.628326 IP (tos 0x0, ttl 64, id 5432, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x1ce8), ack 821, win 346, options [nop,nop,TS val 7879178 ecr 7879173], length 0 06:59:26.274675 IP (tos 0x0, ttl 64, id 5433, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0x07ad), seq 954:1307, ack 821, win 346, options [nop,nop,TS val 7879542 ecr 7879173], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236766, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:36", "ip-address": "172.18.0.103", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:26.327969 IP (tos 0x0, ttl 64, id 179, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x4e73), seq 821:977, ack 1307, win 252, options [nop,nop,TS val 7879547 ecr 7879542], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:26 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:26.328020 IP (tos 0x0, ttl 64, id 5434, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x17fc), ack 977, win 354, options [nop,nop,TS val 7879547 ecr 7879547], length 0 06:59:28.296804 IP (tos 0x0, ttl 64, id 24063, offset 0, flags [DF], proto TCP (6), length 176) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x642a), seq 601:725, ack 665, win 329, options [nop,nop,TS val 7879748 ecr 7878802], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:28.298553 IP (tos 0x0, ttl 64, id 6824, offset 0, flags [DF], proto TCP (6), length 306) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x594e (incorrect -> 0xccbb), seq 665:919, ack 725, win 235, options [nop,nop,TS val 7879748 ecr 7879748], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:28 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:28 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:28.298689 IP (tos 0x0, ttl 64, id 24064, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xe85d), ack 919, win 337, options [nop,nop,TS val 7879748 ecr 7879748], length 0 06:59:29.229138 IP (tos 0x0, ttl 64, id 5435, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xfe06), seq 1307:1660, ack 977, win 354, options [nop,nop,TS val 7879841 ecr 7879547], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236769, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:37", "ip-address": "172.18.0.104", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:29.230883 IP (tos 0x0, ttl 64, id 180, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x4a1a), seq 977:1133, ack 1660, win 260, options [nop,nop,TS val 7879841 ecr 7879841], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:29 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:29.230912 IP (tos 0x0, ttl 64, id 5436, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x13aa), ack 1133, win 363, options [nop,nop,TS val 7879841 ecr 7879841], length 0 06:59:32.314326 IP (tos 0x0, ttl 64, id 24065, offset 0, flags [DF], proto TCP (6), length 405) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xd2fc), seq 725:1078, ack 919, win 337, options [nop,nop,TS val 7880149 ecr 7879748], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236772, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:38", "ip-address": "172.18.0.105", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:32.317838 IP (tos 0x0, ttl 64, id 6825, offset 0, flags [DF], proto TCP (6), length 208) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x18ac), seq 919:1075, ack 1078, win 243, options [nop,nop,TS val 7880150 ecr 7880149], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:32 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:32.317988 IP (tos 0x0, ttl 64, id 24066, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xe333), ack 1075, win 346, options [nop,nop,TS val 7880150 ecr 7880150], length 0 06:59:33.319178 IP (tos 0x0, ttl 64, id 5437, offset 0, flags [DF], proto TCP (6), length 176) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x88a9), seq 1660:1784, ack 1133, win 363, options [nop,nop,TS val 7880250 ecr 7879841], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:33.322475 IP (tos 0x0, ttl 64, id 181, offset 0, flags [DF], proto TCP (6), length 306) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x594e (incorrect -> 0xfd5a), seq 1133:1387, ack 1784, win 260, options [nop,nop,TS val 7880250 ecr 7880250], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:33 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:33 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:33.322526 IP (tos 0x0, ttl 64, id 5438, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0ef6), ack 1387, win 371, options [nop,nop,TS val 7880250 ecr 7880250], length 0 06:59:35.557433 IP (tos 0x0, ttl 64, id 24067, offset 0, flags [DF], proto TCP (6), length 405) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc91f), seq 1078:1431, ack 1075, win 346, options [nop,nop,TS val 7880474 ecr 7880150], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236775, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:39", "ip-address": "172.18.0.106", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:35.558987 IP (tos 0x0, ttl 64, id 6826, offset 0, flags [DF], proto TCP (6), length 208) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x141a), seq 1075:1231, ack 1431, win 252, options [nop,nop,TS val 7880474 ecr 7880474], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:35 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:35.559082 IP (tos 0x0, ttl 64, id 24068, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xdea6), ack 1231, win 354, options [nop,nop,TS val 7880474 ecr 7880474], length 0 06:59:38.859100 IP (tos 0x0, ttl 64, id 24069, offset 0, flags [DF], proto TCP (6), length 405) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc98b), seq 1431:1784, ack 1231, win 354, options [nop,nop,TS val 7880804 ecr 7880474], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236778, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:40", "ip-address": "172.18.0.107", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:38.861043 IP (tos 0x0, ttl 64, id 6827, offset 0, flags [DF], proto TCP (6), length 208) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x0f7e), seq 1231:1387, ack 1784, win 260, options [nop,nop,TS val 7880804 ecr 7880804], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:38 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:38.861141 IP (tos 0x0, ttl 64, id 24070, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xda0c), ack 1387, win 363, options [nop,nop,TS val 7880804 ecr 7880804], length 0 06:59:39.860249 IP (tos 0x0, ttl 64, id 24071, offset 0, flags [DF], proto TCP (6), length 176) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x5041), seq 1784:1908, ack 1387, win 363, options [nop,nop,TS val 7880904 ecr 7880804], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:39.864068 IP (tos 0x0, ttl 64, id 6828, offset 0, flags [DF], proto TCP (6), length 306) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x594e (incorrect -> 0xba27), seq 1387:1641, ack 1908, win 260, options [nop,nop,TS val 7880904 ecr 7880904], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:39 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:39 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:39.864299 IP (tos 0x0, ttl 64, id 24072, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xd7c1), ack 1641, win 371, options [nop,nop,TS val 7880905 ecr 7880904], length 0 06:59:41.998412 IP (tos 0x0, ttl 64, id 24073, offset 0, flags [DF], proto TCP (6), length 405) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xc81a), seq 1908:2261, ack 1641, win 371, options [nop,nop,TS val 7881118 ecr 7880904], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236781, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:41", "ip-address": "172.18.0.108", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:42.008785 IP (tos 0x0, ttl 64, id 6829, offset 0, flags [DF], proto TCP (6), length 208) 05e1a4a4476e.http-alt > kea_1.kea-mng.44216: Flags [P.], cksum 0x58ec (incorrect -> 0x088f), seq 1641:1797, ack 2261, win 269, options [nop,nop,TS val 7881119 ecr 7881118], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:42 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:42.008894 IP (tos 0x0, ttl 64, id 24074, offset 0, flags [DF], proto TCP (6), length 52) kea_1.kea-mng.44216 > 05e1a4a4476e.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0xd40f), ack 1797, win 379, options [nop,nop,TS val 7881119 ecr 7881119], length 0 06:59:45.015655 IP (tos 0x0, ttl 64, id 5439, offset 0, flags [DF], proto TCP (6), length 176) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x58cc (incorrect -> 0x80fc), seq 1784:1908, ack 1387, win 371, options [nop,nop,TS val 7881420 ecr 7880250], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:59:45.022860 IP (tos 0x0, ttl 64, id 182, offset 0, flags [DF], proto TCP (6), length 306) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x594e (incorrect -> 0xeeba), seq 1387:1641, ack 1908, win 260, options [nop,nop,TS val 7881420 ecr 7881420], length 254: HTTP, length: 254 HTTP/1.1 200 OK Content-Length: 145 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:45 GMT [ { "arguments": { "date-time": "Wed, 20 Nov 2019 06:59:45 GMT", "state": "load-balancing" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:59:45.022897 IP (tos 0x0, ttl 64, id 5440, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0450), ack 1641, win 379, options [nop,nop,TS val 7881420 ecr 7881420], length 0 06:59:46.089589 IP (tos 0x0, ttl 64, id 5441, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xee12), seq 1908:2261, ack 1641, win 379, options [nop,nop,TS val 7881527 ecr 7881420], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236786, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:42", "ip-address": "172.18.0.109", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:46.100884 IP (tos 0x0, ttl 64, id 183, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x35f6), seq 1641:1797, ack 2261, win 269, options [nop,nop,TS val 7881528 ecr 7881527], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:46 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:59:46.100966 IP (tos 0x0, ttl 64, id 5442, offset 0, flags [DF], proto TCP (6), length 52) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [.], cksum 0x5850 (incorrect -> 0x0172), ack 1797, win 388, options [nop,nop,TS val 7881528 ecr 7881528], length 0 06:59:49.422817 IP (tos 0x0, ttl 64, id 5443, offset 0, flags [DF], proto TCP (6), length 405) 05e1a4a4476e.47044 > kea_1.kea-mng.http-alt: Flags [P.], cksum 0x59b1 (incorrect -> 0xef52), seq 2261:2614, ack 1797, win 388, options [nop,nop,TS val 7881860 ecr 7881528], length 353: HTTP, length: 353 POST / HTTP/1.1 Content-Length: 281 Content-Type: application/json { "arguments": { "expire": 1574236789, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:43", "ip-address": "172.18.0.110", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:59:49.430854 IP (tos 0x0, ttl 64, id 184, offset 0, flags [DF], proto TCP (6), length 208) kea_1.kea-mng.http-alt > 05e1a4a4476e.47044: Flags [P.], cksum 0x58ec (incorrect -> 0x3154), seq 1797:1953, ack 2614, win 277, options [nop,nop,TS val 7881861 ecr 7881860], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Wed, 20 Nov 2019 06:59:49 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http]
上記より,kea_1
とkea_2
との間で双方向にリースアップデートを更新していることがことがわかる.
load-balancing
モードの場合は,hot-standby
モードとは異なり,リースしたサーバからそうでないサーバ(群)に対してリースアップデートを行うため,リースアップデートが一方向のみでなく,双方向に行われる違いがある.
これがパフォーマンス低下の原因となるため,一般にhot-standby
モードよりもload-balancing
モードの方が応答が遅くなる傾向があるようである.
- ref: Kea Performance Optimization
section 7の Consider the impact of high availability に
Active-Passive is more efficient than load-balancing. をはじめとし,
load-balancing
モードとhot-standby
モードでのパフォーマンスの違いの解説が書かれている.
まとめ
Kea DHCPを使ってload-balancing
モードのHA構成を組むことができました.
本記事では以下のことを実施しました.
- ISCのKea DHCPを用いて
load-balancing
モードのHA構成を組むことについて紹介した. - load-balancingモードのHAにおいて実際にクライアントを模擬してDHCPによるアドレスリースを行い,hot-standbyモードと比べたの応答の違いをパケットキャプチャによって確認した.
次回以降では,RFC3074の掘り下げ,HA構成を取ることによるパフォーマンス影響,HA構成で本当に冗長化ができているのか,等について見てみようと考えています.
References
- Kea DHCPのHigh-Availabilityを検証する - (1)Act-Sbyのhot-standby構成を組む - JP7FKFの備忘録
- Internet Systems Consortium - Kea
- Kea Documentation
- Kea Performance Optimization
- Kea High Availability vs ISC DHCP Failover - Kea DHCP
- RFC3074
- DHCP Failover Load Balance Mode – Microsoft Windows DNS, DHCP and IPAM Team Blog
P.S.
- 例によってQiitaに投稿してみました
Kea DHCPのHigh-Availabilityを検証する - (1)Act-Sbyのhot-standby構成を組む
ゴール
Kea DHCPを用いてAct-Sbyのhot-standby High-Availability構成を組み,動作させることができること.
About Kea DHCP
Kea DHCPとは,ISC DHCPの後継として開発されているオープンソースのDHCPサーバプログラムである. MPL2.0ライセンスのもとISCのGitlabで公開されている.最新のメジャーバージョンはISC DHCPとの違いは下記のように書かれている.
1. モジュラーコンポーネントデザインとHooksモジュールによる拡張 2. REST APIによるオンラインRe-configuration 3. 既存のシステムとのインテグレーション可能なデザイン
1つ目に述べられているhooksモジュールについては,ユーザ自身でこのhooksモジュールを書くことが可能であることを示している.これによりKea DHCPの独自のモジュールを実装し,より柔軟なサービス提供ができるように考慮されている.今回対象とするHA構成についても,このhooksモジュールとして実装されているHA機能を提供するライブラリをincludeして利用する形で実現する.
2つ目に述べられているREST APIによるconfigurationについては,このKea DHCPにはkea-ctrl-agent
が内包されており,このagentがREST APIの仲介者となりkea-dhcp4
プロセス(DHCPv4)やkea-dhcp6
プロセス(DHCPv6)に対して各種設定のgetやset等の様々な操作をすることが可能である.またKea DHCPはconfigを変更した際にrestartが極力必要とならないよう設計されている.多くのconfiguratinにおいては,configのreloadを行うことでconfigの適用を行うことができる.
最後に,既存システムとのインテグレーションについて述べられているが,これはどうもKea DHCPのconfigurationを,configファイルだけでなくDatabaseを用いることでも行うことができる点を指しているようである.これにより,実行環境とconfigurationを分離することができることがこの3つ目の要旨であるようだ.たしかに,実行環境とconfigの環境が異なり,さらにDBを用いて管理をすることができるのは一部のIT管理者にとっては有効かもしれない.
Kea DHCPのHA構成とISC DHCPのFailover
かつてのISC-DHCPではHA機能は提供されておらず,Failover機能のみ提供されているものであった.しかしながらKea DHCPではrelease 1.4.0
よりHA構成が適用可能となった.リリースノートからも分かる通り,1.4.0は2018年6月にリリースされたものであり,まだ1年少々しか経過していない.そのためまだ機能が十分でない部分等も多くあると推察できる.1.4.0のリリース当初はこのHA機能はPremium featureとして提供されるようであったが,現在は通常のhooks libraryとして提供されている.
ISC-DHCPのFailoverとKea DHCPのHA構成については下記で述べられている.
Kea High Availability vs ISC DHCP Failover - Kea DHCP
比較してみると,ISCのFailoverがDHCPv4のみに適用可能だったのに対し,Keaではv4とv6の両方に対して適用可能となっている.他には,ISCでは2つのサーバでの冗長構成のみしか組むことができなかったが,Keaでは2つのactiveサーバと無限のバックアップサーバを用いることが可能である.他にもリースDBのレプリケーション等がKeaでは実施可能であったり,ISC DHCPではOMAPIであったが,Keaではより一般的となっているREST APIによるconfigurationを採用するなど,多くの点でKea DHCPはISC DHCPをfollowする形となっているが,一部機能においてはISCよりデグレしている点が見受けられる.たとえばLoadBalancingだと,ISCではFlexible LBが可能であったが,Keaでは50/50のLBモードしか現状選択することができない.いずれもRFC3074に準拠しているようだ.また,Lazy lease updates(MCLT)の項目についてはISC DHCPでは可能であったがKeaではこれを許さず,リースアップデートが完全に完了してからでなければclientへresponseを送らないなど,より厳密となっている.このLazy lease updates(MCLT)については特にHA構成を組んだ場合のパフォーマンスに大きく影響することとなる.
Kea DHCPでHA構成を組む
Introduction
では早速Kea DHCPを用いたHA構成を組んでいく.
今回はKea DHCP verion 1.5.0を利用する.基本的にはマニュアルを熟読の上設定を行なっていくこととなる.v1.5.0では下記を参照することとなるだろう.
Kea Administrator Reference Manual
HA構成を組む上ではこのマニュアルのうち 15.4.8. ha: High Availability
をrefer するとよい.
また,HA構成において,HA構成を組んだホスト間のリースアップデート等はkea-ctrl-agent
を介したREST API経由で実施されることとなる.そのため,Kea DHCPのREST API,kea-ctrl-agentについての理解も深めておくとより理解が深まると思う.
Build and Configuration
今回はdockerを用いて検証環境を構成してHA構成を組むことを試みる.
下記のdocker file とdocker-compose.ymlを用いてkea-dhcp2台をデプロイし,その間をkea-mng
ネットワークで繋いでおく.docker compose up
する前に,docker network create kea-mng
をしておく必要がある.これはHA構成を組むにあたりheartbeat
やlease-update
をREST APIで実施するためのmanagement network相当のものである.L3疎通性さえあれば問題はない.
FROM ubuntu:latest ENV KEA_DHCP_VERSION=1.5.0 ENV LOG4_CPLUS_VERSION=1.2.1 RUN apt-get update && apt-get install -y iputils-ping net-tools traceroute nmap tcpdump iproute2 python3 vim jq curl automake libtool pkg-config build-essential ccache libboost-dev libboost-system-dev liblog4cplus-dev libssl-dev && \ curl -SL https://downloads.isc.org/isc/kea/${KEA_DHCP_VERSION}/kea-${KEA_DHCP_VERSION}.tar.gz | tar -xzC /root && \ cd /root/kea-${KEA_DHCP_VERSION} && \ ./configure --enable-shell && \ make -s -j$(nproc) && \ make install && \ ldconfig
version: '3' services: kea_1: image: kea:1.5.0 container_name: kea_1 privileged: true networks: - kea-mng tty: true kea_2: image: kea:1.5.0 container_name: kea_2 privileged: true networks: - kea-mng tty: true networks: kea-mng: external: true
環境が構築できたら,実際にconfigを行っていく. manualを見て分かるとおり,HA構成の実現にはhooks libraryを用いる. 今回はDHCPv4のデーモンに対してHA構成を行う例を示す.DHCPv6に対しても似たconfigで実現できると思われる.
早速HA構成を組むためのconfigを見ていこう.
マニュアルのHA構成のconfigサンプルとしてこのような例がある.
{ "Dhcp4": { ... "hooks-libraries": [ { "library": "/usr/lib/hooks/libdhcp_lease_cmds.so", "parameters": { } }, { "library": "/usr/lib/hooks/libdhcp_ha.so", "parameters": { "high-availability": [ { "this-server-name": "server1", "mode": "load-balancing", "heartbeat-delay": 10000, "max-response-delay": 10000, "max-ack-delay": 5000, "max-unacked-clients": 5, "peers": [ { "name": "server1", "url": "http://192.168.56.33:8080/", "role": "primary", "auto-failover": true }, { "name": "server2", "url": "http://192.168.56.66:8080/", "role": "secondary", "auto-failover": true }, { "name": "server3", "url": "http://192.168.56.99:8080/", "role": "backup", "auto-failover": false } ] } ] } } ], ... } }
hooks-libraries
としてlibdhcp_ha.so
を読み込む.デフォルトでは/user/lib/hooks
配下に存在するが,keaのinstall pathによっては異なってくるので注意しよう.基本的にはkeaのroot配下の./lib/hooks
配下にあると考えて良さそうだ.またHA構成を組む場合,lease-update
を送受信してリース情報を交換する必要がある.これを行うためにlibdhcp_lease_cmds.so
を読み込む必要がある.
読み込んでいないとlease情報がAPI経由でやり取りすることができない.たとえばこのlibdhcp_lease_cmd.so
を読み込まずにlease情報をgetしようとすると,下記のようになる.
root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "lease4-get-all", "service": [ "dhcp4" ] }' http://localhost:8080/ | jq .[] { "result": 2, "text": "'lease4-get-all' command not supported." }
さらに各種パラメータのsettingもここで実施する.パラメータの意味はざっくりと下記の通りである.
this-server-name: HA構成のうち自身を指すユニークな名前. mode: HAのモード. heartbeat-delay: パートナーへのハートビートの送信間隔.[ms] max-response-delay: パートナーをdownと判定するまでの時間.[ms] max-ack-delay: パートナーがクライアントからの通信に応答するべきmax時間.これを超えるとunackedと判定される.[ms] max-unacked-clients: パートナーを障害と判定するunackedクライアント数. peers: HAを構成するホストの指定
これらをマニュアルを見つつ適切に設定することとなる.
このうち,動作を大きく変えるのが mode
である.このパラメータはHAをどのモードで動作させるかを決定する.
Kea DHCPのHA動作モードはload-balancing
とhot-standby
のうちから選ぶ.
想像できる通り,load-balancing
モードでは50/50のact-actによる構成,hot-standby
モードではact-sbyのホットスタンバイ構成となる.
今回はまずhot-standby
モードとして下記の通り設定することとする.
primary に相当するのがkea_1
でありIPアドレスは172.18.0.3
,secondaryに相当するのがkea_2
でありIPアドレスは172.18.0.2
とした.
this-server-name: kea_1 //(2台目は"kea_2") mode: hot-standby heartbeat-delay: 10000 max-response-delay: 60000 max-ack-delay: 10000 max-unacked-clients: 0 "peers": [ { "name": "kea_1", "url": "http://172.18.0.3:8080/", "role": "primary", "auto-failover": true }, { "name": "kea_2", "url": "http://172.18.0.2:8080/", "role": "secondary", "auto-failover": true } ]
上記を踏まえてconfigを作成し,各サーバに適用して動作を確認してみよう.
たとえば私の検証では下記のようなconfgをkea_1
に投入した.kea_2
もほぼ同様であるが,"this-server-name"
等を適切に変更する.
{ "Dhcp4": { "interfaces-config": { "interfaces": ["eth0"], "dhcp-socket-type": "raw", "outbound-interface": "use-routing" }, "control-socket": { "socket-type": "unix", "socket-name": "/tmp/kea-dhcp4-ctrl.sock" }, "lease-database": { "type": "memfile", "persist": true, "name": "/usr/local/etc/kea/kea-leases4.csv", "lfc-interval": 1800 }, "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, "renew-timer": 1200, "rebind-timer": 2400, "valid-lifetime": 3600, "option-data": [ { "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" }, { "name": "default-ip-ttl", "data": "0xf0" } ], "hooks-libraries": [ { "library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so", "parameters": { } }, { "library": "/usr/local/lib/hooks/libdhcp_ha.so", "parameters": { "high-availability": [ { "this-server-name": "kea_1", "mode": "hot-standby", "heartbeat-delay": 10000, "max-response-delay": 10000, "max-ack-delay": 5000, "max-unacked-clients": 5, "peers": [ { "name": "kea_1", "url": "http://172.18.0.2:8080/", "role": "primary", "auto-failover": true }, { "name": "kea_2", "url": "http://172.18.0.3:8080/", "role": "standby", "auto-failover": true } ] } ] } } ], "reservation-mode": "disabled", "host-reservation-identifiers": [ "hw-address" ], "subnet4": [ { "id": 1, "subnet": "172.18.0.0/16", "pools": [ { "pool": "172.18.1.1 - 172.18.1.250" } ], "option-data": [ { "name": "routers", "data": "172.18.0.1" } ] } ] }, "Logging": { "loggers": [ { "name": "kea-dhcp4", "output_options": [ { "output": "/usr/local/var/log/kea-dhcp4.log", "maxver": 8, "maxsize": 204800, "flush": true } ], "severity": "DEBUG", "debuglevel": 99 } ] } }
まずはkea_1
でkeaを起動する.今回,起動にはkeactrl
コマンドを用いた.
起動後にRESTAPIでha-heartbeat
を送信し,それぞれのサーバのステータスを見てみよう.
# kea_1 root@0d5f73b7ffc7:/# keactrl start INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.conf root@0d5f73b7ffc7:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:50:37 GMT", "state": "waiting" }, "result": 0, "text": "HA peer status returned." } ] root@0d5f73b7ffc7:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq curl: (7) Failed to connect to 172.18.0.2 port 8080: Connection refused root@0d5f73b7ffc7:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:50:42 GMT", "state": "partner-down" }, "result": 0, "text": "HA peer status returned." } ] root@0d5f73b7ffc7:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq curl: (7) Failed to connect to 172.18.0.2 port 8080: Connection refused
起動後,kea_1
はstateが waiting
から,partner-down
にシフトしていることが見受けられる.
kea_2
に対しても同様のリクエストを行なっているが,kea_2
ではまだkeaを起動していないためConnection refused
が返っている.
kea_1
を起動し,kea_2
を起動していない場合,kea_1
はこの状態に収束する.
ここでkea_2
を起動する.
# kea_2 root@d864a28cbf84:/# keactrl start INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf INFO/keactrl: Starting /usr/local/sbin/kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.conf root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:37 GMT", "state": "partner-down" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:41 GMT", "state": "waiting" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:47 GMT", "state": "partner-down" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:49 GMT", "state": "ready" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:54 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:55 GMT", "state": "ready" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.3:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:57 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ] root@d864a28cbf84:/# curl -sS -X POST -H "Content-Type: application/json" -d '{ "command": "ha-heartbeat", "service": [ "dhcp4" ] }' http:///172.18.0.2:8080/ | jq [ { "arguments": { "date-time": "Fri, 25 Oct 2019 17:51:59 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ]
ログを見てみる.
# kea_1 root@0d5f73b7ffc7:/# grep INFO /usr/local/var/log/kea-dhcp4.log | grep ha-hooks 2019-10-25 17:50:27.312 INFO [kea-dhcp4.ha-hooks/1358] HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully configured 2019-10-25 17:50:27.312 INFO [kea-dhcp4.ha-hooks/1358] HA_INIT_OK loading High Availability hooks library successful 2019-10-25 17:50:27.359 INFO [kea-dhcp4.ha-hooks/1358] HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the kea_1 is in the WAITING state 2019-10-25 17:50:27.359 INFO [kea-dhcp4.ha-hooks/1358] HA_SERVICE_STARTED started high availability service in hot-standby mode as primary server 2019-10-25 17:50:37.372 INFO [kea-dhcp4.ha-hooks/1358] HA_STATE_TRANSITION server transitions from WAITING to PARTNER-DOWN state, partner state is UNDEFINED 2019-10-25 17:50:37.372 INFO [kea-dhcp4.ha-hooks/1358] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in PARTNER-DOWN state 2019-10-25 17:50:37.372 INFO [kea-dhcp4.ha-hooks/1358] HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the kea_1 is in the PARTNER-DOWN state 2019-10-25 17:51:52.821 INFO [kea-dhcp4.ha-hooks/1358] HA_STATE_TRANSITION server transitions from PARTNER-DOWN to HOT-STANDBY state, partner state is READY 2019-10-25 17:51:52.821 INFO [kea-dhcp4.ha-hooks/1358] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in HOT-STANDBY state 2019-10-25 17:53:11.474 INFO [kea-dhcp4.ha-hooks/1358] HA_DEINIT_OK unloading High Availability hooks library successful root@0d5f73b7ffc7:/#
# kea_2 root@d864a28cbf84:/# grep INFO /usr/local/var/log/kea-dhcp4.log | grep ha-hooks 2019-10-25 17:51:33.880 INFO [kea-dhcp4.ha-hooks/901] HA_CONFIGURATION_SUCCESSFUL HA hook library has been successfully configured 2019-10-25 17:51:33.880 INFO [kea-dhcp4.ha-hooks/901] HA_INIT_OK loading High Availability hooks library successful 2019-10-25 17:51:33.928 INFO [kea-dhcp4.ha-hooks/901] HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the kea_2 is in the WAITING state 2019-10-25 17:51:33.928 INFO [kea-dhcp4.ha-hooks/901] HA_SERVICE_STARTED started high availability service in hot-standby mode as standby server 2019-10-25 17:51:45.738 INFO [kea-dhcp4.ha-hooks/901] HA_STATE_TRANSITION server transitions from WAITING to SYNCING state, partner state is PARTNER-DOWN 2019-10-25 17:51:45.738 INFO [kea-dhcp4.ha-hooks/901] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in SYNCING state 2019-10-25 17:51:45.738 INFO [kea-dhcp4.ha-hooks/901] HA_SYNC_START starting lease database synchronization with kea_1 2019-10-25 17:51:45.743 INFO [kea-dhcp4.ha-hooks/901] HA_LEASES_SYNC_LEASE_PAGE_RECEIVED received 0 leases from kea_1 2019-10-25 17:51:45.745 INFO [kea-dhcp4.ha-hooks/901] HA_SYNC_SUCCESSFUL lease database synchronization with kea_1 completed successfully in 6.724 ms 2019-10-25 17:51:45.745 INFO [kea-dhcp4.ha-hooks/901] HA_STATE_TRANSITION server transitions from SYNCING to READY state, partner state is PARTNER-DOWN 2019-10-25 17:51:45.745 INFO [kea-dhcp4.ha-hooks/901] HA_LEASE_UPDATES_DISABLED lease updates will not be sent to the partner while in READY state 2019-10-25 17:51:56.910 INFO [kea-dhcp4.ha-hooks/901] HA_STATE_TRANSITION server transitions from READY to HOT-STANDBY state, partner state is HOT-STANDBY 2019-10-25 17:51:56.911 INFO [kea-dhcp4.ha-hooks/901] HA_LEASE_UPDATES_ENABLED lease updates will be sent to the partner while in HOT-STANDBY state 2019-10-25 17:51:56.911 INFO [kea-dhcp4.ha-hooks/901] HA_LOCAL_DHCP_ENABLE local DHCP service is enabled while the kea_2 is in the HOT-STANDBY state 2019-10-25 17:53:12.373 INFO [kea-dhcp4.ha-hooks/901] HA_DEINIT_OK unloading High Availability hooks library successful root@d864a28cbf84:/#
これらをみてみると,起動直後,これらのHAは下記のような順序で状態遷移していることがわかる.
2019-10-25 17:50:27.359:: kea_1: waiting , kea_2: UNDEFINED 2019-10-25 17:50:37.372:: kea_1: partner-down, kea_2: UNDEFINED 2019-10-25 17:51:33.928:: kea_1: partner-down, kea_2: waiting 2019-10-25 17:51:45.738:: kea_1: partner-down, kea_2: syncing 2019-10-25 17:51:45.745:: kea_1: partner-down, kea_2: ready 2019-10-25 17:51:52.821:: kea_1: hot-standby, kea_2: ready 2019-10-25 17:51:56.910:: kea_1: hot-standby , kea_2: hot-standby
このそれぞれのstateの意味はkeaのdocumentを参照し,簡単に理解をまとめると下記の通りである.ほぼgoogle翻訳.
- Backup: backup-serverの平常状態で,この状態であればアクティブなサーバーからlease-updateを受信する. - hot-standby: hot-standbyモードのアクティブサーバーの平常状態.hot-standbyモードにおけるプライマリサーバーとスタンバイサーバーは,通常この状態をとる.プライマリサーバーはDHCPクエリに応答し,スタンバイサーバーが存在する場合,スタンバイサーバーとバックアップサーバーにlease-updateを送信する - load-balancing: load-balancingモードのアクティブなサーバーの平常状態.loadbalancingモードにおけるプライマリサーバーとセカンダリサーバーは,通常のこの状態をとる.両方のサーバーがDHCPクエリに応答し,リース更新を相互に送信し,バックアップサーバーが存在する場合にはバックアップサーバーに送信する. - partner-down: partnerがオフラインであることを検出すると,アクティブサーバーはこの状態に移行する.バックアップサーバが利用できなくともサーバーはこの状態に移行しない.パートナーダウン状態では,サーバーはすべてのDHCPクエリに応答し,'通常時に現在使用できないpartnerによって処理されるべきクエリ'にも応答する. - ready: lease-databaseをアクティブなパートナーと同期した後、アクティブなサーバーはこの状態となる.この状態は、パートナーに通知される可能性がある(partner-down状態にある可能性が高いため、通常の操作に戻る可能性が高い.その場合,ready 状態にあるサーバーも続けて通常の動作を開始する.) - syncing: アクティブなサーバーはこの状態に移行して,アクティブなパートナーからリースを取得し,ローカルリースデータベースを更新します.この状態になると,dhcp-disableを発行して,リースの取得元のパートナーのDHCPサービスを無効にします. DHCPサービスは最大60秒間無効になります.その後,同期パートナーが再び停止し,サービスを再度有効にできない場合に備えて,自動的に有効になります.同期が完了すると,同期サーバーはdhcp-enableを発行して,パートナーのDHCPサービスを再度有効にします.同期操作は同期です.サーバーは,パートナーからの応答を待っており,リースの同期が行われている間は何もしていません.データベースをパートナーと同期しないように構成されているサーバー,つまりsync-leases構成パラメーターがfalseに設定されている場合,この状態に移行することはありません.代わりに,待機状態から準備完了状態に直接移行します. - terminated: ha-hooksライブラリがHA構成を組めず,問題を解決するために手動オペレーションが必要な場合にアクティブサーバーはこの状態となる.HAセットアップの様々なの問題により,サーバーがこの状態になる可能性がある.. Kea 1.4.0リリースの時点でのHAを終了させる唯一の問題は,各サーバーのクロックが60秒以上離れている場合である.terminated 状態のサーバーは選択されたHAモード(ロードバランシングまたはホットスタンバイ)に基づいてDHCPクライアントに応答し続けますが,lease-updateは交換されず,ha-heartbeatは送信されない.terminated状態になると,サーバーは再起動されるまでこの状態となる.オペレータはサーバーを再起動する前に,根本原因を解決する必要がある. - wainting: 起動された各サーバーはこの状態となる.バックアップサーバーは,この状態からバックアップ状態に直接移行する.アクティブなサーバーは,その状態を確認するためにpartnerにha-heartbeatを送信する.pertnerがオフラインであると考えられる場合,サーバーはpartner-down状態に移行する.そうでない場合,sync-leases構成パラメーターの設定に応じてsyncing状態またはready状態に移行する.両方のサーバーがwaiting状態(同時起動)にあると思われる場合,プライマリサーバーが先に状態遷移する.プライマリサーバーがready状態に移行するまで,セカンダリサーバーまたはスタンバイサーバーはwaiting状態のままとなる.
hot-stanbuyモードでのDHCPリース動作
HA構成を組むことができていることが確認できたので,この状態でDHCPのアドレスリースを行い,HA構成に受けるアドレスリース時の振る舞いを確認していこうと思う.
DHCPリースを模擬するために,今回はdhtestを利用した.
構築してhot-standby HA構成のサーバ群が接続されているNW上に存在するdhtest用VMで,下記の通りコマンドを実行する.
./dhtest -i <interface> -m <mac_addr>
mac_addr
はdhtestホストから送出するDHCPパケットのchaddr
フィールドに入るMACアドレスと思えばよい.
これを数回繰り返し実施した時の振る舞いを見てみる.
dhtestホストでは下記のようにアドレスリースが模擬できているようである.
[root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:33 DHCP discover sent - Client MAC : 00:00:00:11:22:33 DHCP offer received - Offered IP : 172.18.1.1 DHCP request sent - Client MAC : 00:00:00:11:22:33 ^[[ADHCP ack received - Acquired IP: 172.18.1.1 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:34 DHCP discover sent - Client MAC : 00:00:00:11:22:34 DHCP offer received - Offered IP : 172.18.1.2 DHCP request sent - Client MAC : 00:00:00:11:22:34 DHCP ack received - Acquired IP: 172.18.1.2 [root@a50202e240fb dhtest-master]# ./dhtest -i eth0 -m 00:00:00:11:22:35 DHCP discover sent - Client MAC : 00:00:00:11:22:35 DHCP offer received - Offered IP : 172.18.1.3 DHCP request sent - Client MAC : 00:00:00:11:22:35 DHCP ack received - Acquired IP: 172.18.1.3 [root@a50202e240fb dhtest-master]#
この時,kea_1
とkea_2
ホストでパケットキャプチャを行うと.
## kea_1 root@0d5f73b7ffc7:~# tcpdump -i eth0 port 67 or port 68 -v -n tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^[[O06:44:35.308246 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:33, length 251, xid 0x6a521a43, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:35.311244 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.1.68: BOOTP/DHCP, Reply, length 290, xid 0x6a521a43, Flags [none] Your-IP 172.18.1.1 Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:44:35.311902 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:33, length 263, xid 0x6a521a43, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.1 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:36.316180 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.1.68: BOOTP/DHCP, Reply, length 290, xid 0x6a521a43, Flags [none] Your-IP 172.18.1.1 Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:44:38.007073 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:34, length 251, xid 0x23552c97, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:38.009206 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.2.68: BOOTP/DHCP, Reply, length 290, xid 0x23552c97, Flags [none] Your-IP 172.18.1.2 Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:44:38.009418 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:34, length 263, xid 0x23552c97, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.2 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:39.014721 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.2.68: BOOTP/DHCP, Reply, length 290, xid 0x23552c97, Flags [none] Your-IP 172.18.1.2 Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:44:40.623865 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:35, length 251, xid 0x4a57a2d2, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:40.625059 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.3.68: BOOTP/DHCP, Reply, length 290, xid 0x4a57a2d2, Flags [none] Your-IP 172.18.1.3 Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400 06:44:40.625322 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:35, length 263, xid 0x4a57a2d2, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.3 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:42.630578 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 318) 172.18.0.3.67 > 172.18.1.3.68: BOOTP/DHCP, Reply, length 290, xid 0x4a57a2d2, Flags [none] Your-IP 172.18.1.3 Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.0.0 Default-Gateway Option 3, length 4: 172.18.0.1 Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4 Lease-Time Option 51, length 4: 3600 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 172.18.0.3 RN Option 58, length 4: 1200 RB Option 59, length 4: 2400
## kea_2 root@d864a28cbf84:~# tcpdump -i eth0 port 67 or port 68 -v -n tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:44:35.308297 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:33, length 251, xid 0x6a521a43, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:35.311922 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:33, length 263, xid 0x6a521a43, Flags [none] Client-Ethernet-Address 00:00:00:11:22:33 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.1 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:38.007102 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:34, length 251, xid 0x23552c97, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:38.009439 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:34, length 263, xid 0x23552c97, Flags [none] Client-Ethernet-Address 00:00:00:11:22:34 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.2 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:40.623903 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 279) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:35, length 251, xid 0x4a57a2d2, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server 06:44:40.625346 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 291) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:11:22:35, length 263, xid 0x4a57a2d2, Flags [none] Client-Ethernet-Address 00:00:00:11:22:35 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 172.18.1.3 Server-ID Option 54, length 4: 172.18.0.3 Parameter-Request Option 55, length 5: Subnet-Mask, BR, Default-Gateway, Domain-Name Domain-Name-Server
これら2つのパケットキャプチャをみて理解できるとおり,
kea_1
はクライアントからの3つ全てのDHCP要求(DISCOVERY
, REQUEST
)において,クライアントに対してOFFER
, ACK
を返しており,kea_2
はクライアントからの要求には全く応答パケットを送出していないことがわかる.
これはHAモードのうち,primaryの1台のみがDHCPに応答するhot-standby
の動作となっていることがわかる.
またこの時のlease-update
を見てみよう.
## kea_1 root@0d5f73b7ffc7:/# tcpdump -i eth0 port 8080 -v -n tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:44:35.313735 IP (tos 0x0, ttl 64, id 57517, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0x066f), seq 220565762:220566113, ack 2766104306, win 254, options [nop,nop,TS val 26311210 ecr 26310630], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335075, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:33", "ip-address": "172.18.1.1", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:35.315597 IP (tos 0x0, ttl 64, id 2855, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x0bf1), seq 1:157, ack 351, win 235, options [nop,nop,TS val 26311210 ecr 26311210], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:35 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:35.315738 IP (tos 0x0, ttl 64, id 57518, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xd5cc), ack 157, win 262, options [nop,nop,TS val 26311211 ecr 26311210], length 0 06:44:38.012408 IP (tos 0x0, ttl 64, id 57519, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0xfd19), seq 351:702, ack 157, win 262, options [nop,nop,TS val 26311480 ecr 26311210], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335077, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:34", "ip-address": "172.18.1.2", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:38.015389 IP (tos 0x0, ttl 64, id 2856, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x07cf), seq 157:313, ack 702, win 243, options [nop,nop,TS val 26311480 ecr 26311480], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:38 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:38.015425 IP (tos 0x0, ttl 64, id 57520, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xd1ae), ack 313, win 270, options [nop,nop,TS val 26311480 ecr 26311480], length 0 06:44:40.625311 IP (tos 0x0, ttl 64, id 57521, offset 0, flags [DF], proto TCP (6), length 176) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x58cc (incorrect -> 0x473e), seq 702:826, ack 313, win 270, options [nop,nop,TS val 26311745 ecr 26311480], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:44:40.632575 IP (tos 0x0, ttl 64, id 2857, offset 0, flags [DF], proto TCP (6), length 303) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x594b (incorrect -> 0x866a), seq 313:564, ack 826, win 243, options [nop,nop,TS val 26311746 ecr 26311745], length 251: HTTP, length: 251 HTTP/1.1 200 OK Content-Length: 142 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:40 GMT [ { "arguments": { "date-time": "Tue, 29 Oct 2019 06:44:40 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:44:40.632606 IP (tos 0x0, ttl 64, id 57522, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xce1a), ack 564, win 279, options [nop,nop,TS val 26311746 ecr 26311746], length 0 06:44:41.628464 IP (tos 0x0, ttl 64, id 57523, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0xfb10), seq 826:1177, ack 564, win 279, options [nop,nop,TS val 26311845 ecr 26311746], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335080, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:35", "ip-address": "172.18.1.3", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:41.633534 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x0080), seq 564:720, ack 1177, win 252, options [nop,nop,TS val 26311846 ecr 26311845], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:41 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:41.633621 IP (tos 0x0, ttl 64, id 57524, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xcb4f), ack 720, win 287, options [nop,nop,TS val 26311846 ecr 26311846], length 0 06:44:42.637356 IP (tos 0x0, ttl 64, id 43254, offset 0, flags [DF], proto TCP (6), length 176) 172.18.0.2.42824 > 172.18.0.3.8080: Flags [P.], cksum 0x58cc (incorrect -> 0x7e2b), seq 1837942929:1837943053, ack 2537261301, win 254, options [nop,nop,TS val 26311946 ecr 26310830], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:44:42.640120 IP (tos 0x0, ttl 64, id 59900, offset 0, flags [DF], proto TCP (6), length 303) 172.18.0.3.8080 > 172.18.0.2.42824: Flags [P.], cksum 0x594b (incorrect -> 0xb605), seq 1:252, ack 124, win 227, options [nop,nop,TS val 26311946 ecr 26311946], length 251: HTTP, length: 251 HTTP/1.1 200 OK Content-Length: 142 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:42 GMT [ { "arguments": { "date-time": "Tue, 29 Oct 2019 06:44:42 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:44:42.640722 IP (tos 0x0, ttl 64, id 43255, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.2.42824 > 172.18.0.3.8080: Flags [.], cksum 0x5850 (incorrect -> 0x01b8), ack 252, win 262, options [nop,nop,TS val 26311946 ecr 26311946], length 0
## kea_2 root@d864a28cbf84:/# tcpdump -i eth0 port 8080 -v -n tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:44:35.313767 IP (tos 0x0, ttl 64, id 57517, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0x066f), seq 220565762:220566113, ack 2766104306, win 254, options [nop,nop,TS val 26311210 ecr 26310630], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335075, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:33", "ip-address": "172.18.1.1", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:35.315569 IP (tos 0x0, ttl 64, id 2855, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x0bf1), seq 1:157, ack 351, win 235, options [nop,nop,TS val 26311210 ecr 26311210], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:35 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:35.315755 IP (tos 0x0, ttl 64, id 57518, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xd5cc), ack 157, win 262, options [nop,nop,TS val 26311211 ecr 26311210], length 0 06:44:38.012495 IP (tos 0x0, ttl 64, id 57519, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0xfd19), seq 351:702, ack 157, win 262, options [nop,nop,TS val 26311480 ecr 26311210], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335077, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:34", "ip-address": "172.18.1.2", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:38.015323 IP (tos 0x0, ttl 64, id 2856, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x07cf), seq 157:313, ack 702, win 243, options [nop,nop,TS val 26311480 ecr 26311480], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:38 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:38.015447 IP (tos 0x0, ttl 64, id 57520, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xd1ae), ack 313, win 270, options [nop,nop,TS val 26311480 ecr 26311480], length 0 06:44:40.625346 IP (tos 0x0, ttl 64, id 57521, offset 0, flags [DF], proto TCP (6), length 176) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x58cc (incorrect -> 0x473e), seq 702:826, ack 313, win 270, options [nop,nop,TS val 26311745 ecr 26311480], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:44:40.632539 IP (tos 0x0, ttl 64, id 2857, offset 0, flags [DF], proto TCP (6), length 303) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x594b (incorrect -> 0x866a), seq 313:564, ack 826, win 243, options [nop,nop,TS val 26311746 ecr 26311745], length 251: HTTP, length: 251 HTTP/1.1 200 OK Content-Length: 142 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:40 GMT [ { "arguments": { "date-time": "Tue, 29 Oct 2019 06:44:40 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:44:40.632623 IP (tos 0x0, ttl 64, id 57522, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xce1a), ack 564, win 279, options [nop,nop,TS val 26311746 ecr 26311746], length 0 06:44:41.628608 IP (tos 0x0, ttl 64, id 57523, offset 0, flags [DF], proto TCP (6), length 403) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [P.], cksum 0x59af (incorrect -> 0xfb10), seq 826:1177, ack 564, win 279, options [nop,nop,TS val 26311845 ecr 26311746], length 351: HTTP, length: 351 POST / HTTP/1.1 Content-Length: 279 Content-Type: application/json { "arguments": { "expire": 1572335080, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:35", "ip-address": "172.18.1.3", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }[!http] 06:44:41.633418 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [DF], proto TCP (6), length 208) 172.18.0.2.8080 > 172.18.0.3.33988: Flags [P.], cksum 0x58ec (incorrect -> 0x0080), seq 564:720, ack 1177, win 252, options [nop,nop,TS val 26311846 ecr 26311845], length 156: HTTP, length: 156 HTTP/1.1 200 OK Content-Length: 48 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:41 GMT [ { "result": 0, "text": "IPv4 lease added." } ][!http] 06:44:41.633649 IP (tos 0x0, ttl 64, id 57524, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.3.33988 > 172.18.0.2.8080: Flags [.], cksum 0x5850 (incorrect -> 0xcb4f), ack 720, win 287, options [nop,nop,TS val 26311846 ecr 26311846], length 0 06:44:42.637308 IP (tos 0x0, ttl 64, id 43254, offset 0, flags [DF], proto TCP (6), length 176) 172.18.0.2.42824 > 172.18.0.3.8080: Flags [P.], cksum 0x58cc (incorrect -> 0x7e2b), seq 1837942929:1837943053, ack 2537261301, win 254, options [nop,nop,TS val 26311946 ecr 26310830], length 124: HTTP, length: 124 POST / HTTP/1.1 Content-Length: 53 Content-Type: application/json { "command": "ha-heartbeat", "service": [ "dhcp4" ] }[!http] 06:44:42.640413 IP (tos 0x0, ttl 64, id 59900, offset 0, flags [DF], proto TCP (6), length 303) 172.18.0.3.8080 > 172.18.0.2.42824: Flags [P.], cksum 0x594b (incorrect -> 0xb605), seq 1:252, ack 124, win 227, options [nop,nop,TS val 26311946 ecr 26311946], length 251: HTTP, length: 251 HTTP/1.1 200 OK Content-Length: 142 Content-Type: application/json Date: Tue, 29 Oct 2019 06:44:42 GMT [ { "arguments": { "date-time": "Tue, 29 Oct 2019 06:44:42 GMT", "state": "hot-standby" }, "result": 0, "text": "HA peer status returned." } ][!http] 06:44:42.640696 IP (tos 0x0, ttl 64, id 43255, offset 0, flags [DF], proto TCP (6), length 52) 172.18.0.2.42824 > 172.18.0.3.8080: Flags [.], cksum 0x5850 (incorrect -> 0x01b8), ack 252, win 262, options [nop,nop,TS val 26311946 ecr 26311946], length 0
上記より,kea_1
からkea_2
に向けて
{ "arguments": { "expire": 1572335075, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "00:00:00:11:22:33", "ip-address": "172.18.1.1", "state": 0, "subnet-id": 1, "valid-lft": 3600 }, "command": "lease4-update", "service": [ "dhcp4" ] }
というjsonフォーマットでlease-update
が送出され,
{ "result": 0, "text": "IPv4 lease added." }
という形で応答していることがわかる.
Kea DHCPにおいてはこのようにREST APIを用いてlease-update
の交換を行うことが特徴の一つであると言えるだろう.
まとめ
というわけで,無事Kea DHCPを使ってhot-standby
モードのHA構成を組むことができました.
本記事では以下のことを実施しました.
- ISC DHCPの後継であるKea DHCPについて紹介し,冗長構成の違いを紹介した.
- ISCのKea DHCPを用いて
hot-standby
モードのHA構成を組むことについて紹介した. - hot-standyモードのHAにおいて実際にクライアントを模擬してDHCPによるアドレスリースを行い,2つのサーバの応答の違いをパケットキャプチャによって確認した.
- HA構成における2サーバ間の
lease-update
について,REST APIによって行われていることを確認した.
また,次回以降では,load-balancing
モードでのHA構成の構築と,hot-standby
構成との振る舞いの違いや,HA構成を取ることによるパフォーマンス影響,HA構成で本当に冗長化ができているのか,等について見てみようと考えています.
References
- Internet Systems Consortium - Kea
- Kea Documentation
- Kea Performance Optimization
- Kea High Availability vs ISC DHCP Failover - Kea DHCP
P.S.
- この内容をQiitaに投稿してみました: Kea DHCPでAct-Sby(hot-standby)のHA構成を組む - Qiita
Cisco Aironet APの動作モードを変更する
概要
Cisco AironetシリーズのAPにおけるAPモードにはWLCを利用してconfigurationを行い動作する'Lightweight Mode'と,単体でスタンドアロンモードのように自律動作する'Autonomous Mode'が存在する.
この記事ではCisco Aironetシリーズのモード変更を行う際の手順やメモを紹介する.
基本的には下記を参照している.
Lightweight - Autonomous AP変換方法 - Cisco Community
はじめに
Cisco AironetシリーズのAPは,Lightweight ModeとAutonomous Modeの2つのモードをもち,Lightweight ModeではWCLとトンネルを張り,WLCからconfigをLoadし,その後もWLCからのコマンドにより動作をするが,Autonomous Modeでは通常のSW等と同様にAP内部にconfigをもち,その設定をもとに動作する.
今回はCisco AironetシリーズのAIR-CAP1702I-Q-K9
に対して操作を実施した.
Lightweight ModeとAutonomous Modeの変更方法
購入直後は,Lightweight Mode, Autonomous Mode両方のconfigがAPに内包されているようである.
出荷状態であれば,何もしなければLightweight Modeで動作し,これをAutonomous Modeで動かしたい場合は下記のコマンドによりコンバートを行うことができる.
AP 1700 OS コンバートの仕方 - Cisco Community
ap# capwap ap autonomous
なお,このコマンドを入力した場合,2つあったLightweight ModeのイメージとAutonomous Modeのイメージのうち,Lightweightモードのイメージは削除されてしまうめ注意が必要だ.このコマンドでAutonomous ModeにしたAPを,Lightweight Modeに戻したい場合等は下記に示す手順によってFirmwareを入れ替える必要がある.
Lightweight ModeとAutonomous Modeのイメージの違い
Lightweight - Autonomous AP変換方法 - Cisco Communityによると,IOSの記号番号によりIOSの種別が判別できるそうだ.
RCVK9W8 リカバリ IOS (工場出荷時にインストールされている集中管理型用 IOS) K9W8 集中管理型 AP (Lightweight AP) IOS K9W7 自律型 AP (Autonomous AP) IOS
たとえば下記のようなOSのAPがあるとする.
ap# show version | inc IOS Cisco IOS Software, C1700 Software (AP3G2-K9W7-M), Version 15.3(3)JH, RELEASE SOFTWARE (fc3)
するとこれはK9W7
に該当するのでAutonomous Modeで動作していることがわかる.
Lightweight ModeからAutonomous Modeに切り替える場合はAutonomous Modeを示すK9W7
が記載されているFirmwareを,Autonomous ModeからLightweight Modeに切り替える場合はLightweight Modeを示すK9W8
が記載されたFirmwareをそれぞれ事前に入手しておくことが必要である.
Lightweight ModeからAutonomous Modeへの変更
基本的にはコンソールでのログイン後,下記のコマンド群で実施が可能である.
ap# capwap ap ip address <ip_addr> <mask> ap# capwap ap ip default-gateway <gateway_ip> ap# show capwap ip config ap# debug capwap console cli ap# debug capwap client no-reload ap# archive download-sw /create-space /overwrite tftp:<path_to_file> // K9W7(Autonomous Mode)のFirmを指定する. ap# dir flash: ap# show flash ap# show boot ap# verify <path_to_file> ap# reload
上から追っていく.まず,APへのIP address, gateway等の設定を行う.これはFirmwareを流し込む上でftp, tftp等を利用する場合にL3疎通性を確保するためである.その後debugモードを有効にし,archiveコマンドが打てる状態になる.このdebugモードを有効にしていないとarchiveコマンドは正常に発行できないので注意する.その後archiveコマンドを用いてftp/tftp等でFirmwareを転送する.create-space,overwrite等のoptionsは状況/好みに応じて付与するとよいだろう.転送が終了したら,show flash
, show boot
等のコマンドを用いてboot imageが正常に転送されているか,所望の通り変更されているかを確認する.最後にreloadを実施すると,次回そのimageでbootする.
転送後に必要に応じてverifyコマンド等でmd5をチェックしておくと安心である.
Autonomous Mode からLightweight Modeへの変更
上記とほぼ同様である.流れとしてはL3疎通性を確保し,archiveコマンドで書き込み,確認後reloadを行う.
ap(config)# interface bvi 1 ap(config-if)# ip address <ip_addr> <mask> ap(config-if)# no shutdown ap(config-if)# interface GigabitEthernet1 ap(config-if)# no shutdown ap(config-if)# exit ap(config)# ip default-gateway <gateway_ip> ap(config)# end ap# archive download-sw /create-space /overwrite tftp:<path_to_file> // K9W8(Lightweight Mode)のFirmを指定する. ap# dir flash: ap# show flash ap# show boot ap# reload
前半のip指定については,Autonomous Modeで運用している場合は多くの場合すでに付与されていることがほとんどであると考えられるため,多くの状況で省略可能であると思われる. 後の手順はLightweight ModeからAutonomous Modeに変更する手順とほぼ変わらない.
まとめ
- Cisco AironetシリーズのAPにおけるAPモードにはWLCを利用してconfigurationを行い動作する'Lightweight Mode'と,単体でスタンドアロンモードのように自律動作する'Autonomous Mode'が存在することを紹介した.
- Lightweight Mode, Autonomous Mode双方のモード切り替えをFirmware Imageを入れ替えることで実施する例を紹介した.
おまけ - MacOSでtftpサーバを動かす.
# 起動 sudo launchctl load -w /System/Library/LaunchDaemons/tftp.plist # 終了 sudo launchctl unload -w /System/Library/LaunchDaemons/tftp.plist # portが空いているか確認 sudo lsof -i:69 ## MEMO # /private/tftpboot 配下が転送ディレクトリとなる.permissionに注意する. # イメージをputする場合には/private/tftpboot 配下に同名の空ファイルが必要なようである(createの権限不足?). # workaroundとしては,touch コマンド等を利用してからファイルを作成.chmodを実施し適切にpermissionを設定するとよい.
References
Google Cloud Certified - Professional Cloud Architect を受けた話
先日Google Cloud Platformの認定資格であるProfessional Cloud Architect を受験する機会を与えられたので受験してきてみた.
はじめに結果から述べると,無事合格していた.この記事ではProfessional Cloud Architectを受ける上で重要となってくる点などの書き連ねていきたいと思う.
そもそもProfessional Cloud Architectとは何か.
Professional Cloud Architect とは、Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を有することを認められ、ビジネス目標を実現するために、スケーラブルで高可用性を備え、堅牢かつ安全な動的ソリューションを設計、開発、管理できる者をいいます。
と述べられている.要するにGCPを使って組織の目的を達するために必要な一定の知識を持っていることを認めるための資格と思っておけば良さそう. 実際に出題される問題でも,ネットワークのTCP/IPの知識だとか,ストレージのRAIDの話だとか,コンピュートリソースの仮想化だとかそういったテクニカルな話ではなく,GCPのサービスを道具として捉え,それをどのように適用/利用することで本質的な課題を解決できるかどうかという点に問題の重心が置かれている.
試験はどういったものか
具体的に述べることは試験の規約上控えなくてはなないが,試験自体はCBT(computer based test)で,多肢選択式.記述したり,コマンドをエミュレータで打つといったことは,私が試験を受けた時点では存在しなかった.内容は先ほども述べたように,テクニカルは話というよりは,顧客の要求に対してGCPの各種サービスを適切に選んで利用することができるかという点に重点が置かれている.
試験対策は?
私の場合,書籍があるのかなと思って東京駅近くの丸善に行ってみたりしたが,現時点でGCPの試験対策本というものはあまり出回ってない感じだった.なので私はひたすらGCPのドキュメントを読んで,そのサービスの特徴やできること,組み合わせなどを理解することに努めた.実際に手を動かしてGCPの各種サービスを利用してみると行ったこともやってみたかったが,そこまで手は回らなかった.なのである程度の情報工学やクラウドの知識を持ってさえいれば,特段勉強のために投資するといったことは必要ないのではないか,GCPの公開ドキュメントのみで十分なのではないかと思う.
試験にはケーススタディとしてある仮想の会社の要求要件と,それを踏まえたサービスの選択などが求められる場合がある.それは下記試験ガイドから現時点で3つのケーススタディのサンプルがあるのでチェックしておくと良いと思う.
感覚としては,GCPのサービスをわかっていて一通りのサービスを利用したことがある人なら軽々受かるのではないかという印象.そうでない人でも,基本的な情報工学とクラウドの知識さえあればあとは試験ガイドに目を通してあたりをつけ,GCPのドキュメントを読んで理解を進めることで合格できそう.もちろん実際に手を動かして使ってみることも理解を深める上で有効な手段だと思う.
というわけで簡単に受験体験記として書き連ねた.試験自体はそう難しいものでもない印象なので,気になる方は挑戦してみるといいと思う.
認定証もデジタルで,ブロックチェーンを用いた検証が採用されている仕組みを利用している.イマドキという感じがする.
余談だが,無事合格するとGCPのロゴ入りのノベルティがもらえる.現時点だとTimbuk2のリュックと,The North FaceのPulloverと,Marine Layerのパーカーから選べる.
何もらおうかな.
Rebuild Meetup 2019に行ってきました
rebuild.fmでおなじみのfastly @miyagawaさんが日本にいらっしゃるということで,4/12にmeetupが急遽企画されたらしいという電波を受信し,行ってみたいなーと.
4/12 (Fri) 19:30 から東京でミートアップと公開収録を開催します! https://t.co/96qVa62TVV #rebuildfm
— Rebuild Podcast (@rebuildfm) April 8, 2019
知り合いの@_miyachikとこの春に北海道から飛んできた@mktakuyaも行くということなので一緒に行ってきた. 会場は六本木ヒルズのメルカリさんだった.
pre-showとしてはじめに@kansai_takako さんがご登壇. 閑歳さんのトークのなかで頭に残ってるキーワードはこんな感じかな.
閑歳さんのトークは感情とか,感じることを客観的に言語化している感じがした.これを素でできる日本人ってそう多くない気がする.最近は自分も感じることとかを積極的に言語化するようにしたりしている(自然に生きる努力をしている)のだけども,なかなか簡単にできることでもないので見習っていきたい.尊いとか総受けとかは会場から笑いが溢れるトークでした.いいと思う.そんなトークから自然とLGBTなどの文化にもサラっと触れるというテクニックも垣間見れて話の持っていき方といい,聴いてて楽しかった.
閑歳さんはご予定があったようで,pre-showでご登壇されたあとはお帰りになられたようでした.
しばし休憩のあと,いよいよメインのお二方,おなじみの@hakさん, @HigeponJaさんがご登壇.
いつも通りhakさんは開始直後にredbullを開けてました.ウケる.さすが.
お二方のトークのうち印象深かったのはこんな感じかな.
- 盗撮カメラ
- 寿司の出前とレイテンシの話(stadia secret sause)
- ブラックホールの写真の話
- コンピュータが作り出した画像は写真と言えるか?
- 転職テクニック
- Googleに落ちた話
- 試行回数を増やす.運が99.9%
- 儲かっていて,エンジニアが一番(大切にする)会社を選ぶ
- Nさんはshownote白紙ですからね
聴いてる途中は笑いどころを会場のみんながわかってる感じで笑いどころでみんな一斉に笑ったりしてて面白かった.総じて参加者の方々の民度が高い気がして快適だった.
特に印象深かったのは転職関連の話とか,hakさんの人生は運だという話. "転職しました系のうまく言った話とかには生存者バイアスがかかっている.才能と努力と運で決まるなら運の比率は99.9%.運が悪ければ生まれてこない,運が悪ければ隕石が落ちてきて死ぬし,運が悪ければ宇宙人にどうたらで帰ってこない.運が支配的だとすると何度か試行すればうまくいくことがあるはずだ." と,だいたいこんなところだったと思う.運が悪ければ宇宙人がどうたらとかはさておき,本質的な考え方として"やることやったら後は運"的な考え方は自分の中に持つべき1つの考え方としてあるべきな気がする.何でもかんでも自分の責任にしてたらやってられないかなと思う.実際運成分もあるんじゃないかな.たぶん.この考え方を持っておけば生きるのが少しくらいは楽になる気がする.これ大事.たぶん. 一番印象的だったのはこの話だった.
あとは会社の選び方として儲かっていることは給与につながるので大切,あとはエンジニアリングにちゃんと価値があると考えているような会社にいるといいよねという話.まさしくそうだなという感じ.今後の参考にしたい.
総じていつも聴いてるrebuild.fmを目の前で聴けて新鮮な体験だった.今度あるならまた行ってみたい. この時のエピソードは下記で配信されているので,気になる方はチェックしてみるといいと思う.
楽しかったです!ありがとうございましたー!
Thank you everyone for coming to the meetup! #rebuildfm pic.twitter.com/nFKoI8SOS1
— Rebuild Podcast (@rebuildfm) April 13, 2019
2018年買ってよかったもの
2018年買ってよかったもの
なんか周りで書いてる人が多いので便乗して私も書いてみます. 主にAmazonの注文履歴とにらめっこです. 今年は一人暮らしを始めたので,たくさんのものを買った気がします.来年からはちょっと少なめになるかな?
2018年は51件ほどAmazonでお買い物をしたようです.
見なかったことにしようBOX
Astage(アステージ) STボックス #25 クリア W約29.5×D約44.3×H約25.9cm
- 出版社/メーカー: アステージ(Astage)
- メディア: Tools & Hardware
- この商品を含むブログを見る
散らかってるものをとりあえずつっこんでおくとみなかったことにできる魔法のコンテナです. これにだいたいの身の回りのものを綺麗に分別して入れてそのまま引越ししました.引越しとか移動のたびにダンボールに詰めなおして引っ越す必要もなくて大変助かりました. このBOXは重ねてもある程度安定するので,スチールラックとかにこれをそのまま乗っけて整頓しています.【Amazon.co.jp限定】TRUSCO(トラスコ) 薄型折りたたみコンテナ モノトーンカラー 50L ロックフタ付 TR-C50B-A-MONO
- 出版社/メーカー: トラスコ中山(TRUSCO)
- メディア: Tools & Hardware
- この商品を含むブログを見る
こちらも併用しました.こっちは使わないときは折りたたんでおけるので場所を取らなくて便利です.思ったより丈夫だった.PC モニタ
【Amazon.co.jp限定】LG モニター ディスプレイ 27UD58-B 27インチ/4K/IPS 非光沢/HDMI×2、DisplayPort/FreeSync対応/ブルーライト低減機能
- 出版社/メーカー: LG
- 発売日: 2016/07/27
- メディア: Personal Computers
- この商品を含むブログを見る
引越しでディスプレイも東京に持ってきたのですが,利用していたのはメインで21.5インチとサブの18.5インチディスプレイでした. 流石に作業領域が小さいし,時代は4Kでしょ,広いほうが捗るだろうし悩むなら買ってしまおうとポチってしまいました. しかし27インチの4Kは解像度が高すぎてコーディングとかをするには見辛くてダメでした.大失敗.4Kならたぶん30〜40インチあるべきだと思います 4Kの動画を見るときとかに使うことになるんだろうか...これはサブモニタになってしまいました.Acer モニター ディスプレイ EB321HQUBbmidphx 31.5インチ WQHD(2560 x 1440)/IPS/スピーカー内蔵/HDMI端子対応
- 出版社/メーカー: 日本エイサー
- 発売日: 2017/03/31
- メディア: Personal Computers
- この商品を含むブログを見る
ということで4Kまでいかないけどさらに画面がでかい31.5インチのWQHDディスプレイを買ってしまいました. これはなかなかよかったです.今はこれをメインディスプレイにして使っています. 金銭的に余裕ができたら30-40インチくらいの4Kディスプレイを買いたいところです.Anker SoundCore Sport
Anker Soundcore Sport 防水 Bluetooth スピーカー【IPX7 防水防塵 / 10時間連続再生 / 内蔵マイク搭載 】
- 出版社/メーカー: Anker
- メディア: エレクトロニクス
- この商品を含むブログ (4件) を見る
アウトドアで音楽を聴きたいと思ってポチりました.もちろんアウトドアでも大活躍で,家の中でも簡易防水なのでお風呂で音楽が聴けてよいです.長風呂するときには必須アイテム.電話会議では使ったことがないけど,どうなんだろう.今度試してみます.来年からゆるきゃん(ソロキャン)をしていきたいと思っているので.そのときも使っていきたいです.Amazon Echo dot
Echo Dot (エコードット) 第2世代 - スマートスピーカー with Alexa、ブラック
- 出版社/メーカー: Amazon
- 発売日: 2018/04/03
- メディア: エレクトロニクス
- この商品を含むブログ (9件) を見る
一応スマートスピーカーの波に乗っておくかということで,Prime dayかなんかでポチりました.音楽をかけたいときにかけてくれるし,天気もわかるし,今何時?もよく使います.実はこれを目覚ましにしていてweekdayのみ起こしてもらっています.最近はパスタを茹でる時間を計ってもらうことが多いです.家にnature remo的なデバイスがあり,amazon echo連携ができるそうなのでやってみようと思っているのですがまだやってない.家の照明は自作なので,これにも赤外線センサをつけてコントロールしたいと思っています(今後の課題).Zolo Liberty
Anker Zolo Liberty (Bluetooth 4.2 完全ワイヤレスイヤホン) 【PSE認証済 / 最大24時間音楽再生 / Siri対応 / IPX5防水規格】(ブラック)
- 出版社/メーカー: Anker
- メディア: エレクトロニクス
- この商品を含むブログ (1件) を見る
もともとフルワイヤレスイヤホンとしてX3Tを使っていましたが,ちょっとバグることも多く周りの電波が汚いところだとブツブツ切れることが多くてストレスフルでした.なのでAnkerのこいつを試してみようかと購入.音質は満足いくレベルですし,ブツブツ切れることも少なくなりました.さすがに東京都内だと所々切れることはありますが,X3Tよりはいくぶんマシです.バッテリもケースがあるので十分持ちます.総合的には価格を考えるとよくできたデバイス,で買ってよかったと思います.ただこいつはイヤホン本体の操作がタッチ式ではなく完全なクリック式/ボタン式です.耳にはめている状態でボタンをクリックするには結構な力がかかり,単純に耳が痛いと感じることもしばしば.タッチ式だったら最高だったでしょうね.サーモス 真空断熱タンブラー 420ml ステンレス JDE-420
サーモス 真空断熱タンブラー 420ml ステンレス JDE-420
- 出版社/メーカー: サーモス(THERMOS)
- 発売日: 2016/02/01
- メディア: ホーム&キッチン
- この商品を含むブログ (2件) を見る
私はよく作業するときにコーヒーを飲みつつ作業をすることがあります.そうすると普通のマグカップだとすぐにコーヒーは冷めてしまいますが,これに入れておけば本当に長い間温かい状態を保ってくれます.価格も手頃で,お気に入りです.熱いものだけでなく無論冷たいものも長い時間保ってくれますので,夏も快適です.
他にも長年使ってきたモバイルバッテリーがとうとう膨張したのでAnkerのモバイルバッテリーを買ったり,みんな大好きRedbullとかを買ったりしていました.お買い物は価格と品質を吟味して買うかどうかを決定するようにしていて,今の所ほとんどの買い物に納得ができています(4Kディスプレイは品質や価格はよかったと思うのですが,実際の使用感がわかっていなかったので失敗でした),2019年もその調子でお買い物していきたいと思います!
P.S. ほしいものリストは下記です.いつでもお待ちしております.
ほしいものリスト - Amazon.co.jp