DigiLoog

AlliedTelesisのAT-SH210-24GTの2台目を分解してみた

2020年06月28日(日) - 23:58 | カテゴリ: Network

業務用途のL2SWを弄り出した頃、実費で初めて購入したのがAlliedTelesisのスイッチだった。
駆け出しの頃お世話になった事もあり、今でもプライベートではAlliedTelesis製品を使っている。
記事タイトルにもなっている「AT-SH210-24GB」は2016年頃に新品で購入済で、
現在も小型ONU経由で入ってくるパケットを、ISP接続用の各ルータに中継する大事な仕事をしている。
AT-SH210/AT-X210シリーズはコマンド体系がCiscoCatalyst風で使いやすく、
発熱が少なくてファンレス稼働も出来る上、業務用途の機能も搭載しているので隠れた名機だと思う。

今回、故障でも無い無いのに稼働中機種と同じ物を購入したのは、
上記の通り重要部分を収容しているL2SWのオンプレ保守部材確保とL2SW検証を行う為。
というのも、メイン用途から退役済のCiscoCatalyst2960Gを検証用にしていたのだが、
機種が古くなってきたのと、古いからこそのファン軸ブレが発生してしまい騒音が凄まじかったから。

一時期はAT-SH210が潤沢に出回っていたのだが、昨年末から流通量が減って値段が高騰していた。
虎視眈々と購入チャンスを伺っていたのだが、従来の相場相当で出ている中古品を偶然発見。
『コレは買うしかない』と何かを感じたので即購入した。

という事で、2台目の「AT-SH210-24GT」を入手。
中古ならば保証も関係無いので、前回は見送ったシャーシ分解をしてみる事にした。

細かいレビューは1台目の記事を参照。
現在使っている物は回線工事をする時に電源を落としたが、
それ以外に電源断も発生せず順調に毎秒10～100Mbpsのパケットを転送し続けている。
そんな感じに負荷もそれなりにかかっていると思う現行環境のLEDは下の様に光っている。

このL2SWが止まるとONUとの接続が全断するので、結果としてインターネットへの通信も止まる。
写真だと「port1.0.23-24」は光っていないが、SFPを使って別室のCatalyst2960SとLAGを組んで通信中。

………

前置きが長かったが、ここから先が今回購入したL2SWの分解レポート。
蓋を開けたら判ったのだが、メイン基盤が他機種と比較して小型化されており技術の進歩を実感した。

中古NW機器を購入した時にドキドキするのが電源ONとパスワードリカバリが出来るかだったりする。
今回の機種は既に使っている事もあって慣れていたので、難なく作業が完了した。
ただ、搭載しているL2SWのOSが古かったので、Cisco同様のtftpコマンドでOSアップグレードも実施。
アップグレード後に再起動を挟んでI/F設定をした所、無事に「port1.0.1」がリンクアップした。

メイン基盤はシャーシの半分程度になっており、中はかなり余裕をもたせた形になっていた。
ちなみに、メイン基板は固体コンデンサ、電源基盤はアルミ電解コンデンサを使っており、
スイッチ発売当時の2015年のトレンドを抑えた設計になっている。

基盤実装を確認すると何かのチップやピンヘッダを取り付ける空きパターンがある。
排熱ファンの3ピン電源用と思われるパターンも用意されているが、
ファンを搭載しない機種だからかコネクタは乗っていなかった。

電源基盤は普通のPC電源と同類の物がシャーシに直付けされていた。
トランスの型番は判らなかったが、1次平滑回路の大容量コンデンサはルビコンMXRだと思われる。
筐体右側面にあった排熱穴にはファンマウンタも用意されていた。
ただし、ファンをネジ止めしようにもプラスドライバを差し込めない箇所にネジ穴があるので、
マウンタを曲げるか別の手段でマウントする必要がある。
さらに、前述の通りメイン基板にファン用電源コネクタが用意されていないので、
自力で実装するか外部電源を引き込む必要がある。

自宅の様に潤沢に冷やせない環境でも常時稼働し続ける安定性、
RJ45/SFPの両ポートを使える物理構成の柔軟さ、
Cisco系コマンド形態による設定の容易さあり「AT-SH210-24GT」は数少ない愛用L2SWとなっている。
今回は検証用途かつ予備部材として購入したが、既に稼働中のL2SW含め大事に利用したい。

« 続きを隠す

No Comments Subscribe via Entries RSS.

[ns-lab BB] 新環境の権威DNS構成

2020年06月14日(日) - 19:35 | カテゴリ: Linux

自鯖刷新によって様々なインフラを見直したのだが、実は権威DNSの構成変更は行わなかった。
刷新直前にグローバルロードバランサを組み込む構成変更を行ったのと、
権威DNSが止まるとサービス停止に陥るので、見直しをした上で安全重視で従来構成を踏襲した。

全体構成

権威DNSは、グローバルIPを応答するインターネット向け権威DNS(インターネットドメイン)と、
プライベートIPを応答するイントラ向け権威DNS(ローカルネットドメイン)で分離する構成にしている。

インターネットドメインの方は、前回の権威DNS構成変更から基本設計を変更せず、
フロントエンドにdnsdist・バックエンドにBINDとgdnsdで処理する様にしている。
ローカルドメインは親ドメインを管理するBINDを最上位に構えつつ、
下位の権威DNSにサブドメインを委任する構成を取っている。

インターネットドメインは『dnsdist + BIND + gdnsd』の複合構成、
ローカルネットドメインは『BIND』単一構成と『dnsdist + PowerDNS』複合構成にした。
世間では、BIND脱却の為にNSDやPowerDNSを利用する機会も増えてきており、
いざという時に追従出来ないのは問題なので、少し囓った事のあるPowerDNSを使っている。

「自宅サーバでここまで必要か」と言われると不要だと思うが、
本職絡みでもDNSサーバ知識が必須なので、技術検証を柔軟に出来る様に上記構成を取っている。

………

今回のサーバ刷新時に構成変更を行っていないので紹介出来る内容が少なかった (´・ω・｀)
唯一の変更点は、レジストラに管理を委任していた他の検証ドメインも集約化を行い、
正引き・逆引き合わせて最終的に9ドメインを管理する体制にした事。

また、ドメイン集約化を行った事でドメイン管理が複雑化したので、
従来利用していたDNSゾーン適用ansibleを見直し、マルチドメインでも簡単に管理出来る様にした。

自鯖の刷新前後を比較して大きな変更点が無い為、権威DNSについて書く事も少なくなくなった。
とは言っても自鯖刷新で大きく構成変更した、仮想サーバ基盤と録画サーバはまだ紹介出来ていないので、
近いうちに書こうと思う。

No Comments Subscribe via Entries RSS.

メイン回線をIPoE+IPv4占有にしつつルータをRTX830に刷新

2020年06月10日(水) - 22:50 | カテゴリ: Network

今までは、PPPoE+IPv4固定+NVR500の回線環境を使っていたが、最近は速度遅延が顕著になっていた。
特に4月末辺りから遅延が酷くなり、一番酷い時では1Mbps程度まで悪化していた。
また、10年前の機種となるNVR500ではスペック不足の場面も増えており、
TCPセッションを複数張るWebアプリを使い続けると、セッションテーブルを食い潰しそうになっていた。

NVR500が発売された2010年と現在を比較すると、Webアプリ台頭によって通信特性も大きく変化しており、
NATセッション数4,096・RAM搭載量64MBでは心許ないのが主な原因であり、
NVR500のサポートしているダイナミックルーティングプロトコルが少ないのも課題の一つだった。

今までは自宅サーバで公開Webサーバを動かしていた事もあり、品質重視のIPv4固定回線を使っていたが、
先日完了した自宅サーバ刷新によって、公開Webサーバも別拠点の仮想サーバに引っ越した上、
バックボーンにはメイン回線とは別のISPを使ったVPN型に変更したので、
通信品質重視の従来回線を使う必要性が下がっていた。

………

以前もIPoE引越しを検討した事があったのだが、検討当時はIPv4専有オプションが無かったので諦めていた。
しかし、世間から要望が多かったのかVNEでもIPv4アドレス専有オプションを提供開始した上、
JPNEのIPv4専有オプションを使ったサービスとして、
IPQ・OpenCircuit・interlinkがアドレス専有オプションをリリースしていた。

通信遅延・IPv4専有オプション・回線維持の必要性低下を総合的に考えると、
IPoE+IPv4専有オプションに移った方がメリットがある為、IPQ提供のIPoE+IPv4専有接続に変更しつつ、
ルータの処理速度を上げる為にも、メイン回線収容ルータをNVR500からRTX830に刷新してみた。