2019-10-31

Kea DHCPのHigh-Availabilityを検証する - (1)Act-Sbyのhot-standby構成を組む

network software

ゴール

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

P.S.

この内容をQiitaに投稿してみました: Kea DHCPでAct-Sby(hot-standby)のHA構成を組む - Qiita

2019-10-24

Cisco Aironet APの動作モードを変更する

network

概要

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

2019-05-02

Google Cloud Certified - Professional Cloud Architect を受けた話

dialy study

先日Google Cloud Platformの認定資格であるProfessional Cloud Architect を受験する機会を与えられたので受験してきてみた．

はじめに結果から述べると，無事合格していた．この記事ではProfessional Cloud Architectを受ける上で重要となってくる点などの書き連ねていきたいと思う．

そもそもProfessional Cloud Architectとは何か．

Googleのサイトでは

Professional Cloud Architect とは、Google Cloud の技術を組織が活用するために必要なクラウドアーキテクチャと Google Cloud Platform に関する専門的な知識を有することを認められ、ビジネス目標を実現するために、スケーラブルで高可用性を備え、堅牢かつ安全な動的ソリューションを設計、開発、管理できる者をいいます。

と述べられている．要するにGCPを使って組織の目的を達するために必要な一定の知識を持っていることを認めるための資格と思っておけば良さそう．実際に出題される問題でも，ネットワークのTCP/IPの知識だとか，ストレージのRAIDの話だとか，コンピュートリソースの仮想化だとかそういったテクニカルな話ではなく，GCPのサービスを道具として捉え，それをどのように適用/利用することで本質的な課題を解決できるかどうかという点に問題の重心が置かれている．

試験はどういったものか

具体的に述べることは試験の規約上控えなくてはなないが，試験自体はCBT(computer based test)で，多肢選択式．記述したり，コマンドをエミュレータで打つといったことは，私が試験を受けた時点では存在しなかった．内容は先ほども述べたように，テクニカルは話というよりは，顧客の要求に対してGCPの各種サービスを適切に選んで利用することができるかという点に重点が置かれている．

試験対策は？

私の場合，書籍があるのかなと思って東京駅近くの丸善に行ってみたりしたが，現時点でGCPの試験対策本というものはあまり出回ってない感じだった．なので私はひたすらGCPのドキュメントを読んで，そのサービスの特徴やできること，組み合わせなどを理解することに努めた．実際に手を動かしてGCPの各種サービスを利用してみると行ったこともやってみたかったが，そこまで手は回らなかった．なのである程度の情報工学やクラウドの知識を持ってさえいれば，特段勉強のために投資するといったことは必要ないのではないか，GCPの公開ドキュメントのみで十分なのではないかと思う．

試験にはケーススタディとしてある仮想の会社の要求要件と，それを踏まえたサービスの選択などが求められる場合がある．それは下記試験ガイドから現時点で3つのケーススタディのサンプルがあるのでチェックしておくと良いと思う．

cloud.google.com

感覚としては，GCPのサービスをわかっていて一通りのサービスを利用したことがある人なら軽々受かるのではないかという印象．そうでない人でも，基本的な情報工学とクラウドの知識さえあればあとは試験ガイドに目を通してあたりをつけ，GCPのドキュメントを読んで理解を進めることで合格できそう．もちろん実際に手を動かして使ってみることも理解を深める上で有効な手段だと思う．

というわけで簡単に受験体験記として書き連ねた．試験自体はそう難しいものでもない印象なので，気になる方は挑戦してみるといいと思う．

認定証もデジタルで，ブロックチェーンを用いた検証が採用されている仕組みを利用している．イマドキという感じがする．

余談だが，無事合格するとGCPのロゴ入りのノベルティがもらえる．現時点だとTimbuk2のリュックと，The North FaceのPulloverと，Marine Layerのパーカーから選べる． f:id:jp7fkf:20190502214832p:plain

何もらおうかな．

2019-05-02

Rebuild Meetup 2019に行ってきました

dialy

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

閑歳さんのトークは感情とか，感じることを客観的に言語化している感じがした．これを素でできる日本人ってそう多くない気がする．最近は自分も感じることとかを積極的に言語化するようにしたりしている（自然に生きる努力をしている）のだけども，なかなか簡単にできることでもないので見習っていきたい．尊いとか総受けとかは会場から笑いが溢れるトークでした．いいと思う．そんなトークから自然とLGBTなどの文化にもサラっと触れるというテクニックも垣間見れて話の持っていき方といい，聴いてて楽しかった．

閑歳さんはご予定があったようで，pre-showでご登壇されたあとはお帰りになられたようでした．

しばし休憩のあと，いよいよメインのお二方，おなじみの@hakさん, @HigeponJaさんがご登壇． f:id:jp7fkf:20190502211745j:plain

いつも通りhakさんは開始直後にredbullを開けてました．ウケる．さすが．

お二方のトークのうち印象深かったのはこんな感じかな．

盗撮カメラ
寿司の出前とレイテンシの話(stadia secret sause)
ブラックホールの写真の話
コンピュータが作り出した画像は写真と言えるか？
転職テクニック
Googleに落ちた話
試行回数を増やす．運が99.9%
儲かっていて，エンジニアが一番（大切にする）会社を選ぶ
Nさんはshownote白紙ですからね

聴いてる途中は笑いどころを会場のみんながわかってる感じで笑いどころでみんな一斉に笑ったりしてて面白かった．総じて参加者の方々の民度が高い気がして快適だった．

特に印象深かったのは転職関連の話とか，hakさんの人生は運だという話． "転職しました系のうまく言った話とかには生存者バイアスがかかっている．才能と努力と運で決まるなら運の比率は99.9%．運が悪ければ生まれてこない，運が悪ければ隕石が落ちてきて死ぬし，運が悪ければ宇宙人にどうたらで帰ってこない．運が支配的だとすると何度か試行すればうまくいくことがあるはずだ．" と，だいたいこんなところだったと思う．運が悪ければ宇宙人がどうたらとかはさておき，本質的な考え方として"やることやったら後は運"的な考え方は自分の中に持つべき1つの考え方としてあるべきな気がする．何でもかんでも自分の責任にしてたらやってられないかなと思う．実際運成分もあるんじゃないかな．たぶん．この考え方を持っておけば生きるのが少しくらいは楽になる気がする．これ大事．たぶん．一番印象的だったのはこの話だった．

あとは会社の選び方として儲かっていることは給与につながるので大切，あとはエンジニアリングにちゃんと価値があると考えているような会社にいるといいよねという話．まさしくそうだなという感じ．今後の参考にしたい．

総じていつも聴いてるrebuild.fmを目の前で聴けて新鮮な体験だった．今度あるならまた行ってみたい．この時のエピソードは下記で配信されているので，気になる方はチェックしてみるといいと思う．

rebuild.fm

楽しかったです！ありがとうございましたー！

Thank you everyone for coming to the meetup! #rebuildfm pic.twitter.com/nFKoI8SOS1
— Rebuild Podcast (@rebuildfm) April 13, 2019

2018-12-31

2018年買ってよかったもの

dialy

2018年買ってよかったもの

なんか周りで書いてる人が多いので便乗して私も書いてみます．主にAmazonの注文履歴とにらめっこです．今年は一人暮らしを始めたので，たくさんのものを買った気がします．来年からはちょっと少なめになるかな？

f:id:jp7fkf:20181231125048p:plain:w300
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

2018-12-30

2018年を振り返りつつ2019年を眺める

dialy

2018年もいよいよ年の瀬．私の生まれた平成という時代も，もうすぐに終わろうとしています．私の過ごした2018年を振り返りつつ，次の2019年をどう生きるかを書いていきたいと思います．後からみたときに，今何をしてい(る|た)かがわかるように...．

2018年は何があったのか

端的には最悪の一年だったが，ちょっと振り返る．

就職した

就職しました．就職した会社はインターネット関連の会社です．ISPとかをやっているところです．配属された部署は技術を開発するという名前がついている部署でした．私としては今まで得意としていた電気電子，高周波関連とは少し違った道を歩んでいます．それは私がそうやっていきてみたいと決めたからです．とはいえ，通信の世界でも電気電子の知識は少し生きつつ，高周波を学んだことで得られた知見も，少しは役に立っていたと思います．私は就職してから，研修等を経て，本務では主としてVNF（仮想ネットワークアプライアンス）のconfig作成や試験を行っていました．VNFの動作を確かめたり，トラフィックをたっぷり流してどういう挙動を取るのかや，異常系試験などを行っていました．装置の検証というのは装置のconfigが変わると最初からやりなおし，試験を通しなおし，などが起こることがありますが，私はその度に試験を人力で流すのはただの作業であると感じて，誠に稼働の無駄である気がしてならず，最近はRENATというRobot Frameworkを利用した試験自動化ツールを使って試験を自動化することを試みたりしています．

その他にも自社で持っているASの運用，装置の更改，構築などに多少携わらせていただいています．自分としてはもっと技術を触って開発をしたいという思いがありますが，今の所自分としては，業務としてはあまり技術を触っていない/開発をしていない　な，と感じてしまっています．これは会社で働いている以上そういうこともあるので仕方ないという側面もあると思います．ただ，いざ技術を使った業務が来ると，自分の技術力が劣っていることでスムーズにいかないこともあり，これは自分が技術を身につけられていない，怠慢であることに他ならないと感じることもあります．普段技術開発できていなくても，いざ来たときにスピーディに対応できるよう，日々努力は怠ってはならないと感じた一年でもありました．fundationを自分で整え，いざ面白い仕事が来たときのチャンスを逃さず自信を持ってやりますと言えるようにしておきたいと感じました．

周りには優秀な人がたくさんいて，恵まれている環境にいると思います．同期もつよい人が多くて全然ついていけてない自分がいます．
//ちゃんと，技術で勝てるような何かを持たないとダメだなと．
だからこそ，成長できる環境にいるからこそ，自分の努力が足りなかった一年だとも感じています．環境はある程度整っているので，なんとなく過ごしていた2018年を改め，2019年は積極的に手と頭を動かしていきたい．

生活の変化

地方から出てきて東京で一人暮らしをはじめました．私個人として一人暮らしは経験したことがあり，抵抗もまったくないので何事もなく暮らしています．東京はとても便利という印象です．趣味の電子工作で部品が必要になればサクっと電車に乗って秋葉原に行けばいいし，ものが欲しければお店はいくらでもあります．勉強会も，地方と比べて活発に開かれています．Interopのような展示会にも新幹線に乗らずに在来線ですぐだし，とてもよいです．ただやっぱり家賃は高い．何を楽しむにしてもお金がかかったりするし，なかなか難しいところ．はやく稼げるようになって20代を楽しみつつ仕事もガリガリやりたい感じです．仕事というものが生活の軸となって日々の時間を過ごした一年であり，いろいろあって自分のProductivity, Creativity は最悪の一年だったように感じます（当社比）．来年はそんなことがないようにちゃんと何かしらのものを作って，成果を出していきたい．仕事だけじゃなくプライベートでも．

雑に2018年を振り返りましたが，私の2018年はまったく色濃くなく，ここ数年ではワーストレベルのクオリティの年でした．心の中では本当に最悪と思っている．時間もなんとなく過ぎていき，ここまであっという間でした．ただ，一年過ごしているとだんだん動き方がわかってきたので，来年からはよくできるかなと思っています．

2019年はどうしようか

最悪の2018年，同じ繰り返しにならないように2019年を過ごしたい．

目標やらやりたいこと

目標を立ててもだいたい達成しなかったりしますが，目標は目標として一応書いておきます

目標

TOEIC800up: 多分無理かも．努力はする．英語できるとかっこいいじゃん（知らんけど）．
CCNP R&S取得: 今年はCCNAを取ったので，セカンドステップとしてNPを狙います．
電験3種取得: 科目合格が今年まで．これでダメだったら色々無駄になるので頑張る．あと2科目だし．

やりたいこと

ブログでもなんでもいいので(技術的)outputをする
2018年の何が最悪かって，ほぼoutputしていないところ．今専門としているネットワーク技術じゃなくてもいいし，趣味の電子工作，プログラミングやらなんでもいいのでとりあえず何とかしてoutputを出す．ブログでもいいしどこかでLT発表してもいい．outputできるレベルのことを"ちゃんと"やる．小さなことでもoutputしていく．"誰か"にとっては必要とされていることかもしれない．
「あとでやればいいや」を極力なくす
「あと」が延々とこなかったり，あとでやると溜まって大変になって結果的に生産性が落ちていた感じがする．数年前の流行語なのかもしれないけど「今でしょ」精神で，今をちゃんと生きるようにする．
英語以外の外国語に触れる．別に"ちゃんと"喋れなくても，書けなくてもいいので，ちょっと喋れる，ちょっと書ける，ちょっと意味がわかる程度でもいいので第二外国語としてなんらかの言語に触れる．中国語，スペイン語あたりなのかと思っている．

とりあえず雑に書いた．後でいくらでも変えていいと思っている自由人なので，今回はこのくらいにしておく．来年もどうぞよろしくお願いします．

2018-09-06

Cisco Catalyst 2960G switchを修理した話

network electronics

壊れたCisco Catalyst 2960Gなswitchを譲渡してもらった．

壊れたCisco のCatalystスイッチを譲渡していただける機会があった．私はモノを修理するのが好きなので，今回も治すことを試みた．

症状としては，電源を入れてもコンソールからは何も出力されない． Catalyst 上のインジケータLEDも，特に意味のある光り方をしない． (具体的には，電源を入れると点灯こそするものの，その後は一切変化しない．電源を入れるたびにオレンジ，緑等の色が変化する．電源を入れるたびに光ったり，光らなかったりするLEDが出るなど，ステータスを表しているとは到底思えないような光り方をしていた．)

LED表示はこんな感じ．コンセントをさしたり抜いたりすると光るところが変わったりする．明らかにおかしい． f:id:jp7fkf:20180906124027j:plain:w500

Cisco デバイスはどの順序で各メモリを利用するのか．

ここで，Cisco スイッチの起動順序をおさらいしてみることにする．私はそもそもあまり詳しくないので，調査してみてわかったことを簡単に書いてみる．正しいかどうかはわからない．

起動順序は下記URL等を参照した．
Ciscoデバイスの操作 - Ciscoルータ - メモリの種類と起動順序

ciscoデバイスは，Flash, NVRAM, RAM, ROMの4種類の記憶装置が存在する．具体的には，ROMはPOST，Bootstrap，ROMMON, miniIOSなど，最小限のソフトウェアが乗っている．FlashはIOSイメージが格納され，起動時にRAMにロードされて実行される．RAMはIOSがロードされるほか，running-confingもここに乗っている．NVRAMはwrite mem等をした際に書き込まれる領域，つまりstartup-configが格納されている．

というわけで，基本的にロード順序としてはROM -> Flash -> RAM -> NVRAM の順序で読み込まれるような気がしていた．しかしながらよく考えると，ROMに書かれているプログラムもRAMに展開されて実行されるような気もしていた．これはコンピュータアーキテクチャが分かっていればすぐにわかることなだろうが，ciscoがどのようなアーキテクチャで作っているのか私は知識がなく，断定はできなかった．

現状として，電源を接続しても，Catalyst 上のインジケータLEDは，特に意味のある光り方をしない．点灯こそするものの，その後は一切変化しない，など，syst, statランプの点滅などもなかったため，POSTすら実行できていない可能性が高いと推測をした．

起動しない原因と可能性

これらの原因として考えられるものの1つとして，ROMの破損が考えられた．しかしながらROMが破壊していた場合，ROMを交換するだけでなく，その中に書き込まれているプログラムも他のciscoスイッチ等からコピーする必要があり，現状その手段を持ち合わせていないため，交換して修理することは難しいと判断した．

2つ目の可能性として，POSTやブートストラップが，仮にRAM上に展開されて実行される場合，RAMの故障によりPOSTが動いていないことが考えられた．

RAMは電源断時には情報は持つことはなく，電源が入っているときのみ記憶動作を行うため，これは交換することで修理が可能であると考えた．

他の可能性として，根本的にデバイスに供給されている電源の不具合（各電圧ラインの電圧が異常である等）が考えられたが，これはテスタですべての電圧ラインを確認し問題ないことを確認した．

FlashとNVRAMについては，これが破壊されていた場合でも，最低限POSTは走るであろうと考えられたため，今回はこれらの故障が原因ではないと判断した．

上記の判断と，自分が行うことのできるレベルとして，RAMを交換して様子を見るということが初手として打てる手であると判断し，当該スイッチので用いられているRAM交換することにした．

DRAMの交換を試みる．

スイッチの蓋をあけると，RAMと思われるデバイスが見つかった．
f:id:jp7fkf:20180906124034j:plain:w500
f:id:jp7fkf:20180906124051j:plain:w500
型番を調べるとビンゴで，512MBのSDRAMである．
こいつはMicron TechnologyのMT46VというシリーズのSDRAMのようだ．"-6T"というのは，Speed Gradeで，使えるClock Rateを示している．
Micron MT46V Series DDR-SDRAM

本来であれば同一の型番のDRAMを用いるべきであるが，digikey等で検索しても1qty. から適正価格で買えるものが見つからず，入手性の観点から互換的に利用できると考えられた"-5B"というSpeed Gradeのものをを代わりに用いることとした．こちらはより高速なクロックに対応したモデルであるが，データシートを見て，当該スイッチで用いられているクロックでも問題なく動作すると判断した．

最近ではマルツパーツ館でdigi-keyのパーツが1個から購入できるので大変便利である．私もこれを利用させていただくことにした．

パーツは5営業日くらいでマルツの店舗に到着し，受け取ることができた．十分早い．
f:id:jp7fkf:20180906124043j:plain:w500
交換するDRAMが入手できたので，早速交換を行う．

交換の仕方は割とワイルドに？交換対象のDRAMの足にたっぷりの半田を盛り付けて熱容量をあげておく．半田を盛ったら，周囲の部品を壊さない程度に半田ごてをがっつり当てて半田を溶かして部品を取り外す．
f:id:jp7fkf:20180906124058j:plain:w500

取り外すことができた．
f:id:jp7fkf:20180906124111j:plain:w500

半田の残骸をはんだ吸い取り線等を用いて綺麗に取り除く．
f:id:jp7fkf:20180906124119j:plain:w500

綺麗になったら，いよいよ新しいDRAMを取り付ける． DRAMと基板をマスキングテープ等で固定すると，面実装部品でも比較的簡単に半田付けを行うことができる．軽くマスキングテープで固定し，足とパッドにフラックスを塗布する．面実装部品の場合は，ほとんどの場合フラックスを塗ることは必須だと思う．塗っておくと上手にパッドに半田が流れてくれるし，ブリッジもしにくくなる．無洗浄タイプを用いると，後から洗浄を行わなくてよかったり，余計な腐食の心配をしなくていいので楽だと思う． f:id:jp7fkf:20180906124127j:plain:w500

フラックスを塗ったら，いよいよ半田付けを行なっていくが，このような面実装部品では軽くコテ先に半田を含ませて足をなぞるようにするとうまくいく．

この要領で全てのパッドと足がはんだづけされていることを確認する．ブリッジ等が起こっていると，電源を入れた場合にDRAMだけでなく周辺の回路も破壊することがあるので，できるだけルーペなどを用いてブリッジがないということをしっかり確認する．
f:id:jp7fkf:20180906124144j:plain:w500

DRAMの交換が終わったので，元どおりにシャーシを組み上げ，電源を入れる．これでLEDがうまく点滅，点灯したり，コンソール表示が出れば成功だ．緊張の一瞬である．
f:id:jp7fkf:20180906124137j:plain:w500
f:id:jp7fkf:20180906124148j:plain:w500

無事息を吹き返した．よかった．

まとめ

これらの事象が示していることは，POSTは確かにRAMにロードされて動いているとみられるということだ．RAMが死んでいるとPOSTすらまともに走らないし，LEDも無論まともに点灯しない．当たり前といえば当たり前の話なのだが，アーキテクチャを理解していないとわからないことでもあった．この事実を知ったことは，ふるまいが確認できたという点で，大変良い経験となった．

というわけで，無事Cisco Catalyst 2960G を修理することができた． DRAMの故障だと見抜くことは難しいことだと思うが，今回はROMではなくRAMが死んでいてくれただけで大変助かった．めでたし．

P.S. 同じような症状で死んだCat2960GをRAM交換で直そうとしていた人がいた...けど，この人は失敗していた．
Repair of a Cisco 2960G switch with amber LED via RAM chip replacement (FAIL/defect) - YouTube