Failover構成でのIPアドレスの切り替わりについて（management Interface）

[athirano1]

こんにちは

ASA5515X + OS:9.6系の組み合わせで、構成を検討しております。

・Failover構成(Active-Standby)を組む予定です。
・管理／監視系通信（ssh, ASDM, NTP, Syslogなど）には、Management Interfaceを使う予定です。

Failoverが発生すると、Active機が持っていたIPアドレスをStandby機が引き継ぐわけですが、
その対象外として、Management Interfaceを指定することは可能でしょうか。
「Active／Standbyが切り替わっても、Management InterfaceのIPアドレスは変わらない」という仕様にできれば、
運用監視担当者のオペレーションがやりやすくなります。）

・サポートフォーラムに類似のディスカッション（ASA 7.2系）がありましたが、そこでは「そのような設定はできない」という結論のようでした
    「ASA, management interface and failover.」
    https://supportforums.cisco.com/discussion/11851186/asa-management-interface-and-failover

・Failoverのモニター対象からManagement Interfaceを除外する  という設定例は、いろいろな文書に載っていますが、
  今回実現したいこととは直接は関係ありません。

・本番運用している既存機器（ASA 8系、9.1系など）では、
  プロンプトにて、[host名の情報]＋[Primary/Secondary情報]＋[Active/Standby情報]を表示することで
  「今、どちらの機器にログインしているか」、「Failoverが発生したか否か」を分かるようにしているのですが
  運用監視担当者によっては混乱することもあります。
  また、Management InterfaceのIPが変わらない方が、syslog確認がやりやすくなることも考えられます。
  そのため、今回の質問をしております。

よろしくお願いします。

[Akira Muranaka · Accepted solution]

athirano1さん、こんにちわ。

残念ながら、ASAのIPアドレスは Primary/Secondary(ハードウェア)に紐づいてはおらず、Active/StandbyのStateに設定・紐づいています。 そのため、装置(Primary/Secondary)にIPを紐づけることはできなかったはずです。 いい意味で考えると、PrimaryもSecondaryも関係なく、Activeになった機器は完全に仕事を引き継ぎ、しっかり仕事をしてくれます。 PrimaryとSecondaryはミラーに近いです。 また、動作として シンプルですので、不具合発生要素が少なくなり、安定しやすいと思います (これはFirewallとして重要です)。 

なお、ログにはPrimaryかSecondaryかの記載があるため、ASAの場合 IPアドレスがState(Active/Standby)に紐づけられるという点だけ注意して運用して頂ければ、シスログ運用上は あまり困らないのかな、と思います。 Failoverが発生したかの監視は、ASA-1-xxxxのシスログメッセージを監視されていれば、十分運用できます。 

ASA/pri/act(config)# no fail act
ASA/pri/act(config)# Waiting for the earlier webvpn instance to terminate...
Previous instance shut down. Starting a new one.

Switching to Standby

ASA/pri/stby(config)# fail act
Waiting for the earlier webvpn instance to terminate...
Previous instance shut down. Starting a new one.

Switching to Active
ASA/pri/act(config)#
ASA/pri/act(config)# sh log
Syslog logging: enabled
 Facility: 20
 Timestamp logging: enabled
 Hide Username logging: enabled
 Standby logging: disabled
 Debug-trace logging: disabled
 Console logging: disabled
 Monitor logging: disabled
 Buffer logging: level errors, 16 messages logged
 Trap logging: disabled
 Permit-hostdown logging: disabled
 History logging: disabled
 Device ID: disabled
 Mail logging: disabled
 ASDM logging: level informational, 260 messages logged
Dec 21 2016 17:17:12: %ASA-1-105004: (Primary) Monitoring on interface outside n ormal
Dec 21 2016 17:17:12: %ASA-1-105004: (Primary) Monitoring on interface inside no rmal
Dec 21 2016 17:17:16: %ASA-1-104002: (Primary) Switching to STANDBY - Set by the config command
Dec 21 2016 17:17:18: %ASA-1-104001: (Primary) Switching to ACTIVE - Set by the config command.
ASA/pri/act(config)#

[athirano1]

Akira Muranaka さん、こんにちは

ご回答ありがとうございました。
やはり、仕様ですよね。。
運用・監視担当者には、引き続きプロンプトなどでの確認により、業務をしてもらう予定です。

ありがとうございました。

[Akira Muranaka]

athirano1さん、こんにちわ。

コメント、Ratingありがとうございます！

少し補足させて頂くと、Primary側に常にAcive機の管理IPアドレスを、出来る限り紐づけるようにすることは、(制限はありますが)以下のテクノロジーと設定を使えば可能です。

・Multiple Contextモードを使う
・Active/Active構成にする
・Active/Activeの場合、ASA内で2つのFailover-groupを設定できる
・Failover-group 1を実際のデータの流れる設定に紐づける
・Failover-group 2を管理用IPに紐づける & 管理Interfaceを no managemnet-interfaceで監視対象から外す
・Preempt(自動切戻り)を有効にする (※Act/Act構成のみ設定可能)

上記は、ASA筐体内に、仮想コンテキスト（※仮想マシンのようなもの）を複数動作させて実現するトリッキーな構成です。当構成にすることで、論理上は、Primary機の電源断以外は、Primary機はActiveの管理IPアドレスを出来る限り保持できるような構成にできます。ただ、この構成の実現のためには、設定や検証がシングルモード時に比べて数倍難しくなりますし、設定量が増える分 パフォーマンスも若干下がるでしょうし、サポートしてない機能もあったり、まずそもそも 構成が複雑なので管理・運用が大変です。（私も幾つか似た構成で運用されているお客様を見たことがありますが、管理が大変なので、次回はこの構成はやめたい、と仰ってました。。）

ASAのシンプルな構成時の「常にStateに Active IP or Standby IPが紐づく」という前提の元、運用されたほうが、上記のようなトリッキーな構成にしなくてもよく、設定管理や運用管理上も楽で、パフォーマンス上もいいのかなぁと思いました。 合わせて ご参考になれば。。

[athirano1]

Akira Muranakaさん

こんにちは、athirano1です。
追加情報ありがとうございます。

Multiple Contextは、以前、複数の顧客システムを１台のASAで収容（接続）する目的で検討＋検証機でのコマンド試し打ちをしたことがあります。
しかし「構成が複雑なので、運用・監視業務を、一定の水準で継続するには不安がある」という理由でチーム内で不採用となりました。

Active/Active構成は、（今回の質問からははずれますが）ASAでSSL-VPNサーバを構成する際の、通信振り分けのために検討したことがあります。検証を考えると、運用開始時期に間に合わないことが明らかだったため、こちらも、不採用としました。
（ユーザーへのClientProfileの配布を考慮することで、結果的に通信を分散させました。）

いずれも、現時点では「複雑なので」という理由で採用を見送っています（避けて通っています）が、いつかは向かい合う日が来るのではないかと考えております。。

ありがとうございました。