cles::blog

年度の予算使いきりのシーズンになったので Celestica Seastone DX010 という 100GbE スイッチを手にいれてみました。ちょっと古めの機種ですが、送料込みで US$500 未満だったので思っていたよりもだいぶ安く調達できました。

導入にあたっては以下の記事が非常に参考になりました。

• クリスマスなのにスイッチでソニックを遊んでみた！ #SONiC - Qiita
• Inside a Celestica Seastone DX010 32x 100GbE Switch - ServeTheHome

† 初めてのホワイトボックススイッチ

このスイッチの面白い点は、ONIE によって Debian ベースの SONiC^*1という Network OS がインストールできるということです。

これまで Cisco や HP, Juniper, Mellanox(nvidia) などのスイッチは触ったことがありますが、こういう OSS がインスト-ルできるネットワーク機器というのは DD-WRT をいじくり回していた時以来です。しかも今回は家庭用の機器ではなく業務用の機器です。

うるさいという話は聞いていましたが、Mellanox SX6012 よりは静かで助かりました。

† L2 として使う

まずシリアルは速度が 115,200bps であることに注意が必要です。
また、初期ID, PW は admin, YourPaSsWoRd になっています。

今回は BGP とかは使わずにいく予定なので、ログイン後に以下のような感じでプレーンな L2 状態にしてみました。

これからいろいろと遊んでいきたいと思います。

• ^*1: SONiC/sourcecode.md at master·sonic-net/SONiC·GitHub

ちょっとサーバの構築をしていて、ネットワーク機器にpingを打っていたら機器やサーバによって TTL の値が違うことに気づきました。

† TTL とは

IP パケットの TTL (Time to Live) はパケットがネットワーク上でルータ等を介して転送しても良い回数を表しています。ルータ等を通る度に TTL は 1 ずつ減少し、0 になるとパケットは破棄され、送信元にはエラー（ICMP time to live exceeded in transit）が返される仕組みになっているので、パケットが無限にネットワークを流れ続けることがないようになっています。

† 値によって N/W機器、Windows, Linux が区別できるみたい

この TTL の値は 255 までの整数を取ることになっていますが、どうやら OS 等によってデフォルト値が違うようです。

ネットで検索してみると、TTL で OS を知るみたいな一種のインテリジェンスとして使われているみたいですね。ちなみにLinux 等の場合は 64、Windows は 128、ネットワーク機器は 255 と考えれば良いようです。実際に僕が試してみた画像でも、Linux が組み込まれたルーターは 64, Windows は 128, Yamaha のルータは 255 を返しています。

Identify Operating System Using TTL Value And Ping - OSTechNix

The default initial TTL value for Linux/Unix is 64, and TTL value for Windows is 128.

HPE が Juniper を約 140 億ドルで買収することがニュースになっていたのでメモ。

HPE はしばらく前に Aruba を買収してスイッチや無線 LAN は Aruba ブランドに集約が終わったと思っていましたが、次の手が Juniper の買収ということでちょっと驚きました。もう HPE はサーバーのメーカーというよりも、Cisco のようなネットワーク機器メーカーですね。

国内のネットワーク機器のシェアとしてはやはり Cisco が強く、半分弱を占めている状況^*1なので、これで少しでも版図が変わってくれると面白いのですが。

• ^*1: 国内ネットワーク機器市場シェアを発表

今日は YAMAHA の RTX1300 をセットアップ。
僕が触る YAMAHA のルータでは初の 10GbE 対応機です。

今回は無線 AP の WLX222 も含めて YAMAHA で統一しています。

• Yamaha RTX1300
• Yamaha WLX222

設定した感じは RTX1220 とほぼ変わらない感じでしょうか。
VLAN 周りの設定が変わっていますが、RTX1220 の形式で設定は流し込めるので特に戸惑うことはないと思います。

ESET が中古のネットワーク機器から企業の機密情報が取り出せるという研究「How I (could've) stolen your corporate secrets for $100 （100ドルで企業秘密を盗む方法）」の結果を公表していたのでメモ。

設定情報が消去されないままに中古のネットワーク機器が流通しているという実態と、そのリスクを指摘しています。先日の大阪急性期・総合医療センターのインシデント報告書では、脆弱性を持った VPN 機器が侵入の発端であったことが記載されていましたが、きちんとパッチが当たっている VPN 機器であっても接続のための情報がそのまま第三者に渡ってしまうとセキュリティに対して重大な脅威になる可能性があります。

IT 機器の廃棄については、例えば HDD 等では「データ消去技術ガイドブック」などが整備されていたり、ISMS やプライバシーマークなどで破壊等の方法が定められていたりしますが、ネットワーク機器はそのような IT 機器廃棄のライフサイクルから漏れていたりするということですね。

“廃棄された”ルーターが初期化されずに中古市場で流通。深刻なセキュリティリスクに | WIRED.jp

9台のデバイスには、組織が使っていたVPN（仮想プライベートネットワーク）の認証情報や別の安全なネットワーク通信サービスの認証情報、またはハッシュ化されたルート管理者のパスワードが含まれたままだったという。そしてすべてのデバイスに、以前のルーターの所有者やオペレーターが誰であったかを十分に識別できるデータが含まれていた。

光ファイバーや細い LAN ケーブルにタグ付けするときに便利なヘラマンタイトンの光コード識別表示板 IP2FAが切れてしまったので、在庫があるうちにまとめて確保しておくことにしました。

光ケーブルの行き先には数が多い場合は小判型の線名札でもいいんですけど、僕はいちいち結んだり他と絡んだりするのが嫌なんですよね。
IP2FA はこの部品自体は大きめですが、線の密度がそれほど高くなければ部品同士が当たって邪魔ということはありません。

最近、無線 LAN AP など PoE/PoE+ (802.11af/at)機器も増えてきて、lAN ボックス内にいくつも PoE インジェクタが入るようになってしまったので、安い PoE スイッチを使って1つに纏めてしまうことにしました。

• TL-SG1016PE | 16ポート ギガビット デスクトップ/ラックマウント スイッチ （8 PoE+ポート搭載） | TP-Link 日本

† 現在は定常出力で 20W くらい

PoE のステータスを見てみると、無線 LAN AP が最も消費電力が高く（7.6W）、その他おネットワークカメラ、SIP 電話機、Raspberry Pi 3 ほぼ大差ないようです。

出力は定常状態で 20W そこそこですから、一時的に負荷かかかって電力消費量が増えたとしても、このスイッチの限界である最大 150W までは届きそうにありませんから性能的な問題はなさそうです。

バッファローの Twitter が Wi-Fi ルーターを暖房がついてる部屋に置くように注意喚起をしていたのでメモ。

家庭用のルータの多くの動作保証環境は 0℃ ～ 40℃、周囲湿度 15 ～ 80%（ただし、結露しないこと）という感じのものが多いですが、高温で誤動作した経験はあっても、低温で誤動作した経験はないので、確かに下限を意識したことはないかもしれません。

† ちなみに業務用でもあまり変わらなさそう

業務用である Yamaha の WLX212 等を見てみると^*1上限は 50℃ になっていますが、こちらも下限は 0℃ ですね。寒いとダメなのは電解コンデンサの特性とかでしょうか。

動作環境条件 周囲温度0～50℃、周囲湿度15～80%（結露しないこと）

† 屋外使用ができる AP は、やはりスペックが違う

さらに屋外使用ができる業務用 AP を見てみると Ubiquiti の U6 Long-Range AP は -30 to 60℃ 対応になっています^*2。
そして、Cisco Catalyst 9124AX に至っては -40 ～ 65℃ 対応となっていて、さすがといった感じではあります^*3。

• ^*1: WLX212 仕様
• ^*2: U6 Long-Range アクセスポイント – Ubiquiti 日本公式ストア
• ^*3: Cisco Catalyst 9124AX シリーズ アクセス ポイント データシート - Cisco

SadServers という実際に Linux サーバのトラブルーシューティングを体験できる演習環境を見つけたのでメモ。
実際にサーバ運用をしたことがあれば、Easy や Medium あたりは楽しんで挑戦できると思いますが、Hard はかなり難しいです。

SadServers - Troubleshooting Linux Servers

Troubleshoot and make a sad server happy!
"Like LeetCode for Linux"
Capture The Flag challenges. Train and prove your debugging skills.
Practice for your next SRE/DevOps interview.
Get a full remote Linux server with a problem and fix it.

この演習環境のアーキテクチャについては GitHub - fduran/sadservers: SadServers.com Public で解説されていますが、1 回ごとに EC2 でインスタンスが立ち上がるようになっているようです。

Docker のコンテナに対する通信は nftables (iptables) の INPUT chain を通らないので通常のルールが効きません。
このことを忘れていると、Docker で立ち上げたサービスのポートがうっかり外部に公開されていたということになってしまいます。

みんな困っていると思うのですが、あまり良い解決方法がないようなので firewalld にルールを設定してみました。
ルールはipset で作ったホワイトリストと firewalld を流用することにしました。

コンテナへの通信は FORWARD から DOCKER-USER に流れるようなので、DOCKER-USERの方にルールを入れていきます^*1。
以下の設定では http(80/tcp), https(443/tcp,udp) は無条件で許可し、それ以外のポートの通信はホワイトリストに従います。

この passthrough 定義は初めて使いました。

• ^*1: Docker と iptables — Docker-docs-ja 20.10 ドキュメント