シナプス技術者ブログ

シナプスの技術者公式ブログ。インターネットで、鹿児島の毎日を笑顔にします。

冗長化にGLBPを使って監視設定でハマった話

シナプスの技術部 ネットワーク課の福山と申します。

前々回、弊社の松元が紹介した記事のWi-Fiネットワークでネットワーク構築を担当しました。

デフォルトゲートウェイの冗長化にGLBPを使い、トラフィックの分散ができてよかったのですが、インターネット側からZabbixによる監視の設定をした際に、うまくいかなかったことがありました。そのことについて書き留めておきたいと思います。

構築環境の概要

今回のネットワーク構築環境の概要は以下となります。

  • R : ルータ
  • SW : PoEスイッチ
  • AP : 無線アクセスポイント
  • DG : デフォルトゲートウェイ

f:id:chamesan:20190511135839j:plain

  • 各APに無線接続した端末(スマホ等)にDHCPでプライベートIPとデフォルトゲートウェイを割り当てる
  • デフォルトゲートウェイはGLBPの仮想IP
  • 端末(スマホ等)に割り当てられたプライベートIPからインターネット接続するためにPATでグローバルIPに変換

インターネット側への通信

各無線APに無線接続した端末のインターネット側への通信は、GLBPにより端末1からはR01側へ、端末2からはR02側へといったようにトラフィックが分散されます。 仮にR02側の回線及びR02の機器自体に障害があった場合、端末1も端末2もR01側で通信できます。

f:id:chamesan:20190511140004j:plain

  • R02障害時

f:id:chamesan:20190511140023j:plain

監視の設定

弊社側にZabbixサーバをたてて各無線APのトラフィックを監視しました。

各無線APを接続しているスイッチがSNMPに対応していたので、スイッチのポートを監視するため、ルータにポートフォワーディングを設定しました。

  • R01
ip nat inside source static udp 192.168.0.11 161 [グローバルIP1] 16111
ip nat inside source static udp 192.168.0.12 161 [グローバルIP1] 16112
  • R02
ip nat inside source static udp 192.168.0.11 161 [グローバルIP2] 16111
ip nat inside source static udp 192.168.0.12 161 [グローバルIP2] 16112

スイッチのデフォルトゲートウェイをGLBPの仮想IPにすることで、仮にR02側に障害が発生しても、R01側からSW01、SW02両方の監視をできればと思い、ポートフォワーディングの設定をSW01、SW02向けに2つ入れています。

f:id:chamesan:20190511140052j:plain

  • R02障害時

f:id:chamesan:20190511140105j:plain

うまくいかなかったこと

実際に監視をしてみると、トラフィックデータを取得できる時とできない時がありました。

そこでZabbixサーバ側でパケットキャプチャをしてみました。

取得できたとき

  • snmpget 実行
# snmpget -v 2c -c public [グローバルIP1]:16111 SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: BUFFALO BS-GS2008P
  • パケット
22:57:02.404663 IP [ZabbixサーバのIP].35901 > [グローバルIP1].16111: UDP, length 125
22:57:02.699144 IP [グローバルIP1].16111 > [ZabbixサーバのIP].35901: UDP, length 135
22:57:02.470849 IP [ZabbixサーバのIP].52709 > [グローバルIP1].16111: UDP, length 44
22:57:02.714195 IP [グローバルIP1].16111 > [ZabbixサーバのIP].52709: UDP, length 1088

取得できなかったとき

  • snmpget 実行
# snmpget -v 2c -c public [グローバルIP1]:16111 SNMPv2-MIB::sysDescr.0
Timeout: No Response from [グローバルIP1]:16111.
  • パケット
22:59:17.205606 IP [ZabbixサーバのIP].60802 > [グローバルIP1].16111: UDP, length 43
22:59:17.456822 IP [グローバルIP2].16111 > [ZabbixサーバのIP].60802: UDP, length 61
22:59:18.207031 IP [ZabbixサーバのIP].60802 > [グローバルIP1].16111: UDP, length 43
22:59:18.219009 IP [グローバルIP2].16111 > [ZabbixサーバのIP].60802: UDP, length 61

トラフィックデータを取得できない時は、SNMPリクエストの宛先IPに対して、SNMPレスポンスの送信元IPが異なっていました。 例えばR01経由でSW01宛てのSNMPリクエストに対して、GLBPによりR02経由でSNMPレスポンスが返ってきた時です。

SNMPリクエストに対してSNMPレスポンスが返ってくればよいのではと単純に考えていたのですが、ポートフォワーディングしているので、SNMPリクエストの宛先IPとSNMPレスポンスの送信元IPが異なることで通信が成り立たないようでした。

f:id:chamesan:20190511140122j:plain

まとめ

結局、監視設定に関しては冗長化はあきらめ、SW01のデフォルトゲートウェイはR01の物理インターフェース、SW02のデフォルトゲートウェイはR02の物理インターフェースに固定しました。

そもそも今回、光回線を2回線準備したので、デフォルトゲートウェイの冗長化にはトラフィックの分散のためのGLBPを使うのではなく、HSRPでもよかったかもしれません。

ですが、今回のように想定通りにいかない時に、パケットキャプチャをして実際のパケッ トの動きをみてみることの大事さを改めて実感することができ、貴重な経験となりました。

参考サイト www.infraexpert.com