アライドテレシスマネージメントフレームワーク（AMF） / 応用
ここでは、応用編と題し、AMFの高度な機能や利用法を紹介します。
AT-DC2552XSでは、外部メディアはサポート対象外のため、AMFバックアップデータの保存先としては外部のSSHサーバーのみ使用可能です。
応用編では、手順説明に重点を置くため、ワーキングセットプロンプト移行時の対象ノード一覧表示など、コマンド実行時に表示されるメッセージを必要に応じて省略しています。あらかじめご了承ください。
機種固有の制限事項・注意事項については、導入編の「導入にあたり」もご参照ください。
他ノードのファイル操作
AMFネットワークでは、以下のコマンドを使用して他のAMFノードのファイルシステムを操作できます。
本機能はAMFセキュアモード時には使用できません。
他のAMFノードのファイルを指定するときは、通常のローカルファイルパスの代わりに、次の形式を使用してください。前述のコマンドにおいてローカルファイルパスを指定できる箇所なら、どこでもこの形式を使用できます。
<NODENAME>.atmf/<ABSOLUTEPATH>
ここで、<NODENAME>はAMFノードのノード名を、<ABSOLUTEPATH>は該当メンバーのファイルシステムにおける絶対パス（デバイス名を含む完全なパス）を表します。
たとえば、AMFノード「FSW241」上のファイルflash:/sample.cfgは次のように表します。
FSW241.atmf/flash:/sample.cfg
次のようにすることで、このファイルをマスター（SBx81）にコピーすることが可能です。
SBx81# copy ESW231.atmf/flash:/sample.cfg flash:/ ↓
Enter destination file name[sample.cfg]: ↓
Copying.
Successful operation
その他の動作や表示内容は、通常のファイル操作と同じです。
ファイル操作の詳細は、「運用・管理」/「ファイル操作」をご覧ください。
ユーザー追加とパスワード変更
ワーキングセット機能を利用するには、マスターとメンバーでCLIログイン用のユーザー名を統一しておく必要があるため、ユーザーの追加やパスワードの変更は次のように全ノードを対象とするワーキングセットプロンプトから行うのがよいでしょう。
■ 新規管理者ユーザーの追加は次の手順で行います。
- すべてのノードを対象とするワーキングセットプロンプトに移行します。
SBx81# atmf working-set group all ↓
- 全ノード一括で新規管理者ユーザーを追加します。
AMF001[4]# configure terminal ↓
AMF001[4](config)# username supervisor privilege 15 password YYYYYYYY ↓
AMF001[4](config)# end ↓
- 全ノード一括で設定を保存します。
AMF001[4]# write ↓
- マスターのCLIからいったんログアウトし、新しく追加した管理者ユーザーのユーザー名とパスワードでログインしなおします。
これ以降、ワーキングセット機能では、新しいユーザー名とパスワードで各ノードへの操作が行われます。
AMF001[4]# exit ↓
SBx81 login: supervisor ↓
Password: YYYYYYYY ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
SBx81>
■ 既存管理者ユーザーのパスワード変更は次の手順で行います。
- すべてのノードを対象とするワーキングセットプロンプトに移行します。
SBx81# atmf working-set group all ↓
- 全ノード一括で既存管理者ユーザーのパスワードを変更します。
AMF001[4]# configure terminal ↓
AMF001[4](config)# username manager password XXXXXXXX ↓
AMF001[4](config)# end ↓
パスワードを変更しても、マスターのCLIからログアウトするまで、現行のワーキングセットセッションは有効です。
- 全ノード一括で設定を保存します。
AMF001[4]# write ↓
- マスターのCLIからいったんログアウトし、新しいパスワードでログインしなおします。
これ以降、ワーキングセット機能では、新しいパスワードで各ノードへの操作が行われます。
AMF001[4]# exit ↓
SBx81 login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
SBx81>
ネットワーク構成について
マスターの二重化
AMFネットワークは、管理機能を実現するためのコントロールプレーンだけを提供しており、ユーザートラフィック用のネットワーク（データプレーン）とは独立しているため、仮にマスターが停止しても、ワーキングセットやバックアップ、オートリカバリーなどAMFの管理機能が使えなくなるだけで、マスター以外のデータプレーンには影響が及びません。
また、コンソールターミナル、Telnet、SSH、SNMPなどの従来からある管理機能は、AMFネットワークの動作状態と関係なく使用できるため、AMFマスター不在によりメンバーの管理ができなくなることもありません。
マスターを復旧させればAMFの管理機能も再び使えるようになるため、AMFの観点からは必須ではありませんが、マスターを2台配置して二重化することも可能です。
マスターを二重化するメリットは次のとおりです。
- 1台が停止しても、AMFの管理機能を継続利用できます。
- 1台構成ではマスターの交換時に手動リカバリーが必要ですが、2台構成であればもう1台のマスターが持つバックアップデータからオートリカバリーが可能です。
- 2台のマスターはバックアップを個別に行うため、両方のマスターにUSBメモリー、SD/SDHCカードを装着しておけば、バックアップデータも二重化されます。（USBメモリー、SD/SDHCカードの内容が同期されるわけではないことに注意）
マスターを2台使用する場合は、同一の機種およびAMFマスターライセンスをご用意ください。異なる機種・ライセンスを混在させた構成はサポート対象外です。ただし、マスターとしてSwitchBlade x8100を2台使う場合は、片方のコントロールファブリックカードがAT-SBx81CFC400、もう一方がAT-SBx81CFC960の構成でもかまいません。ただしその場合も、AMFマスターライセンスのサポートメンバー数は同じものをご使用ください。
■ 1つのAMFネットワークにマスターを2台配置したいときは、マスター同士を接続するポートを通常のAMFリンク（switchport atmf-link）ではなく、AMFクロスリンク（switchport atmf-crosslink）に設定してください。
たとえば、SBx81aとSBx81bをそれぞれポート1.1.1で接続する場合は、次のように設定します。
SBx81a(config)# interface port1.1.1 ↓
SBx81a(config-if)# switchport atmf-crosslink ↓
SBx81b(config)# interface port1.1.1 ↓
SBx81b(config-if)# switchport atmf-crosslink ↓
AMF Cloudを二重化する場合は仮想クロスリンク（atmf virtual-crosslink）を使います。
■ 次図は、ユーザートラフィック用のネットワーク（データプレーン）においてVRRPを用いた構成例です。
■ ワーキングセット機能において、マスターは予約済みグループmasterの所属となります。
2台のマスターにコマンドを同時発行したいときは、group masterを指定してワーキングセットプロンプトに入ると便利です。
SBx81a# atmf working-set group master ↓
===============
SBx81a, SBx81b:
===============
Working set join
AMF001[2]#
■ オートリカバリー中のAMFノードは、AMFネットワーク上のすべてのマスターに対して、自ノード用のバックアップデータがないかを問い合わせ、新しいほうのデータを使ってリカバリーを実行します。atmf recoverコマンドによる手動リカバリー時も、MASTER_NODENAMEパラメーターを指定しない場合は同じ動作です。MASTER_NODENAMEパラメーターでどちらかのマスターを指定した場合は、指定したマスターが持つバックアップデータを使ってリカバリーします。
リング構成での考慮事項
次のようなリング構成では、AMFネットワークの階層レベル（show atmf nodesコマンドで表示されるNode Depth）が深くなります。
Node Depthには「最大8」のサポートリミット（導入編の「導入にあたり」を参照）などがあるため、リング構成では、次図のようにリングを構成する各ノードを通常のAMFリンク（switchport atmf-link）ではなくAMFクロスリンク（switchport atmf-crosslink）で接続することをおすすめします。
これにより、リングを構成するノードはすべて同一階層となり、AMFネットワーク全体の階層レベルが浅くなります。
なお、同じリング構成でも、次図のようなロングディスタンスVCS（LD-VCS）構成の場合は、リング全体が1台のAMFノードとして扱われるため、AMFクロスリンクを使う必要はありません。
AMFネットワークの分割（メンバー数がサポート上限を超える場合）
1つのAMFネットワーク（マスター1～2台）に接続できるメンバーは最大2/10/20/40/82/124/304台です（上限はマスターの機種とライセンスによって異なります。詳細は導入編を参照）。
メンバー数がご使用中のライセンスのサポート上限を超える場合は、次の図（40メンバーライセンスの例）のようにAMFネットワークを分割し（異なるAMFネットワーク名を設定し）、それぞれのマスターを非AMF接続ポートで接続してください。
異なるAMFネットワークに所属するマスター間の連携はありません。この例では、AMFネットワーク1 に所属するメンバーの操作は AMFマスター1 のCLIから行い、AMFネットワーク2に所属するメンバーの操作は AMFマスター2 のCLIから行う形になります。
なお、ユーザートラフィック用のネットワーク（データプレーン）上でVRRPを使用することにより、次のような構成も可能です。
AMF仮想リンクによるワイドエリアAMFネットワーク
WAN経由で接続されている拠点をAMFネットワークに参加させる場合は、AMF仮想リンク（atmf virtual-link）というAMF専用のトンネリング機能を使用します。
AMF仮想リンクを設定することにより、データプレーン（運用ネットワーク）のIPv4ネットワーク経由でAMF対応スイッチ同士を接続し、AMFパケットの送受信を行わせることができます。AMF仮想リンクでは、AMFパケットをIPパケットに載せて運ぶため、IPによる通信が可能であれば、AMF対応スイッチ間にルーターなどのAMF非対応機器が介在していてもAMFネットワーク上は2台が直結されているかのように扱うことができます。
AMF仮想リンクの製品ごとの設定可能数や注意事項については、atmf virtual-linkコマンドの「注意・補足事項」をご参照ください。
仮想リンクでAMFネットワークに接続しているAMFノードにおいても、隣接するノードの補助によりオートリカバリーが可能です。 詳細は、運用編の「仮想リンク経由で接続しているAMFノードのオートリカバリー」をご覧ください。
■ 前図における本社側のAMFノード HQ001（10.1.1.1）と、支社側のAMFノード BR101（10.10.10.1）の間にAMF仮想リンクを設定するには、次の手順にしたがいます。
ここでは、本社側のHQ001はすでにAMFの基本設定が行われており、運用中であると仮定しています。一方、支社側のBR101は通常動作については運用中ですが、AMFは未設定と仮定します。
- 本社側ノード HQ001
- 仮想リンクの接続先である支社側ノード BR101とIPv4による通信ができることを確認します。できない場合は、適宜IPの設定を行ってください。
- atmf virtual-linkコマンドでAMF仮想リンクを設定します。
HQ001(config)# atmf virtual-link id 1 ip 10.1.1.1 remote-id 1 remote-ip 10.10.10.1 ↓
- 支社側ノード BR101
- ネットワーク名を設定します。これにはatmf network-nameコマンドを使います。
ネットワーク名は、同一AMFネットワークを構成するすべてのノードに同じ名前を設定する必要があります（マスターと異なるネットワーク名を設定したメンバーはAMFネットワークに参加できません）。また、ネットワーク名は大文字小文字を区別するので、その点にもご注意ください。
BR101> enable ↓
BR101# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
BR101(config)# atmf network-name AMF001 ↓
- AMFの設定を有効にするため、設定をスタートアップコンフィグに保存し、再起動します。
BR101(config)# end ↓
BR101# write memory ↓
Building configuration...
[OK]
BR101# reboot ↓
reboot system? (y/n): y ↓
- 再起動後、仮想リンクの接続先である本社側ノード HQ001とIPv4による通信ができることを確認します。できない場合は、適宜IPの設定を行ってください。
- atmf virtual-linkコマンドでAMF仮想リンクを設定します。
BR101(config)# atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1 ↓
以上で仮想リンクの設定は完了です。これ以降、支社側のノード BR101は、AMFネットワークAMF001上において、本社側のAMFノードと同様に扱うことができます。さらに、BR101 配下のノードに対しても、通常のAMF設定を行うことでAMFネットワークAMF001に参加させることが可能です。
■ AMF仮想リンクでは、データプレーン（運用ネットワーク）上にAMFのコントロールプレーン（管理ネットワーク）を配置する形となるため、データプレーンのトラフィックがAMFの接続性に影響を与える可能性があります。
この影響を最小限にするため、AMF仮想リンクを使用するノード（仮想リンクの両端ノード）では、次のようなQoS設定を行い、対向ノードからのパケットを優先的に処理するよう設定することを推奨します。
また、AMF仮想リンクの経路上にある機器（ルーターなど）においても、必要に応じて優先制御等の設定を行ってください。
以下のコンフィグはAMF仮想リンク使用時に推奨されるQoS設定の大枠を示すためのものです。実際の環境や機器にあわせて、適宜パラメーターの変更等を実施してください。また、すでにQoSの設定を行っている場合は、既存のポリシーマップに下記の設定内容を適宜追加してください。
- SwitchBlade x8100、SwitchBlade x908、x900シリーズの場合
...
mls qos enable
access-list hardware vlink
send-to-cpu ip 10.10.10.1/32 10.1.1.1/32
!
class-map vlink
match access-group vlink
!
class-map vlinkarp
match eth-format ethii-any protocol 0806
match vlan 10
!
policy-map vlink
class default
class vlink
set queue 6
class vlinkarp
set queue 6
!
...
!
interface port1.0.10
switchport
switchport mode access
switchport access vlan 10
service-policy input vlink
!
...
interface vlan10
ip address 10.1.1.1/24
!
...
atmf virtual-link id 1 ip 10.1.1.1 remote-id 1 remote-ip 10.10.10.1
...
- AT-DC2552XS、x930シリーズ、x550シリーズ、x510シリーズ、x510Lシリーズ、AT-IX5-28GPX、x310シリーズの場合
...
mls qos enable
access-list hardware vlink
permit ip 10.1.1.1/32 10.10.10.1/32
!
class-map vlink
match access-group vlink
!
class-map vlinkarp
match eth-format ethii-any protocol 0806
match vlan 10
!
policy-map vlink
class default
class vlink
remark new-cos 6 both new-cpu-queue 6
class vlinkarp
remark new-cos 6 both new-cpu-queue 6
!
...
!
interface port1.0.10
switchport
switchport mode access
switchport access vlan 10
service-policy input vlink
!
...
interface vlan10
ip address 10.10.10.1/24
!
...
atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1
...
- x610シリーズ、x210シリーズ、x200シリーズ、IE200シリーズの場合
...
mls qos enable
access-list hardware vlink
permit ip 10.1.1.1/32 10.10.10.1/32
!
class-map vlink
match access-group vlink
!
class-map vlinkarp
match eth-format ethii-any protocol 0806
match vlan 10
!
policy-map vlink
class default
class vlink
remark new-cos 6 both
class vlinkarp
remark new-cos 6 both
!
...
!
interface port1.0.10
switchport
switchport mode access
switchport access vlan 10
service-policy input vlink
!
...
interface vlan10
ip address 10.10.10.1/24
!
...
atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1
...
■ AMF仮想リンクのトンネリングパケットには下記のUDPパケットが使われます。
- 始点ポート（5001～9094）＝ 5000 + ローカルID（1～4094）
- 終点ポート（5001～9094）＝ 5000 + リモートID（1～4094）
前項のQoS設定ではパケットの識別条件としてIPアドレスだけを使用していますが、上記UDPポートを条件に追加することで、純粋に仮想リンクのトンネリングパケットだけを優先処理の対象にすることも可能です。
先ほどのQoS設定例にUDPポート指定を追加した場合、アクセスリストの設定は次のようになります（赤字は変更または追加箇所です）。
ここでは、どちらのノードもIDとして1を使用しているため、UDPポート番号は始点・終点とも5001になっています。
- SwitchBlade x8100、SwitchBlade x908、x900シリーズの場合
...
access-list hardware vlink
send-to-cpu udp 10.10.10.1/32 eq 5001 10.1.1.1/32 eq 5001
...
atmf virtual-link id 1 ip 10.1.1.1 remote-id 1 remote-ip 10.10.10.1
...
- AT-DC2552XS、x930シリーズ、x610シリーズ、x550シリーズ、x510シリーズ、x510Lシリーズ、AT-IX5-28GPX、x310シリーズ、x210シリーズ、x200シリーズ、IE200シリーズの場合
...
access-list hardware vlink
permit udp 10.1.1.1/32 eq 5001 10.10.10.1/32 eq 5001
...
atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1
...
■ AMF仮想リンクの経路上にある中継機器（ルーターなど）でパケットフィルタリングを行っている場合、AMF仮想リンクパケットだけを透過させるには、トンネル両端ノードのIPアドレスと前述のUDPポートを条件として、中継機器に許可設定を行ってください。
たとえば、次のような仮想リンクを設定している場合、
site11(config)# atmf virtual-link id 11 ip 192.168.10.1 remote-id 12 remote-ip 192.168.10.2 ↓
site12(config)# atmf virtual-link id 12 ip 192.168.10.2 remote-id 11 remote-ip 192.168.10.1 ↓
仮想リンクのトンネリングパケットは次の条件で識別できますので、中継機器に対して下記のパケットを許可する設定を行ってください。
- site11 → site12
UDP 192.168.10.1:5011 → 192.168.10.2:5012
- site12 → site11
UDP 192.168.10.2:5012 → 192.168.10.1:5011
パケットフィルタリングの具体的な設定方法については、中継機器のマニュアル等でご確認ください。
AMFセキュア仮想リンク
下記の製品は、AMF仮想リンクの暗号化（AMFセキュア仮想リンク）に対応しています。
- x510シリーズ
- x510Lシリーズ
- AT-IX5-28GPX
- x310シリーズ
- x230シリーズ（52ポート版を含む）
- x230Lシリーズ
- x220シリーズ
- AT-AR4050S
- AT-AR3050S
- AT-AR2050V
- AT-AR2010V
- AT-AR1050V
- AMF Cloud
仮想リンクを暗号化するには、両側の機器において、通常の仮想リンクの設定に加えてatmf virtual-link protection ipsecコマンドを実行し、共通のパスワード（事前共有鍵）を設定します。
以下、先に述べた通常の仮想リンク設定例に暗号化の設定を追加した例を示します。
（ここでは両ノードともAMFセキュア仮想リンクをサポートしている機種だと仮定しています）
- 本社側ノード HQ001
HQ001(config)# atmf virtual-link id 1 ip 10.1.1.1 remote-id 1 remote-ip 10.10.10.1 ↓
HQ001(config)# atmf virtual-link id 1 protection ipsec key SecretKey ↓
- 支社側ノード BR101
BR101(config)# atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1 ↓
BR101(config)# atmf virtual-link id 1 protection ipsec key SecretKey ↓
AMFセキュア仮想リンクの製品ごとの設定可能数や注意事項については、atmf virtual-link protection ipsecコマンドの「注意・補足事項」をご参照ください。
AMFコントローラー機能
さらに大規模なネットワークを構築したい場合は、AMFコントローラー機能（以下、コントローラー）を使います。
コントローラー機能は、複数のエリア内のAMFマスターおよびメンバーを、統合管理する機能です。
最大60のローカルマスターを通して18000台のAMFメンバーを、コントローラーから操作できるため、複数のマスターを必要とする大規模環境で集中管理が可能となり、遠隔からのメンテナンスによるネットワークの管理リソース削減や、オートリカバリーを利用することでのダウンタイム抑制による、ネットワーク全体の管理コスト削減と可用性を向上できます。
AMF Cloudのマルチテナントモードでは、最大300のローカルマスターを管理可能です。
■ 対象機器
- コントローラー（ライセンスが必要）
AMF Cloud、
AT-SBx81CFC960、
SwitchBlade x908 GEN2
- マスター
AT-SBx81CFC960、
AT-SBx81CFC400、
x950シリーズ、
x930シリーズ、
SwitchBlade x908、
SwitchBlade x908 GEN2、
AT-AR4050S
x900シリーズとAT-DC2552XSはAMFマスターとして使用できますが、AMFコントローラー配下のローカルマスターとしては使用できません。
■ サポート機能
本機能では、コントローラー配下のAMFマスターを「ローカルマスター」と定義し、コントローラーから以下の機能を通じて、複数マスターにまたがるネットワーク全体の統合管理が可能です。
- 最大60のローカルマスターを操作可能
最大60のローカルマスターを通して18000台のAMFメンバーを、コントローラーから操作可能です。
AMF Cloudのマルチテナントモードでは、最大300のローカルマスターを管理可能です。
- ワーキングセットの実行
コントローラーから指定した1つのローカルマスターに対してワーキングセットを実行できます。
1つのローカルマスターに対してのみ実行可能であり、複数ローカルマスターへの同時実行は未サポートです。
- ローカルマスターからコントローラーへのバックアップ
コントローラーから自動または手動でローカルマスターのバックアップを取得できます。
- ローカルマスターのオートリカバリー
ローカルマスター配下のメンバーにローカルマスターのコンフィグファイルを保持させ、機器交換時に配下のメンバーからのコンフィグファイルとコントローラーからバックアップファイルを取得することで、オートリカバリーを行います。
- 仮想リンクサポート（エリア仮想リンク）
コントローラーとAMFネットワーク間の接続には物理接続および仮想リンクを使用可能です。
基本設定
コントローラー機能の設定は、次の手順で行います。ここでは、スイッチSwitchBlade x8100をコントローラースイッチとし、2つのエリアを作成します。
既存のAMFネットワークに対して、エリアの設定を行う手順を説明します。
全機器ではすでにAMFノード名（hostnameコマンド）、AMFネットワーク名（atmf network-nameコマンド）、AMF接続ポート（AMFリンク）の設定（switchport atmf-linkコマンド）が行われていることを前提とします。また、コントローラーと各ローカルマスターにはAMFノード名、AMFネットワーク名、IPアドレスとAMFマスター（atmf masterコマンド）の設定が行われていることを前提とします。
※全エリアで同じAMFネットワーク名を設定してください。
1. コントローラースイッチを設定します
1-1. エリアの設定（上図の構成例を例としています）
1-1-1. 対象ノードをコントローラーとして設定します。これにはatmf controllerコマンドを使います。
SBx81(config)# atmf controller ↓
1-1-2. 対象ノードをコントローラーエリアとして設定します。これにはatmf area idコマンドを使います。
SBx81(config)# atmf area area1 id 1 local ↓
1-1-3. エリア2を作成します。これにはatmf area idコマンドを使います。
SBx81(config)# atmf area area2 id 2 ↓
1-1-4. エリア2のパスワードを設定します。これにはatmf area passwordコマンドを使います。
SBx81(config)# atmf area area2 password abcabcabc ↓
1-1-5. エリア3をエリア2作成時と同様に作成します。エリア2作成時と同じコマンドを使います。
SBx81(config)# atmf area area3 id 3 ↓
SBx81(config)# atmf area area3 password xyzxyzxyz ↓
1-2. エリア2と接続するために、ポートにエリアリンクを設定します。これにはswitchport atmf-arealink remote-areaコマンドを使います。
SBx81(config)# interface port1.1.1 ↓
SBx81(config-if)# switchport atmf-arealink remote-area area2 vlan 2000 ↓
ここで指定するVLAN IDは、コントローラー機能が内部的に使用するマネージメントVLANのIDとなります。vlan databaseコマンドで作成したVLAN IDは指定できません。vlan databaseコマンドで設定を行っていないVLAN IDを指定してください。
1-3. エリア3と接続するために、エリア仮想リンクの設定をします。
SBx81(config)# atmf virtual-link id 1 ip 192.168.0.254 remote-id 1 remote-ip 192.168.0.1 remote-area area3 ↓
コントローラーの設定は以上です。
2. エリア2のローカルマスターを設定します。
2-1. エリアの設定（上図の構成例を例としています）
2-1-1. エリア2の対象ノードを、AMFローカルマスターエリアとして設定します。これにはatmf area idコマンドを使います。
SBx908a(config)# atmf area area2 id 2 local ↓
2-1-2. エリア2のパスワード（前述手順の1-1-4で設定したパスワード）を入力します。これにはatmf area passwordコマンドを使います。
SBx908a(config)# atmf area area2 password abcabcabc ↓
2-1-3. コントローラーエリア（前述手順の1-1-2で設定したエリア）を入力します。これにはatmf area idコマンドを使います。
SBx908a(config)# atmf area area1 id 1 ↓
2-2. エリア1との接続するために、ポートにエリアリンクの設定をします。
SBx908a(config)# interface port1.1.1 ↓
SBx908a(config-if)# switchport atmf-arealink remote-area area1 vlan 2000 ↓
switchport atmf-arealink remote-areaコマンドは、マスターでもメンバーでも、どちらでも設定を行うことができます。環境に合わせて使い分けてください。
エリア2のローカルマスターの設定は以上です。
正常に組めると、以下のメッセージがコントローラー上で出力されます。
SBx81# 15:51:51 SBx81 ATMF [4158]: area2 is reachable. 1 reachable area in total ↓
3. エリア3のローカルマスターの設定をします。
3-1. エリアの設定（上図の構成例を例としています）
3-1-1. エリア2のローカルマスター設定と同様に設定します。
SBx908b(config)# atmf area area3 id 3 local ↓
SBx908b(config)# atmf area area3 password xyzxyzxyz ↓
SBx908b(config)# atmf area area1 id 1 ↓
3-2. エリア1との接続するために、エリア仮想リンクの設定をします。
SBx908b(config)# atmf virtual-link id 1 ip 192.168.0.1 remote-id 1 remote-ip 192.168.0.254 remote-area area1 ↓
atmf virtual-linkコマンドは、マスターでもメンバーでも、どちらでも設定を行うことができます。環境に合わせて使い分けてください。
エリア3のローカルマスターの設定は以上です。
正常に組めると、以下のメッセージがコントローラー上で出力されます。
SBx81# 16:52:29 SBx81 ATMF[4158]: area3 is reachable. 2 reachable areas in total. ↓
■ エリアとの接続を確認したい場合は、show atmf areaコマンドを使います。
SBx81# show atmf area ↓
ATMF Area Information:
* = Local area
Area Area Local Remote Remote Node
Name ID Gateway Gateway Master Count
--------------------------------------------------------------------------------
* area1 1 Reachable N/A N/A 1
area2 2 Reachable Reachable Auth OK 2
area3 3 Reachable Reachable Auth OK 2
Area count: 3 Area node count: 5
■ 全エリアのスイッチを確認したい場合は、show atmf area nodesコマンドを使います
SBx81# show atmf area nodes ↓
area2 Area Node Information:
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
SBx908a SwitchBlade x908 Y S none 0
x230 x230-10GP N N SBx908a 1
area2 node count 2
area3 Area Node Information:
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
SBx908b SwitchBlade x908 Y S none 0
x510 x510-28GTX N S SBx908b 1
area3 node count 2
■ 別エリアのローカルマスターを制御したい場合は、atmf select-areaコマンドを使用してください。
SBx81# atmf select-area area2 ↓
=========================================
Connected to area area2 via host SBx908a:
=========================================
area2#
■ 別エリアのスイッチを制御したい場合は、atmf select-areaコマンドでエリアを選択してから、atmf working-setコマンドを使用してください。
SBx81# atmf select-area area2 ↓
=========================================
Connected to area area2 via host SBx908a:
=========================================
area2# atmf working-set group x230 ↓
=====
x230:
=====
Working set join
area2[1]#
■ ローカルマスターのバックアップを有効にするには、atmf backup area-masters enableコマンドを使います。
注意事項
- AMF使用時は、ネットワーク構成や併用機能に関する注意事項や制限事項があります。「導入にあたり」を参照し、既存のネットワーク構成や使用中の機能に問題がないかご確認ください。
サポート対象外のネットワーク構成や併用機能がある場合は、構成や機能を適宜変更してからAMFの導入を進めてください。
- AMFコントローラーを2台以上の機器に設定しないでください。
- コントローラーは各エリアのAMFノードの参加/不参加を表すログやトラップは出力せず、各ローカルマスターで出力しています。そのため、各エリアのローカルマスターで、必要に応じて、SNMP機能やログ機能の設定を行うようにしてください。
- エリア間の内部通信では、FD00:4154:4D46:xxxx::yyyyのアドレスを使用しています。インターフェースにFD00:4154:4D46:xxxx::yyyyのアドレスの設定を行っている場合、AMFコントローラー機能の設定ができません。
- switchport atmf-arealink remote-areaコマンドを設定すると、そのポートは自動的にタグ付きポートになります。タグなしポートとして運用していたポートをAMF接続ポートに設定すると、タグなしVLANの設定が失われるため、AMF接続ポートの設定後にネイティブVLANの再設定が必要です。
たとえば、次の設定がしてあるポート1.0.1をエリアリンクに設定する場合を考えます。
FSW244(config)# interface port1.0.1 ↓
FSW244(config-if)# switchport mode access ↓
FSW244(config-if)# switchport access vlan 10 ↓
ここでポート1.0.1をエリアリンクに設定すると、このポートはタグ付きポートになるので、タグなしパケットをvlan10として扱えるよう、switchport trunk native vlanコマンドでネイティブVLANをvlan 10に設定してください。
FSW244(config)# interface port1.0.1 ↓
FSW244(config-if)# switchport atmf-arealink remote-area area1 vlan 1000 ↓
FSW244(config-if)# switchport trunk native vlan 10 ↓
- ローカルマスターのゼロタッチインストレーションは未サポートです。
- atmf select-areaコマンドでログインできるエリアは、CLIログイン用のユーザー名、パスワードが同じ必要があります。
atmf select-area機能では、コントローラーのCLIにログインしたときのユーザー名、パスワードを使って他のエリアを操作するため、コントローラー側と同じ名前のユーザーがローカルマスターに存在しない、コントローラーとローカルマスターでパスワードが異なるなどの不一致があると、atmf select-area機能で該当エリアを操作できません。
制御したいエリアのローカルマスターに存在するユーザーでログインするようにしてください。
ローカルマスターオートリカバリー(概要)
ローカルマスターオートリカバリー機能は、AMFローカルマスターを新品の機器と交換するときに、バックアップデータからフラッシュメモリーの内容を復元し、交換前の機器と同じ構成で再起動する仕組みです。
ローカルマスター交換時にオートリカバリーが動作するには、次の条件を満たす必要があります。
- コントローラーのUSBメモリー、SD/SDHCカード、または、コントローラーに設定された外部SSHサーバーに該当ローカルマスターのバックアップデータが存在すること
バックアップデータがない場合、オートリカバリーは正しく実行できません。交換前のスイッチがまだ動作している場合は、atmf backup area-masters nowコマンドで手動バックアップを取ってから交換してください。
- 新しいスイッチ（代替機）がご購入時の状態であること
代替機がご購入時の状態（正確には「AMFクリーン状態」）でない場合は、オートリカバリーの前提である「AMF自動検出メカニズム」（応用編を参照）が動作せず、結果的にオートリカバリーも実行されません。
このような場合は、応用編の「AMFクリーン化手順」を参照し、代替機をAMFクリーン状態に戻してから交換手順を実施してください。
- エリアリンクを使って交換対象のローカルマスターと繋がるAMFメンバーが1つ以上存在し、そのメンバーが5.4.5以降のファームウェアで動作していること
- 新しいスイッチにバージョン5.4.5以降のファームウェアが搭載されていること
代替機に搭載されているファームウェアのバージョンが5.4.5以降でない場合は、あらかじめ代替機を5.4.5以降にバージョンアップしておく必要があります。
- 新旧のスイッチが同一型番であること
代替機が異なるシリーズの製品である場合（CFC400からCFC960に交換する場合など）、オートリカバリーは実行されません。
また、代替機が同一シリーズでポート構成のみ異なる場合（XS16からXS6に交換する場合など）、オートリカバリーは開始されますが、ポート設定が復元されないなどの現象が発生するため、交換時には原則として同一型番の代替機を用意してください。
ただし、交換前の機器と代替機の間における下記の差分は、オートリカバリーの実行に影響を与えません。
- 同一シリーズ同一ポート構成の機器でPoE機能の有無のみ異なる場合
例）AT-x930-28GTXからAT-x930-28GPXへの変更など
PoE対応機種からPoE非対応機種に交換した場合は、オートリカバリー後にPoE機能を使用できなくなります。また、逆にPoE非対応機種からPoE対応機種に交換した場合、オートリカバリー後は初期設定によりPoE機能が有効になります。PoE機能が不要な場合はPoE無効化の設定を追加してください。
- SFP/SFP+モジュールの違い
例）AT-MG8TからAT-SPSXへの変更など
- 交換時は以前と同じノードの同じポートに代替機を接続すること
AMFネットワーク内での物理的な位置が異なる場合、オートリカバリーが動作しない、あるいは、別のノードとして復元される可能性があります。代替機にケーブルを接続するときは交換前と同じポートに接続してください（代替機側だけでなく接続先機器のポートも同じにしてください）。
注意事項
- オートリカバリーは、新規ローカルマスター（AMFクリーン状態のスイッチ）が「AMF自動検出メカニズム」（応用編を参照）の過程で自律的に実行します。コントローラーは、新規スイッチの求めに応じてバックアップファイルを提供するだけです。そのため、コントローラー側でオートリカバリーの進捗状況を確認することはできません（復元後のAMFネットワークへの復帰は確認できます）。進捗確認は、新規スイッチに接続したコンソールターミナルから行ってください。
以下、新規スイッチのコンソールターミナルに出力されるメッセージ例を示します。
- バックアップデータが存在しないなどの理由によりオートリカバリーが不可能と判断された場合は、次のようなログメッセージが出力されます。
この場合は、セーフコンフィグが適用された状態のまま、AMFネットワークに参加します。
12:10:16 awplus ATMF[837]: No identity found for this device so automatic node recovery is not possible
- オートリカバリーが可能と判断された場合は、次のログメッセージが出力され、オートリカバリーの処理が開始されます。
16:52:16 SBx908a ATMF[839]: Automatic node recovery started
- オートリカバリー成功時には次のログメッセージが出力されます。
この後、自動的に再起動が行われ、復元した設定内容でAMFネットワークに復帰します。
17:49:30 SBx908a ATMFFSR[6547]: File recovery from master node succeeded. Node will now reboot
- オートリカバリー失敗時には次のログメッセージが出力されます。
この場合は、セーフコンフィグが適用された状態のまま、AMFネットワークに参加します。
16:33:02 SBx908a ATMF[831]: Automatic node recovery failed - user intervention required
- オートリカバリー中のスイッチの電源を切らないでください。オートリカバリー中にはいったんすべてのファームウェアを削除するため、途中で電源を切るとスイッチが起動しなくなる恐れがあります。
- コントローラーのオートリカバリーはできません。ただし、コントローラーとAMFマスター機能は共存して起動することができる為、AMFマスターとしても動作させることで、AMFマスターのリカバリーと同じ手順でリカバリーすることができます。詳細はAMFマスターのリカバリーに関する説明をご参照ください。
- オートリカバリーは1台ずつ実行してください。複数台同時に実行した場合、ネットワーク構成により一部のノードでオートリカバリーに失敗する可能性があります。
- VCS構成のAMFマスターを交換する場合は、状況によって作業手順が異なります。
詳細はこちらをご覧ください。
- オートリカバリーではアニュアルライセンスの自動適用はできません。
（アニュアルライセンス以外のライセンスや、設定、ファームウェアの復元は可能です）。
ローカルマスター対応機種は標準でAMFマスター（2メンバー）に対応しているため、オートリカバリーでアニュアルライセンスが適用されなくても、リカバリー後にローカルマスターとしてコントローラーとの接続が可能ですが、2メンバーしか管理できないためAMFネットワークが不安定な状態になります。
アニュアルライセンスを適用しているローカルマスターをオートリカバリーした場合は、次の手順にしたがい、リカバリー後に手動でアニュアルライセンスを適用しなおしてください。
- コントローラーから atmf select-areaコマンドを実行し、ローカルマスター（代替機）にアクセスします。
- ローカルマスター（代替機）にアニュアルライセンスファイルを転送します。
- ローカルマスター（代替機）でlicense update fileコマンドを実行し、アニュアルライセンスを有効にします。
なお、オートリカバリーに先立ち、コントローラーのバックアップメディアに該当ローカルマスター（代替機）用のアニュアルライセンスファイルを格納しておけば、オートリカバリー時にライセンスファイルが代替機のフラッシュメモリーに転送されるため、手順2が不要になります。
また、以下の構成においては、アニュアルライセンスを適用しているローカルマスターのリカバリーはサポートされません。
これらの構成では、あらかじめ手動でローカルマスターの代替機にファームウェア、コンフィグ、ライセンスを復元した上で、AMFネットワークに接続してください。
- ローカルマスターを二重化している場合
- ローカルマスター以外のノードにエリアリンクが設定されている場合
（ローカルマスターにエリアリンクが設定されている場合は問題ありません）
ローカルマスターの交換（オートリカバリー）
ここでは、稼働中の下記AMFネットワークを例に、ローカルマスターSBx908aを新品の代替機と交換し、オートリカバリーによって自動復元する手順を示します。
| 機種 |
ノード名 |
AMFにおける役割 |
概要 |
| SwitchBlade x8100 |
SBx81 |
コントローラー |
コアスイッチ |
| SwitchBlade x908 |
SBx908a |
ローカルマスター |
コアスイッチ（エリア2）[交換対象] |
| SwitchBlade x908 |
SBx908b |
ローカルマスター |
コアスイッチ（エリア3） |
| AT-x230-10GP |
x230 |
メンバー |
エッジスイッチ |
| AT-x510-28GTX |
x510 |
メンバー |
エッジスイッチ |
なお、コントローラーSBx81にはUSBメモリーが装着されており、自動バックアップ機能によって作成されたローカルマスターSBx908aのバックアップデータが存在しているものとします。
- ローカルマスターSBx908aと同一型番の新しいスイッチ（代替機）を用意します。代替機はご購入時の状態であればよく、事前設定は一切不要です。
代替機がご購入時の状態でない場合は、応用編の「AMFクリーン化手順」を参照し、代替機をAMFクリーン状態に戻してください。
また、ファームウェアバージョンが5.4.5以降でない場合は、最初に代替機を5.4.5以降にバージョンアップしてください。
- ローカルマスターSBx908aの電源を切り、LANケーブルを抜きます。
- ローカルマスターSBx908aと代替機を交換します。
- 代替機にLANケーブルを元通り（交換前と同じポートに）接続し、電源を入れます。
オートリカバリーの進捗を確認するため、代替機にはコンソールを接続しておくとよいでしょう。
ご購入時状態のAMF対応スイッチでは、起動時にAMFネットワークを検出して自動的に参加する処理が働きます。
この過程でオートリカバリーが可能かどうかの判断を行い、可能と判断した場合はマスターのUSBメモリーに格納されたバックアップデータからフラッシュメモリーの内容を復元して再起動を行い、交換前の機器と同一の状態でAMFネットワークに参加します。
なおこの間、「AMFセーフコンフィグ」が適用されてAMF接続ポート（エリアリンク）以外のポートはすべてシャットダウンされるため、通常のネットワークポートでループなどが発生する恐れはありません。
ローカルマスターのオートリカバリーの際には、エリアリンクでローカルマスターと繋がっていたAMFメンバーを必ず接続してください。 (上記図ではx230)
- 起動中、代替機のローカルコンソールには次のようなログメッセージが表示されます。
また、代替機の機種や拡張モジュールによっては、ポートLEDの表示によってもリカバリー実行中であることが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
17:45:36 awplus ATMF[2223]: ATMF network detected
17:45:36 awplus ATMF[2223]: ATMF safe mode config applied (forwarding disabled)
17:45:46 awplus ATMF[2223]: Shutting down all non ATMF ports
17:45:46 SBx908a ATMF[2223]: host_0009_41fd_c9ab has left. 0 member in total.
17:45:47 SBx908a ATMF[2223]: SBx908a has joined. 1 member in total.
17:45:47 SBx908a ATMF[2223]: Automatic node recovery started
17:45:47 SBx908a ATMF[2223]: ATMF recovery file detected (forwarding enabled)
17:45:53 SBx908a ATMF[2223]: x230 has joined. 2 members in total.
17:45:56 SBx908a ATMF[2223]: x230 has left. 1 member in total.
17:46:02 SBx908a ATMF[2223]: x230 has joined. 2 members in total.
17:47:24 SBx908a ATMF[2223]: Enabling all ports
17:48:54 SBx908a ATMF[2223]: Recovery file processing successful, attempting to recover as SBx908a
17:48:54 SBx908a ATMF[2223]: Checking controller and master node availability
17:48:56 SBx908a ATMFFSR[6547]: Retrieving recovery data from recovery node SBx81
17:49:30 SBx908a ATMFFSR[6547]: File recovery from master node succeeded. Node will now reboot
- オートリカバリーが成功すると、代替機はいったん再起動し、AMFローカルマスターSBx908aとしてAMFネットワークを統括しコントローラーに接続してきます。
SBx81# show atmf area-nodes ↓
ATMF Area Information:
* = Local area
Area Area Local Remote Remote Node
Name ID Gateway Gateway Master Count
--------------------------------------------------------------------------------
* area1 1 Reachable N/A N/A 1
area2 2 Reachable Reachable Auth OK 2
area3 3 Reachable Reachable Auth OK 2
Area count: 3 Area node count: 5
SBx81# show atmf area-nodes ↓
area2 Area Node Information:
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
SBx908a SwitchBlade x908 Y S none 0
x230 x230-10GP N N SBx908a 1
area2 node count 2
area3 Area Node Information:
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
SBx908b SwitchBlade x908 Y S none 0
x510 x510-28GTX N S SBx908b 1
area3 node count 2
新しいスイッチがSBx908aとして復元され、そのエリアのAMFネットワークの情報が確認できます。
■ オートリカバリーが失敗したときは、次のようなメッセージが出力されます。
また、代替機の機種や拡張モジュールによっては、ポートLEDの表示によってもリカバリーに失敗したことが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
この場合は、後述の「オートリカバリー失敗時の手動リカバリー」を参照して、手動でリカバリーを実施してください。
16:27:52 awplus ATMF[831]: ATMF network detected
16:27:52 awplus ATMF[831]: ATMF safe config applied (forwarding disabled)
16:28:02 awplus ATMF[831]: Shutting down all non ATMF ports
16:28:02 SBx908a ATMF[831]: Automatic node recovery started
16:28:02 SBx908a ATMF[831]: Attempting to recover as SBx908a
16:28:02 SBx908a ATMF[831]: Checking master node availability
16:33:02 SBx908a ATMF[831]: Failed to find any master nodes
16:33:02 SBx908a ATMF[831]: Automatic node recovery failed - user intervention required
■ 上の例では、エリアリンクで接続されているローカルマスターSBx908aを交換しましたが、エリア仮想リンクで接続されているローカルマスターを交換する場合も手順は同じです。
例として、エリア仮想リンクで接続されているローカルマスターSBx908bを交換するケースを考えます。
SBx908bの交換作業にともない、コントローラーとの接続性が失われるため、一時的にAMFネットワークから離脱しますが、オートリカバリーが成功すると、SBx908bはAMFネットワークに自動復帰します。
■ VCS構成のAMFメンバーを交換する場合は、状況によって作業手順が異なります。
- VCSグループは稼働したまま、一部のVCSメンバーを交換する場合
このケースでは、機器交換時にもAMFメンバーとしての動作や設定が保持されるため、AMFのリカバリー処理は行いません。
通常のVCSメンバー交換手順にしたがって機器を交換することで、VCSマスターから設定情報などが同期され、VCSグループが完全復旧します。
- VCSグループ全体を停止して、すべてのVCSメンバーを交換する場合
この場合は、最初にVCSマスターとなる機器だけをオートリカバリーによって復旧します（メンバー交換手順を参照）。
その後、VCSスレーブとなる機器を通常のVCSメンバー追加手順にしたがって接続することで、VCSマスターから設定情報などが同期され、VCSグループが完全復旧します。
ローカルマスターの交換（手動リカバリー）
何らかの原因によりオートリカバリーを利用できない場合は、手動によるリカバリー処理を行うことも可能です。
ここでは、稼働中の下記AMFネットワークを例に、ローカルマスターSBx908aを新品の代替機と交換し、手動リカバリーによって復元する手順を示します。
| 機種 |
ノード名 |
AMFにおける役割 |
概要 |
| SwitchBlade x8100 |
SBx81 |
コントローラー |
コアスイッチ |
| SwitchBlade x908 |
SBx908a |
ローカルマスター |
コアスイッチ（エリア2）[交換対象] |
| SwitchBlade x908 |
SBx908b |
ローカルマスター |
コアスイッチ（エリア3） |
| AT-x230-10GP |
x230 |
メンバー |
エッジスイッチ |
| AT-x510-28GTX |
x510 |
メンバー |
エッジスイッチ |
- ローカルマスターSBx908aと同一型番の新しいスイッチ（代替機）を用意して、起動します。
代替機に搭載されているファームウェアバージョン5.4.5以降でない場合は、最初にバージョンアップしてください。また、AMFマスターライセンスの有効化も必要です。
- 代替機にAMFバックアップファイルの入ったUSBメモリーを装着します。
- 代替機にログインし、USBメモリーにバックアップされているマスターのコンフィグファイルを、代替機の本体内蔵フラッシュメモリーにコピーします。
awplus login: manager ↓
Password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.5 xx/xx/xx xx:xx:xx
awplus> enable ↓
awplus# copy card:/atmf/AMF001/areas/area1/nodes/SBx908a/flash/default.cfg flash ↓
Copying...
Successful operation
- AMFを有効にしてatmf recoverコマンドを利用可能にするため、コピーしたコンフィグで再起動します。
awplus# reboot ↓
Are you sure you want to reboot the whole chassis? (y/n): y
- 再起動後にログインしたら、atmf recoverコマンドを実行して、USBメモリー内のバックアップファイルから代替機の内蔵フラッシュメモリーの内容を手動でリカバリーします。
代替機の機種や拡張モジュールによっては、ポートLEDの表示によってリカバリー実行中であることが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
SBx908a login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.5 xx/xx/xx xx:xx:xx
SBx908a> enable ↓
SBx908a# atmf recover SBx908a controller SBx81 ↓
This command will erase ALL flash contents. Continue node recovery? (y/n) y
Manual node recovery successfully initiated
17:39:12 SBx908a ATMFFSR[5594]: Retrieving recovery data from master node SBx81
17:39:32 SBx908a ATMFFSR[5594]: Manual node recovery completed
17:39:32 SBx908a ATMFFSR[5594]: Node needs to be restarted for the configu
ration to take effect. Make sure the configuration is appropriate for the node
before restart.
- リカバリー処理が完了したら、もう一度再起動します。
SBx908a# reboot ↓
Are you sure you want to reboot the whole chassis? (y/n): y
- 再起動が完了したらAMFネットワークが再構成され、コントローラー、及び自身のエリア内のAMFメンバーとの接続性が回復します。
AMFマルチテナント機能
AMFマルチテナント機能とは、1台のAMFコントローラーと複数のローカルマスター（AMFコンテナ）を、ひとつのAMF Cloud上で管理する機能です。
ひとつのAMF Cloud上では、AMFコントローラー1台につき、最大300台のローカルマスター（AMFコンテナ）を管理することができます。
本機能には、AMFコントローラーライセンスと、AMFマスターライセンスが必要です。
AMFコンテナごとに、管理台数分のAMFマスターライセンスが必要になります。
AMF Cloudは、AMFコントローラーに対応しており、AMF Cloud上の仮想マシンをAMFコントローラーとして設定することが可能です。
AMFマルチテナント機能では、AMF Cloud上の仮想マシンをAMFコントローラーとして設定し、さらにその配下にAMFコンテナと呼ばれるローカルマスターを作成することで、AMFコントローラーからAMFコンテナ（ローカルマスター）までをAMF Cloud上で設定することができます。
AMFマルチテナントコントローラーが管理できる総メンバー数は18000台です。
AMFマルチテナント機能を使った基本構成は以下のようになります。
※パブリッククラウドサービス（アマゾン ウェブ サービス（AWS）、Microsoft Azure）上ではネットワーク構成が異なります。詳しくは「AMF CloudのVPN機能を利用したAWS/Azureでの設定」、「AzureのVPN機能を利用した設定」をご覧ください。
AMFコンテナと呼ばれる仮想インスタンスを作成し、AMFエリアのローカルマスターとして動作させることで、同エリア内のAMF Cloudの外部のネットワークに繋がる機器をメンバーとして管理できます。
外部のネットワークには、AMF Cloudのeth0インターフェース経由で接続します。
仕様
AMFマルチテナント機能の基本的な仕様は以下の通りです。
- 動作環境
AMFマルチテナント機能を使用する場合は、「インストールガイド」/「はじめに」の「動作環境」 で「マルチテナントモード」の要件をご確認ください。
- RADIUS認証、TACACS+認証によるログイン
RADIUS認証、TACACS+認証による、AMFマルチテナントコントローラーやAMFコンテナへのログインをサポートします。
詳しくは、「運用・管理」/「ユーザー認証」をご覧ください。
- AMFマルチテナントコントローラーでは、AMFコンテナの作成・設定が可能
AMFマルチテナントコントローラーにつき最大300台までのAMFコンテナの作成・管理が可能です。
AMFコンテナはatmf containerコマンドで作成します。状態の確認はshow atmf containerコマンドで確認できます。
atmf containerコマンドで作成したAMFコンテナのコンテナ名の変更を行うと、AMFコンテナのシリアルナンバーが変更になり、ライセンスを再発行する必要があります。AMFコンテナを作成した後は、atmf select-areaコマンドで各エリアにログインするなどして、エリア名を使用した管理を行うようにしてください。管理するエリアの名称を変更したい場合は、atmf area idコマンドでエリア名を変更するようにしてください。
- AMFマルチテナントコントローラーとAMFコンテナのディスク容量
AMFコンテナとAMFマルチテナントコントローラーは、ディスク（flash）容量を共有します。
1台のAMFコンテナのディスク容量の空きが少ない状態でファイルを保存してしまうと、他のAMFコンテナにファイルが保存できなくなります。調整して使用してください。
- エリアリンク接続によるAMFコンテナの管理
AMFマルチテナントコントローラーとAMFコンテナはエリアリンクで接続します。
エリアリンクでの接続により、AMFコンテナの設定・管理が可能になります。
エリアリンクでの接続はarea-linkコマンドで行います。
- AMFコンテナ内では、AMFマスターと同じ管理機能を提供
マスターが提供する管理機能については、「アライドテレシスマネージメントフレームワーク（AMF）」/「概要」をご覧ください。
- AMFコンテナでは仮想クロスリンク未サポート
マルチテナント構成のAMFコンテナでは仮想クロスリンク（atmf virtual-crosslinkコマンド）は未サポートです。
- AMFコンテナによるブリッジ機能をサポート
AMFコンテナとAMF Cloud外部のネットワークへの接続には、ブリッジを使用します。
Microsoft AzureのVPN機能を使用する構成では、AMFコンテナとAMF Cloudの外部接続用インターフェース間でのブリッジングやVLANタグの使用は未サポートです。同構成でもコンテナの外部接続にブリッジインターフェース（brX）を使用しますが、brX を L3インターフェースとして使用するルーティング構成になります。詳しくは「AzureのVPN機能を利用する設定」をご覧ください。
ブリッジの作成はbridgeコマンドで行います。
AMFコンテナの外部接続用インターフェース（eth1）をブリッジに接続するにはbridge-groupコマンド（AMFコンテナコンフィグモード）を使用します。
AMF Cloudの外部接続用インターフェースをブリッジに接続するにはbridge-groupコマンド（インターフェースモード）を使用します。
AMFマルチテナント機能におけるブリッジの仕様は以下の通りです。
- AMFコンテナが接続可能なブリッジは1つのみ
- 複数のAMFコンテナによる同一ブリッジへの接続が可能
- 複数のAMFコンテナを同一ブリッジへ接続した場合、各AMFコンテナ間でL2通信が可能
- 各AMFコンテナを異なるブリッジに接続した場合、各AMFコンテナは独立したL2ネットワーク（VLAN）上で動作する
- ブリッジはタグ付きトラフィックをサポート（仮想化環境 VMware vSphere、Citrix XenServer のみ）
- AMFコンテナでのエリアの自動設定
AMFマルチテナントコントローラーから、AMFコンテナの作成・設定をし、area-linkコマンドによりエリアリンクを設定すると、AMFコンテナ内部で以下の自動設定処理が行われます。
- AMFネットワーク名（AMFマルチテナントコントローラーと同じもの）を設定
- atmf containerコマンドで作成したAMFコンテナのコンテナ名をhostnameコマンドのホスト名として設定
- AMFマスター機能（ローカルマスターとして動作）を有効に設定
- AMFマルチテナントコントローラー用エリアを設定
- AMFテナント用エリアとエリアパスワードを設定
- AMFコンテナの内部接続用インターフェース（eth0）からAMFマルチテナントコントローラーへのエリアリンクの接続
本設定はAMFコンテナのランタイムメモリー上にあるため、システムを再起動すると消えてしまいます。
AMFコンテナに起動時コンフィグが無い場合にのみ、自動設定処理が行われます。
自動設定処理が行われた後に、AMFマルチテナントコントローラーからAMFコンテナの設定変更をしても、AMFコンテナには反映されません。AMFコンテナの設定変更をする場合は、自動で設定される全ての設定を手動で変更する必要があります。
自動設定処理が行われた後に、AMFコンテナの設定を変更し、再度自動設定処理を行う場合には、以下の手順を実行してください。
- AMFコンテナにログインし、boot config-fileコマンドをno形式で実行し、AMFコンテナの起動時コンフィグを解除
- AMFマルチテナントコントローラー側で、stateコマンドのdisabledを実行し、AMFコンテナを無効に設定
- area-linkコマンドをno形式で実行し、エリアリンクを削除
- area-linkコマンドで再度エリアリンクを設定
- stateコマンドのenableを実行し、AMFコンテナを有効に設定
上記の手順を実行することにより、再度AMFコンテナの自動設定処理が行われます。
- AMFコンテナインターフェースの仕様
AMFコンテナには2つのネットワークインターフェース（eth0とeth1）があります。
eth0インターフェースは、自動的に、AMFマルチテナントコントローラーへと接続するAMFエリアリンクとして設定されます。
eth0へのユーザー手動による設定はしないでください。
eth1インターフェースには、IPv4とIPv6のどちらのIPアドレスも設定できます。
仮想リンクはIPv4アドレスのみ設定可能です。IPv6アドレスは、各管理機能へのアクセスに使用できます。
eth1インターフェース上には、encapsulation dot1qコマンドにより、最大80個までのサブインターフェースを追加することが可能です（仮想化環境 VMware vSphere、Citrix XenServer のみ）。
- AMFコンテナでの時刻設定
AMFコンテナでは、NTP、clock setコマンドが未サポートであり、AMFマルチテナントコントローラーの持つ時刻と同期します。
また、AMFコンテナとAMFメンバー間の時刻同期は自動的に行われません。
外部のNTPサーバーに時刻を同期する設定を各AMFメンバーに設定するようにしてください。
- AMFコンテナでのサポート機能
AMFコンテナでは以下の機能をサポートします。
基本設定
仮想化環境 VMware vSphere、Citrix XenServer における、AMFマルチテナント機能の基本設定について説明します。
パブリッククラウドサービス Microsoft Azure 上での設定については、「Microsoft Azureでの設定」をご覧ください。
例として、以下の構成の設定を説明します。
本構成例のように、各AMFコンテナをAMFマルチテナントコントローラー上の異なるブリッジに接続すると、各AMFコンテナのL2ネットワーク（VLAN）を分離することができます。
本例では各AMFコンテナに異なるIPアドレスを設定していますが、たとえば構成図中の「VLAN対応のスイッチorルーター」でVRF-Liteを使用するなどして、各コンテナが所属するL2ネットワーク（VLAN）間のIP通信ができないように設定すれば、AMFコンテナ間で重複するIPアドレスを使用できるため、AMFコンテナごとに独自のIPアドレス設計が可能になります。
以降の説明では、AMFマルチテナントコントローラーとして動作させるAMF Cloud上の仮想マシンを「VAA」とします。
また、AMFコンテナとして動作させるAMF Cloud上の仮想マシンをそれぞれ「ConA」「ConB」とします。
AMFマルチテナントコントローラー「VAA」の設定
まず、AMFマルチテナントコントローラー「VAA」の設定手順を説明します。
1. AMFマルチテナントコントローラーにログインし、ホスト名をhostnameコマンド、ネットワーク名をatmf network-nameコマンドで設定します。
ホスト名は各機器固有のものを、AMFネットワーク名はすべてのノードに同じものを設定します。
awplus> enable ↓
awplus# configure terminal ↓
awplus(config)# hostname VAA ↓
VAA(config)# atmf network-name AMF ↓
2. atmf masterコマンドとatmf controllerコマンドにより、AMFマスター兼AMFコントローラー機能を有効にします。
AMFコントローラーと同様、AMFマルチテナントコントローラーとして使用する場合は、AMFマルチテナントコントローラーと同じエリアにAMFマスターが存在する必要があります。この条件を満たすためには、AMFマルチテナントコントローラーと同じエリア内にAMFマスターを設置するか、AMFマルチテナントコントローラー自身をマスターとしても動作させます。
VAA(config)# atmf master ↓
VAA(config)# atmf controller ↓
3. AMFマルチテナントコントローラー用のエリア1「Core」、AMFコンテナ「ConA」用のエリア2「A」、AMFコンテナ「ConB」用のエリア3「B」を作成します。
エリアの作成にはatmf area idコマンドとatmf area passwordコマンドを使用します。
VAA(config)# atmf area Core id 1 local ↓
VAA(config)# atmf area A id 2 ↓
VAA(config)# atmf area A password AAAAaaaa ↓
VAA(config)# atmf area B id 3 ↓
VAA(config)# atmf area B password BBBBbbbb ↓
4. atmf containerコマンドでAMFコンテナ「ConA」と「ConB」を作成し、area-linkコマンドにてそれぞれエリア2「A」、エリア3「B」に配置し、stateコマンドにてコンテナを有効化します。
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# area-link A ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# area-link B ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
5. AMFマルチテナントコントローラーのeth0インターフェース経由でコンテナ「ConA」「ConB」が外部のネットワークに接続できるよう、各AMFコンテナに対応するブリッジ「2」「3」をbridgeコマンドにて作成し、それぞれ「ConA」「ConB」のeth1と、AMFマルチテナントコントローラーの「eth0.2」「eth0.3」を接続します。
AMFマルチテナントコントローラーのeth0インターフェース上に「eth0.2」「eth0.3」を作成するには、encapsulation dot1qコマンドを使用します。
「eth0.2」「eth0.3」と、ブリッジ「2」「3」を接続するには、bridge-groupコマンド（インターフェースモード）を使用します。
「ConA」「ConB」の外部接続用インターフェース（eth1）と、ブリッジ「2」「3」を接続するには、bridge-groupコマンド（AMFコンテナコンフィグモード）を使用します。
これにより、「ConA」のeth1から送信するパケットは、AMFマルチテナントコントローラーのeth0からVLAN ID=2のタグ付きパケットとして出力されるようになります。
「ConB」のeth1から送信するパケットは、AMFマルチテナントコントローラーのeth0からVLAN ID=3のタグ付きパケットとして出力されるようになります。
同様に、AMFマルチテナントコントローラーのeth0で受信したVLAN ID=2のタグ付きパケットは、「ConA」のeth1に（タグなしで）転送され、AMFマルチテナントコントローラーのeth0で受信したVLAN ID=3のタグ付きパケットは、「ConB」のeth1に（タグなしで）転送されます。
VAA(config)# bridge 2 ↓
VAA(config)# interface eth0 ↓
VAA(config-if)# encapsulation dot1q 2 ↓
VAA(config-if)# exit ↓
VAA(config)# interface eth0.2 ↓
VAA(config-if)# bridge-group 2 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# bridge-group 2 ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# bridge 3 ↓
VAA(config)# interface eth0 ↓
VAA(config-if)# encapsulation dot1q 3 ↓
VAA(config-if)# exit ↓
VAA(config)# interface eth0.3 ↓
VAA(config-if)# bridge-group 3 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# bridge-group 3 ↓
VAA(config-atmf-container)# exit ↓
6. AMFマルチテナントコントローラーの設定はこれで完了です。
AMFの設定を有効にするため、設定を保存して再起動します。
VAA(config)# end ↓
VAA# write ↓
VAA# reload ↓
reboot system? (y/n): y
AMFコンテナ（ローカルマスター）「ConA」の設定
AMFコンテナ（ローカルマスター）「ConA」の設定を行います。
AMFマルチテナントコントローラー「VAA」が再起動したら、コンテナ「ConA」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConA」にログインします。
VAA> enable ↓
VAA# atmf container login ConA ↓
2. ここからは「ConA」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConA> enable ↓
ConA# show running-config ↓
ConA# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、AMF Cloud外に接続されているeth1にIPアドレスを設定します。
ConA# configure terminal ↓
ConA(config)# interface eth1 ↓
ConA(config-if)# ip address 10.0.2.1/24 ↓
ConA(config-if)# exit ↓
4. メンバーネットワークへのIP経路を設定します。
ここでは構成図の「VLAN対応のスイッチorルーター」をゲートウェイと仮定し、メンバーが存在するネットワークへのスタティック経路を設定していますが、実際のネットワーク構成や要件にあわせて適切な経路設定を行ってください。
ConA(config)# ip route 192.168.2.0/24 10.0.2.254 ↓
5. atmf virtual-linkにより、ConA（10.0.2.1）・NodeA（192.168.2.1）間に仮想リンクを作成します（NodeA側にも逆向きの設定が必要です）。
ConA(config)# atmf virtual-link id 1 ip 10.0.2.1 remote-id 1 remote-ip 192.168.2.1 ↓
6. AMFコンテナ「ConA」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConA(config)# end ↓
ConA# write ↓
ConA# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFコンテナ（ローカルマスター）「ConB」の設定
AMFコンテナ（ローカルマスター）「ConB」の設定を行います。
コンテナ「ConB」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConB」にログインします。
VAA> enable ↓
VAA# atmf container login ConB ↓
2. ここからは「ConB」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConB> enable ↓
ConB# show running-config ↓
ConB# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、AMF Cloud外に接続されているeth1にIPアドレスを設定します。
ConB# configure terminal ↓
ConB(config)# interface eth1 ↓
ConB(config-if)# ip address 10.0.3.1/24 ↓
ConB(config-if)# exit ↓
4. メンバーネットワークへのIP経路を設定します。
ここでは構成図の「VLAN対応のスイッチorルーター」をゲートウェイと仮定し、メンバーが存在するネットワークへのスタティック経路を設定していますが、実際のネットワーク構成や要件にあわせて適切な経路設定を行ってください。
ConB(config)# ip route 192.168.3.0/24 10.0.3.254 ↓
5. atmf virtual-linkにより、ConB（10.0.3.1）・NodeB（192.168.3.1）間に仮想リンクを作成します（NodeB側にも逆向きの設定が必要です）。
ConB(config)# atmf virtual-link id 1 ip 10.0.3.1 remote-id 1 remote-ip 192.168.3.1 ↓
6. AMFコンテナ「ConB」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConB(config)# end ↓
ConB# write ↓
ConB# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFメンバー「NodeA」「NodeB」の設定
AMFコンテナ（ローカルマスター）「ConA」「ConB」のメンバーとなる「NodeA」「NodeB」には、atmf virtual-linkコマンドによる、仮想リンクの作成が必要です。
高度な設定
仮想化環境 VMware vSphere、Citrix XenServer における、AMFマルチテナント機能の高度な設定について説明します。
パブリッククラウドサービス Microsoft Azure 上での設定については、「Microsoft Azureでの設定」をご覧ください。
基本設定では、各AMFコンテナがAMFマルチテナントコントローラー上の共通インターフェース「eth0」経由で外部ネットワークと接続されていましたが、物理サーバーに複数のネットワークインターフェースカード（NIC）が装着されており、また、AMFマルチテナントコントローラーをインストールした仮想マシンもこれら複数のインターフェースを使用するよう設定されている場合は、各AMFコンテナをAMFマルチテナントコントローラー上の異なるインターフェース（たとえば、「eth0」と「eth1」）に接続することで、各AMFコンテナのネットワークを完全に分離することができます。
この構成であれば、AMFコンテナ間で重複するVLAN IDやIPアドレスを使用できるため、AMFコンテナごとに独自のVLAN、IPアドレス設計が可能です。
基本設定でも、各AMFコンテナは異なるブリッジに接続されているため、たとえば基本設定の構成図中にある「VLAN対応のスイッチorルーター」でVRF-Liteを使用するなどして、各コンテナが所属するL2ネットワーク（VLAN）間のIP通信ができないように設定すれば、AMFコンテナ間で重複するIPアドレスを使用することは可能です。
ここでは、基本設定を元にした以下の構成を例として、基本設定からの変更点のみを示します。
本構成では、各AMFコンテナのネットワークが独立していることを示すため、AMFコンテナ「ConA」と「ConB」、AMFメンバー「NodeA」「NodeB」に同じVLAN、同じIPアドレスを設定していますが、これはAMFコンテナ間でVLAN、IPアドレスの重複設定が可能であることを示すためのもので、必須の設定ではありません。また、各AMFコンテナにVLANを複数設定していますが、これもAMFコンテナ上に複数のVLANを設定する方法を例示することが目的であり、こちらも必須の設定ではありません。
AMFマルチテナントコントローラー「VAA」の設定
AMFマルチテナントコントローラー「VAA」では、基本設定の手順5を次のように変更します。
基本設定では、AMFコンテナ「ConA」「ConB」ともに、AMFマルチテナントコントローラーの「eth0」経由で外部ネットワークに接続されていましたが、本構成では、AMFコンテナ「ConA」をAMFマルチテナントコントローラーの「eth0」に、「ConB」を同「eth1」に接続します。
また、基本設定では、AMFコンテナ「ConA」「ConB」側ではVLANの設定を行わず、AMFマルチテナントコントローラーの「eth0」上に作成した802.1Qサブインターフェース「eth0.2」「eth0.3」で各コンテナに対応するVLANタグを付与していましたが、本構成ではAMFコンテナの「eth1」上に作成した802.1Qサブインターフェース「eth1.2」「eth1.3」でVLANタグを付与するため、AMFマルチテナントコントローラー側ではVLAN設定を行っていません。
AMFマルチテナントコントローラー「VAA」手順5
VAA(config)# bridge 2 ↓
VAA(config)# interface eth0 ↓
VAA(config-if)# bridge-group 2 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# bridge-group 2 ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# bridge 3 ↓
VAA(config)# interface eth1 ↓
VAA(config-if)# bridge-group 3 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# bridge-group 3 ↓
VAA(config-atmf-container)# exit ↓
AMFコンテナ（ローカルマスター）「ConA」「ConB」の設定
AMFコンテナ「ConA」、「ConB」ともに、基本設定（ConA）、基本設定（ConB）の手順3と手順5を次のように変更します。
基本設定では、AMFコンテナ「ConA」「ConB」側ではVLANの設定を行わず、AMFマルチテナントコントローラーの「eth0」上に作成した802.1Qサブインターフェース「eth0.2」「eth0.3」で各コンテナに対応するVLANタグを付与していましたが、本構成ではAMFコンテナ側に複数のVLANを設定するため、AMFコンテナの「eth1」上に802.1Qサブインターフェース「eth1.2」「eth1.3」を作成し、それぞれにIPアドレスを設定します。
また、本構成ではメンバー「NodeA」「NodeB」のIPアドレスがAMFコンテナ「ConA」「ConB」と同一サブネットに変更されているため、仮想リンクのリモートIPアドレスを変更します。
本構成では、各AMFコンテナのネットワークが独立していることを示すため、AMFコンテナ「ConA」と「ConB」、AMFメンバー「NodeA」「NodeB」に同じVLAN、同じIPアドレスを設定していますが、これはAMFコンテナ間でVLAN、IPアドレスの重複設定が可能であることを示すためのもので、必須の設定ではありません。また、各AMFコンテナにVLANを複数設定していますが、これもAMFコンテナ上に複数のVLANを設定する方法を例示することが目的であり、こちらも必須の設定ではありません。
AMFコンテナ「ConA」手順3
ConA# configure terminal ↓
ConA(config)# interface eth1 ↓
ConA(config-if)# encapsulation dot1q 2 ↓
ConA(config-if)# encapsulation dot1q 3 ↓
ConA(config-if)# exit ↓
ConA(config)# interface eth1.2 ↓
ConA(config-if)# ip address 10.0.2.1/24 ↓
ConA(config-if)# exit ↓
ConA(config)# interface eth1.3 ↓
ConA(config-if)# ip address 10.0.3.1/24 ↓
ConA(config-if)# exit ↓
AMFコンテナ「ConA」手順5
ConA(config)# atmf virtual-link id 1 ip 10.0.2.1 remote-id 1 remote-ip 10.0.2.2 ↓
AMFコンテナ「ConB」手順3
ConB# configure terminal ↓
ConB(config)# interface eth1 ↓
ConB(config-if)# encapsulation dot1q 2 ↓
ConB(config-if)# encapsulation dot1q 3 ↓
ConB(config-if)# exit ↓
ConB(config)# interface eth1.2 ↓
ConB(config-if)# ip address 10.0.2.1/24 ↓
ConB(config-if)# exit ↓
ConB(config)# interface eth1.3 ↓
ConB(config-if)# ip address 10.0.3.1/24 ↓
ConB(config-if)# exit ↓
AMFコンテナ「ConB」手順5
ConB(config)# atmf virtual-link id 1 ip 10.0.2.1 remote-id 1 remote-ip 10.0.2.2 ↓
AMFメンバー「NodeA」「NodeB」の設定
本構成において、AMFコンテナ（ローカルマスター）「ConA」「ConB」のメンバーとなる「NodeA」「NodeB」の設定変更は、VLAN設定とIPアドレスのみです。
ここではVLAN、IPアドレスの設定については割愛し、基本設定で説明した仮想リンクの設定コマンドのみ示します。
本構成ではメンバー「NodeA」「NodeB」のIPアドレスがAMFコンテナ「ConA」「ConB」と同一サブネットに変更されているため、仮想リンクのローカルIPアドレスを変更します。
なお、本構成では各メンバーに複数のVLAN「vlan2」「vlan3」が設定されており、それぞれIPアドレス「10.0.2.2」「10.0.3.2」が設定されていますが、ここでは仮想リンクには「10.0.2.2」を使うものとします。
本構成では、各AMFコンテナのネットワークが独立していることを示すため、AMFコンテナ「ConA」と「ConB」、AMFメンバー「NodeA」「NodeB」に同じVLAN、同じIPアドレスを設定していますが、これはAMFコンテナ間でVLAN、IPアドレスの重複設定が可能であることを示すためのもので、必須の設定ではありません。また、各AMFコンテナにVLANを複数設定していますが、これもAMFコンテナ上に複数のVLANを設定する方法を例示することが目的であり、こちらも必須の設定ではありません。
AMF CloudのVPN機能を利用したAWS/Azureでの設定
パブリッククラウドサービスのアマゾン ウェブ サービス（AWS）や Microsoft Azure 上で本製品を使用している場合は、本製品のVPN機能（L2TPv3 + IPsec）を利用して、AMFマルチテナント構成を組むことが可能です。
ここでは、AMF Cloudのインストールガイドで使用した下記の構成をもとに説明します。
■ AWS
■ Azure
以降の説明は、AMF Cloudインストールガイドの記述にしたがって、マルチテナント用のネットワーク基本設定が完了していることを前提としています。
この構成では、各コンテナ・テナントネットワーク間の通信経路が完全に分離されているため、各テナントにおいて独自のIPアドレス設計が可能です（テナント間でIPアドレスが重複してもかまいません）。
以下、AMFマルチテナントコントローラーとして動作させるAMF Cloud上の仮想マシンを「VAA」とします。
また、AMFコンテナとして動作させるAMF Cloud上の仮想マシンをそれぞれ「ConA」「ConB」とします。
これ以降の説明は、AWS、Azureのどちらでも同じです。
本構成では、各AMFコンテナのネットワークが独立していることを示すため、AMFコンテナ「ConA」と「ConB」およびテナントA、Bのネットワークで同じIPアドレスを設定していますが、これはAMFコンテナ間でVLAN、IPアドレスの重複設定が可能であることを示すためのもので、必須の設定ではありません。
AMFマルチテナントコントローラー「VAA」の設定
まず、AMFマルチテナントコントローラー「VAA」の設定手順を説明します。
1. AMFマルチテナントコントローラーにログインし、ホスト名をhostnameコマンド、ネットワーク名をatmf network-nameコマンドで設定します。
ホスト名は各機器固有のものを、AMFネットワーク名はすべてのノードに同じものを設定します。
awplus> enable ↓
awplus# configure terminal ↓
awplus(config)# hostname VAA ↓
VAA(config)# atmf network-name AMF ↓
2. atmf masterコマンドとatmf controllerコマンドにより、AMFマスター兼AMFコントローラー機能を有効にします。
AMFコントローラーと同様、AMFマルチテナントコントローラーとして使用する場合は、AMFマルチテナントコントローラーと同じエリアにAMFマスターが存在する必要があります。この条件を満たすためには、AMFマルチテナントコントローラーと同じエリア内にAMFマスターを設置するか、AMFマルチテナントコントローラー自身をマスターとしても動作させます。
VAA(config)# atmf master ↓
VAA(config)# atmf controller ↓
3. AMFマルチテナントコントローラー用のエリア1「Core」、AMFコンテナ「ConA」用のエリア2「A」、AMFコンテナ「ConB」用のエリア3「B」を作成します。
エリアの作成にはatmf area idコマンドとatmf area passwordコマンドを使用します。
VAA(config)# atmf area Core id 1 local ↓
VAA(config)# atmf area A id 2 ↓
VAA(config)# atmf area A password AAAAaaaa ↓
VAA(config)# atmf area B id 3 ↓
VAA(config)# atmf area B password BBBBbbbb ↓
4. atmf containerコマンドでAMFコンテナ「ConA」と「ConB」を作成し、area-linkコマンドにてそれぞれエリア2「A」、エリア3「B」に配置し、stateコマンドにてコンテナを有効化します。
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# area-link A ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# area-link B ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
5. AMFマルチテナントコントローラーがテナントA、BネットワークのVPNルーターとの間に構築したL2TPv3 + IPsecトンネルインターフェース「tunnel1」、「tunnel2」経由でコンテナ「ConA」、「ConB」がテナントA、Bのネットワークに接続できるよう、各AMFコンテナに対応するブリッジ「1」「2」をbridgeコマンドにて作成し、それぞれ「ConA」「ConB」のeth1と、AMFマルチテナントコントローラーの「tunnel1」「tunnel2」を接続します。
「tunnel1」「tunnel2」と、ブリッジ「1」「2」を接続するには、bridge-groupコマンド（インターフェースモード）を使用します。
「ConA」「ConB」の外部接続用インターフェース（eth1）と、ブリッジ「1」「2」を接続するには、bridge-groupコマンド（AMFコンテナコンフィグモード）を使用します。
これにより、「ConA」のeth1から送信するパケットは、AMFマルチテナントコントローラーのtunnel1インターフェースでL2TPv3によってカプセル化され、さらにトランスポートモードのIPsecで暗号化されてテナントAネットワークのVPNルーターに転送されるようになります。
同様に、「ConB」のeth1から送信するパケットは、AMFマルチテナントコントローラーのtunnel2インターフェースでL2TPv3によってカプセル化され、さらにトランスポートモードのIPsecで暗号化されてテナントBネットワークのVPNルーターに転送されるようになります。
VAA(config)# bridge 1 ↓
VAA(config)# interface tunnel1 ↓
VAA(config-if)# bridge-group 1 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# bridge-group 1 ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# bridge 2 ↓
VAA(config)# interface tunnel2 ↓
VAA(config-if)# bridge-group 2 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# bridge-group 2 ↓
VAA(config-atmf-container)# exit ↓
6. AMFマルチテナントコントローラーの設定はこれで完了です。
AMFの設定を有効にするため、設定を保存して再起動します。
VAA(config)# end ↓
VAA# write ↓
VAA# reload ↓
reboot system? (y/n): y
AMFコンテナ（ローカルマスター）「ConA」の設定
AMFコンテナ（ローカルマスター）「ConA」の設定を行います。
AMFマルチテナントコントローラー「VAA」が再起動したら、コンテナ「ConA」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConA」にログインします。
VAA> enable ↓
VAA# atmf container login ConA ↓
2. ここからは「ConA」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConA> enable ↓
ConA# show running-config ↓
ConA# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、AMF Cloud外に接続されているeth1にIPアドレスを設定します。
ConA# configure terminal ↓
ConA(config)# interface eth1 ↓
ConA(config-if)# ip address 172.16.0.1/24 ↓
ConA(config-if)# exit ↓
4. メンバーネットワークへのIP経路を設定します。
ここでは構成図の「テナントAネットワークのVPNルーター」がデフォルトゲートウェイになるため、同VPNルーターのtunnel0インターフェースに設定された172.16.0.2をネクストホップアドレスとして指定しています。
ConA(config)# ip route 0.0.0.0/0 172.16.0.2 ↓
5. atmf virtual-linkにより、ConA（172.16.0.1）・NodeA（192.168.1.1）間に仮想リンクを作成します（NodeA側にも逆向きの設定が必要です）。
ConA(config)# atmf virtual-link id 1 ip 172.16.0.1 remote-id 1 remote-ip 192.168.1.1 ↓
6. AMFコンテナ「ConA」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConA(config)# end ↓
ConA# write ↓
ConA# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFコンテナ（ローカルマスター）「ConB」の設定
AMFコンテナ（ローカルマスター）「ConB」の設定を行います。
AMFマルチテナントコントローラー「VAA」が再起動したら、コンテナ「ConB」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConB」にログインします。
VAA> enable ↓
VAA# atmf container login ConB ↓
2. ここからは「ConB」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConB> enable ↓
ConB# show running-config ↓
ConB# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、AMF Cloud外に接続されているeth1にIPアドレスを設定します。
ConB# configure terminal ↓
ConB(config)# interface eth1 ↓
ConB(config-if)# ip address 172.16.0.1/24 ↓
ConB(config-if)# exit ↓
4. メンバーネットワークへのIP経路を設定します。
ここでは構成図の「テナントBネットワークのVPNルーター」がデフォルトゲートウェイになるため、同VPNルーターのtunnel0インターフェースに設定された172.16.0.2をネクストホップアドレスとして指定しています。
ConB(config)# ip route 0.0.0.0/0 172.16.0.2 ↓
5. atmf virtual-linkにより、ConB（172.16.0.1）・NodeB（192.168.1.1）間に仮想リンクを作成します（NodeB側にも逆向きの設定が必要です）。
ConB(config)# atmf virtual-link id 1 ip 172.16.0.1 remote-id 1 remote-ip 192.168.1.1 ↓
6. AMFコンテナ「ConB」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConB(config)# end ↓
ConB# write ↓
ConB# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFメンバー「NodeA」「NodeB」の設定
AMFコンテナ（ローカルマスター）「ConA」「ConB」のメンバーとなる「NodeA」「NodeB」には、atmf virtual-linkコマンドによる、仮想リンクの作成が必要です。
AzureのVPN機能を利用した設定
パブリッククラウドサービスの Microsoft Azure 上で本製品を使用している場合は、Azureが提供するVPN機能（IPsec）を利用して、AMFマルチテナント構成を組むことも可能です。
ここでは、下記の構成をもとに説明します。
本構成では、仮想ネットワークゲートウェイからAMF Cloud（マルチテナントコントローラー）および各コンテナまでの通信経路が共有のIPネットワークになっているため、各テナントで独自のIPアドレス設計を行うことはできません。
仮想ネットワークからAMF Cloud、AMFコンテナ、ユーザーネットワーク、テナントネットワークまでのすべてを考慮して、IPアドレスが重複しないようにネットワークを設計してください。
以降の説明では、AMFマルチテナントコントローラーとして動作させるAMF Cloud上の仮想マシンを「VAA」とします。
また、AMFコンテナとして動作させるAMF Cloud上の仮想マシンをそれぞれ「ConA」「ConB」とします。
AMFマルチテナントコントローラー「VAA」の設定
まず、AMFマルチテナントコントローラー「VAA」の設定手順を説明します。
1. AMFマルチテナントコントローラーにログインし、ホスト名をhostnameコマンド、ネットワーク名をatmf network-nameコマンドで設定します。
ホスト名は各機器固有のものを、AMFネットワーク名はすべてのノードに同じものを設定します。
awplus> enable ↓
awplus# configure terminal ↓
awplus(config)# hostname VAA ↓
VAA(config)# atmf network-name AMF ↓
2. atmf masterコマンドとatmf controllerコマンドにより、AMFマスター兼AMFコントローラー機能を有効にします。
AMFコントローラーと同様、AMFマルチテナントコントローラーとして使用する場合は、AMFマルチテナントコントローラーと同じエリアにAMFマスターが存在する必要があります。この条件を満たすためには、AMFマルチテナントコントローラーと同じエリア内にAMFマスターを設置するか、AMFマルチテナントコントローラー自身をマスターとしても動作させます。
VAA(config)# atmf master ↓
VAA(config)# atmf controller ↓
3. AMFマルチテナントコントローラー用のエリア1「Core」、AMFコンテナ「ConA」用のエリア2「A」、AMFコンテナ「ConB」用のエリア3「B」を作成します。
エリアの作成にはatmf area idコマンドとatmf area passwordコマンドを使用します。
VAA(config)# atmf area Core id 1 local ↓
VAA(config)# atmf area A id 2 ↓
VAA(config)# atmf area A password AAAAaaaa ↓
VAA(config)# atmf area B id 3 ↓
VAA(config)# atmf area B password BBBBbbbb ↓
4. atmf containerコマンドでAMFコンテナ「ConA」と「ConB」を作成し、area-linkコマンドにてそれぞれエリア2「A」、エリア3「B」に配置し、stateコマンドにてコンテナを有効化します。
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# area-link A ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# area-link B ↓
VAA(config-atmf-container)# state enable ↓
VAA(config-atmf-container)# exit ↓
5. AzureではVLANタグを使えないため、コンテナと外部ネットワークの接続は、マルチテナントコントローラーのIP転送（ルーティング）機能によって実現します。
具体的には、マルチテナントコントローラー上でブリッジインターフェース「1」（br1）を作成し、eth0、br1のそれぞれにIPアドレスを設定することで、これら2つのL3インターフェース間でIPパケットのルーティングが行われるようにします（eth0のアドレスはAzureからのDHCPで自動設定されます）。
次に、「ConA」、「ConB」をブリッジ「1」に接続し、各コンテナのeth1にもブリッジ「1」と同一サブネットのIPアドレスを設定します。さらに、各コンテナのデフォルトゲートウェイとして、ブリッジ「1」に設定したマルチテナントコントローラーのIPアドレスを指定します。
これにより、「ConA」、「ConB」のeth1から送信するIPパケットは、マルチテナントコントローラーのbr1インターフェースからeth0に転送され、外部と通信できるようになります。ブリッジ「1」（br1）をポートVLAN（タグなしVLAN）と考えるとイメージしやすいかもしれません。
VAA(config)# bridge 1 ↓
VAA(config)# interface br1 ↓
VAA(config-if)# ip address 172.20.0.1/16 ↓
VAA(config-if)# exit ↓
VAA(config)# atmf container ConA ↓
VAA(config-atmf-container)# bridge-group 1 ↓
VAA(config-atmf-container)# exit ↓
VAA(config)# atmf container ConB ↓
VAA(config-atmf-container)# bridge-group 1 ↓
VAA(config-atmf-container)# exit ↓
6. AMFマルチテナントコントローラーの設定はこれで完了です。
AMFの設定を有効にするため、設定を保存して再起動します。
VAA(config)# end ↓
VAA# write ↓
VAA# reload ↓
reboot system? (y/n): y
AMFコンテナ（ローカルマスター）「ConA」の設定
AMFコンテナ（ローカルマスター）「ConA」の設定を行います。
AMFマルチテナントコントローラー「VAA」が再起動したら、コンテナ「ConA」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConA」にログインします。
VAA> enable ↓
VAA# atmf container login ConA ↓
2. ここからは「ConA」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConA> enable ↓
ConA# show running-config ↓
ConA# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、外の世界につながっているeth1にIPアドレスを設定します。
設定するアドレス、サブネットマスクは、AMFマルチテナントコントローラーのbr1インターフェースに割り当てたIPアドレスと同一サブネットのものにしてください。
ConA# configure terminal ↓
ConA(config)# interface eth1 ↓
ConA(config-if)# ip address 172.20.1.1/16 ↓
ConA(config-if)# exit ↓
4. デフォルトゲートウェイとして、このコンテナが接続されているマルチテナントコントローラーのbr1インターフェースのIPアドレスを指定します。
ConA(config)# ip route 0.0.0.0/0 172.20.0.1 ↓
5. atmf virtual-linkにより、ConA（172.20.1.1）・NodeA（192.168.10.1）間に仮想リンクを作成します（NodeA側にも逆向きの設定が必要です）。
ConA(config)# atmf virtual-link id 1 ip 172.20.1.1 remote-id 1 remote-ip 192.168.10.1 ↓
6. AMFコンテナ「ConA」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConA(config)# end ↓
ConA# write ↓
ConA# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFコンテナ（ローカルマスター）「ConB」の設定
AMFコンテナ（ローカルマスター）「ConB」の設定を行います。
コンテナ「ConB」にログインして設定を確認したのち、追加設定を行います。
1. AMFマルチテナントコントローラー「VAA」にログインし、そこからatmf container loginコマンドでコンテナ「ConB」にログインします。
VAA> enable ↓
VAA# atmf container login ConB ↓
2. ここからは「ConB」のCLIで設定を行います。
AMFマルチテナントコントローラー「VAA」での設定により自動的に追加されたコンフィグを確認し、保存します。
ConB> enable ↓
ConB# show running-config ↓
ConB# write ↓
3. メンバーと仮想リンクを張るためにはIPアドレスが必要なので、外の世界につながっているeth1にIPアドレスを設定します。
設定するアドレス、サブネットマスクは、AMFマルチテナントコントローラーのbr1インターフェースに割り当てたIPアドレスと同一サブネットのものにしてください。
ConB# configure terminal ↓
ConB(config)# interface eth1 ↓
ConB(config-if)# ip address 172.20.1.2/16 ↓
ConB(config-if)# exit ↓
4. デフォルトゲートウェイとして、このコンテナが接続されているマルチテナントコントローラーのbr1インターフェースのIPアドレスを指定します。
ConB(config)# ip route 0.0.0.0/0 172.20.0.1 ↓
5. atmf virtual-linkにより、ConB（172.20.1.2）・NodeB（192.168.20.1）間に仮想リンクを作成します（NodeB側にも逆向きの設定が必要です）。
ConB(config)# atmf virtual-link id 1 ip 172.20.1.2 remote-id 1 remote-ip 192.168.20.1 ↓
6. AMFコンテナ「ConB」の設定はこれで完了です。
AMFコンテナの設定を保存しておきます。
ConB(config)# end ↓
ConB# write ↓
ConB# logout ↓
AMFコンテナのCLIからログアウトしてもAMFマルチテナントコントローラーのプロンプトには戻らないので、AMFマルチテナントコントローラーのプロンプトに戻るにはCtrl/A、Qの順に入力してください。
AMFメンバー「NodeA」「NodeB」の設定
AMFコンテナ（ローカルマスター）「ConA」「ConB」のメンバーとなる「NodeA」「NodeB」には、atmf virtual-linkコマンドによる、仮想リンクの作成が必要です。
AMFゲストノード機能
ファームウェアバージョン5.4.6-0.1より、AMF非対応機器（以下 ゲストノード）がAMFネットワークに参加可能となる、AMFゲストノード機能に対応します。本機能では、AMFメンバーにゲストノードが接続されると、AMFメンバーが取得した当該ノードの機器情報をAMFマスターに通知します。
この仕組みにより、AMFマスターからのゲストノードの状態管理が可能となります。
また、別売製品であるAT-Vista Manager EXのAWCプラグインと連携することで、同プラグインの「ゼロタッチコンフィグ」機能や「オートリカバリー」機能を利用できるようになります。
■ 対象機器
- マスター
AMF Cloud、
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908、
AT-AR4050S
- メンバー
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908、
x610シリーズ、
x550シリーズ、
x530シリーズ、
x530Lシリーズ、
x510シリーズ、
x510Lシリーズ、
AT-IX5-28GPX、
x310シリーズ、
x230シリーズ（52ポート版を含む）、
x230Lシリーズ、
x220シリーズ、
IE210Lシリーズ、
IE200シリーズ、
AT-AR4050S、
AT-AR3050S、
AT-AR2050V、
AT-AR1050V、
SH510シリーズ、
SH310シリーズ、
SH230シリーズ、
XS900MXシリーズ、
GS980MXシリーズ、
GS980Mシリーズ、
GS900MX/GS900MPXシリーズ、
FS980Mシリーズ
AT-AR2010Vはスイッチポートを持たず、仮想リンクでしかAMFネットワークに接続できないため、ゲストノード機能はサポートしていません。
- ゲストノード
- IPカメラ
Axis社製、Panasonic社製
- スイッチ
CentreCOM x600シリーズ、CentreCOM 9900シリーズ、CentreCOM 8700シリーズ
- 無線LAN AP
AT-TQシリーズ（AT-TQ5403、AT-TQm5403、AT-TQ5403e、AT-TQ4600、AT-TQ4400e、AT-TQ4400、AT-TQ3600、AT-TQ3400、AT-TQ3200、AT-TQ2450）
AT-TQシリーズにてAMFゲストノードバックアップ機能を使用する場合は、AMFゲストノード機能に対応したファームウェアバージョンを使用してください。
AT-TQシリーズをゲストノードとして使用する場合、AT-TQシリーズのHTTP／HTTPS設定は、最大セッション数をのぞきデフォルトから変更しないでください。
ただし、ゲストノードバックアップ（自動または手動）の実行もAT-TQシリーズ側ではセッション数としてカウントされるため、最大セッション数がデフォルトの「1」のまま、AT-TQシリーズのWeb設定画面にログオンした状態でゲストノードバックアップを実行すると、バックアップに失敗します。その場合は最大セッション数をデフォルトの「1」から「2」以上に変更してください。
別売製品Allied Telesis Unified Wireless Controller、およびAT-UWC-APLにより管理されているAT-TQシリーズは、対象外となります。
■ サポート機能
- AMFマスターによるゲストノードの状態管理
AMFマスターにより、ゲストノードの状態管理が可能です。
マスターにより管理可能なゲストノードの台数は、接続するメンバーのポート数に依存します。
- ゲストノードからAMFマスターへのコンフィグファイルのバックアップ（AT-TQシリーズのみサポート）
atmf backup guests enableコマンド、atmf backup guests nowコマンドにより、自動または手動でゲストノードからAMFマスターへコンフィグファイルをバックアップできます。
ゲストノードからAMFマスターへのコンフィグファイルのバックアップは、AT-TQシリーズでのみサポートしています。
ゲストノードの自動バックアップは初期設定で有効であり、毎晩3時に実行します。
ゲストノードのバックアップファイルは、設定されているバックアップメディア上のゲストノードディレクトリーに保管されます。
ゲストノードのバックアップは、親ノードおよびポート名によって識別されます。
別売製品AT-Vista ManagerとAT-Vista Manager EXのAWCプラグインで管理している無線LANアクセスポイントでは、ゲストノードとしてのコンフィグバックアップ、手動リカバリーはサポート対象外です。
- ゲストノードの手動リカバリー
atmf recover guestコマンドを使って、ゲストノードの手動リカバリーが可能です。
ゲストノードのリカバリーは、AT-TQシリーズでのみサポートしています。
基本設定
ゲストノード機能の設定は、次の手順で行います。
ここでは、SwitchBlade x8100をマスター（ノード名SBx81）、AT-x510-28GTXをメンバー（ノード名FSW241）として、DHCPにてIPアドレスを取得する1つのゲストノード（無線LANアクセスポイントAT-TQ4600）を接続します。
既存のAMFネットワークに対して、ゲストノードの設定を行う手順を説明します。
マスターとメンバーはすでにAMFノード名（hostnameコマンド）、AMFネットワーク名（atmf network-nameコマンド）、AMF接続ポート（AMFリンク）の設定（switchport atmf-linkコマンド）、IPの設定、ゲストノードにIPアドレスを払い出すDHCPサーバーの設定が行われていることを前提とします。
メンバーがゲストノードの情報を取得する際にはIP通信を使用しますので、ゲストノードを接続するVLANにIPアドレスを設定する必要があります。
1. ゲストノードの設定 （上図の構成例を例としています）
1-1.メンバーFSW241に接続するゲストノードのゲストクラスを作成し、AMFゲストコンフィグモードに移動します。これにはatmf guest-classコマンドを使います。
FSW241(config)# atmf guest-class tq_device ↓
1-2. 接続するゲストノードのデバイス種別を設定します。これにはmodeltypeコマンドを使います。
FSW241(config-atmf-guest)# modeltype tq ↓
1-3. 接続するゲストノードの機器情報を取得する方法を設定します。これにはdiscoveryコマンドを使います。
FSW241(config-atmf-guest)# discovery dynamic ↓
パラメーターでdynamicを選択し、LLDPにて機器情報を取得する場合は、LLDP機能を有効にする必要があります。
1-4. ゲストノードにログインする際に使用するユーザー名とパスワードを設定します。これにはusernameコマンドを使います。
FSW241(config-atmf-guest)# username manager password friend ↓
以降の設定はdiscoveryコマンドにて、dynamicパラメーターを選択した場合の追加設定です。
1-5. システム全体でDHCP Snooping機能を有効にします。
FSW241(config-atmf-guest)# exit ↓
FSW241(config)# service dhcp-snooping ↓
1-6. ポートのリンクダウンに応じてDHCP Snoopingテーブルの情報を自動的に削除する機能を有効にします。
FSW241(config)# ip dhcp snooping delete-by-linkdown ↓
1-7. ゲストノードを接続するVLANインターフェースでDHCP Snooping機能を有効にします。
FSW241(config)# interface vlan1 ↓
FSW241(config-if)# ip dhcp snooping ↓
1-8. マスターSBx81と接続するポートを、DHCP SnoopingのTrustedポートに設定します。
FSW241(config-if)# exit ↓
FSW241(config)# interface port1.0.1 ↓
FSW241(config-if)# ip dhcp snooping trust ↓
他のスイッチを接続するポートも同様に、DHCP SnoopingのTrustedポートに設定します。
2. ゲストノードの接続
2-1. ゲストノードを接続するために、メンバーFSW241のポートにゲストリンクを設定し、作成したゲストクラスtq_deviceを割り当てます。これにはswitchport atmf-guestlinkコマンドを使います。
FSW241(config)# interface port1.0.5 ↓
FSW241(config-if)# switchport atmf-guestlink class tq_device ↓
リンクアグリゲーションのポートには、本コマンドは使用できません。
2-2. ゲストノードのノード名を設定します。これにはdescriptionコマンドを使います。
FSW241(config-if)# description AP221 ↓
ゲストノードのノード名は、ポートに設定された説明文となります。
discoveryコマンドのパラメーターでstaticを選択している時は、AMFメンバーはswitchport atmf-guestlinkコマンドで指定されたIPアドレスに対し接続を試みますが、接続に失敗すると以降は30秒間隔で5回試行します。それでも接続できない場合は以後接続を試みません。この場合は、ゲストノードを接続した機器のリンクダウン・アップを行ってください。
discoveryコマンドのパラメーターでdynamicを選択している時は、DHCP Snoopingテーブル（バインディングデータベース）からゲストノードのエントリーが削除されると、ゲストノードは一端AMFから離脱します。
設定は以上です。
ゲストノードを追加する場合は、同様に設定します。
■ 接続されている対象ノードで、ゲストノード接続ポート（ゲストリンク）情報を確認したい場合は、show atmf links guestコマンドを使います。
FSW241# show atmf links guest ↓
Guest Link Information:
DC = Discovery configuration
S = static D = dynamic
Local Guest Model MAC IP / IPv6
Port Class Type DC Address Address
--------------------------------------------------------------------------------
1.0.5 tq_device TQ D 001a.ebab.d2e0 192.168.1.221
Total number of guest links configured 1
■ マスターからゲストノードの各種情報を確認したい場合は、show atmf guestsコマンドを使います。
SBx81# show atmf guests ↓
Guest Information:
Device Device Parent Guest IP/IPv6
Name Type Node Port Address
--------------------------------------------------------------------------------
AP221 AT-TQ4600 FSW241 1.0.5 192.168.1.221
Current ATMF guest node count 1
■ AMFコントローラーで、エリア内のゲストノードの各種情報を確認したい場合は、show atmf area guestsコマンドを使います
SBx81# show atmf area guests ↓
area1 Area Guest Node Information:
Device Device Parent Guest IP/IPv6
Name Type Node Port Address
------------------------------------------------------------------------------
AP221 AT-TQ4600 FSW241 1.0.5 192.168.1.221
main-building guest node count 1
■ ゲストノードのバックアップの設定や状態を確認するには、マスターでshow atmf backup guestコマンドを使います。
注意事項
- AMF使用時は、ネットワーク構成や併用機能に関する注意事項や制限事項があります。「導入にあたり」を参照し、既存のネットワーク構成や使用中の機能に問題がないかご確認ください。
サポート対象外のネットワーク構成や併用機能がある場合は、構成や機能を適宜変更してからAMFの導入を進めてください。
- ゲストノードにおいて、以下AMF機能は未サポートです。
- オートリカバリー機能
- ワーキングセット機能
- リブートローリング機能
- ゼロタッチインストレーション
- ゲストノードのノード名設定（hostnameコマンド）
ゲストノードのノード名はポートの説明文になります（descriptionコマンド）。
- ゲストノードのDHCPサーバー機能
ゲストノードにてDHCPを使用する場合は、通常のDHCPサーバー機能、または外部のDHCPサーバーを使用してください。
- リモートログイン機能
手動リカバリー（概要）
手動リカバリー機能は、ゲストノードを新品の機器と交換するときに、バックアップデータから設定内容を復元し、交換前の機器と同じ構成にする仕組みです。
ゲストノード交換時にリカバリーが動作するには、次の条件を満たす必要があります。
- マスターのUSBメモリー、SD/SDHCカード、または、マスターに設定された外部SSHサーバーに該当ゲストノードのバックアップデータが存在すること
バックアップデータがない場合、リカバリーは正しく実行できません。交換前のスイッチがまだ動作している場合は、atmf backup guests nowコマンドで手動バックアップを取ってから交換してください。
- 交換時は以前と同じノードの同じポートに代替機を接続すること
AMFネットワーク内での物理的な位置が異なる場合、リカバリーが動作しない、あるいは、別のノードとして復元される可能性があります。代替機に ケーブルを接続するときは交換前と同じポートに接続してください（代替機側だけでなく接続先機器のポートも同じにしてください）。
ゲストノードの交換（手動リカバリー）
ここでは、稼働中の下記AMFネットワークを例に、ゲストノードの無線LAN APを新品の代替機と交換し、手動リカバリーによって復元する手順を示します。
| 機種 |
ノード名 |
AMFにおける役割 |
概要 |
| SwitchBlade x8100 |
SBx81 |
マスター |
コアスイッチ |
| AT-x510-28GTX |
FSW241 |
メンバー |
フロアスイッチ |
| AT-TQ4600 |
AP221 |
ゲストノード |
無線LAN AP [交換対象] |
- ゲストノードAT-TQ4600と同一型番の新しいノード（代替機）を用意して、起動します。
- マスターにAMFバックアップファイルの入ったUSBメモリーを装着します。
- ゲストノードの接続されているメンバーにログインします。
FSW241 login: manager ↓
Password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.6 xx/xx/xx xx:xx:xx
FSW241> enable ↓
- ログインしたら、atmf recover guestコマンドを実行して、USBメモリー内のバックアップファイルから代替機の設定内容を手動でリカバリーします。リカバリーが完了すると代替機は自動的に再起動が行われます。
FSW241# atmf recover guest port1.0.5 ↓
- ゲストノードの再起動が完了したらAMFネットワークが再構成され、AMFメンバーおよびマスターとの接続性が回復します
AWCプラグインのゼロタッチコンフィグとオートリカバリーについて
AMFゲストノード機能を使用している環境では、別売製品AT-Vista Manager EXのAWCプラグインが持つ下記機能を利用できます。
- ゼロタッチコンフィグ - 出荷時状態の無線APをAMFノードに接続するだけでAWCプラグインの管理下に登録する機能
- オートリカバリー - AWCプラグインの管理下にある無線APを同一機種に交換するだけで以前の設定を復元する機能
AWCプラグインのゼロタッチコンフィグおよびオートリカバリー機能を使用するには、以下の条件を満たしている必要があります。
- AMFネットワーク側
- 無線AP（AT-TQシリーズ）の管理用VLANがタグなしVLANとして設定されている
- 無線APがAMFノードにゲストノードとして設定されており、接続するゲストノードの機器情報を自動取得（"discovery dynamic" コマンド）するよう設定されている
AT-ARシリーズではdynamicパラメーターが未サポートのため、配下のゲストノードに対してAWCプラグインのゼロタッチコンフィグおよびオートリカバリーを実行させることはできません。
- AMFノードにおいて、無線APの管理用VLANに対してDHCP Snooping機能が有効に設定されている
ゲストノードを接続するスイッチポートが複数のVLANに所属している場合、無線APの管理用VLANに対してのみDHCP Snoopingを有効にし、他のVLANではDHCP Snooping機能を有効にしないでください。
[1] AT-TQシリーズをAMFゲストノードとして使用し、AT-Vista Manager EXのAWCプラグインによるオートリカバリーを利用する場合は、前述のとおりゲストノードの機器情報取得方法を「dynamic」に設定してください。
[2] AT-TQシリーズをAMFゲストノードとして使用し、ゲストノードの機器情報取得方法を「dynamic」に設定している環境において、DHCPクライアントとして動作する無線端末を該当AT-TQシリーズに接続する場合は、下記の条件を満たすよう設定してください。
- AT-TQシリーズの管理用 VLAN と他のVLAN（VAP VLAN）を別 VID とすること
- DHCP Snooping は AT-TQシリーズの管理用 VLAN に対してのみ有効に設定すること
（他のVLAN（VAP VLAN）では DHCP Snooping を有効にしないこと。デフォルトは無効）
[3] 上記[1]と[2]に該当しない環境において、AT-TQシリーズやCentreCOM x600シリーズ、9900シリーズ、8700シリーズをAMFゲストノードとして使用し、かつゲストノード配下にDHCPクライアントを接続する場合は、ゲストノードの機器情報取得方法を「static」に設定してください。
「dynamic」で機器情報を取得すると、ゲストノードの情報取得が正常に行われなかったり、ゲストノード配下のDHCPクライアントがIPアドレスをリリースするとゲストノードが離脱したと誤検知されるなどの現象がおこることがあります。
- AT-Vista Manager EX側
- 該当のAMFネットワークが管理対象に設定されている
- AT-Vista Manager EXバージョン 2.3.0以降を使用している
- 無線AP側
- 使用するAT-Vista Manager EXがサポートしているファームウェアバージョンがインストールされている
- DHCPクライアント機能が有効（デフォルト）に設定されており、DHCPサーバーからIPアドレスを取得している
AT-Vista Manager EX（AWCプラグイン）、無線APの詳細および設定については、それぞれのマニュアルをご参照ください。
AMFエージェントノード機能
ファームウェアバージョン5.4.6-2.1より、特殊なプログラムが組み込まれたAMF非対応機器（以下 エージェントノード）の情報を取得する、AMFエージェントノード機能に対応します。本機能では、AMFメンバーにエージェントノードが接続されると、AMFメンバーが取得した当該ノードの機器情報をAMFマスターに通知します。
この仕組みにより、AMFマスターからのエージェントノードの状態管理が可能となります。
■ 対象機器
- マスター
AMF Cloud、
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908、
AT-AR4050S
- メンバー
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908、
x610シリーズ、
x550シリーズ、
x530シリーズ、
x530Lシリーズ、
x510シリーズ、
x510Lシリーズ、
AT-IX5-28GPX、
x310シリーズ、
x230シリーズ（52ポート版を含む）、
x230Lシリーズ、
x220シリーズ、
IE210Lシリーズ、
IE200シリーズ、
AT-AR4050S、
AT-AR3050S、
AT-AR2050V、
AT-AR1050V、
SH510シリーズ、
SH310シリーズ、
SH230シリーズ、
XS900MXシリーズ、
GS980MXシリーズ、
GS980Mシリーズ、
GS900MX/GS900MPXシリーズ、
FS980Mシリーズ
AT-AR2010Vはスイッチポートを持たず、仮想リンクでしかAMFネットワークに接続できないため、本機能はサポートしていません。
- エージェントノード
- スイッチ
AT-x600-48Ts-LM、AT-x600-24Ts-PoE（ファームウェアバージョン5.4.2-3.16）
■ サポート機能
- AMFマスターによるエージェントノードの状態管理
AMFマスターにより、エージェントノードの状態管理が可能です。
マスターにより管理可能なエージェントノードの台数は、接続するメンバーのポート数に依存します。
基本設定
エージェントノード機能の設定は、次の手順で行います。
ここでは、SwitchBlade x8100をマスター（ノード名SBx81）、AT-x510-28GTXをメンバー（ノード名FSW241）として、DHCPにてIPアドレスを取得する1つのエージェントノード（スイッチAT-x600-48Ts-LM）を接続します。
既存のAMFネットワークに対して、エージェントノードの設定を行う手順を説明します。
マスターとメンバーはすでにAMFノード名（hostnameコマンド）、AMFネットワーク名（atmf network-nameコマンド）、AMF接続ポート（AMFリンク）の設定（switchport atmf-linkコマンド）、IPの設定、エージェントノードにIPアドレスを払い出すDHCPサーバーの設定が行われていることを前提とします。
1. エージェントノードの接続（上図の構成例を例としています）
1-1. エージェントノードを接続するために、メンバーFSW241のポートにエージェントリンクを設定します。これにはswitchport atmf-agentlinkコマンドを使います。
FSW241(config)# interface port1.0.5 ↓
FSW241(config-if)# switchport atmf-agentlink ↓
1-2. エージェントノードのノード名を設定します。これにはdescriptionコマンドを使います。
FSW241(config-if)# description ESW221 ↓
エージェントノードのノード名は、ポートに設定された説明文となります。
設定は以上です。
エージェントノードを追加する場合は、同様に設定します。
■ 接続されている対象ノードで、エージェントノード接続ポート（エージェントリンク）情報を確認したい場合は、show atmf links guestコマンドを使います。
■ マスターからエージェントノードの各種情報を確認したい場合は、show atmf guestsコマンドを使います。
注意事項
- AMF使用時は、ネットワーク構成や併用機能に関する注意事項や制限事項があります。「導入にあたり」を参照し、既存のネットワーク構成や使用中の機能に問題がないかご確認ください。
サポート対象外のネットワーク構成や併用機能がある場合は、構成や機能を適宜変更してからAMFの導入を進めてください。
- エージェントノードにおいて、以下AMF機能は未サポートです。
- バックアップ機能
- リカバリー機能
- ワーキングセット機能
- リブートローリング機能
- ゼロタッチインストレーション
- エージェントノードのノード名設定（hostnameコマンド）
エージェントノードのノード名はポートの説明文になります（descriptionコマンド）。
- エージェントノードのDHCPサーバー機能
エージェントノードにてDHCPを使用する場合は、通常のDHCPサーバー機能、または外部のDHCPサーバーを使用してください。
- リモートログイン機能
リモートログイン
AMFリモートログイン（atmf remote-loginコマンド）は、指定したAMFノードのコンソールにリモートアクセスする機能です。単一ノードを対象とするワーキングセットプロンプトでもほぼ同じことができるため、補助的な位置付けであり、通常あまり使う必要がありませんが、ワーキングセットプロンプトとは異なり任意のユーザー名、パスワードでログインでき、またconsoleログが出力されるため、ご購入時状態の新規スイッチに初期設定を行うときや、オートリカバリーに失敗したノードを手動でリカバリーするときは、リモートログイン機能を使います。
AMFリモートログインは、TelnetやSSHによるリモートログインと似ていますが、ログイン先をノード名で指定できること、AMFネットワーク経由での通信になること、通常コンソールターミナルにだけ出力されるconsoleログが表示されること、などの相違点があります。文字どおり、指定したノードのコンソールターミナルにリモートからアクセスするイメージです。
ユーザー認証にRADIUSサーバーまたはTACACS+サーバーを使用する場合、次のようにRADIUSサーバーまたはTACACS+サーバーの次に、ユーザー認証データベースで認証を行うように設定してください。
awplus(config)# aaa authentication login default group radius local ↓
■ 他のAMFノードのコンソールにリモートログインするには、マスターのCLIからatmf remote-loginコマンドを実行します。
SBx81# atmf remote-login FSW241 ↓
Type 'exit' to return to SBx81.
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
FSW241>
■ 特定のユーザーでリモートログインしたい場合は、userパラメーターでログイン先のユーザー名を指定してください。ユーザー名を指定した場合は必要に応じてパスワードプロンプトが表示されるので、ログイン先のパスワードを入力できます。
SBx81# atmf remote-login user manager host_001a_eb54_e0c5 ↓
Type 'exit' to return to SBx81.
manager@172.31.0.5's password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus>
AMF自動検出メカニズム
ご購入時状態（正確にはAMFクリーン状態）のAMF対応スイッチでは、起動時にAMFネットワークを検出して自動的に参加する仕組みが働きます。これをAMF自動検出メカニズムと呼びます。
クリーン状態のAMF対応スイッチにおける、AMF自動検出メカニズムの動作は次のとおりです。
- クリーン状態のスイッチが起動時にAMFパケットを受信すると、そのポートでAMFを有効化します（対向ポートがAMFリンクなら該当ポートをAMFリンクに、対向ポートがAMFクロスリンクなら該当ポートをAMFクロスリンクに自動設定します）。また、受信したAMFパケットに含まれるAMFネットワークを所属先として設定します。
さらに、既存AMFネットワークにおいて、マネージメントVLAN、ドメインVLANのVLAN IDやマネージメントサブネットが初期値から変更されている場合は、これらの設定も自動的に行います。
19:29:49 awplus ATMF[829]: ATMF network detected
- ネットワークループなどを防ぐため、セーフコンフィグと呼ばれる特殊なランニングコンフィグを適用します。
19:29:49 awplus ATMF[829]: ATMF safe config applied (forwarding disabled)
19:29:59 awplus ATMF[829]: Shutting down all non ATMF ports
セーフコンフィグの具体的な内容は次のとおりです。
- 無効状態のVLAN（セーフVLAN）が作成されます（VLAN IDはドメインVLANやマネージメントVLANと重複しないよう自動選択されます。標準はvlan4090です）
- AMFリンクを含むすべてのポートがタグ付き（トランクポート）に設定され、セーフVLANにのみ所属した状態となります
- AMFリンク以外のポートはすべてerr-disabledステータス（AMFプロトコルによるシャットダウン状態）となります
- オートリカバリー（運用編を参照）が可能かどうかを判断します。
可能と判断した場合は、オートリカバリーを実行し、復元されたノード名でAMFネットワークに復帰します。
（マスターからバックアップデータを取得し、内蔵フラッシュメモリーの内容を復元してから自動的に再起動します）
16:52:16 ESW231 ATMF[839]: Automatic node recovery started
16:52:16 ESW231 ATMF[839]: Attempting to recover as ESW231
16:52:16 ESW231 ATMF[839]: Checking master node availability
:
:
16:52:27 ESW231 ATMFFSR[3375]: Retrieving recovery data from master node SBx81
16:54:27 ESW231 ATMFFSR[3375]: File recovery from master node succeeded. Node will now reboot
- オートリカバリーが不可能と判断した場合は、セーフコンフィグが適用された状態のままAMFネットワークに参加します。
12:10:16 awplus ATMF[837]: No identity found for this device so automatic node recovery is not possible
この場合は、ホスト名が初期値awplusのままなので、MACアドレスを元にした「host_xxxx_xxxx_xxxx」形式のノード名が暫定的に自動設定されます。
オートリカバリーせずにAMFネットワークに自動参加した場合のランニングコンフィグから要点を抜粋します。
!
! 受信したAMFパケットに含まれるネットワーク名を自動設定
!
atmf network-name VCF001
!
! 転送を行わないセーフVLANを自動作成
!
vlan database
vlan 4090 name atmf_node_recovery_safe_vlan
vlan 4090 state disable
!
! AMFパケットを受信したポートは、対向ポートにあわせて
! AMFリンクかAMFクロスリンクに自動設定される（本例ではAMFリンク）。
! VLAN設定は「セーフVLANのみ所属のタグ付きポート」だが、
! AMFリンクの設定があるためAMFパケットの送受信は行われる
!
interface port1.0.1
switchport
switchport atmf-link
switchport mode trunk
switchport trunk allowed vlan add 4090
switchport trunk native vlan none
!
! その他のポートはすべてerr-disabled（AMFによるシャットダウン状態）になる
! VLAN設定は「セーフVLANのみ所属のタグ付きポート」
!
interface port1.0.2-1.0.50
switchport
switchport mode trunk
switchport trunk allowed vlan add 4090
switchport trunk native vlan none
AMF自動検出メカニズムによってAMFネットワークに参加した新規ノードは、ワーキングセットやリモートログイン、リブートローリングなどの諸機能を利用できますが、自動バックアップの対象にはなりません。いったん設定を保存して再起動すると、それ以降はバックアップされるようになります。
AMFネットワーク未検出時の拡張動作
ファームウェアバージョン5.4.7-1.1以降ではAMF自動検出メカニズムが拡張され、AMFネットワークを検出できなかった場合でもIPv4/IPv6ネットワーク経由でのアクセス（SSHログイン）を可能にする仕組みが追加されました。
さらに、ファームウェアバージョン5.4.7-2.x以降では、適切に設定されたDHCPサーバー/DNSサーバーを利用することにより、AMF仮想リンク経由でAMFネットワークに接続している単独ノードのオートリカバリーを可能にする仕組みが追加されました。
AMFクリーン状態で起動した装置がAMFネットワークを検出できなかった場合、以下で述べる動作を行います。
本機能を利用することで、たとえば次のようなことが可能になります。
- 出荷時設定（AMFクリーン状態）の装置とノートPCをLANケーブルで直結し、SSHでログインして初期設定を行う。
（SSHクライアントソフトウェアを用意すれば、コンソールケーブルが手元になくても初期設定が可能です）
■ 通常、Windowsでは有効なIPv4アドレスを設定できなかった場合に169.254.0.0/16レンジからリンクローカルアドレスが自動設定されるため、Windows PCとAMFクリーン状態の装置を直結した場合、双方とも同一サブネット（169.254.0.0/16）内での通信が可能です（＝ルーターや経路設定が不要）。
■ 直結PCのOSがIPv4リンクローカルアドレスの自動設定をサポートしていない場合でも、169.254.42.42 を除く 169.254.0.0/16 内のアドレスを手動設定すれば、同様の通信が可能です。
■ また、最近のOSは初期設定でIPv6をサポートしているものが多いため、IPv6のリンクローカルアドレスも自動設定されている可能性があります。
その場合、クリーン状態の装置にIPv6のリンクローカルアドレスでSSHログインすることもできるでしょう。
ただし、IPv6のリンクローカルアドレスはIPv4のように固定ではなく、MACアドレスにもとづくEUI-64形式アドレスになるため、何らかの方法でこのアドレスを知る必要があります。
それにはたとえば、PC・AMFクリーン装置間のリンクにおいて、PCから全ノードマルチキャストアドレス（ff02::1）宛てのIPv6 pingを実行し、その応答から装置のIPv6リンクローカルアドレスを知る方法があります。
Ubuntu 16.04における次の例では、(DUP!) と表示されている2つ目の応答が装置からのものです。
$ ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::18e1:3ff:fed0:56a2 eth0: 56 data bytes
64 bytes from fe80::18e1:3ff:fed0:56a2: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from fe80::feed:dad:ace:beef icmp_seq=1 ttl=64 time=1.06 ms (DUP!)
^C
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +1 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.034/0.547/1.060/0.513 ms
この場合、次のようにしてIPv6でのSSHアクセスが可能です。
$ ssh -6 manager@fe80::feed:dad:ace:beef%eth0
AMFクリーン化手順
AMFの運用中にメンバーの機器交換を行った場合、交換後の機器を交換前の機器と同じ状態に戻すオートリカバリー処理が実行されます。
ただし、オートリカバリーが機能するためには、交換後の機器が「AMFクリーン状態」でなくてはなりません。
（より正確には、オートリカバリーの前提条件であるAMF自動検出メカニズムが働くために必要な状態を「AMFクリーン」と呼びます）
AMFクリーン状態とは、以下の条件をすべて満たしている状態をいいます。
ご購入時のAMF対応スイッチはクリーン状態です。
- 起動時コンフィグ（スタートアップコンフィグ）の実体ファイルが初期設定の「flash:/default.cfg」である
- バックアップ用のコンフィグやファームウェアが設定されていない。
- フラッシュメモリーのルートディレクトリーにコンフィグファイル（*.cfg）やスクリプトファイル（*.scp）が存在しない
- フラッシュメモリーの.configsディレクトリーにstk.conf、atmf-links.conf、atmf.confというファイルが存在しない
- フラッシュメモリーのルートディレクトリーにユーザーが作成したディレクトリーが存在しない
- USBメモリーやSD/SDHCカードを装着していない。あるいは、USBメモリーやSDカードを装着していても、オートブート機能が無効化されているか、ルートディレクトリーにautoboot.txtというファイルが存在しない
ファームウェアイメージファイルはいくつ存在していてもかまいません。ただし、オートリカバリー時には、内蔵フラッシュメモリー上のファームウェアイメージファイルがいったんすべて削除され、バックアップデータに含まれるファームウェアイメージファイルだけが復元されますのでご注意ください。
使用済みの機器をAMFクリーン状態に戻すには、次の手順を実行してください。
- 機器を単体構成（非VCS構成）で起動してください。
また、SwitchBlade x8100の場合は、単体構成かつコントロールファブリックカード（CFC）を1枚だけ装着した状態で実行してください。
SwitchBlade x908は、必ずポート拡張モジュール（AT-XEM-1XP、AT-XEM-2XP、AT-XEM-2XS、AT-XEM-2XT、AT-XEM-12S/12Sv2、AT-XEM-12T/12Tv2、AT-XEM-24T）を1つ以上装着した状態で使用してください。拡張モジュールを1つも装着していない状態で起動したり、運用中にすべての拡張モジュールを取り外したりしないでください。
- atmf cleanupコマンドを実行します。
確認のプロンプトが出ますので、「y」を入力して再起動してください。
awplus# atmf cleanup ↓
This command will erase all NVS, all flash contents except for
the boot release, and any license files, and then reboot the switch.
Proceed ? (y/n): y ↓
- これでクリーン化作業は完了です。
フラッシュメモリー、USBメモリー、SD/SDHCカード内に存在するファイル、ディレクトリーの情報は、dirコマンドで確認できます。
起動時コンフィグとバックアップ用コンフィグ、バックアップ用ファームウェアの設定状態は、show bootコマンドで確認できます。
ファームウェアバージョン5.4.7-2.x以降では、GS900MXシリーズにかぎり、VCSを無効化していてもAMFクリーン状態と判定され、オートリカバリーが可能になりました。詳しくは「スタックポートをAMF接続ポートとして使用している場合の手動リカバリー」をご参照ください。
新規ノード追加手順（自動検出＋CLI設定）
稼働中のAMFネットワークに機器を追加する方法には、運用編で説明したように、AMFネットワーク名やノード名などの初期設定をすませてから既存のAMFノードと接続し、以後マスターのCLIから設定を行う方法が基本ですが、ご購入時状態のAMF対応スイッチがAMFネットワークに自動参加する機能を利用して、最初からマスターのCLIで設定を行う方法もあります。
ここでは後者の例を示します。
想定するネットワーク環境は運用編と同じです。すなわち、下記AMFネットワークに、新しいフロアスイッチFSW243をメンバーとして追加する場合を例として説明します。
| 機種 |
ノード名 |
AMFにおける役割 |
所属グループ |
概要 |
| SwitchBlade x8100 |
SBx81 |
マスター |
- |
コアスイッチ |
| AT-x510-28GTX |
FSW241 |
メンバー |
floor, 1F |
フロアスイッチ |
| AT-x510-28GTX |
FSW242 |
メンバー |
floor, 2F |
フロアスイッチ |
| AT-x510-28GTX |
FSW243 |
メンバー |
floor, 3F |
フロアスイッチ（新規追加） |
| AT-x510-52GTX |
ESW231 |
メンバー |
edge, 2F |
エッジスイッチ |
追加するスイッチ（新規ノード）はご購入時の状態であると仮定します。
もしそうでない場合は、「AMFクリーン化手順」を参照し、新規ノードをAMFクリーン状態に戻してから下記の手順を実施してください。
接続先ノードの設定変更
新規ノードを接続する既存のAMFノード（接続先ノード）にAMFリンクを追加設定する方法は、運用編で紹介した基本手順と同じですので、運用編をご覧ください。
新規ノードの接続と初期設定
接続先ノードの設定変更が済んだら、新規ノードを起動して、接続先ノードと接続します。
- 新規ノードを起動します。
- 接続先ノードであるマスターのポート1.1.3と、新規ノードのポート1.0.1を接続します。
すると、マスターのコンソールに、新規ノードがJoin（AMFネットワークに参加）したことを示すメッセージが出力されます。
21:09:23 SBx81 ATMF[1946]: host_eccd_6d82_6b3d has joined. 5 members in total.
新規ノードはノード名が未設定のため、MACアドレスを元にした「host_eccd_6d82_6b3d」という名前で動作していることがわかります。
- マスターのCLIから、show atmf nodesコマンドでノード情報を確認します。
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
host_eccd_6d82_6b3d x510-28GTX N S SBx81 1
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
ESW231 x510-52GTX N S FSW242 2
Current ATMF node count 5
- AMFリモートログイン機能（atmf remote-loginコマンド）を使って新規ノードにログインします。
このとき、userパラメーターで初期設定の管理者ユーザー名であるmanagerを指定してください。こうすることにより、マスター側でmanagerのパスワードを変更していても、新規ノードにログインできます。
SBx81# atmf remote-login user manager host_eccd_6d82_6b3d ↓
Type 'exit' to return to SBx81.
manager@172.31.0.5's password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus>
- hostnameコマンドでノード名を「FSW243」に設定します。
ノード名の変更にともない、新規ノードはいったんAMFネットワークから離脱するため、リモートログインセッションが切断され、マスターのローカルプロンプトに戻ります。
awplus> enable ↓
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# hostname FSW243 ↓
21:18:27 SBx81 ATMF[1946]: host_eccd_6d82_6b3d has left. 4 members in total.
SBx81#
- 新しいノード名で再度ログインします。
SBx81# atmf remote-login user manager FSW243 ↓
Type 'exit' to return to SBx81.
manager@172.31.0.5's password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
FSW243>
- ご購入時状態のスイッチがAMF自動検出メカニズムによってAMFネットワークに参加し、オートリカバリーが行われなかった場合、該当スイッチにはループ防止用の特殊なコンフィグ（セーフコンフィグ）がランニングコンフィグとして適用された状態になりますので、最初にこれを削除します。
FSW243(config)# vlan database ↓
FSW243(config-vlan)# no vlan 4090 ↓
FSW243(config-vlan)# exit ↓
FSW243(config)# interface port1.0.2-1.0.50 ↓
FSW243(config-if)# no shutdown ↓
FSW243(config-if)# switchport mode access ↓
FSW243(config-if)# exit ↓
FSW243(config)#
- 運用に必要な設定を追加します（以下は一例です）。
FSW243(config)# atmf group floor,3F ↓
FSW243(config)# interface vlan1 ↓
FSW243(config-if)# ip address 192.168.1.243/24 ↓
FSW243(config-if)# exit ↓
:
:
（以下省略）
:
:
FSW243(config)# end ↓
- AMF自動検出メカニズムによってAMFネットワークに参加したノードは、リモートログイン、ワーキングセット、リブートローリングによる操作は可能ですが、自動バックアップの対象にはなりません。
AMF自動検出メカニズムで追加したノードに必要な設定を終えたら、設定を保存して再起動してください。再起動後から自動バックアップされるようになります。
なお、再起動にともない新スイッチがAMFネットワークから脱退するため、リモートログインセッションが切断され、マスターのローカルプロンプトに戻ります。
FSW243# write memory ↓
[OK]
FSW243# reboot ↓
reboot system? (y/n): y ↓
21:21:41 SBx81 ATMF[1946]: FSW243 has left. 4 members in total.
SBx81#
- 再起動が完了したら、状態を確認します。
21:23:15 SBx81 ATMF[1946]: FSW243 has joined. 5 members in total.
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
FSW243 x510-28GTX N S SBx81 1
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
ESW231 x510-52GTX N S FSW242 2
Current ATMF node count 5
FSW243がAMFネットワークに参加していることを確認できます。
これ以降、マスターのCLIから、ワーキングセット機能を用いて新規ノードFSW243の設定や状態監視が可能です。
新規ノード追加手順（自動検出＋事前作成コンフィグ転送）
稼働中のAMFネットワークに機器を追加する場合に、ご購入時状態のAMF対応スイッチがAMFネットワークに自動参加する機能を利用して、マスターのCLIから新規スイッチにリモートログインし、事前に用意しておいたコンフィグファイルとファームウェアを転送してから再起動することで、新規ノードを運用状態に持って行く方法を紹介します。
想定するネットワーク環境は前の例と同じです。すなわち、下記AMFネットワークに、新しいフロアスイッチFSW243をメンバーとして追加する場合を例として説明します。
| 機種 |
ノード名 |
AMFにおける役割 |
所属グループ |
概要 |
| SwitchBlade x8100 |
SBx81 |
マスター |
- |
コアスイッチ |
| AT-x510-28GTX |
FSW241 |
メンバー |
floor, 1F |
フロアスイッチ |
| AT-x510-28GTX |
FSW242 |
メンバー |
floor, 2F |
フロアスイッチ |
| AT-x510-28GTX |
FSW243 |
メンバー |
floor, 3F |
フロアスイッチ（新規追加） |
| AT-x510-52GTX |
ESW231 |
メンバー |
edge, 2F |
エッジスイッチ |
追加するスイッチ（新規ノード）はご購入時の状態であると仮定します。
もしそうでない場合は、「AMFクリーン化手順」を参照し、新規ノードをAMFクリーン状態に戻してから下記の手順を実施してください。
接続先ノードの設定変更
新規ノードを接続する既存のAMFノード（接続先ノード）にAMFリンクを追加設定する方法は、運用編で紹介した基本手順と同じですので、運用編をご覧ください。
新規ノードの接続と初期設定
接続先ノードの設定変更が済んだら、新規ノードを起動して、接続先ノードと接続します。
- あらかじめ新規ノード用の設定ファイルを作成し、マスターに装着したUSBメモリー内の任意のディレクトリーに格納しておきます。設定ファイルには、AMFの初期設定だけでなく、新スイッチの運用に必要なすべてのコマンドが記述されているものとします。
ここでは、設定ファイルをFSW243.cfgという名前で作成し、USBメモリーの/configディレクトリーに置いたものと仮定します。
AMFの初期設定については、導入編の「メンバーの初期設定」をご参照ください。
- 新規ノードを起動します。
- 接続先ノードであるマスターのポート1.1.3と、新規ノードのポート1.0.1を接続します。
すると、マスターのコンソールに、新規ノードがJoin（AMFネットワークに参加）したことを示すメッセージが出力されます。
21:09:23 SBx81 ATMF[1946]: host_eccd_6d82_6b3d has joined. 5 members in total.
新規ノードはノード名が未設定のため、MACアドレスを元にした「host_eccd_6d82_6b3d」という名前で動作していることがわかります。
- マスターのCLIから、show atmf nodesコマンドでノード情報を確認します。
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
host_eccd_6d82_6b3d x510-28GTX N S SBx81 1
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
ESW231 x510-52GTX N S FSW242 2
Current ATMF node count 5
- AMFリモートログイン機能（atmf remote-loginコマンド）を使って新規ノードにログインします。
このとき、userパラメーターで初期設定の管理者ユーザー名であるmanagerを指定してください。こうすることにより、マスター側でmanagerのパスワードを変更していても、新規ノードにログインできます。
SBx81# atmf remote-login user manager host_eccd_6d82_6b3d ↓
Type 'exit' to return to SBx81.
manager@172.31.0.5's password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus>
- マスターのUSBメモリーに格納されているFSW243用のコンフィグファイルとファームウェアを新規ノードにダウンロードします。
awplus> enable ↓
awplus# copy SBx81.atmf/usb:/config/FSW243.cfg flash:/default.cfg ↓
Copying...
Successful operation
awplus# copy SBx81.atmf/usb:/fw/x510-5.4.9-1.9.rel flash ↓
Enter destination file name[x510-5.4.9-1.9.rel]: ↓
Copying...
Successful operation
awplus# dir ↓
20570492 -rwx Jan 24 2013 21:40:11 x510-5.4.9-1.9.rel
1263 -rwx Jan 24 2013 21:38:31 default.cfg
20570305 -rw- Jan 22 2013 19:49:12 x510-5.4.9-1.8.rel
5.4.9-1.8と5.4.9-1.9は説明上使用している架空のファームウェアです。本マニュアル作成時点では実在しませんのでご注意ください。
- ダウンロードしたファームウェアを通常起動時のファームウェアに、現在のファームウェアをバックアップ用ファームウェアに設定します。
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# boot system x510-5.4.9-1.9.rel ↓
awplus(config)# boot system backup x510-5.4.9-1.8.rel ↓
awplus(config)# end ↓
- 新しいファームウェアとコンフィグで再起動します。
再起動にともない新規ノードがAMFネットワークから脱退するため、リモートログインセッションが切断され、マスターのローカルプロンプトに戻ります。
awplus# reboot ↓
reboot system? (y/n): y ↓
21:40:55 SBx81 ATMF[1946]: host_eccd_6d82_6b3d has left. 4 members in total.
SBx81#
- 新規ノードが再起動を完了し、新しいノード名で再参加してきたことは、マスターのコンソールに次のメッセージが表示されることでわかります。
21:42:32 SBx81 ATMF[1946]: FSW243 has joined. 5 members in total.
- マスターのCLIから状態を確認します。
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
FSW243 x510-28GTX N S SBx81 1
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
ESW231 x510-52GTX N S FSW242 2
Current ATMF node count 5
FSW243がAMFネットワークに参加していることを確認できます。
これ以降、マスターのCLIから、ワーキングセット機能を用いて新規ノードFSW243の設定や状態監視が可能です。
オートリカバリー失敗時の再試行手順
何らかの理由でオートリカバリーに失敗した場合、以下の手順で再度オートリカバリーを試みてください。
- AMFマスターにバックアップファイルが保存されているかどうかを確認してください。
バックアップファイルの確認方法は、運用編の「バックアップファイルの確認方法」をご覧ください。
- オートリカバリーに失敗した機器のケーブルを一旦全て外してください。
- 対象機器にコンソールを接続し、atmf cleanupコマンドを実行し、「AMFクリーン状態」にしてください。
クリーン化コマンド実行により自動的に再起動します。
- 再起動後、AMFマスターにつながっているポート（※1）の1ポートだけ接続した状態にしてください。オートリカバリーが動作します。
- オートリカバリー完了後、元のケーブルに戻してください。
※1 アップリンク（マスターに近い方のポート）ポートという意味で、AMFマスターと直接接続されている必要はありません。
オートリカバリー失敗時の手動リカバリー
なんらかの理由によりオートリカバリーが動作しなかったり、失敗したときでも、AMF自動検出メカニズムによってAMFネットワークに参加できていれば、atmf recoverコマンドを用いた手動によるリカバリーが可能です。
以下では、運用編の「メンバーの交換（オートリカバリー）」でオートリカバリーに失敗した場合を例に、手動リカバリーの手順を説明します。
- 代替機のコンソールターミナル、または、LED表示（代替機の機種や拡張モジュールによっては行われない場合があります。詳細はatmf recover led-offコマンドのページをご覧ください）によってオートリカバリーの失敗を確認した場合は、マスターのCLIからshow atmf nodesコマンドでノード情報を確認し、該当ノードがAMFネットワークに参加していることを確認します。
以下の例では、代替機のノード名が未設定のため、MACアドレスを元にした「host_eccd_6d82_6b34」という名前でAMFネットワークに参加していることがわかります。
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
host_eccd_6d82_6b34 x510-52GTX N S FSW242 2
Current ATMF node count 4
- AMFネットワークに参加できている場合は、代替機のCLIから手動リカバリーが可能です。
AMFリモートログイン機能（atmf remote-loginコマンド）を使って代替機にログインしてください。
このとき、userパラメーターで初期設定の管理者ユーザー名であるmanagerを指定してください。こうすることにより、マスター側でmanagerのパスワードを変更していても、代替機にログインできます。
また、リモートログイン機能ではconsoleログが表示されるため、オートリカバリーの進捗をリアルタイムに確認でき便利です。
SBx81# atmf remote-login user manager host_eccd_6d82_6b34 ↓
Type 'exit' to return to SBx81.
manager@172.31.0.4's password: friend ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus>
- atmf recoverコマンドを実行して、マスターに装着されたUSBメモリー内のバックアップファイルから代替機の内蔵フラッシュメモリーの内容を手動でリカバリーします。
代替機の機種や拡張モジュールによっては、ポートLEDの表示によってリカバリー実行中であることが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
awplus> enable ↓
awplus# atmf recover ESW231 ↓
This command will erase ALL flash contents. Continue node recovery? (y/n)y
Manual node recovery successfully initiated
16:56:00 awplus ATMFFSR[4283]: Retrieving recovery data from master node SBx81
16:57:47 awplus ATMFFSR[4283]: Manual node recovery completed
- リカバリーが完了したら、再起動します。
再起動にともない代替機がAMFネットワークから脱退するため、リモートログインセッションが切断され、マスターのローカルプロンプトに戻ります。
awplus# reboot ↓
reboot system? (y/n): y ↓
17:00:21 SBx81 ATMF[1958]: host_eccd_6d82_6b34 has left. 3 members in total.
SBx81#
- 新スイッチが再起動を完了し、新しいノード名で再参加してきたことは、マスターのコンソールに次のメッセージが表示されることでわかります。
17:01:59 SBx81 ATMF[1958]: ESW231 has joined. 4 members in total.
- マスターのCLIから状態を確認します。
SBx81# show atmf nodes ↓
Node Information:
* = Local device
SC = Switch Configuration:
C = Chassis S = Stackable N = Standalone
Node Device ATMF Node
Name Type Master SC Parent Depth
--------------------------------------------------------------------------------
* SBx81 AT-SBx81CFC960 Y C none 0
FSW242 x510-28GTX N S SBx81 1
FSW241 x510-28GTX N S SBx81 1
ESW231 x510-52GTX N S FSW242 2
Current ATMF node count 4
ESW231がAMFネットワークに参加していることを確認できます。
スタックポートをAMF接続ポートとして使用している場合の手動リカバリー
導入編に記載の機種において、スタックポート（本体搭載のスタックポート、またはスタック/ポート拡張兼用モジュール）を通常ポートに設定し、AMFリンクとして使用している場合はオートリカバリーが動作しません。
スタックポートを通常ポートとして動作させるにはVCS無効化の設定（no stack <1-8> enable）が必要ですが、この設定が入ることで「AMFクリーン状態」でなくなり、オートリカバリーの前提条件であるAMF自動検出メカニズム が働かなくなるためです。
この場合は、以下の手順にしたがって、手動でリカバリーを実施してください。
ファームウェアバージョン5.4.7-2.x以降では、GS900MXシリーズにかぎり、以下の仕様変更によって、VCSを無効化していてもAMFクリーン状態と判定され、オートリカバリーが可能になりました。
- VCSを無効化した状態で atmf cleanup を実行すると、これまではAMFクリーン化にともないVCS無効化の設定も消去されていましたが、VCS無効化の状態をシステムファイルに記録することで、AMFクリーンかつVCS無効化の状態で再起動、オートリカバリーが可能になりました。
- 同様に、すでに AMFクリーンな状態で no stack <1-8> enable を実行しても、設定を保存せずに再起動すれば、AMFクリーンかつVCS無効化の状態での再起動、オートリカバリーが可能になりました。
以下では、リカバリー対象ノードのノード名を「FSW245」、機種をAT-x510-28GTXとし、バックアップ済みと仮定します。
- 代替機を起動してコンソールターミナルからログインしたら、VCSを無効化し、スタックポートを通常ポートとして使えるようにします。show stackコマンドでスタックメンバーIDを確認し、stack enableコマンドをno形式で実行してください。
awplus login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus> enable ↓
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# no stack 1 enable ↓
Warning: this will disable the stacking hardware on member-1.
Are you sure you want to continue? (y/n): y ↓
14:50:41 awplus VCS[752]: Deactivating Stacking Ports at location 1.0
- ネットワーク名を設定します。これにはatmf network-nameコマンドを使います。
ネットワーク名は、同一AMFネットワークを構成するすべてのノードに同じ名前を設定する必要があります（マスターと異なるネットワーク名を設定したメンバーはAMFネットワークに参加できません）。また、ネットワーク名は大文字小文字を区別するので、その点にもご注意ください。
awplus(config)# atmf network-name AMF001 ↓
- VCS無効化とAMFネットワーク名の設定を有効にするため、設定をスタートアップコンフィグに保存し、再起動します。
awplus(config)# end ↓
awplus# write memory ↓
Building configuration...
[OK]
awplus# reboot ↓
reboot system? (y/n): y ↓
- 再起動後にログインしたら、通常ポートに設定したスタックポートをAMFリンクに設定します。これには、switchport atmf-linkコマンドを使います。
awplus login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus> enable ↓
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# interface port1.0.27 ↓
awplus(config-if)# switchport atmf-link ↓
- AMFネットワークへの参加を確認したら、atmf recoverコマンドを実行して手動リカバリーを実行します。
代替機の機種や拡張モジュールによっては、ポートLEDの表示によってリカバリー実行中であることが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
awplus(config-if)# end ↓
awplus# atmf recover FSW245 ↓
This command will erase ALL flash contents. Continue node recovery? (y/n) y ↓
Manual node recovery successfully initiated
17:39:12 SBx81 ATMFFSR[5594]: Retrieving recovery data from master node SBx81
17:39:32 SBx81 ATMFFSR[5594]: Manual node recovery completed
- リカバリー処理が完了したら、もう一度再起動します。
awplus# reboot ↓
reboot system? (y/n): y ↓
AMF仮想リンクを使用しているノードの手動リカバリー
AMF仮想リンク（atmf virtual-link）で、AMFネットワークに接続しているノードのオートリカバリーを実施するときに、運用編「仮想リンク経由で接続しているAMFノードのオートリカバリー」の機能の利用条件に合致しない場合は、以下の手順にしたがって、手動でリカバリーを実施してください。
以下では、リカバリー対象ノードを「BR101」（10.10.10.1）、仮想リンクの接続先を「HQ001」（10.1.1.1）とした場合の手動リカバリー手順を説明します。「BR101」はバックアップ済みと仮定します。
（構成図は「AMF仮想リンクによるワイドエリアAMFネットワーク」を参照）
- 代替機を起動し、交換前と同じポートにケーブルを接続したら、コンソールターミナルからログインし、仮想リンクの接続先である「HQ001」とIPv4による通信を行うために必要な最小限の設定をします。
awplus login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus> enable ↓
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# interface vlan1 ↓
awplus(config-if)# ip address 10.10.10.1/24 ↓
awplus(config-if)# exit ↓
awplus(config)# ip route 0.0.0.0/0 10.10.10.32 ↓
- ネットワーク名を設定します。これにはatmf network-nameコマンドを使います。
ネットワーク名は、同一AMFネットワークを構成するすべてのノードに同じ名前を設定する必要があります（マスターと異なるネットワーク名を設定したメンバーはAMFネットワークに参加できません）。また、ネットワーク名は大文字小文字を区別するので、その点にもご注意ください。
awplus(config)# atmf network-name AMF001 ↓
- atmf virtual-linkコマンドでAMF仮想リンクを設定します。
awplus(config)# atmf virtual-link id 1 ip 10.10.10.1 remote-id 1 remote-ip 10.1.1.1 ↓
ここまでの設定は、手動リカバリーを動作させることだけを目的とした仮のものです。リカバリー後は、バックアップされていた本来の設定で動作します。
- 仮のAMF設定を有効にするため、設定をスタートアップコンフィグに保存し、再起動します。
awplus(config)# end ↓
awplus# write memory ↓
Building configuration...
[OK]
awplus# reboot ↓
reboot system? (y/n): y ↓
- 再起動後、AMFネットワークへの参加を確認したら、atmf recoverコマンドを実行して手動リカバリーを実行します。
代替機の機種や拡張モジュールによっては、ポートLEDの表示によってリカバリー実行中であることが示されます（詳細はatmf recover led-offコマンドのページをご覧ください）。
awplus# atmf recover BR101 ↓
This command will erase ALL flash contents. Continue node recovery? (y/n) y ↓
Manual node recovery successfully initiated
17:39:12 SBx81 ATMFFSR[5594]: Retrieving recovery data from master node SBx81
17:39:32 SBx81 ATMFFSR[5594]: Manual node recovery completed
- リカバリー処理が完了したら、再起動します。
awplus# reboot ↓
reboot system? (y/n): y ↓
拠点側ルーターの手動リカバリー
AMFマスターと異なる拠点に設置されたAMF対応ルーター製品（AT-AR3050S/AT-AR4050S。以下、AMFルーター）が、拠点間のVPN接続を担っており、なおかつ、AMFネットワークへの接続性を配下のAMF対応スイッチが張るAMF仮想リンクに依存している場合、配下のAMF対応スイッチも、仮想リンクを張るためにはAMFルーターによる拠点間接続が必要という相互依存の関係になっているため、このような構成における拠点側AMFルーターはいかなる場合においてもオートリカバリーができません。
拠点側ルーターに仮想リンクが設定されている場合は、隣接するノード（配下のAMF対応スイッチ）の補助によりオートリカバリーが可能です。詳細は、運用編の「仮想リンク経由で接続しているAMFノードのオートリカバリー」をご覧ください。
仮想リンクを設定していない拠点側のAMFルーターを交換するときは、以下の手順にしたがって手動でリカバリーを実施してください。
- 代替機を用意し、拠点間通信を行うために必要な最小限の設定を行います。
具体的には、配下のAMF対応スイッチがAMF仮想リンクを確立し、AMFルーターからAMFマスターにアクセスできるようにする必要があります。
必要な設定はネットワーク構成によって異なりますので、ここでは示しません。具体的な例としては、設定例集をご参照ください。
awplus login: manager ↓
Password: XXXXXXXX ↓（実際には表示されません）
AlliedWare Plus (TM) 5.4.9 xx/xx/xx xx:xx:xx
awplus> enable ↓
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)#
awplus(config)# no spanning-tree rstp enable ↓
awplus(config)# interface eth1 ↓
awplus(config-if)# encapsulation ppp 0 ↓
awplus(config-if)# exit ↓
awplus(config)# interface ppp0 ↓
...
- ネットワーク名を設定します。これにはatmf network-nameコマンドを使います。
ネットワーク名は、同一AMFネットワークを構成するすべてのノードに同じ名前を設定する必要があります（マスターと異なるネットワーク名を設定したメンバーはAMFネットワークに参加できません）。また、ネットワーク名は大文字小文字を区別するので、その点にもご注意ください。
awplus(config)# atmf network-name AMF001 ↓
- 仮のAMF設定を有効にするため、設定をスタートアップコンフィグに保存し、再起動します。
awplus(config)# end ↓
awplus# write memory ↓
Building configuration...
[OK]
awplus# reboot ↓
reboot system? (y/n): y ↓
- ケーブルを交換前と同じポートに接続します。
- 再起動後、AMFネットワークへの参加を確認したら、atmf recoverコマンドを実行して手動リカバリーを実行します。
awplus# atmf recover RouterC ↓
This command will erase ALL flash contents. Continue node recovery? (y/n) y ↓
Manual node recovery successfully initiated
17:39:12 SBx81 ATMFFSR[5594]: Retrieving recovery data from master node SBx81
17:39:32 SBx81 ATMFFSR[5594]: Manual node recovery completed
- リカバリー処理が完了したら、再起動します。
awplus# reboot ↓
reboot system? (y/n): y ↓
- 再起動後、リカバリー前と同じ設定で立ち上がります。
AT-Vista Managerによるネットワーク管理
ファームウェアバージョン5.4.5-2.1より、GUI（Graphical User Interface）でAMFネットワークや無線LANアクセスポイントの情報、配置などの管理が行えるAT-Vista Manager（弊社別売ソフトウェア製品。以下 AVM）に対応しています。
AVM を使用することにより、以下のようなことが行えます。
- AMFネットワークの直感的なグラフィカル表示
- AMFネットワークのステータス情報の表示
- AMF機能で、自動リカバリーなどイベントが発生した際の即時性のある通知
- 機器の検索、管理
- 無線LANアクセスポイントの管理
AVMのAWCプラグインで管理している無線LANアクセスポイントでは、ゲストノードとしてのコンフィグバックアップ、手動リカバリーはサポート対象外です。
AVMで情報を表示するためには、AMFネットワークが構築されている必要があります。
また、AVMを使用する上で、AMF機器に以下の設定を行ってください。
- すべてのAMFマスターで、atmf topology-gui enableコマンドを有効にする。
AMFコントローラーでは自動でコマンドが有効になります。
AT-AR4050SとAMF Cloudでは、service httpコマンドも有効にしてください。
- AMFコントローラー（存在しない場合はAMFマスター）で、log event-host atmf-topology-eventコマンドを有効にする。
- AMFコントローラーとすべてのAMFマスターが、AVMをインストールしたPCと通信できるようにIPの設定を行う。
- AMFコントローラー（存在しない場合はAMFマスター）で、AVMが使用するユーザーがsshログインを行うことができるようにsshサーバーの設定を行う（「運用・管理」/「Secure Shell」を参照）。
- AVMで登録するユーザー名とパスワードは、AMFコントローラー、AMFマスター、AMFメンバーのすべてで同じものを設定するようにしてください。
ファームウェアバージョン5.4.7-2.x以降では、AVMの認証に電子証明書を用いたTLSクライアント証明書認証を使用することで、AMFノード側でのユーザー名、パスワード一本化が不要になります。詳しくは次節「TLSクライアント証明書認証」をご覧ください。
AVMの詳しい使い方については、AVMのユーザーガイドをご覧ください。
TLSクライアント証明書認証
ファームウェアバージョン5.4.7-2.x以降では、AVMの認証に電子証明書を用いたTLSクライアント証明書認証を使用することで、AMFノード側でのユーザー名、パスワード一本化が不要になります。
AVM側もTLSクライアント証明書認証に対応したバージョンが必要です。また、AVM側でもTLSクライアント証明書認証を使用するよう設定する必要があります。
TLSクライアント証明書認証はデフォルト無効です。同認証を有効にするには、AMFコントローラー（存在しない場合はAMFマスター）でローカルCAを作成し、atmf trustpointコマンドでローカルCA名（トラストポイント名）を指定します。
以下、AMFコントローラー（またはAMFマスター）側でTLSクライアント証明書認証を有効にするための設定手順を説明します。
なお、ローカルCA機能の詳細については、「運用・管理」/「ローカルCA」をご参照ください。
- ローカルCAを作成します。
本機能で使用するローカルCAの名前は「local」以外にする必要があります。
ここでは例として「vista-ca」という名前のローカルCAを作成するものとします。
これには、crypto pki trustpoint、enrollment、crypto pki authenticateコマンドを使います。
awplus(config)# crypto pki trustpoint vista-ca ↓
Created trustpoint "vista-ca".
awplus(ca-trustpoint)# enrollment selfsigned ↓
awplus(ca-trustpoint)# end ↓
awplus# crypto pki authenticate vista-ca ↓
Generating 2048-bit key for local CA...
Successfully authenticated trustpoint "vista-ca".
- 前の手順で作成したローカルCA「vista-ca」から本製品のサーバー証明書を発行します。
これには、rsakeypair、crypto pki enrollコマンドを使います。
ここでは例として本製品の公開鍵ペアに「amf-server-key」という名前を付けています。
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# crypto pki trustpoint vista-ca ↓
awplus(ca-trustpoint)# rsakeypair amf-server-key ↓
awplus(ca-trustpoint)# end ↓
awplus# crypto pki enroll vista-ca ↓
Generating 2048-bit key "amf-server-key"...
Successfully enrolled the local server.
- AMFにおけるTLSクライアント証明書認証を有効にします。
これには、atmf trustpointコマンドで使用するローカルCA名を指定します。
前述のとおり、同コマンドで指定するローカルCAは「local」以外の名前でなくてはなりません。
awplus# configure terminal ↓
Enter configuration commands, one per line. End with CNTL/Z.
awplus(config)# atmf trustpoint vista-ca ↓
AMFコントローラー（またはAMFマスター）側の設定は以上です。
あとは、AVM側でもTLSクライアント証明書認証を有効にしてください。具体的な方法についてはAVMのユーザーガイドをご覧ください。
AMFアプリケーションプロキシー機能
AMFアプリケーションプロキシーは、弊社のAMF-SECurityコントローラー AT-SecureEnterpriseSDN Controller（AT-SESC）から被疑端末の情報を受け取ったAMFマスターが、配下のAMFメンバーに該当端末の通信遮断（L2またはL3レベルでの破棄、接続ポート無効化、隔離）やログ記録を指示することで、AT-SESCからAMF対応機器でのアクセス制御を可能にするAMF-SEC（AMF-SECurity）の連携機能です。
- AMFアプリケーションプロキシー機能を使用する場合、AMFネットワーク上のすべてのノードでファームウェアバージョンを統一する必要があります。
- 本機能はファームウェアバージョン5.4.7-2.5で仕様が変更されているため、本マニュアルの記述にしたがって本機能を使用する場合は、AMFネットワーク上のすべてのノードを5.4.7-2.5以降で運用してください。
- AMFアプリケーションプロキシー機能による遮断ステータスをAT-Vista Manager EXまたはAT-SESC上で確認する（AT-Vista Manager EXまたはAT-SESCとの連携を使用する）場合は、AMFネットワーク上のすべてのノードを5.4.8-1.x以降で運用してください。
- ファームウェアバージョン5.4.9-0.xで追加されたログ（log-only）アクション、IPフィルターのリダイレクト機能、ホワイトリスト機能のいずれかを使用する場合は、AMFネットワーク上のすべてのノードを5.4.9-0.x以降で運用してください。
- ファームウェアバージョン5.4.9-1.xで追加されたプロキシーノード・ホワイトリストサーバー間の通信暗号化（コントロールセッションの暗号化）を使用する場合は、AMFネットワーク上のすべてのノードを5.4.9-1.x以降で運用してください。
対応製品
本機能において、AMFノードは次の2つの役割に分かれます。
- プロキシーノード：外部アプリケーションからの端末遮断要求を受け付け、エッジノードに指示を出す（AMFマスター）
- エッジノード：プロキシーノード（AMFマスター）からの指示を受け付け、指定された端末（アドレス）を遮断する（AMFメンバー）
プロキシーノードはエッジノードを兼ねることもできます。
それぞれの対応製品および連携対象アプリケーションは次のとおりです。
■ 対応製品
- マスター（プロキシーノード）
AMF Cloud、
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908
AT-DC2552XS、x950シリーズ、x930シリーズではAMFマスターライセンス以外に別途AMFアプリケーションプロキシーライセンスが必要です。
- メンバー（エッジノード）
AT-SBx81CFC960、
AT-SBx81CFC400、
AT-DC2552XS、
x950シリーズ、
x930シリーズ、
SwitchBlade x908 GEN2、
SwitchBlade x908、
x550シリーズ、
x530シリーズ、
x530Lシリーズ、
x510シリーズ、
x510Lシリーズ、
AT-IX5-28GPX、
x310シリーズ、
x230シリーズ（52ポート版を含む）、
x230Lシリーズ、
x220シリーズ、
XS900MXシリーズ、
GS980MXシリーズ、
GS980Mシリーズ、
GS900MX/GS900MPXシリーズ、
FS980Mシリーズ、
IE210Lシリーズ、
IE200シリーズ、
AT-AR4050S、
AT-AR3050S、
AT-AR2050V、
AT-AR1050V、
SH510シリーズ、
SH310シリーズ、
SH230シリーズ
IE200シリーズは「ポート無効化」、「ログ」、「IPフィルター」、「隔離」アクションのみをサポートします。「破棄」アクションは未サポートです。
AT-AR4050S、AT-AR3050S、AT-AR2050Vは「ログ」、「隔離」アクションのみをサポートします。他のアクションは未サポートです。
AT-AR1050Vは「ログ」アクションのみをサポートします。他のアクションは未サポートです。
AT-AR1050VはMACベース認証未サポートのため、ホワイトリスト機能はサポートしていません。
AT-AR2010Vは本機能をサポートしていません。
■ 連携対象アプリケーション
- 弊社 AT-SecureEnterpriseSDN Controller（AT-SESC）
AT-SESC側がアプリケーションプロキシーとの連携に対応している必要があります。
また、被疑端末を検出するセキュリティーソフトウェアや機器とのSyslog/SNMP連携が必要です。
詳細はAT-SESCのリファレンスマニュアルをご覧ください。
機能
エッジノードが実行可能な動作（アクション）には次の種類があります。
- 破棄（drop）
IPアドレスまたはMACアドレスで指定された被疑端末の通信をレイヤー2（MACレベル）で破棄します。
破棄アクションでは、IPアドレスで被疑端末が指定された場合でも、エッジノードにおける実際の遮断はMACアドレスによって行われます。
- ポート無効化（link-down）
IPアドレスまたはMACアドレスで指定された被疑端末の接続ポートを無効化（err-disabled状態）します。
- ログ（log-only）
IPアドレスまたはMACアドレスで指定された被疑端末の接続ポートをログに記録します。実際の遮断動作は行いません。
- IPフィルター（ip-filter）
IPアドレスで指定された被疑端末の通信をレイヤー3（IPレベル）で破棄します。
また設定により、被疑端末からのWebアクセス（HTTPリクエスト）を特定のURL（状況説明ページなど）にリダイレクトすることもできます。
- 隔離（quarantine）
IPアドレスまたはMACアドレスで指定された被疑端末の接続ポートをあらかじめ用意した隔離用VLANに移動します。
- ホワイトリスト
他のアクションと異なり、デフォルトではすべての通信を遮断しつつ、端末の接続場所（接続先のエッジノードとそのポート）とMACアドレスをもとにして特定の端末にだけ通信を許可します。通信可否の判断はプロキシーノード経由でAT-SESCサーバー（ホワイトリストサーバー）に問い合わせることで行います。
制限
AMFアプリケーションプロキシー機能には、以下の制限があります。
- AMFアプリケーションプロキシーとVRF-Liteを併用する場合、VRFインスタンス間で重複するIPアドレスは使用できません。
- AMFアプリケーションプロキシーとVRF-Liteを併用する場合、通信遮断はグローバルインスタンス上でのみ動作します。
- ブロック可能なアドレス（IP/MACの合計）は最大10000個です。
- ホワイトリスト機能によって通信を許可できる端末はAMFネットワーク全体で最大5000台、装置・ポートあたりでは最大1024台です。
装置・ポートあたりの台数には、ホワイトリスト機能だけでなくポート認証機能（MAC、Web、802.1X認証の合計）のSupplicant数を含みます。
- AMFゲストノード機能でdiscovery dynamicを設定している場合、AT-SESCで指定するAMFアクションのリンクダウンは未サポートです。
- リンクアグリゲーション（LAG）に関して
- スタティックチャンネルグループ、LACPチャンネルグループ上でサポートするアクションは、IPフィルターのみです。
ただし、LAG上ではIPフィルターのリダイレクト機能 は使用できません。
- タグ付きポートでの「隔離」アクションは未サポートです。
- 「隔離」アクションとポート認証を同一ポート上で併用する場合、ダイナミックVLANは使用できません。
IPフィルターアクション使用時、および、DHCP Snooping使用時は、ハードウェアパケットフィルターを消費します。
遮断可能な被疑端末数は、ハードウェアパケットフィルターのエントリー数に依存します。
また、ハードウェアパケットフィルターのエントリー消費量はルール数やポート数、ハードウェアパケットフィルターを使用する機能の有効/無効に依存します。
IPフィルターアクションのリダイレクト機能使用時は、IPフィルターの被疑端末数の2倍のハードウェアパケットフィルターを消費します。また被疑端末数に関わらず、ハードウェアパケットフィルターを3つ消費します。
エッジノードにおける動作
破棄、ポート無効化、ログ、隔離アクション
「破棄」、「ポート無効化」、「ログ」、「隔離」アクションでは、対象端末の指定にMACアドレス、IPアドレスのどちらかが使われますが、最終的な動作時にはMACアドレスを使用します。
これらのアクションを指示されたエッジノードは、自装置のポート配下に該当端末が存在するかどうかを次のフローにしたがって調べ、存在した場合にアクションを実行します。
- MACアドレスで対象端末が指定された場合
- FDB（MACアドレステーブル）内に該当MACアドレスが登録されている場合、該当端末が存在すると判断します。
- IPアドレスで対象端末が指定された場合
- DHCP Snoopingテーブルに該当IPアドレスが登録されている場合、該当端末が存在すると判断します。
- ARPテーブルに該当IPアドレスが登録されている場合、該当端末が存在すると判断します。
なお、DHCP SnoopingまたはARPテーブルから被疑端末のIPアドレスに対応するMACアドレスを検索できたAMFノードは、他のすべてのAMFノードにその情報を通知し、他ノードの遮断動作を支援します。
こうして取得した該当端末のMACアドレスが、遮断動作が有効な（application-proxy threat-protectionコマンドが設定されている）ポート配下に存在していた場合は、次のようにして動作を実行します。
- 破棄アクションの場合は、上記フローによって取得した該当端末のMACアドレスを遮断エントリーとしてFDBに登録します。
- ポート無効化アクションの場合は、同MACアドレスが存在するポートを無効化（err-disabled状態）にします。
- ログアクションの場合は、同MACアドレスが存在するポートに関するログを出力します。
- 隔離アクションの場合は、同MACアドレスが存在するポートの所属先を隔離VLANに移動します。
該当端末が自装置のポート配下に存在していても、該当ポートにapplication-proxy threat-protectionコマンドが設定されていない場合は遮断動作を行いません。
IPフィルターアクション
他のアクションと異なり、「IPフィルター」アクションでは遮断端末の指定も遮断動作もIPアドレスにもとづいて行われます。
また、「IPフィルター」アクションは装置全体で有効・無効を設定する点も他のアクションと異なります。
「IPフィルター」アクションを指示されたエッジノードは、グローバルコンフィグモードのapplication-proxy ip-filterコマンドによって自装置で「IPフィルター」アクションが有効になっている場合、被疑端末からのパケットを破棄するハードウェアパケットフィルターを全ポートに適用します。
被疑端末が接続されているポートに他アクション（破棄、ポート無効化、ログ、隔離）が設定されている場合、被疑端末のMACアドレスを取得した時点でポートに設定されたアクションが実行されます。
リダイレクト機能
さらに、IPフィルターアクションでは、被疑端末からのWebアクセスを特定のURLにリダイレクトすることもできます。
通常、被疑端末のユーザーがWebサイトにアクセスしようとしても、ブラウザーがタイムアウトするだけでアクセス不可の理由を知ることはできませんが、リダイレクト機能を利用すれば、該当ユーザーからのWebアクセスをあらかじめ指定したURLにリダイレクトできるため、同URLに状況説明ページを用意しておくことでブロックの理由や問い合わせ先などをユーザーに伝えることができます。
本機能の基本仕様は次のとおりです。
- リダイレクト機能が動作するためには、被疑端末が接続されているノード上で下記の設定がすべて行われている必要がある。
- リダイレクトの対象となる通信は、IPフィルターアクションによってブロックされた被疑端末からのWebアクセスのみ。
ここでのWebアクセスとは次の通信を指す。
- IPv4上のHTTP通信（TCPポート80番宛て）
- リダイレクト先URLはHTTPのIPv4サイトのみサポート。HTTPSやIPv6サイトは未サポート。
- サポートするブラウザーは、Internet Explorer、Edge、Chrome、Firefoxの各最新版。
- リダイレクト機能の有効時は、IPフィルターでブロックされているIPアドレスからのDNS（TCP, UDP）とARPパケット、および、リダイレクト後のURLに対するWebアクセスが許可される。
ホワイトリスト機能
これまで説明してきた「破棄」、「ポート無効化」、「ログ」、「隔離」、「IPフィルター」アクションは疑わしい端末からの通信を遮断または通知する機能であり、デフォルトでは通信を許可します。
これに対し、デフォルトでは通信をすべて遮断し、特定の端末にだけ通信を許可したい場合を想定した機能として、ファームウェアバージョン5.4.9以降ではホワイトリスト機能をサポートしています。
ホワイトリスト機能は、エッジノードの端末接続ポートにおいて、特定の端末だけを通信可能にするための機能です。
通信可否の判断は、端末のMACアドレスと接続場所（接続先のエッジノードとポート）をもとに、プロキシーノード経由でAT-SESCサーバー（ホワイトリストサーバー）に問い合わせることで行います。
そのため、許可端末のリスト（ホワイトリスト）はAT-SESCサーバー側で設定する形になります。
エッジノードは、ホワイトリスト機能が有効に設定されているポート（ホワイトリストポート）に端末が接続されると、該当端末のMACアドレス、エッジノード名、ポート番号をプロキシーノードに送信して、同端末の通信可否を問い合わせます（オプションでエッジノードのIPv4アドレスも送信可能）。プロキシーノードは問い合わせ要求をあらかじめ設定されたAT-SESCに中継して結果をエッジノードに返し、エッジノードは通信許可の応答を得たときだけ該当端末の通信を許可します。
ホワイトリスト機能はMACベース認証の仕組みを使用しているため、MACベース認証でサポートされているオプションやパラメーターはホワイトリスト機能にも適用されます。
AT-AR1050VはMACベース認証未サポートのため、本機能はサポートしていません。
エッジノードがVCS構成の場合、VCSマスターが切り替わっても接続を許可されている端末は通信を継続できます。
エッジノードがVCS構成の場合、VCSマスター切り替え中に接続または接続認証の更新を受けようとしたクライアントは切り替え完了まで通信ができません。
プロキシーノードがVCS構成の場合、VCSマスター切り替え中に接続または接続認証の更新を受けようとしたクライアントは切り替え完了まで通信ができません。
本機能の運用中にエッジノードが中継役のプロキシーノードにアクセスできなくなった場合、あるいは、プロキシーノードがホワイトリストサーバーにアクセスできなくなった場合、エッジノードに接続し通信を許可されている端末は、セッションタイムアウトまたは許可更新のタイミングまでは通信を継続できますが、それ以降は通信ができなくなります。
本機能を使用する場合は、RADIUSクライアント機能のip radius source-interfaceコマンドを設定しないでください。
基本設定
AMFアプリケーションプロキシー機能を利用するには、プロキシーノード、エッジノードのそれぞれで最低限以下の設定を行ってください。
ここでは、デフォルトでは通信を許可しながら、疑わしい端末を遮断、通知する「破棄」、「ポート無効化」、「ログ」、「隔離」、「IPフィルター」アクションの設定についてのみ説明します。デフォルトでは通信を拒否し、特定の端末にのみ通信を許可する「ホワイトリスト機能」の設定については「ホワイトリスト機能の設定」をご参照ください。
本機能を利用するためには、本機能に対応しているAMFネットワーク上のすべてのノードで本機能が有効化されている必要があります。
「破棄」、「ポート無効化」、「ログ」、「隔離」アクションを使用する場合は、エッジノードの端末接続ポートで遮断動作が有効に設定されている必要があります。また、「IPフィルター」アクションを使用する場合は、装置全体の設定（グローバルコンフィグ）としてIPフィルターアクションが有効に設定されている必要があります。
- AMFアプリケーションプロキシー機能を使用する場合、AMFネットワーク上のすべてのノードでファームウェアバージョンを統一する必要があります。
- 本機能はファームウェアバージョン5.4.7-2.5で仕様が変更されているため、本マニュアルの記述にしたがって本機能を使用する場合は、AMFネットワーク上のすべてのノードを5.4.7-2.5以降で運用してください。
- AMFアプリケーションプロキシー機能による遮断ステータスをAT-Vista Manager EXまたはAT-SESC上で確認する（AT-Vista Manager EXまたはAT-SESCとの連携を使用する）場合は、AMFネットワーク上のすべてのノードを5.4.8-1.x以降で運用してください。
- ファームウェアバージョン5.4.9-0.xで追加されたログ（log-only）アクション、IPフィルターのリダイレクト機能、ホワイトリスト機能のいずれかを使用する場合は、AMFネットワーク上のすべてのノードを5.4.9-0.x以降で運用してください。
プロキシーノード
プロキシーノードでは下記の設定が必要です。
- AMFアプリケーションプロキシー機能を有効にします。これには、service atmf-application-proxyコマンドを使います。
awplus(config)# service atmf-application-proxy ↓
- プロキシーノードとして AMF Cloud を使う場合は、service httpコマンドでWebサーバー機能を有効にしてください。
awplus(config)# service http ↓
プロキシーノードに対応するその他の製品では初期状態でWebサーバー機能が有効になっていますが、もし無効化している場合は同様に有効化してください。
- AMFとGUIの連携機能を有効化します。これには、atmf topology-gui enableコマンドを使います。
AT-Vista Manager EXやAT-SESC上で遮断情報を確認したり、AT-SESC上でホワイトリスト機能による認証結果を確認するには、プロキシーノードでAMF・GUI連携機能（atmf topology-gui enable）を有効にしておく必要があります。
awplus(config)# atmf topology-gui enable ↓
プロキシーノードをエッジノードとしても使用する場合（プロキシーノード上で遮断動作も行う場合）は、端末接続ポートに対し、次に述べるエッジノードの設定を追加してください。
エッジノード
DHCP Snoopingを使用しない場合
DHCP Snoopingを使用しない、あるいは、サポートしていないエッジノードでは、下記の設定が必要です。
- AMFアプリケーションプロキシー機能を有効にします。これには、service atmf-application-proxyコマンドを使います。
awplus(config)# service atmf-application-proxy ↓
- 端末接続ポートでポート単位の遮断動作（破棄、ポート無効化、ログ、隔離）を有効にします。これには、application-proxy threat-protectionコマンドを使います。
同コマンドでは、AT-SESCからアクションを指定されなかった場合に実行するデフォルトの遮断動作を指定してください。
なお、AT-SESCからアクションを指定された場合は、同コマンドの設定にかかわらず、AT-SESCから指定された遮断動作を実行します。
awplus(config)# interface port1.0.2-1.0.12 ↓
awplus(config-if)# application-proxy threat-protection drop ↓
awplus(config-if)# exit ↓
- IPフィルターアクションを使用する場合は、グローバルコンフィグモードのapplication-proxy ip-filterコマンドを使って、同アクションを装置全体で有効にします。
awplus(config)# application-proxy ip-filter ↓
- IPフィルターでブロックした端末からのWebアクセスを特定のURLにリダイレクトしたい場合は、グローバルコンフィグモードのapplication-proxy redirect-urlコマンドでURLを指定します。
awplus(config)# application-proxy http://www.i.example.com/error_blocked.html ↓
リダイレクト機能を使用する場合は、端末が接続されているノードにおいて、端末の所属VLANにIPv4アドレスを設定しておく必要があります。
DHCP Snoopingを使用する場合
DHCP Snoopingを使用するエッジノードでは、下記の設定が必要です。
端末接続ポートでDHCP Snoopingを使用する場合、「破棄」、「ポート無効化」、「ログ」、「隔離」アクション実行時に、DHCP Snoopingテーブルを利用した被疑端末のMACアドレス検索が可能になります。
DHCP Snoopingをサポートしていないエッジノードや、DHCP Snoopingの設定を行っていないエッジノードでも、ARPテーブルや他のエッジノードからの通知により、被疑端末のMACアドレスを取得し、該当端末を遮断することは可能です。また、IPフィルターアクションはこれらのテーブルを使用しないため、同アクションが有効に設定されていれば、DHCP Snoopingのサポートや設定の有無にかかわらず使用できます（IPフィルターアクションをサポートしていない機種は除く）。
以下では、端末接続ポートがvlan100に所属しているものと仮定しています。
DHCP Snoopingの詳細は、「L2スイッチング」/「DHCP Snooping」をご覧ください。
- AMFアプリケーションプロキシー機能を有効にします。これには、service atmf-application-proxyコマンドを使います。
awplus(config)# service atmf-application-proxy ↓
- 端末接続ポートでポート単位の遮断動作（破棄、ポート無効化、ログ、隔離）を有効にします。これには、application-proxy threat-protectionコマンドを使います。
同コマンドでは、AT-SESCからアクションを指定されなかった場合に実行するデフォルトの遮断動作を指定してください。
なお、AT-SESCからアクションを指定された場合は、同コマンドの設定にかかわらず、AT-SESCから指定された遮断動作を実行します。
awplus(config)# interface port1.0.2-1.0.12 ↓
awplus(config-if)# application-proxy threat-protection drop ↓
awplus(config-if)# exit ↓
- IPフィルターアクションを使用する場合は、グローバルコンフィグモードのapplication-proxy ip-filterコマンドを使って、同アクションを装置全体で有効にします。
awplus(config)# application-proxy ip-filter ↓
- IPフィルターでブロックした端末からのWebアクセスを特定のURLにリダイレクトしたい場合は、グローバルコンフィグモードのapplication-proxy redirect-urlコマンドでURLを指定します。
awplus(config)# application-proxy http://www.i.example.com/error_blocked.html ↓
リダイレクト機能を使用する場合は、端末が接続されているノードにおいて、端末の所属VLANにIPv4アドレスを設定しておく必要があります。
- 機器全体でDHCP Snoopingを有効にします。これには、service dhcp-snoopingコマンドを使います。
awplus(config)# service dhcp-snooping ↓
- DHCPクライアントを接続するVLANでDHCP Snoopingを有効にします。これには、ip dhcp snoopingコマンドを使います。
awplus(config)# interface vlan100 ↓
awplus(config-if)# ip dhcp snooping ↓
awplus(config-if)# exit ↓
- DHCPサーバーが接続されているポートをTrustedポートとして設定します。これには、ip dhcp snooping trustコマンドを使います。
awplus(config)# interface port1.0.1 ↓
awplus(config-if)# ip dhcp snooping trust ↓
awplus(config-if)# exit ↓
- DHCPクライアントを接続するUntrustedポートでフィルタリングを行うために必要なハードウェアアクセスリストを作成します。これには、access-list hardware(list)コマンドとサブコマンドのaccess-list hardware(seq entry)コマンドを使います。
awplus(config)# access-list hardware dhcp-client ↓
awplus(config-ip-hw-acl)# permit ip dhcpsnooping any ↓
awplus(config-ip-hw-acl)# deny ip any any ↓
awplus(config-ip-hw-acl)# exit ↓
- DHCPクライアントを接続するUntrustedポートに前の手順で作成したアクセスリストを適用します。これには、access-groupコマンドを使います。
このアクセスリストは、DHCPクライアントにのみ接続を許可するためのもので、Untrustedポートでは必須の設定です。
awplus(config)# interface port1.0.2-1.0.12 ↓
awplus(config-if)# access-group dhcp-client ↓
UntrustedポートにDHCPクライアントを複数接続する場合は、ip dhcp snooping max-bindingsコマンドで接続可能数を設定してください（初期設定は1のため、複数のDHCPクライアントを接続できません）。
awplus(config-if)# ip dhcp snooping max-bindings 5 ↓
DHCP Snoopingを利用する状況について
「エッジノードにおける動作」でも述べたように、「破棄」、「ポート無効化」、「ログ」、「隔離」アクションでは、被疑端末の指定にMACアドレス、IPアドレスのどちらかが使われますが、最終的な動作時にはMACアドレスを使用します。
AT-SESCからIPアドレス形式で被疑端末情報が通知される場合、エッジノードは遮断動作のために該当MACアドレスを学習する必要があります。
次図「構成1」のようにプロキシーノードがL3スイッチとして動作している場合、プロキシーノードは自身のARPテーブルから被疑端末のMACアドレスを学習し、他のすべてのAMFノードにその情報を通知するため、エッジノードは対象MACアドレスを学習でき、「破棄」、「ポート無効化」、「ログ」、「隔離」アクションを実行可能です。
[構成1]
しかし、次図「構成2」のように被疑端末のARPエントリーがAMF非対応のL3スイッチに登録されている環境においては、AMF非対応のL3スイッチは、（AMF対応 L3スイッチと異なり）自身のARPテーブルに登録されている被疑端末のMACアドレス情報を他ノードへ通知しないため、エッジノードは被疑端末のMACアドレスを学習することができず、「破棄」、「ポート無効化」、「ログ」、「隔離」アクションを実行できません。
このような場合に、エッジノードで DHCP Snooping が有効であれば、DHCP Snoopingのバインディングデータベースから被疑端末のMACアドレスを学習し、「破棄」、「ポート無効化」、「ログ」、「隔離」アクションを実行することが可能です。
[構成2]
「破棄」、「ポート無効化」、「ログ」、「隔離」アクションを実行する場合で、AT-SESCからMACアドレス形式で被疑端末情報が通知される場合、プロキシーノードとエッジノード間にAMF非対応機器が配置されている環境であっても、エッジノード自身のFDBから被疑端末の MAC アドレスを探索しアクションを実行することが可能です。
IPフィルターアクションで遮断する場合は、被疑端末の指定も遮断動作もIPアドレスにもとづいて行われるためMACアドレスの学習が不要です。したがって、上記のAMF非対応のL3スイッチが配置された環境であってもDHCP Snooping機能の有効/無効にかかわらずエッジノードで遮断可能です。
AT-SESC
AMF機器側の設定とは別に、AT-SESC側でプロキシーノード（AMFマスター）を指定してください。これにより本機能が動作するようになります。
AT-SESCの詳しい使い方については、AT-SESCのリファレンスマニュアルをご覧ください。
ホワイトリスト機能の設定
AT-SESC側で設定した許可端末リスト（ホワイトリスト）にもとづき、特定の端末にのみ通信を許可するホワイトリスト機能を使用するには、プロキシーノード、エッジノードで以下の設定を行います。
ホワイトリスト機能を使用する場合は、AMFネットワーク上のすべてのノードを5.4.9-0.x以降で運用してください。
プロキシーノード
ホワイトリスト機能を使用する場合、プロキシーノードでは下記の設定が必要です。
- AMFアプリケーションプロキシー機能を有効にします。これには、service atmf-application-proxyコマンドを使います。
awplus(config)# service atmf-application-proxy ↓
- プロキシーノードとして AMF Cloud を使う場合は、service httpコマンドでWebサーバー機能を有効にしてください。
awplus(config)# service http ↓
プロキシーノードに対応するその他の製品では初期状態でWebサーバー機能が有効になっていますが、もし無効化している場合は同様に有効化してください。
- AMFとGUIの連携機能を有効化します。これには、atmf topology-gui enableコマンドを使います。
AT-Vista Manager EXやAT-SESC上で遮断情報を確認したり、AT-SESC上でホワイトリスト機能による認証結果を確認するには、プロキシーノードでAMF・GUI連携機能（atmf topology-gui enable）を有効にしておく必要があります。
awplus(config)# atmf topology-gui enable ↓
- 許可端末リスト（ホワイトリスト）を保持しているAT-SESCサーバー（ホワイトリストサーバー）のIPv4アドレスと事前共有鍵を指定します。これには、application-proxy whitelist serverコマンドを使います。
これにより、プロキシーノードはエッジノードからの通信可否問い合わせ要求をAT-SESCに中継できるようになります。
awplus(config)# application-proxy whitelist server 192.168.1.5 key 1iMe2W0dA4oN! ↓
ホワイトリストサーバーの設定は1台のAMFマスターにだけ行ってください。複数のマスターに設定することはサポート対象外です。
プロキシーノードをエッジノードとしても使用する場合（プロキシーノード上で遮断動作も行う場合）は、端末接続ポートに対し、次に述べるエッジノードの設定を追加してください。
■ ホワイトリスト機能の設定はshow application-proxy whitelist serverコマンドで確認できます。
awplus# show application-proxy whitelist server ↓
エッジノード
ホワイトリスト機能を使用するエッジノードでは、下記の設定が必要です。
- AMFアプリケーションプロキシー機能を有効にします。これには、service atmf-application-proxyコマンドを使います。
awplus(config)# service atmf-application-proxy ↓
- 端末接続ポートでホワイトリスト機能を有効化し、同ポートをホワイトリストポートに設定します。これには、application-proxy whitelist enableコマンドを使います。
これにより、エッジノードは該当ポートに接続された端末の通信可否をプロキシーノード経由でAT-SESCに問い合わせ、許可された端末からの通信だけを通過させるようになります。
awplus(config)# interface port1.0.2-1.0.12 ↓
awplus(config-if)# application-proxy whitelist enable ↓
同一ポート上においてホワイトリスト機能とMACベース認証は併用できません。同一ポート上でホワイトリスト機能とWeb認証、802.1X認証は併用可能です。また、ホワイトリストポート以外のポートであれば、同一装置上でMACベース認証を使用することは可能です。
ホワイトリストポートでは「隔離」アクションを併用できません。他のアクションは併用可能です。ホワイトリストで許可された端末であっても、他の遮断アクションの対象となった場合、該当端末からの通信はブロックされます。
ホワイトリスト機能はMACベース認証の仕組みを使用しているため、MACベース認証でサポートされているオプションやパラメーターはホワイトリスト機能にも適用されます。
- ホワイトリストサーバー側の設定や運用方法にあわせ、ホワイトリストポートに対して必要な追加設定を行います。
- ホワイトリストサーバーでスケジュール認証を使用する場合は、ホワイトリストポートにauth session-timeoutコマンドを設定してください。
同コマンドが有効に設定されている場合、端末の通信が許可されてから、ホワイトリストサーバー側で設定した「セッションタイムアウト」時間が経過すると、通信許可が取り消されます。
awplus(config-if)# auth session-timeout ↓
- ホワイトリストポート配下に複数の端末を接続する場合は、各端末の通信可否を個別に問い合わせるためauth host-modeコマンドでMulti-Supplicantモードに設定します。
awplus(config-if)# auth host-mode multi-supplicant ↓
- ホワイトリストサーバー側の設定にもとづいて通信許可端末の所属VLAN（ネットワーク）を動的に変更するには、ホワイトリストポートでダイナミックVLAN（auth dynamic-vlan-creationコマンド）を有効にします。
ホワイトリストポート配下に複数の端末を接続し、個別にVLANを割り当てるには、次のように「type multi」でマルチプルダイナミックVLAN（サポートしている機種のみ）を有効にしてください。
awplus(config-if)# auth dynamic-vlan-creation type multi ↓
ダイナミックVLANが有効でも、ホワイトリストサーバーで通信許可端末の所属VLANが設定されていない、または値「0」が設定されている場合、ホワイトリストポートに設定されたVLANが使用されます。
ダイナミックVLANが無効の場合、ホワイトリストサーバー側で指定した所属VLANは使用されず、ホワイトリストポートに設定されたVLANが使用されます。
■ 端末の通信可否をホワイトリストサーバーに問い合わせるときに、該当端末のMACアドレス、エッジノード名、ポート番号に加え、エッジノードのIPv4アドレスを問い合わせに含めるには、通知したいIPv4アドレスが設定されているエッジノードのIPインターフェースをapplication-proxy whitelist advertised-addressコマンドで指定します。
たとえば、あるエッジノードにおいて、vlan10のIPv4アドレスを通信可否の問い合わせに含めたい場合は次のように設定します。
awplus(config)# application-proxy whitelist advertised-address vlan10 ↓
■ ホワイトリストポートの一覧はshow application-proxy whitelist interfaceコマンドで確認できます。
awplus# show application-proxy whitelist interface ↓
■ ホワイトリストポートで許可された端末の一覧はshow application-proxy whitelist supplicantコマンドで確認できます。
awplus# show application-proxy whitelist supplicant ↓
AT-SESC
AMF機器側の設定とは別に、AT-SESC側で許可端末リスト（ホワイトリスト）を設定してください。これにより本機能が動作するようになります。
AT-SESCの詳しい使い方については、AT-SESCのリファレンスマニュアルをご覧ください。
プロキシーノード・ホワイトリストサーバー間の通信暗号化
ファームウェアバージョン5.4.9-1.x以降では、ホワイトリスト機能使用時にプロキシーノード・ホワイトリストサーバー（AT-SESC）間の通信（コントロールセッション）を暗号化できるようになりました。
コントロールセッションを暗号化する場合は、AMFネットワーク上のすべてのノードを5.4.9-1.x以降で運用してください。
■ 暗号化に必要なもの
コントロールセッションを暗号化する場合、プロキシーノード、ホワイトリストサーバー（AT-SESC）にそれぞれ以下のものが必要です。
- プロキシーノード
- 暗号化に対応したバージョン
- 1. 外部CAの証明書（ルートCA証明書）
- 2. クライアント証明書 ※1のルートCA証明書で検証できること
- 3. クライアント秘密鍵
プロキシーノードのクライアント秘密鍵はAMFバックアップの対象になりません。そのため、プロキシーノードのリカバリーを行うと秘密鍵が削除され、ホワイトリスト機能が使用できなくなります。その場合は、以下の「プロキシーノードの設定」にしたがい、トラストポイントを再設定してください。
- ホワイトリストサーバー
- 暗号化に対応したバージョン
- 4. サーバー証明書 ※1のルートCA証明書で検証できること
- 5. サーバー秘密鍵
本マニュアル執筆時点では、ホワイトリストサーバー（AT-SESC）は本製品のクライアント証明書を検証せず、コントロールセッションの暗号化にのみ使用します。そのため、ホワイトリストサーバー側には、本製品のクライアント証明書を検証するためのルートCA証明書は必要ありません。
ただし、この仕様はホワイトリストサーバーのバージョンアップにより変更される可能性があります。詳細はホワイトリストサーバーのドキュメントでご確認ください。
コントロールセッションの暗号化はデフォルト無効です。
暗号化を使用するには、プロキシーノード、ホワイトリストサーバーにそれぞれ以下の設定を行ってください。
■ あらかじめ用意するもの
設定開始前に下記のファイルを用意してください。ファイル形式はいずれもPEM（Privacy Enhanced Mail）です。
表中の番号は前記「暗号化に必要なもの」と対応しています。
「2. クライアント証明書」と「3. クライアント秘密鍵」はプロキシーノードの設定中に生成、発行するため、設定開始時点では不要です。
| |
説明 |
以下の説明における例示用ファイル名 |
| 1 |
外部CAの証明書（ルートCA証明書） |
ca_cert.pem |
| 4 |
ホワイトリストサーバーの証明書（サーバー証明書） |
server_cert.pem |
| 5 |
ホワイトリストサーバーの秘密鍵（サーバー秘密鍵） |
server_key.pem |
■ プロキシーノードの設定
- 外部CAの証明書ファイル（本例ではca_cert.pem）をプロキシーノードのフラッシュメモリーにコピーします。
- 暗号化に必要な証明書と鍵を保存するためのトラストポイント（ここでは例として「whitelist」という名前を使います）を作成し、外部CAの証明書をインポートします。
これには、crypto pki trustpoint、enrollment、crypto pki import pemコマンドを使います。
証明書の情報が表示されたら、内容を確認し、「Accept this certificate?」に「y」で答えてください。
awplus(config)# crypto pki trustpoint whitelist ↓
Created trustpoint "whitelist".
awplus(ca-trustpoint)# enrollment terminal ↓
awplus(ca-trustpoint)# end ↓
awplus# crypto pki import whitelist pem ca_cert.pem ↓
...
Accept this certificate? (y/n): y ↓
The certificate was successfully imported.
- プロキシーノードの公開鍵ペア（秘密鍵と公開鍵）を生成し、公開鍵証明書の署名要求（CSR）を生成します。
crypto pki enrollコマンドを実行すると、次のようにCSRの内容が出力されるので、-----BEGIN CERTIFICATE REQUEST----- の行から-----END CERTIFICATE REQUETS----- の行までをクリップボードにコピーしてPC上のファイル（ここでは「client_csr.pem」とします）に保存してください。
awplus# crypto pki enroll whitelist ↓
Generating 2048-bit key "server-default"...
Cut and paste this request to the certificate authority:
-----------------------------------------------------------------
-----BEGIN CERTIFICATE REQUEST-----
MIIC0zCCAbsCAQAwQzEYMBYGA1UECgwPQWxsaWVkV2FyZSBQbHVzMScwJQYDVQQD
DB5hd3BsdXMudHcuYWxsaWVkLXRlbGVzaXMuY28uanAwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDP7yYzo7SRJeLLcoVpfJ8R0BhnotIDhkOS2X9t6tt5
KeiS7CZlw3rBZ9XblL4Wk0c8KdAFZAQ7LU5KMchcyRoUq4HpKcy2cO5KD1dReU27
G6OyHiuhTdDb7g5GeR3/Gn7wec398WmqHEZpqxMfjWDgE6GcLGq1kbYjnhyezIiB
ivgfM+FWKkQao7hMFap4EnION/4Qi1rLG1y4ji+SBaqMaTrpIjmJajFMtrSDWhZP
371fJ04lTA9EPaLoP5QlcIRXsK/MzTv99Ifa3I5uMOogqm6Lf0HuUusNg13OUFlu
gcfB8FwgGGdAjhK3dAj5XywrP8urfKkjvYjolq4UKePvAgMBAAGgSzBJBgkqhkiG
9w0BCQ4xPDA6MAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAIMrupXUp/f18
jgIs/mcrlkevV6YE34MGX+KP8pJyQ2mNW/3zorb4L5tc6xzZr9OvtSs4FSuaUeOB
YTEMP6v/B5aBTh3csevol97DQnl/QDT5PjVkrhsO3zKqtzasV/9ozG0m/s28xRoE
4v1wQtdvBqNyxDXTZSFiR2Qu+8RInA5TvjfI/pCjVsyQggpD9i6UWICOWDwi9M9U
A6Q9vTgASeejX1ac1ZERGFYUG0BzO/gwm8zjnXxBRA1i5LcL4C7JEU9jgtUbzVln
lFcuC5jQJrT8a8J9ZCLomQasatQoXtp2xJz1cJXAkD+Cwg92AbQqFwzqxqF/ZBr8
IKvYIzscHQ==
-----END CERTIFICATE REQUEST-----
-----------------------------------------------------------------
- 前の手順でPC上に保存したCSRファイル（本例ではclient_csr.pem）を外部CAに渡し、クライアント証明書の発行を依頼してください。
ここでは、外部CAが発行したクライアント証明書を client_cert.pem という名前のファイルとして入手したものと仮定します。
- 外部CAによって発行されたクライアント証明書ファイル（本例ではclient_cert.pem）をプロキシーノードのフラッシュメモリーにコピーします。
- 作成済みのトラストポイント「whitelist」にプロキシーノードのクライアント証明書をインポートします。
これにはcrypto pki import pemコマンドを使います。
証明書の情報が表示されたら、内容を確認し、「Accept this certificate?」に「y」で答えてください。
awplus# crypto pki import whitelist pem client_cert.pem ↓
...
Accept this certificate? (y/n): y ↓
The certificate was successfully imported.
- コントロールセッションを暗号化する場合、application-proxy whitelist serverコマンドでホワイトリストサーバーを登録するときに、認証用ポート（auth-port）として「2083」を明示的に指定する必要があります。
awplus(config)# application-proxy whitelist server 192.168.1.5 key 1iMe2W0dA4oN! auth-port 2083 ↓
- 暗号化に使用する証明書一式（ルートCA証明書、クライアント証明書・秘密鍵）をトラストポイント名「whitelist」で指定します。
awplus(config)# application-proxy whitelist trustpoint whitelist ↓
プロキシーノード側の設定は以上です。
■ ホワイトリストサーバーの設定
- ホワイトリストサーバー（AT-SESC）にサーバー証明書とサーバー秘密鍵をアップロードします。
具体的には、「AMF設定」ページの「AMF アプリケーションプロキシー 設定」＞「SSL証明書」セクションの「SSL証明書のアップロード」ボタンで「SSL証明書のアップロード」ダイアログを開き、サーバー証明書（本例ではserver_cert.pem）と秘密鍵（server_key.pem）をアップロードしてください。
本マニュアル執筆時点では、ホワイトリストサーバー（AT-SESC）は本製品のクライアント証明書を検証せず、コントロールセッションの暗号化にのみ使用します。そのため、ホワイトリストサーバー側には、本製品のクライアント証明書を検証するためのルートCA証明書は必要ありません。
ただし、この仕様はホワイトリストサーバーのバージョンアップにより変更される可能性があります。詳細はホワイトリストサーバーのドキュメントでご確認ください。
詳細についてはAT-SESCのドキュメントをご覧ください。
■ 暗号化通信の確認
プロキシーノード上でshow application-proxy whitelist serverコマンドを実行し、「TLS Status」が「Alive」になっていれば暗号化が行われています。
awplus# show application-proxy whitelist server ↓
Application Proxy Whitelist Details:
External Server Details:
IP: 192.168.1.5
Port: 2083
Trustpoint: whitelist
TLS Status: Alive
Proxy Details:
IP: 172.31.0.139
Status: Unknown
その他
■ 本機能によって遮断されている端末（アドレス）の情報はshow application-proxy threat-protectionコマンドで確認できます。
awplus# show application-proxy threat-protection ↓
AT-SESCの「ポリシー設定」/「アクション一覧」画面でも遮断されている端末の情報を確認することができます。詳細についてはAT-SESCのリファレンスマニュアルをご覧ください。
■ 本機能による遮断を解除するにはclear application-proxy threat-protectionコマンドを使います。
awplus# clear application-proxy threat-protection 10.1.2.34 ↓
遮断の解除は基本的にAT-SESC側で実施します。上記コマンドによりAMFマスター側で遮断を解除することもできますが、その場合、AMFマスターからAT-SESCに被疑端末情報を削除する指示は出しません。そのため、AT-SESC上では被疑端末情報を保持したままになりますので、必要に応じてAT-SESC側で該当アクションを削除してください。詳細についてはAT-SESCのリファレンスマニュアルをご覧ください。
■ 本機能を無効化するには、service atmf-application-proxyコマンドをno形式で実行します。
awplus# no service atmf-application-proxy ↓
- プロキシーノード（AMFマスター）で本機能を無効化した場合は、すべてのアドレスの遮断が解除されます。
- エッジノード（AMFメンバー）で本機能を無効化した場合は、該当ノードにおけるアドレスの遮断だけが解除されます。
機器交換および機器再起動時の被疑端末情報の扱われ方
- AMFマスターの再起動 （reboot/reloadコマンド、電源オフ/オン）
被疑端末の情報を保持しているAMFマスターが再起動した場合、被疑端末の情報はAMFマスターから削除されます。
このとき AMFメンバーは被疑端末の情報を保持した状態のまま変わりありません。
再起動後AT-SESCからこの被疑端末の情報の再通知はないため、被疑端末の情報を学習することはできません。
AMFマスターに被疑端末の情報を学習させるためには、AT-SESCから手動で被疑端末の情報を通知してください。
- AMFメンバーの再起動 （reboot/reloadコマンド、電源オフ/オン）
被疑端末の情報を保持しているAMFメンバーが再起動した場合、被疑端末の情報はAMFメンバーから削除されます。
このとき AMFマスターは被疑端末の情報を保持した状態のまま変わりありません。
再起動後AMFノードのAMF参加を検知したAMFマスターから被疑端末の情報が再送信されるため、AMFメンバーは被疑端末の情報を学習することができます。
AMFセキュアモード
AMFセキュアモードは、ファームウェアバージョン5.4.7-1.1から導入されたAMFの新しい動作モードです。
機能
このモードでは以下の機能を提供します。
- AMFネットワークへの接続時認証
AMFネットワークに接続するノードの認証を必須とし、認証を受けていないノードがAMFネットワークに接続できないようにします。
- AMFメンバーはAMFマスター（コントローラーネットワークでは所属エリアのローカルマスター）の認証を受ける必要があります。
- コントローラーネットワークにおけるローカルマスターはコントローラーの認証を、コントローラーはローカルマスターの認証を受ける必要があります。
- AMFパケットの暗号化
AMFネットワーク上で送受信されるパケットを暗号化することで、セキュリティーを高め、DoS（サービス妨害）などの攻撃を受ける可能性を低減します。
- ログによる監視
AMFノードの認証結果などをログに記録することで、AMFネットワーク上のセキュリティー関連イベントを監視できるようにします。
- アクセス制御の強化
ワーキングセットとリモートログインの操作をAMFマスターからだけに限定します（セキュアモード時にはatmf restricted-loginが強制的に有効になります）。
以降の説明では、新規導入されたモードを「セキュアモード」、従来からあるモードを「非セキュアモード」と記述します。
制限
セキュアモード時は、非セキュアモードと比べ、以下の制限があります。
- 1つのAMFネットワークに所属できるノード（マスター、メンバー）の最大数が126台までに制限されます。
- AMFネットワーク内の全ノードをセキュアモードにする必要があります。非セキュアモードのノードはセキュアモードのネットワークに接続できません。
これはAMFコントローラーを使用する構成でも同じです。一部のエリアだけ非セキュアモードで運用することはできません。
- AMFコントローラーを使用する場合、コントローラーとコントローラーエリアのローカルマスターは同じ装置で実行する必要があります。
- 手動リカバリーはサポートされません。
- ゲストノード、エージェントノードのバックアップおよびリストアはサポートされません。
- AMFネットワーク上におけるAMFノード間でのファイルコピーはサポートされません。
注意事項
セキュアモード時に特に注意すべき点について説明します。
- AMFマスターライセンス
セキュアモードを使用するには、AMFマスターとAMFコントローラーにAMFマスターライセンスが必要です。
- AMFマスターの二重化
セキュアモードでは、AMFマスターがAMFノードの認証を行う関係上、AMFマスターの二重化がより一層重要になります。
セキュアモードのAMFネットワークでAMFマスターがダウンした場合、マスターを代替機と交換することになりますが、旧マスターが発行した証明書（認証情報）は無効になるため、旧マスターが発行した証明書をすべてのノードから手動でクリアする必要があり、また、新マスターで全ノードを認証しなおす必要が生じるためです。
このような事態を避けるため、AMFセキュアモード使用時はなるべくAMFマスターを二重化することをおすすめします。その方法については、「AMFマスターの二重化」をご覧ください。
AMF Cloudを二重化する場合は仮想クロスリンク（atmf virtual-crosslink）を使います。
なお、マスターの二重化が行えない場合は、代替策としてAMFマスターをVCS構成で運用する方法もあります。
- バックアップ
AMFバックアップは、取得時と同じモードで動作しているノードにしかリストアできません。
すなわち、
- 非セキュアモードで取得したバックアップは、非セキュアモードのノードにのみリストア可能
- セキュアモードで取得したバックアップは、セキュアモードのノードにのみリストア可能
となります。
非セキュアモードからセキュアモード、またはセキュアモードから非セキュアモードに切り替えたときは、ただちにフルバックアップを実行することをおすすめします。
- オートリカバリー
- セキュアモードでオートリカバリーのプロセスが開始されるための条件は次のとおりです。
- 代替機の起動ファームウェアバージョンがセキュアモードをサポートしている5.4.7-1.1以降であること
- バックアップされているファームウェアのバージョンがセキュアモードをサポートしている5.4.7-1.1以降であること
- 交換前の機器がセキュアモードに設定されていたこと
なお前記条件を満たす場合でも、通常はオートリカバリーの途中で代替機の認証（マスターのCLIからatmf authorizeを実行する）が必要になるため、手動による作業は避けられません。
ただし、管理者がAMFマスターからコマンドを実行し、あらかじめ代替機を認証しておけば、セキュアモードでも交換時のオートリカバリーが可能です。詳細は「代替機の事前認証」をご覧ください。
- 仮想リンク経由で接続しているAMFノードのオートリカバリーに関しては、運用編の「仮想リンク経由で接続しているAMFノードのオートリカバリー」をご覧ください。
- AMFエリアのパスワード
セキュアモードでは、AMFエリアのパスワード設定（atmf area password）は不要です。
設定と運用
既存AMFネットワークをセキュアモードに移行する
ここでは、すでに運用中のAMFネットワークをセキュアモードに移行する方法を説明します。
■ 全ノードを一括でセキュアモードに移行するには、マスターでatmf secure-mode enable-allコマンドを実行します。
確認のプロンプトが出るので、移行を進めるなら「y」を、キャンセルするなら「n」を入力してください。
SBx81a# atmf secure-mode enable-all ↓
Total number of nodes 3
3 nodes support secure-mode
Enable secure-mode across the AMF network ? (y/n): y ↓
...
02:23:08 SBx81a IMISH[5068]: All 3 compatible nodes have joined the secure mode network.
同コマンドを実行すると、既存ノードがいったんAMFネットワークから離脱したのち、すべてのノードに対して事前認証（atmf authorize provision）の処理が自動的に行われ、その後各ノードがセキュアモードでAMFネットワークに再加入してセキュアモードへの移行が完了します。
移行状況はshow atmfコマンドで確認できます。
SBx81a# show atmf ↓
ATMF Summary Information:
ATMF Status : Enabled
Network Name : AMF001
Node Name : SBx81a
Role : Master
Restricted login : Enabled
Secure Mode : Enabled
Current ATMF Guests : 0
Current ATMF Nodes : 3
■ セキュアモードから非セキュアモードに移行するには、マスターからatmf secure-mode enable-allコマンドをno形式で実行します。
SBx81a# no atmf secure-mode enable-all ↓
セキュアモードのAMFネットワークに機器を追加する
セキュアモードのAMFネットワークに新しい機器を追加接続するには、次の手順を実行します。
なお以下では、新しい機器と接続先の機器の両方に、新規AMFノードを追加するための基本的な設定が完了しているものと仮定しています。
AMF機器の追加方法については、運用編をご覧ください。
- 新しいAMFノードでセキュアモードを有効にします。これには、atmf secure-modeコマンドを使います。
FSW235(config)# atmf secure-mode ↓
FSW235(config)# end ↓
FSW235# write ↓
セキュアモードの新ノードがAMFネットワークに物理的に接続されると、AMFマスターのCLI上に新しいノードが認証を求めていることを示すログメッセージが表示されます。
03:06:33 SBx81a ATMF[749]: Node FSW235 (area:other_area) [eccd.6db5.1045] - requests authorization
また、AMFマスターからshow atmf authorization pendingコマンドを実行することで、認証待ちのノード一覧を見ることもできます。
SBx81a# show atmf authorization pending ↓
Pending Authorizations:
other_area Requests:
Node Name Product Parent Node Interface
------------------------------------------------------------------------------
FSW231 x510L-28GT SBx81a port1.0.3
FSW232 x510L-28GT SBx81a sa1
FSW235 x310-26FT SBx81a port1.0.1
- AMFマスターで新しいAMFノードを認証します。これには、atmf authorizeコマンドを使います。
SBx81a# atmf authorize FSW235 ↓
03:10:28 SBx81a ATMF[749]: FSW235 has joined. 4 members in total.
代替機の事前認証
セキュアモードでも、オートリカバリー のプロセスは開始されますが、リカバリー完了前に代替機の認証（マスターのCLIからatmf authorizeコマンドを実行する）が必要になるため、通常は手動操作が必要となります。
ただし、以下の方法により代替機の事前認証を行えば、セキュアモードでもオートリカバリーが可能です。
代替機をAMFネットワークに接続することなく、代替機のMACアドレスや、代替機を接続予定の既存AMFノードのポートを指定して事前認証を行うには、atmf authorize provisionコマンドを使います。
■ MACアドレスを指定して代替機を事前認証するには次のようにします。
SBx81a# atmf authorize provision mac 0000.1111.2222 ↓
これにより、MACアドレス「0000.1111.2222」を持つクリーン状態の代替機をAMFネットワークに接続した場合は、認証なしでオートリカバリーが完了します。
■ 接続先となる既存AMFノード（FSW234）のポートを指定して代替機を事前認証するには次のようにします。
SBx81a# atmf authorize provision node FSW234 interface port1.0.8 ↓
これにより、既存AMFノード（FSW234）の port1.0.8 にクリーン状態の代替機を接続した場合は、認証なしでオートリカバリーが完了します。
事前認証には有効期間があるため、代替機の接続はその期限内に行う必要があります（デフォルト60分）。期限を過ぎた場合は代替機の再認証が必要です。有効期間は atmf authorize provisionコマンド の timeoutオプションにより 1～6000分の範囲で指定可能です。
状態確認
■ セキュアモードの有効・無効などの基本的な情報はshow atmfコマンドで確認できます。
FSW234# show atmf ↓
■ セキュアモードのステータスはshow atmf secure-modeコマンドで確認できます。
SBx81a# show atmf secure-mode ↓
■ 認証待ちノードの一覧を見るには、AMFマスター上でshow atmf authorization pendingコマンドを実行します。
SBx81a# show atmf authorization pending ↓
■ 認証済みノードの一覧を見るには、AMFマスター上でshow atmf authorization currentコマンドを実行します。
SBx81a# show atmf authorization current ↓
■ 隣接ノードのAMF接続ポートに物理的に接続したものの、未認証のためAMFネットワークに接続できていないノードはshow atmf linksコマンドで確認できます。該当ノードはリンク状態が「OneWaySm」になります。
SBx81a# show atmf links ↓
(C) 2015 - 2019 アライドテレシスホールディングス株式会社
PN: 613-002107 Rev.AA