このページの内容
付録:Day 1 導入
WANルーターのインストール
この章では、ジュニパー Mist クラウドによっても管理されるジュニパー WANルーターの設定例を共有します。このようなソリューションは、支社/拠点にあるすべてのネットワークデバイスを一元的に管理できるため、「フルスタック」ソリューションと呼ばれます。これらのデバイスは、SSRベースまたはSRXベースのいずれかです。
Juniper Mist Cloudが管理するWANルーターとしてのジュニパーSSR
SSR向けのWANエッジ専用のJVDが少し前に公開されていたため、SSR WANルーターを使用したテストはこのJVDには含まれていません。SSR WANルーターとブランチEXシリーズスイッチの統合については、以前のテストプロセスですでに説明していました。
このドキュメントの「SSR上のWANエッジ向けJVD」または「SRX」セクションを参照し、以下の必要な変更点に注意してください。
- SSRルーターをインストールするために特別なAppIDライセンスは必要ありません。これは、SRXシリーズファイアウォールでのみ必要です。
- ジュニパーネットワークスSSR®シリーズルーターは、LAGインターフェイス(リリースV6.2.0以降)と、リリースV6.3.0以降で推奨されるLACPの「フォースアップ」オプションをサポートしています。LAGを構築する場合とスイッチの帯域内管理が必要な場合の両方を使用することが推奨されているため、 導入リリースV6.3.0以降を開始することをご検討ください。
- SSRルーターは、複数のスタンドアロンインターフェイスまたは複数のLAG間でのVLANの共有をサポートしていません。SRX3xxシリーズファイアウォールとは異なり、ネットワーク設計時にこの制限を考慮するか、必要なVLAN構造に対応するために分散型スイッチを使用する必要があります。特に、アクセスポイントのローカルブリッジングがブレイクアウトトラフィックに使用されるシナリオで、無線クライアントローミングをサポートする場合は、VLANがブランチアクセススイッチにどのように配布されるかを確認することが重要です。
- アプリケーションポリシーを適用する際、SRXシリーズファイアウォールに必要なように、LANへのトラフィックステアリングを設定しないでください。SSRルーターについては、 表1 を以下のように実装してください。
| シリアル番号 | ルール名 | ネットワーク | アクション | 宛先 | ステアリング |
|---|---|---|---|---|---|
| 1 | Inside_Branch_hairpin | VLAN1033、VLAN1099、VLAN1088 | 通る | 支社/拠点VLAN | 該当なし |
| 2 | インターネット | VLAN1033、VLAN1099、VLAN1088 | 通る | 任意 | WAN |
- SSRをサイトに割り当てる際に、設定管理を直接有効にする必要があります。
Juniper Mist Cloudが管理するWANルーターとしてのジュニパーSRX
SRXシリーズファイアウォールにAppIDライセンスがあることを確認しないと、ジュニパー Mist クラウドで管理できません。これは、スタンドアロンのファイアウォールとして使用するか、VPNを管理するSD-WANルーターとして使用するかには依存しません。
以下の例では、スタンドアロンのWANルーターとスタンドアロンのEXシリーズスイッチと、LAGインターフェイスを介してスイッチのインバンド管理を備えたシンプルなブランチを確立するための最小要件を共有しています。EXシリーズスイッチをバーチャルシャーシを構成するか、WANルーターを高可用性クラスターペアを構成することで、これを拡張できます。残念ながら、ここでは考えられるすべての順列を説明することはできないので、基本のみを取り上げます。
設計にWANルーターからアクセススイッチに向かう複数のLAGがある場合は、次のオプションがあります。1.ジュニパーSRX 3xxシリーズファイアウォールを使用する場合、VLANを複数のLAG間で共有できます。この設定では、ジュニパー Mist クラウドは、この機能をサポートするように IRB インターフェイスを自動的に設定できます2。ジュニパーSRX 1500シリーズファイアウォール以上を使用する場合は、LAGごとに一意のVLANセットを定義するか、クラスターモードで高可用性設定でディストリビューションレイヤーアーキテクチャを利用する必要があります。
組織>アプリケーションに移動し、以下の設定を持つ既存のアプリケーションがあることを確認します。
- 名前=
any - タイプ=
Custom Apps - IPアドレス=
0.0.0.0/0
以下の設定で別のアプリケーションを追加します。
- 名前=
Branch-VLANs - タイプ=
Custom Apps - IPアドレス=
10.0.0.0/8
以下に示すように、2つのアプリケーションが表示されます。
組織>ネットワークに移動し、最初のVLANを追加します。
- 名前=
VLAN1033 - サブネットIPアドレス=
10.33.33.0 - プレフィックス長=
24 - VLAN ID=このフィールドは空白のままにしてください。これは、接続されたEXシリーズスイッチとAPのインバンド管理に使用されるネイティブVLANです。
- Mist Cloud=
Enabledへのアクセス。接続されたスイッチとAPがジュニパーMistクラウドで管理されるには、この機能を有効にする必要があります。
次に、2 番目の VLAN を追加します(このトポロジーでは、これを有線クライアントに使用します)。
- 名前=
VLAN1099 - サブネットIPアドレス=
10.99.99.0 - プレフィックス長=
24 - VLAN ID =
1099
次に、3つ目のVLANを追加します(このトポロジーでは、AP経由で接続された無線クライアントに使用します)
- 名前=
VLAN1088 - サブネットIPアドレス=
10.88.88.0 - プレフィックス長=
24 - VLAN ID =
1088
3つのネットワークを確認し、スイッチとAP管理ネットワークにVLAN IDが設定されていないことを確認します。これはダウンリンクトランク上のネイティブVLANであるためです。
次のJSONテンプレートを使用して、支社/拠点のWANルーターを設定できます。または、支社/拠点 WAN ルーターの手動設定手順は、JSON テンプレートの直後に記載されています。
{
"type": "standalone",
"port_config": {
"ge-0/0/0": {
"usage": "wan",
"name": "wan",
"ip_config": {
"type": "dhcp"
}
},
"ge-0/0/15": {
"usage": "wan",
"name": "wan2",
"ip_config": {
"type": "dhcp"
}
},
"cl-1/0/0": {
"usage": "wan",
"name": "lte",
"wan_type": "lte",
"ip_config": {
"type": "dhcp"
}
},
"ge-0/0/5-6": {
"usage": "lan",
"aggregated": true,
"ae_disable_lacp": false,
"ae_lacp_force_up": true,
"ae_idx": 0,
"redundant": false,
"critical": false,
"disabled": false,
"networks": [
"VLAN1033",
"VLAN1099",
"VLAN1088"
]
}
},
"ip_configs": {
"VLAN1033": {
"type": "static",
"ip": "10.33.33.1",
"netmask": "/24"
},
"VLAN1099": {
"type": "static",
"ip": "10.99.99.1",
"netmask": "/24"
},
"VLAN1088": {
"type": "static",
"ip": "10.88.88.1",
"netmask": "/24"
}
},
"dhcpd_config": {
"VLAN1033": {
"type": "local",
"ip_start": "10.33.33.10",
"ip_end": "10.33.33.250",
"gateway": "10.33.33.1",
"dns_servers": [
"8.8.8.8",
"9.9.9.9"
],
"options": {}
},
"VLAN1099": {
"type": "local",
"ip_start": "10.99.99.10",
"ip_end": "10.99.99.250",
"gateway": "10.99.99.1",
"dns_servers": [
"8.8.8.8",
"9.9.9.9"
],
"options": {}
},
"VLAN1088": {
"type": "local",
"ip_start": "10.88.88.10",
"ip_end": "10.88.88.250",
"gateway": "10.88.88.1",
"dns_servers": [
"8.8.8.8",
"9.9.9.9"
],
"options": {}
}
},
"path_preferences": {
"wan": {
"paths": [
{
"type": "wan",
"name": "wan"
}
]
},
"LAN": {
"strategy": "ordered",
"paths": [
{
"type": "local",
"networks": [
"VLAN1033"
]
},
{
"type": "local",
"networks": [
"VLAN1099"
]
},
{
"type": "local",
"networks": [
"VLAN1088"
]
}
]
}
},
"service_policies": [
{
"name": "inside_Branch_hairpin",
"tenants": [
"VLAN1033",
"VLAN1088",
"VLAN1099"
],
"services": [
"Branch-VLANs"
],
"action": "allow",
"path_preference": "LAN",
"idp": {
"enabled": false
}
},
{
"name": "Internet",
"tenants": [
"VLAN1033",
"VLAN1099",
"VLAN1088"
],
"services": [
"any"
],
"action": "allow",
"path_preference": "wan",
"idp": {
"enabled": false
}
}
],
"bgp_config": {},
"routing_policies": {},
"extra_routes": {},
"vrf_instances": {},
"tunnel_configs": {},
"oob_ip_config": {
"type": "dhcp",
"node1": {
"type": "dhcp"
}
},
"ntp_servers": [
"time.google.com"
],
"dns_servers": [
"8.8.8.8",
"9.9.9.9"
],
"tunnel_provider_options": {
"jse": {},
"zscaler": {}
},
"additional_config_cmds": [
"set security zones security-zone VLAN1033 host-inbound-traffic system-services ping",
"set security zones security-zone VLAN1099 host-inbound-traffic system-services ping",
"set security zones security-zone VLAN1088 host-inbound-traffic system-services ping"
],
"name": "Branch-WAN-Router"
}
JSONテンプレートを使用しない場合は、代わりに以下の手順を実行してブランチWANルーターを設定します。
Organization > WAN Edge テンプレートに移動します。
以下のパラメーターを使用して新しいテンプレートを作成します。
- 名前=
Branch-WAN-Router - タイプ=
Standalone - デバイスモデルから作成=
Checked - モデル=
<Select your Model>
テンプレートを作成したら、以下のような環境に基づいた基本的な構成設定から始めます。
- NTP=
time.google.com - DNSサーバー=
8.8.8.8, 9.9.9.9
テンプレートを確認すると、以下の事前設定済みのWANインターフェイスが表示されます。「wan」ge-0/0/0インターフェイスを使用して、ブロードバンドルーターからDHCPリースを取得します。
このテンプレートの LAN インターフェイスを変更します。事前設定された「lan」インターフェイスを削除します(ここには表示されていません)。
次に、次のIP設定で最初のLANネットワーク(デバイス管理用にネイティブ)を作成します。
- ネットワーク=
VLAN1033 - IPアドレス=
10.33.33.1 - IPプレフィックス長=
24
以下のDHCP設定で設定します。
- ネットワーク=
VLAN1033 - DHCP=
Server - IP開始=
10.33.33.10 - IPエンド=
10.33.33.250 - ゲートウェイ=
10.33.33.1 - DNSサーバー=
8.8.8.8, 9.9.9.9
次に、次のIP設定で2つ目のLANネットワーク(有線クライアント用にトランク)を作成します。
- ネットワーク=
VLAN1099 - IPアドレス=
10.99.99.1 - IPプレフィックス長=
24
以下のDHCP設定で設定します。
- ネットワーク=
VLAN1099 - DHCP=
Server - IP開始=
10.99.99.10 - IPエンド=
10.99.99.250 - ゲートウェイ=
10.99.99.1 - DNSサーバー=
8.8.8.8, 9.9.9.9
次に、次のIP設定で3つ目のLANネットワーク(無線クライアント用にトランク)を作成します。
- ネットワーク=
VLAN1088 - IPアドレス=
10.88.88.1 - IPプレフィックス長=
24
以下のDHCP設定で設定します。
- ネットワーク=
VLAN1088 - DHCP=
Server - IP開始=
10.88.88.10 - IPエンド=
10.88.88.250 - ゲートウェイ=
10.88.88.1 - DNSサーバー=
8.8.8.8, 9.9.9.9
最後に、LAGとForce-Upオプションを使用してLANインターフェイスを設定し、3つのネットワークをバインドします。
- インターフェイス=
ge-0/0/5-6 - ポートアグリゲーション=
Enabled - LACP=
Uncheckedを無効にします(デフォルト) - フォースアップを有効にする=
Enabled - AEインデックス=
0 - ネットワーク=
VLAN1033とVLAN1099とVLAN1088
最終的な LAN インターフェイス テーブルは、次の図のようになります。
次のステップは、トラフィックステアリングポリシーに新しい宛先を追加することです。これは、この例で実現したいローカルVLAN間の通信を有効にするために必要です。以下の設定を使用して、新しいトラフィックステアリングポリシーを追加します。
- 名前=
LAN - 戦略=
Ordered - パス：
- タイプ=
LAN: VLAN1033 - タイプ=
LAN: VLAN1099 - タイプ=
LAN: VLAN1088
- タイプ=
トラフィックステアリングの宛先に次の情報が表示されます。
デバイスがSRXシリーズファイアウォールである場合のアプリケーションポリシーの表 2 を実装します。修正するだけでよい部品がすでに存在している必要があります。
| シリアル番号 | ルール名 | ネットワーク | アクション | 宛先 | ステアリング |
|---|---|---|---|---|---|
| 1 | Inside_Branch_hairpin | VLAN1033、VLAN1099、VLAN1088 | 通る | 支社/拠点VLAN | LAN |
| 2 | インターネット | VLAN1033、VLAN1099、VLAN1088 | 通る | 任意 | WAN |
上記の表を実装した後、アプリケーションポリシーの次の設定が表示されます。
現在のバージョンでは、ローカルゲートウェイとしてWANルーターにICMP pingを送信するときに、LAN側のクライアントが応答を得ることができません。ただし、ローカルのデバッグでは ping の受信が不可欠です。したがって、Junos OS CLIコマンドを追加して、有線または無線クライアントが接続されているVLANのローカルゲートウェイとしてWANルーターに対してpingできるようにすることを強くお勧めします。以下の例をご覧ください。
set security zones security-zone VLAN1033 host-inbound-traffic system-services ping set security zones security-zone VLAN1099 host-inbound-traffic system-services ping set security zones security-zone VLAN1088 host-inbound-traffic system-services ping
ポータルでは、次の図のようになります。
[ 保存] をクリックしてテンプレートを今すぐ保存します。
このテンプレートにサイトを割り当てる必要があり、そうでない場合はどのデバイスでも使用されません。
ここでは、スイッチが配置されているテンプレートにSpoke1サイトを追加します。
SRXシリーズファイアウォールデバイスをサイトに割り当てるには、デバイスがジュニパー Mistインベントリに存在する必要があります。SRXシリーズファイアウォールを申請または採用して、ジュニパー Mist クラウドにオンボーディングすることができます。デバイスがオンボーディングされると、組織のインベントリにデバイスが表示されます。
SRXシリーズファイアウォールをサイトに割り当てるには:
- ポータルで、 組織>管理>インベントリをクリックします。
- ブラウザを更新し、[ WAN Edges ]で、SRXシリーズファイアウォールがインベントリの一部であるかどうかを確認します。
- サイトに割り当てオプションを使用して、各SRXシリーズファイアウォールを個々のサイトに割り当てます。
- [ WAN エッジの割り当て ] ページで、使用可能なサイトのリストから割り当てるサイトを選択します。
- [ Mistで設定を管理] オプションを選択しないでください。変更すると、SRXシリーズファイアウォールの設定に不要な変更が表示される可能性があります。このオプションは、デバイスをサイトに割り当てた後、必要に応じて後で有効にできます。
- 有効なアプリケーション セキュリティ ライセンスをお持ちの場合は、[ アプリ追跡ライセンスにサイト設定を使用する ] オプションをオンにし、[ サイトへの割り当て] をクリックします。
以下の図は、デバイスをサイトに割り当てた後のインベントリの変更を示しています。
- デバイスがオンボーディングされたら、[ WAN Edges ] タブで [<サイト> を選択し、デバイスをクリックします。
- デバイスと AppSecure の状態を確認します。
- ここで、[ 構成管理を有効にする] をクリックして、最後のステップとしてアクティブ化し、Mistがデバイスを構成できるようにします。
- オプション:ジュニパーMistクラウドがデバイスの管理を引き継いだ後、リモートコンソールを使用してデバイスの設定とステータスを確認します。この例では、以下の出力が表示されます。
root@spoke1> show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0 up up ge-0/0/0.0 up up inet 192.168.173.145/24 . ge-0/0/5 up up ge-0/0/5.0 up up aenet --> ae0.0 ge-0/0/5.1088 up up aenet --> ae0.1088 ge-0/0/5.1099 up up aenet --> ae0.1099 ge-0/0/5.32767 up up aenet --> ae0.32767 ge-0/0/6 up up ge-0/0/6.0 up up aenet --> ae0.0 ge-0/0/6.1088 up up aenet --> ae0.1088 ge-0/0/6.1099 up up aenet --> ae0.1099 ge-0/0/6.32767 up up aenet --> ae0.32767 . ae0 up up ae0.0 up up inet 10.33.33.1/24 ae0.1088 up up inet 10.88.88.1/24 ae0.1099 up up inet 10.99.99.1/24 ae0.32767 up up . root@spoke1> show lacp interfaces Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/5 FUP Actor No No Yes Yes Yes Yes Fast Active ge-0/0/5 FUP Partner No Yes No No Yes Yes Fast Passive ge-0/0/6 Actor No Yes No No No Yes Fast Active ge-0/0/6 Partner No Yes No No No Yes Fast Passive LACP protocol: Receive State Transmit State Mux State ge-0/0/5 FUP Current Fast periodic Collecting distributing ge-0/0/6 Defaulted Fast periodic Detached
EXシリーズスイッチを取り付けて電源を入れるとすぐに、WANルーターからDHCPリースを取得します。これは、以下に示すように確認できます。この例のように、スイッチ上のPhone Homeクライアントがリダイレクトサーバに接続しようとしているのを見ることも時々表示されます。
root@spoke1> show dhcp server binding detail
Client IP Address: 10.33.33.11
Hardware Address: 04:5c:6c:6b:13:42
State: BOUND(LOCAL_SERVER_STATE_BOUND)
Protocol-Used: DHCP
Lease Expires: 2024-03-07 17:02:09 UTC
Lease Expires in: 85474 seconds
Lease Start: 2024-03-06 17:02:09 UTC
Last Packet Received: 2024-03-06 17:02:09 UTC
Incoming Client Interface: ae0.0
Client Interface Vlan Id: 1
Server Identifier: 10.33.33.1
Session Id: 2
Client Pool Name: VLAN1033
root@spoke1> show security flow session source-prefix 10.0.0.0/8
Session ID: 249108247036, Policy name: 01_Internet/20, State: Stand-alone, Timeout: 854, Valid
In: 10.33.33.11/59874 --> 44.231.144.179/443;tcp, Conn Tag: 0x0, If: ae0.0, Pkts: 8, Bytes: 1278,
Out: 44.231.144.179/443 --> 192.168.173.145/8983;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 18, Bytes: 13734,
Total sessions: 1
以下の例は、冗長クラスター構成でのSRXシリーズファイアウォールの使用を示しています。このJVDが作成された時点では、GUIを使用して必要な設定を完全に完了できませんでした。そこで、ハイブリッドなアプローチを採用しました:冗長イーサネットインターフェイスはGUIで設定し、LAGインターフェイスは「フォースアップ」オプション付きで、同じテンプレート内のCLIを介して手動で追加しました。
SRXシャーシクラスター
シャーシクラスターモードでSRXシリーズファイアウォールを使用する場合、LAGを使用すると、2つの冗長クラスターノード間で単一の集合型イーサネットバンドルにまたがることができないため、最低4つのリンクを設定する必要があります。代わりに、各ローカルクラスターノード上に個別の集約イーサネットバンドルを形成し、「reth」インターフェイスと呼ばれる冗長イーサネットインターフェイスを介してそれらをバインドします。 図2にトポロジーの例を示します。
としてのSRXシャーシクラスタージュニパーブランチトポロジー
設定を変更する場合:
- インターフェイスフィールドには、すべてのクラスターノードに分散される4つのインターフェイス名がすべて含まれている必要があります。ノード 1 では、クラスターの構築時にインターフェイス名の名前が常に変更されます。新しいインターフェイス名の正確な内容はデバイス固有で、詳細はこちらで確認できます。
- 既存のLAG設定に冗長インターフェイスオプションを追加する必要があります。
以下の例では、以下の設定を追加しています。
- インターフェイス=
ge-0/0/5-6, ge-5/0/5-6 - 冗長=
Enabled- 冗長インデックス=
1 - 冗長グループ=
empty(デフォルト) - プライマリノード=
Node0
- 冗長インデックス=
クレームおよびZTPベースのインストールによるグリーンフィールドスイッチの有効化
スイッチ専用のQRコードは購入時に設定されます。スイッチはクラウド対応のロゴが入った箱に入って到着し、スイッチの背面のファン排気口とインターフェイスの近くにQRコードが記載されたステッカーが貼られます。
MistAIアプリを使用して、ジュニパー Mistにクラウド対応スイッチを追加するクラウド
手順：
- MistAIアプリをスマートフォンにダウンロードしてインストールします。
- スイッチを開梱し、管理ポートをインターネットに接続して、電源を入れます。ZTPプロセスの一環として、スイッチは自動的にPHCサーバー(または設定されている場合はDHCPサーバー)にアクセスし、構成更新のためにジュニパー Mistクラウドに接続します。
- Webブラウザを使用して、ジュニパー Mistアカウントにログインします。 監視 画面が表示され、ジュニパー Mist クラウドと、すでに接続されているAPとクライアントの概要が表示されます。左側のメニューで、 スイッチ をクリックしてその画面を開きます。ZTPプロセスが解決されると、スイッチが自動的にここに表示されます(Webページを更新しても数分経ってもスイッチが表示されない場合は、ログアウトしてから再度ログインするか、以下のトラブルシューティングセクションに移動して、デバイスがクラウドに接続しているかどうかを確認する方法を確認してください)。
- スイッチがジュニパー Mist クラウドで解決されている間に、スイッチの前面にあるQRコードを見つけます。
- 携帯電話でMistAIアプリを開き、ジュニパー Mist クラウドアカウントにログインします。表示される [AP を組織に要求 ] ボタンをタップします。
- スイッチのQRコードにQRコードビューアを向けます。QR コードに焦点が合うと (つまり、カメラが適切な距離に保持されている場合)、アプリは自動的にデバイスを要求し、ポータル内の組織のインベントリに追加します。
クラウド対応スイッチを Juniper Mist Cloud に手動で追加する
手順：
クラウド対応スイッチを手動で導入するには、スイッチのアクティベーションコードが必要です(これらのコードは、購入時に登録されているアドレスに電子メールで送信されるか、ジュニパー Mist カスタマーエンゲージメントチームに連絡して取得できます)。アクティベーションコードを使用すると、スイッチと注文書に含まれているすべてのジュニパーAPが採用され、購入に含まれるサブスクリプションも請求されます。
- まず、スイッチを開梱し、管理ポートをインターネットに接続し、電源を入れます。ZTPプロセスの一環として、スイッチは自動的にPHCサーバー(または設定されている場合はDHCPサーバー)にアクセスし、構成更新のためにジュニパー Mistクラウドに接続します。
- Webブラウザを使用して、ジュニパー Mistアカウントにログインします。 監視 画面が表示され、ジュニパー Mist クラウドと、すでに接続されているジュニパー AP とクライアントの概要が表示されます。左側のメニューで、 組織>インベントリ をクリックして、その画面を開きます。
- インベントリ画面の上部にあるスイッチタブを選択し、 スイッチの請求 ボタンをクリックして、スイッチの請求コードまたはアクティベーションコードを入力します。
- 画面上のその他のフィールドにも必要に応じて入力します。 [要求されたスイッチをサイトに割り当てる]の選択を解除すると、スイッチは[スイッチ]ページに表示されません。スイッチページでスイッチを表示するには、まずイン ベントリ ページからスイッチをサイトにスイッチを割り当てる必要があります。 ジュニパー Mistで設定を管理に チェックを入れ、スイッチのrootパスワードを入力します。この選択により、スイッチがMistの管理下に置かれるため、競合を防ぐためにCLIを使用したローカル設定を制限することをジュニパーは推奨しています(たとえば、スイッチ上でシステムログインメッセージを作成して、CLIからローカルで設定変更を行わないように警告することができます)。
- ZTPプロセスが解決されると、スイッチが自動的に インベントリ 画面に表示されます。Webページを更新しても数分経ってもスイッチが表示されない場合は、ログアウトしてから再度ログインするか、以下のトラブルシューティングセクションに移動して、デバイスがクラウドに接続しているかどうかを確認する方法を確認してください。
導入コードベースのインストールによるブラウンフィールドスイッチの有効化
ブラウンフィールドスイッチをアクティブにする前に、スイッチ上の既存のJunos OS設定をバックアップすることが重要です。以下で説明するように、スイッチがジュニパー Mistクラウドからの管理に採用されると、古い設定が置き換えられるためです。これを行うには、 request system software configuration-backup <path> コマンドを実行します。これにより、現在アクティブな設定とインストール固有のパラメーターが保存されます。
スイッチがジュニパー Mistクラウドに採用された後、ユーザーがスイッチの設定にJunos OS CLI使用できないようにするには、スイッチ上でシステムログインメッセージを作成して、設定変更を警告したり、パスワードを変更したり、Junos OS CLIユーザーアカウントに制限をかけたりして、管理アクセスを完全に制限することができます。
スイッチの採用では、最初は常にアウトバウンド SSH を使用します。JMAがインストールされたCloudX対応スイッチを持っていたとしても、システムはそれを事前に知ることができません。最も一般的でない判定子は、Mist クラウドで管理する必要があるすべてのスイッチの outbound-ssh です。スイッチがMist Cloudによって完全に管理され、JMAがインストールされると、アウトバウンドssh機能を無効化し、それ以降はHTTPS経由のCloudXを使用することができます。
この手順では、サポートされているバージョンのJunos OSを実行しているサポートされているEXシリーズスイッチ間で、セキュアな接続を設定する方法について説明します。ここでは、Junos OS CLIを使用して、ポータル上とスイッチ上でいくつかの設定変更を行います。両方のシステムにログオンできることを確認してください。
- ジュニパー Mistクラウドで企業にログインし、メニューの 組織>インベントリ をクリックします。
- 表示される画面の上部で スイッチ を選択し、右上隅にあるスイッチ を採用 ボタンをクリックして、相互運用性に必要なJunos OS CLIコマンドを生成します。コマンドは、ジュニパー Mist ユーザー アカウントを作成し、TCP ポート 2200 を介してジュニパー Mist クラウドへの SSH 接続を作成します(スイッチ接続は管理インターフェイスから行われ、構成設定とテレメトリ データの送信に使用されます)。
- 表示されるウィンドウで、[ クリップボードにコピー] をクリックして、ジュニパー Mist クラウドからコマンドを取得します。
- Junos OS CLIで、「edit」と入力して設定モードを開始し、コピーしたコマンドを貼り付けます(まだ階層のベースレベルにいない場合は、「top」と入力します)。
- ポータルに戻り、 組織>インベントリ>スイッチ をクリックし、追加したスイッチを選択します。
- 画面上部の [ さらに表示 ] ドロップダウンをクリックし、[ サイトに割り当て ] ボタンをクリックして、プロンプトに従って選択を続行します。
- 階層のシステムサービスレベルでshowコマンドを実行し、階層のシステムログインユーザーjuniper-mistレベルで再度実行して、スイッチの更新を確認します。
cli show configuration system services ssh { protocol-version v2; } netconf { ssh; } outbound-ssh { client mist { device-id 3634a49d-3e20-46d6-b0c9-0b0d6a314690; secret "trimmed"; ## SECRET-DATA keep-alive { retry 12; timeout 5; } services netconf; oc-term.mistsys.net { port 2200; retry 1000; timeout 60; } } } show configuration system login user mist full-name mist; uid 63157; class super-user; authentication { encrypted-password "trimmed"; ## SECRET-DATA ssh-rsa "trimmed"; ## SECRET-DATA }
採用向けのJunos OS CLIは、Mist組織独自のものです。取得後は、同じ組織に所属する他のEXシリーズスイッチで使用できます。最初にジュニパーMistクラウドに接続した後、デフォルトのパスワードはデバイスごとに固有のパスワードに変更されます。
スイッチをジュニパー Mistポータルに追加し、詳細を表示
スイッチがポータルに登録できるようになったので、次のステップはスイッチを適切なサイトに追加してAPを割り当てることです。これはポータルから行います。
手順：
- スイッチをサイトに追加するには、ジュニパー Mistメニューの組織 >インベントリ をクリックし、表示される画面上部の スイッチ タブをクリックします。追加したスイッチを選択し、[ さらに表示 ]ボタン、[ サイトへの割り当て]の順にクリックし、[ スイッチの割り当て ]ウィンドウに表示されるドロップダウンリストからサイトを選択します。 サイトに割り当て ボタンをクリックしてアクションを完了します。
- アクセスポイントをクリックすると、割り当てられていないAPのリストが表示されます。
- スイッチをクリックすると、スイッチのリストが表示されます。リストからスイッチを選択して、スイッチとポータルが正しくプロビジョニングされていることを確認します。スイッチのインターフェイスで以前に設定した PoE コンプライアンスが、VLAN やその他の詳細と同様にスイッチとともに表示されていることに注意してください。
- スイッチページでスイッチ名をクリックすると、接続されているAPやクライアントを含むそのスイッチの詳細ビューにドリルダウンします。リストにある各スイッチについて、バージョン、モデル番号、CPUとメモリの使用率、転送バイト、PoEデバイスによって消費される電力、ポートエラーなど、さまざまなプロパティを表示できます。
- 最後に、このJVDの出発点として、追加したばかりのスイッチを選択し、スイッチ画面の右上隅にあるJunos OSシェルを開くことにより、ポータルからJunos OSシェルを開きます。ここから、スイッチへの完全な読み取りおよび書き込みアクセスが可能になり、さらに構成を変更することができます。
WANルーターの背後にあるEXシリーズスイッチ
次に、スイッチをオンボーディングしてインフラストラクチャに追加します。この例では、WAN ルーターで LAG を形成し、前の章「 アップリンク インターフェイスでリンク アグリゲーションを使用する場合のベスト プラクティス」で説明したフォースアップ方式を使用することを前提としています。
スイッチをサイトに割り当てるには:
- ポータルで、 組織>管理>インベントリをクリックします。
図3:インベントリ
への移動
- インベントリページで、インベントリビューが組織(組織全体)に設定されていることを確認し、すべてのデバイスが表示されるまでブラウザーを更新します。
図4:インベントリ
内のEXシリーズスイッチ
- 新しいスイッチを選択し、 サイトへの割り当てをクリックします。
- [ Assign スイッチ ]ページで、次の手順に従います。
spoke1-siteを選択します。- Mistオプションで設定を管理オプションを無効にします。必要に応じて、このオプションは後で有効にできます。
図5:スイッチ
を割り当てるサイトの選択
- サイトへの割り当てをクリックします。
- デバイスをサイトに割り当てたら、インベントリの変更を確認します。
- [新規サイト]の下に
spoke1-siteが表示されます。図6:サイトへの割り当てられたスイッチの詳細
- ポータルで、スイッチに移動し、スポーク1サイトを選択します。
図7:変更
に割り当てられたスイッチの選択
このページには、サイトに割り当てられているスイッチのリストが表示されます。
- 必要なスイッチをクリックして、スイッチ設定ページを開きます。
- デバイス名を確認し、 スイッチ設定 セクションまで下にスクロールして、 設定管理を有効にするにチェックを入れます。
図8:割り当てられたスイッチ
の設定
- ポート設定で、 ポート範囲の追加をクリックします。
図9:割り当てられたスイッチ
のポート設定
- 新しいポート範囲ページで、以下のオプションを設定します。
- ポートIDを
ge-0/0/1とge-0/0/2(LAG用の2つのポート)に設定します。 - インターフェイスには、デフォルトの「
L2 Interface」を選択します。 - 既存の設定プロファイルを「
Uplink」として選択します。 - ポートアグリゲーションを有効にします。
- 障害または壊れたリンクを検出できるように LACP を有効にします。
- フォースアップを無効にします。このオプションを有効にする必要があるのは、WANルーターの場合、またはアクセススイッチへのダウンリンクを設定する分散型スイッチの場合のみです。
- LACPの定期的な低速は無効のままにします。
- AEインデックスを0に設定して、AEインデックスが両側で同じになるようにします。
図10:割り当てられたスイッチ
のポート設定
- ポートIDを
- 以下の図は、ポート設定の概要を示しています。
図11:割り当てられたスイッチ
のポート設定
- 変更を 保存 します。
これで、新しいEXシリーズスイッチがジュニパー Mist Wired アシュアランス環境に追加されました。
オプションで、次のサンプル出力に示すように、リモートシェルを使用してスイッチで2つのリンクがアップしていることを確認できます。
show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing
トラブルシューティングのヒント
この章では、スイッチとジュニパー Mist クラウド間の接続について詳しく説明します。記事「 EXシリーズスイッチをJuniper Mist Cloudに接続して管理する方法とは? スキップされた場合に備えて、これらの方法を紹介しました。
ジュニパー Mist クラウドのオンボーディング プロセスで問題が発生した場合、以下の手順を実行すると、デバイスのリセットやジュニパー Mist クラウドへのさらなる通信が保証される場合があります。外部リファレンスは、次のリンクから入手できます。 https://www.mist.com/documentation/troubleshooting-switches/
EXシリーズスイッチとMist Cloud通信間のファイアウォールを確認する
ここで説明するように、ファイアウォールにプロトコルとポート開口部が実装されていることを前提としています。EXシリーズスイッチの管理では、最も重要な3つのプロトコルとポート口は次のとおりです。
- ジュニパーMistクラウドへのアウトバウンドSSH接続の場合:宛先ポート 2200 への TCP。EXシリーズスイッチは、アウトバウンドSSHセッションを確立して、インターネットに向けて送信元NATを渡します。これは次のように機能します。
- デバイスは、ジュニパー Mist クラウドへの TCP 接続に未加工のソケットを使用します。
- TCP接続が確立されると、デバイスから特別なDMIメッセージが送信され、ジュニパー Mistクラウドがデバイスのシリアル番号などの情報を収集して、管理する必要があるデバイスを判断します。
- ジュニパー Mist クラウドが DMI に基づいてデバイスを識別した場合、既存の TCP 接続を使用して、SSH ログインで既知の資格情報を持つデバイスへのリバース SSH セッションを確立します。
- ファイアウォールベンダーが、セッションを詳細に調べて、アプリケーションレベルの管理をこれ以上適用しようとしないことが重要です。特殊なDMIメッセージとリバースSSHログインは未知のアプリケーションであると推測できます。このTCP 2200ポートセッションは、より深く検査してはならず、常に生として扱う必要があります。
- スイッチのクレームおよびZTPの場合:宛先ポート443、FQDN
redirect.juniper.netへのHTTPS TLS暗号化セッション。これは、ZTPプロセスが機能し、デバイスが初期設定を取得して正しいジュニパーMistクラウドにアタッチするために必要です。何らかの理由でこれが不可能な場合は、代わりにブラウンフィールドの採用方法を検討してください。 - ジュニパー MistクラウドへのCloudX接続の場合:ジュニパー Mist クラウド宛ての宛先ポート 443 に向けて、HTTPS TLS 暗号化セッションを開く必要があります。ここで、ファイアウォールベンダーはTLSセッションにアプリケーションレベルの管理を適用できます。宛先FQDNは通常
jma-terminator.<cloud>.mist.com
アウトバウンド SSH と CloudX の操作に必要な両方のポートを開くことをお勧めします。新しいスイッチを開梱する場合、工場出荷時にインストールされているJunos OSバージョンの一部としてJMAクライアントがインストールされていない場合があります。また、この採用方法では、最初にアウトバウンド SSH を使用してデバイスを管理します。
デバイスへのコンソール アクセス権がある場合は、次のチェックを試すことができます。
# test you can ping a site in the internet root> ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=53 time=5.371 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=5.175 ms # test DNS working as well root> ping www.google.com inet PING www.google.com (142.251.32.36): 56 data bytes 64 bytes from 142.251.32.36: icmp_seq=0 ttl=112 time=24.966 ms 64 bytes from 142.251.32.36: icmp_seq=1 ttl=112 time=18.031 ms 64 bytes from 142.251.32.36: icmp_seq=2 ttl=112 time=9.661 ms 64 bytes from 142.251.32.36: icmp_seq=3 ttl=112 time=8.440 ms
Juniper Mist Cloudへの接続としてアウトバウンドSSHを使用するスイッチ
次のステップでは、ジュニパー Mist クラウドの管理インスタンスの FQDN を把握する必要があります。この情報を取得するには、[ 組織>インベントリ ] に移動し、[ スイッチ ] を選択し、[ スイッチの採用] をクリックします。
上記の例では、デバイスは FQDN「oc-term.mistsys.net」によって管理されているため、ポート 2200 への telnet セッションを開くことができます。
# test that a telnet session can be established root> telnet oc-term.mistsys.net port 2200 Trying 52.53.57.207... Connected to a4119aeb75a5342119e38dd3c475aff9-99130767d4e77d46.elb.us-west-1.amazonaws.com. Escape character is '^]'. ^C
Telnet セッションを正常に確立できれば、それは肯定的な兆候ですが、完全な接続が保証されるわけではありません。これは、テスト Telnet セッションでは完全な接続プロセスを再現できないためです。アプリケーションレベルの検査を実行するファイアウォールの中には、後でセッションを終了するものもあります。したがって、次のステップは、セッションが予期しない中断なしに、長時間にわたってアクティブで安定した状態を維持できることを確認することです。
# test that an outbound ssh session can be established root> show system connections | match 2200 | match ESTA tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED # see for a longer time that the connection stays really up root> show system connections | match 2200 | match ESTA | refresh 5 ---(refreshed at 2024-02-29 14:49:49 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:49:54 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:49:59 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:04 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:09 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:14 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:19 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:24 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:29 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:34 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:39 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:44 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:49 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(refreshed at 2024-02-29 14:50:54 UTC)--- tcp4 0 0 192.168.10.205.60913 52.53.57.207.2200 ESTABLISHED ---(*more 100%)---[abort]
Juniper Mist Cloudへの接続としてCloudXを使用するスイッチ
スイッチがCloudXを使用してジュニパーMistクラウドと通信できるかどうかを確認するには:
- スイッチ上で以下のCLIコマンドを実行します。
user@switch> show version | match mist JUNOS Mist Agent [v1.0.2205-2] . user@switch> show system connections | grep 443 tcp4 0 0 192.168.2.52.62957 52.52.102.40.443 ESTABLISHED
- ジュニパー Mistポータルを通じてCloudXを確認するには、以下の手順に従います。
- ジュニパー Mistポータル(manage.mist.com)にログインします。
- スイッチ名スイッチ>をクリックして、スイッチの詳細ページに移動します。
- 任意のポートまたはポート範囲をクリックします。
CloudX が実行されている場合、[ パケット キャプチャ] ボタンが有効になります。それ以外の場合は、ボタンがグレー表示されます。
CloudXが複数のスイッチで有効になっているかどうかは、ジュニパーのMistポータルを使用して確認することもできます。
そのためには、 サイト>スイッチパケットキャプチャ>スイッチを追加をクリックします。
ここにリストされているスイッチはすべてCloudXに対応しています。
- ジュニパー Mist クラウド デーモン(mcd)と Junos Mist デーモン(jmd)が実行されていることを確認します。
mcd プロセスは、スイッチとクラウド間の通信を可能にする役割を果たします。クラウド内のターミネーターへのセキュアなWebSocket接続を維持します。
jmdプロセスは、以下の目的で使用されます。
- デバイスの定期的な統計情報を生成する。
- デバイス設定を適用しています。
- デバイスイベントの収集。
- デバイス機能(パケットキャプチャやソフトウェアアップデートなど)を開始する。
- 要求された関数(ファイルやストリーミングデータなど)からの結果を返します。
jmdとmcdが実行されていることを確認するには、以下のCLIを使用します。
user@switch> set cli screen-width 400 user@switch> start shell % ps aux | grep jmd root 21408 0.0 0.4 1246080 32200 - S Fri23 15:17.51 /var/run/scripts/jet/jmd -mcd-socket /var/run/mist_mcd.ipc mist 3706 0.0 0.0 11136 2516 0 S+ 07:14 0:00.00 grep jmd % % % ps aux | grep mcd root 21319 0.0 0.3 1242924 22256 - I Fri23 8:18.00 /var/run/scripts/jet/mcd root 21408 0.0 0.4 1246080 32200 - S Fri23 15:17.53 /var/run/scripts/jet/jmd -mcd-socket /var/run/mist_mcd.ipc mist 3708 0.0 0.0 11136 2516 0 S+ 07:14 0:00.00 grep mcd %
- 以下のCLIコマンドを使用して、jmdログとmcdログにエラーがないか確認します。通常、jmd ログには、設定または統計に関連する問題が表示されます。MCDログは、スイッチとクラウド間の接続に関連する問題を報告します。
user@switch> show log jmd.log | last 10 [jmd] 2024/11/04 07:12:02 collector.go:850: total stats collection time = 10s [jmd] 2024/11/04 07:12:02 app_states.go:355: app sending stats to mist cloud (26171 bytes) [jmd] 2024/11/04 07:12:02 app_states.go:360: successfully sent ipc stats: [jmd] 2024/11/04 07:12:02 app.go:282: processing app state "STEADY" [jmd] 2024/11/04 07:12:12 app.go:339: sending ipc keep-alive [jmd] 2024/11/04 07:12:22 app.go:339: sending ipc keep-alive [jmd] 2024/11/04 07:12:32 app.go:339: sending ipc keep-alive [jmd] 2024/11/04 07:12:42 app.go:339: sending ipc keep-alive [jmd] 2024/11/04 07:12:52 app.go:339: sending ipc keep-alive [jmd] 2024/11/04 07:12:52 collector.go:417: collecting periodic stats, interval 60
.
user@switch> show log mcd.log | last 10 [mcd] 2024/11/04 07:09:31 app.go:967: successfully sent msg to cloud: ep-telemetry [mcd] 2024/11/04 07:10:02 ipc_server.go:414: rx ipc request: send cloud telemetry [mcd] 2024/11/04 07:10:02 ipc_server.go:447: forwarding ipc telemetry to "junos-stats-" (26167 bytes) [mcd] 2024/11/04 07:11:02 ipc_server.go:414: rx ipc request: send cloud telemetry [mcd] 2024/11/04 07:11:02 ipc_server.go:447: forwarding ipc telemetry to "junos-stats-" (26171 bytes) [mcd] 2024/11/04 07:12:01 app.go:967: successfully sent msg to cloud: ep-telemetry [mcd] 2024/11/04 07:12:02 ipc_server.go:414: rx ipc request: send cloud telemetry [mcd] 2024/11/04 07:12:02 ipc_server.go:447: forwarding ipc telemetry to "junos-stats-" (26171 bytes) [mcd] 2024/11/04 07:13:02 ipc_server.go:414: rx ipc request: send cloud telemetry [mcd] 2024/11/04 07:13:02 ipc_server.go:447: forwarding ipc telemetry to "junos-stats-" (26171 bytes)
- 何らかの理由でjmdまたはmcdが実行されない場合は、以下のサンプルに示すように再起動してみてください。
user@switch> request extension-service restart-daemonize-app mcd Extension-service application 'mcd' with pid: 92502 exited with return: -1 Extension-service application restarted successfully
手記：Junos OS 22.4xxバージョンを使用している場合は、コマンド
request extension-service daemonize-restart mcdを使用します。 - スイッチがクラウドに接続していない場合は、pingテストとcurlテストを使用して、スイッチの到達可能性を確認します。これらのテストは、必要なポートがファイアウォールの通過が許可されているかどうかを確認するのに役立ちます。
クラウドエンドポイントは、pingテストに応答するように設定されていません。ただし、pingテストを実行すると、DNSがFQDNを解決することが確実になります。以下は ping テストの例です。
user@switch> ping jma-terminator-staging.mistsys.net PING a8481a00030ad459aac15af07d5f2c5b-75855524.us-east-1.elb.amazonaws.com (3.210.247.53): 56 data bytes ^C --- a8481a00030ad459aac15af07d5f2c5b-75855524.us-east-1.elb.amazonaws.com ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss
カールテストの例は次のとおりです。
user@switch> start shell % curl -k https://jma-terminator.mistsys.net/test Welcome to MIST %
curl テストからの有効な応答は、ジュニパー Mist クラウド内の jma-terminator に到達可能であることを証明します。応答がないか、エラーを受信した場合は、ファイアウォールが原因で、スイッチとクラウド間のパスがこれらのポートをブロックしていることを示しています。テストで使用されるURLはファイアウォール ポート のURLと同じで、クラウドインスタンスによって異なります。
root パスワードのリカバリー
root パスワードをリカバリーする必要がある場合は、デバイスにローカル コンソール接続してから、次の手順に従ってください。 https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/recovering-root-password.html。
バーチャルシャーシの削除
バーチャルシャーシのセットアップで問題が発生した場合、場合によってはシステム全体を工場出荷時の設定にリセットすることをお勧めします。以下の CLI 出力は、 YouTube の優れたデモ ビデオに基づいています。
# Login on first Switch and do request virtual-chassis vc-port set interface vcp-255/1/0 disable request virtual-chassis vc-port set interface vcp-255/1/1 disable # added interfaces for EX4400 request virtual-chassis vc-port set interface vcp-255/1/2 disable request virtual-chassis vc-port set interface vcp-255/1/3 disable
プライマリスイッチで上記のコマンドを入力すると、プライマリスイッチとバーチャルシャーシが切断されます。このスイッチでさらに入力されたコマンドは、このスイッチ専用のコンソール ポートに移動します。システムによって新しいプライマリが選択されるため、次のコンソールポートを試して、最終的にすべてのスイッチがバーチャルシャーシから切断され、すべてのスイッチに専用のコンソール接続ができるようになるまで、このプロセスを繰り返します。
次に、各スイッチにアクセスし、メンバーIDに基づいて適切なコマンドを実行します。
# delete any exiting pre-provision config first
edit
delete virtual-chassis pre-provision
commit and-quit
.
# When indicated by the ":1" member ID do the following
{master:1}
request virtual-chassis recycle member-id 0
request virtual-chassis renumber member-id 1 new-member-id 0
yes
.
# When indicated by the ":0" member ID do the following
{master:0}
request virtual-chassis recycle member-id 1
.
# In case the switch went into linecard-mode do this and then login again
request virtual-chassis reactivate
最後のステップとして、ラボを離れる前に、すべてのスイッチにロールとして「マスター」が表示され(マスター優先度は無視してください)、他のスイッチが接続されていないことを確認します。
show virtual-chassis
.
Virtual Chassis ID: 3d2d.5316.b4c3
Virtual Chassis Mode: Enabled
. Mstr Mixed Route Neighbor List
Member ID Status Serial No Model prio Role Mode Mode ID Interface
0 (FPC 0) Prsnt NX0216330306 ex3400-48t 128 Master* N VC
#
# Make sure there is no other memebr displayed here
#
.
Member ID for next new member: 1 (FPC 1)
単一デバイスの工場出荷時のリロード
EXシリーズスイッチを工場出荷時の初期設定に戻すには、以下のコマンドを実行してから、ジュニパー Mist クラウドに接続できることを確認します。
cli
edit
load factory-default
delete chassis auto-image-upgrade
set system root-authentication plain-text-password
# we are adding the below as a best practice
set system name-server 8.8.8.8
set interfaces irb unit 0 family inet dhcp force-discover
set interfaces vme unit 0 family inet dhcp force-discover
commit and-quit
show configuration | save /config/recovery.conf
# now check that you got a DHCP-lease and have a default route
show route
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
Limit/Threshold: 32768/32768 destinations
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Access-internal/12] 00:01:34, metric 0
> to 10.33.33.1 via irb.0
10.33.33.0/24 *[Direct/0] 00:01:35
> via irb.0
10.33.33.11/32 *[Local/0] 00:01:35
Local via irb.0
# test you can ping a site in the internet
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=53 time=5.371 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=5.175 ms
# test DNS working as well
ping www.google.com inet
PING www.google.com (142.251.32.36): 56 data bytes
64 bytes from 142.251.32.36: icmp_seq=0 ttl=112 time=24.966 ms
64 bytes from 142.251.32.36: icmp_seq=1 ttl=112 time=18.031 ms
64 bytes from 142.251.32.36: icmp_seq=2 ttl=112 time=9.661 ms
64 bytes from 142.251.32.36: icmp_seq=3 ttl=112 time=8.440 ms
ZTPの問題が発生した場合は、デバイスのRTCクロックを確認します。
デバイスがストレージに長く残っているほど、内部クロックのドリフトが多くなります。phone-home ZTPプロセス中に、デバイスはサーバー証明書を検証し、ローカルクロックが1970に設定されているなど、著しく間違っている場合、検証は失敗します。ベストプラクティスとして、デバイスの時刻を同期するためには常にNTPサーバーを使用する必要があります。デバイスが管理下に置かれると、ジュニパー Mist クラウドがこれを自動的に構成します。ただし、ZTP起動時の工場出荷時の初期デフォルト状態では、この設定はまだ適用されていません。この問題が発生した場合、以下に示すように、NTPサーバーを設定するか、システムクロックを手動で設定できます。
# optional: set a local NTP server of this lab cli edit set system ntp boot-server 216.239.35.0 set system ntp server 216.239.35.0 commit and-quit # check current time else ZTP CA-Certificates may be rejected show system uptime Current time: 2024-01-08 14:16:34 UTC . . # In case the date is below Year 2024 manually adjust the local time # set date YYYYMMDDhhmm.ss # or check if you already have enough connctivity to do that via our lab ntp # set date ntp 216.239.35.0 restart phone-home-client Phone home client daemon signalled but still running, waiting 28 seconds more Phone home client daemon still running, sending another terminate signal Phone home client daemon started, pid 7197
EXシリーズスイッチに接続されたジュニパーアクセスポイント
ここでは、ブランチインストールを完了するための次の要素を統合します。これは、無線クライアントをサポートするためにスイッチにAPを接続するものです。
APオンボーディングに満たさなければならない前提条件
このラボを実行するには、次の条件が満たされていることを前提としています。
- APはジュニパーのEXシリーズスイッチにケーブル接続されており、外部電源またはPoE経由で電力が供給されます。
- PoEを使用する場合、スイッチには十分な利用可能なPoE電力があり、APモデルに応じて少なくともIEEE 802.3afまたはIEEE 802.3at標準をサポートしている必要があります。
- LLDPは、トラブルシューティングを支援するためにスイッチとルーターで有効にする必要がありますが、厳密に必須というわけではありません。
- 上記の章には次の手順が含まれているため、手順に従ってください。
- DHCP サーバーは、この支社の AP 管理 VLAN 1033 サブネット 10.33.33.0/24 用に設定されています。この例では、これはWANルーターで行われています。
- 追加の VLAN 1088 サブネット 10.88.88.0/24 が WLAN クライアントに使用されます。
- 有線クライアントには、追加の VLAN 1099 サブネット 10.99.99.0/24 が使用されます。
- WAN ルーターでは、ネイティブ VLAN 1033 と VLAN 1088 および 1099 をトランクとして含むスイッチに LAG が形成されます。それ以上変更することなく、アップリンクからのネイティブVLANがスイッチ上のVLAN 1に割り当てられ、インバンド管理用のirb.0が割り当てられていることに注意してください。その管理VLANをAPなどのダウンストリームデバイスに提供するには、このVLAN 1を参照する必要があります。
- スイッチが接続されているポートでは、デフォルトのVLAN 1がネイティブで、VLAN 1088がトランクされています。ポートがサポートする必要がないため、有線クライアント向けに1099を再度追加しませんでした。
- WANルーターは、ジュニパー Mistクラウドへの管理トラフィックを許可するために、WANインターフェイスに何らかの形式のソースNATを実装する必要があります。
以下は、スイッチの最小設定(アップリンクを除く)についてのリマインダーです。
組織にAPを要求する方法
APは、アクティベーションコード、クレームコード、QRコードのいずれかを使用して、どの組織にも請求できます。
アクティベーションコード
APをご注文いただくたびに、当社の営業運用チームからアクティベーションコードをお送りします。このコードを使用して、ご注文に応じてAPとサブスクリプションを請求できます。このアクティベーションコードを使用して、APを一度に請求できます。APを請求するには、 組織>サブスクリプション ページに移動し、右上隅にある アクティベーションコードの追加 ボタンを選択します。アクティベーションコードを追加してアクティベートすると、すべてのAPが自動的に組織に要求されます。APのリストは、 インベントリ ページ(組織>インベントリ)で確認できます。
AP請求コード
組織にAPを個別に請求するには、 組織>インベントリ>APの請求 に移動し、各APの背面にある請求コードを入力します。
AP QRコード
MistAIモバイルアプリを使用して、APの背面に印刷されたQRコードをスキャンして、APを組織に請求することができます。私たちのアプリは、iOS デバイスと Android デバイスの両方と互換性があります。詳細については、こちらをご覧ください: https://www.mist.com/documentation/mist-ai-mobile-app/
組織内のAPの請求コードはどこで入手できますか?
APのQRコードが印刷されているAPの裏面には、APの請求コードが記載されています。
の写真
トラブルシューティング:「APを「接続済み」としてインベントリにオンラインにする
このステップでは、上記のいずれかの方法を使用してAPをインベントリに要求したことを前提としています。3〜5分後にブラウザウィンドウを更新すると、下の図に示すように、APがインベントリに「接続済み」状態で自動的に表示されます。
APが「接続済み」と表示されている場合は、次の手順でAPが接続されていない場合のトラブルシューティングについて説明しているため、このセクションをスキップできます。
ジュニパー APのトラブルシューティングについては、 こちら https://www.mist.com/documentation/category/troubleshooting/ で詳しく説明しています。このセクションでは、インベントリでAPを「Connected」状態にするために、EXシリーズスイッチ側で何をトラブルシューティングすればよいかに焦点を当てます。
APがサイトに割り当てられていない場合、クラウドへの接続状況に関係なく、常に「切断」状態が表示されます。APの登録に加えて、サイトへのAPの割り当ても必須であることに留意してください。
サイトのローカルにいる場合は、点滅コードがエラーを示している可能性があるため、APのステータスLEDを確認してください。
最初に行うことは、APのステータスLEDを見てエラーの原因を理解することです。APにLEDが表示されない場合は、再起動します。AP に PoE が供給されている場合は、次の 2 つの方法のいずれかを使用して実行できます。
- ポータルの バウンスポート オプションを使用します。APが接続されているポートを選択すると、ペインが開き、特定のポートをバウンスするように直接選択できます。これにより、接続されているAPの電源も入れ替わります。
以下の図に示すように、バウンスポートのステータスに関する情報が記載された新しいウィンドウが表示されます。
プロセスの一環として 2 つの Junos OS 設定コミットを行う必要があるため、ポートのバウンスには数分かかる場合があります。
- リモートシェルを使用してPoEインターフェイス設定を変更します(このオプションは推奨されません)。
cli edit set poe interface ge-0/0/3 disable commit # wait >20seconds delete poe interface ge-0/0/3 disable commit and-quit exit
APに外部電源が供給されている場合は、誰かにしばらくプラグを抜いてから、再度電源を入れるように依頼する必要があります。APには、スイッチのようなコンソール接続はありません。
次のステップでは、スイッチのリモートコンソールを使用して、以下の項目を確認します。
- APが接続されているポートが「アップ」と表示されていませんか?
- APが接続されているポートは正しく設定されており、パケットを転送していますか?
- APのMACアドレスは予想されるポートに表示されますか?
- APがLLDPネイバーとして表示されていると思いますか?
- APにPoEが供給されていると仮定すると、実際の消費電力はどれくらいでしょうか?
次の出力例は、インターフェイスge-0/0/3に接続されたAPを示しています。
- ポートが管理上「
up」されており、物理リンクが検出されているかどうかを確認します。root@Switch1> show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0 up down ge-0/0/0.0 up down eth-switch ge-0/0/1 up up ge-0/0/1.0 up up aenet --> ae0.0 ge-0/0/2 up up ge-0/0/2.0 up up aenet --> ae0.0 ge-0/0/3 up up ge-0/0/3.0 up up eth-switch ge-0/0/4 up down ge-0/0/4.0 up down eth-switch . - 次に、ポートが転送モードであり、予期されるVLAN(この例ではデフォルトVLAN)で設定され、アクセスモードになっていることを確認します。また、割り当てられたVLANが、AP管理用のDHCPリース配布資料にWANルーターが使用するVLANと同じであることを検証します。
root@Switch1> show ethernet-switching interface ge-0/0/3 Routing Instance Name : default-switch Logical Interface flags (DL - disable learning, AD - packet action drop, LH - MAC limit hit, DN - interface down, MMAS - Mac-move action shutdown, AS - Autostate-exclude enabled, SCTL - shutdown by Storm-control, MI - MAC+IP limit hit) Logical Vlan TAG MAC MAC+IP STP Logical Tagging interface members limit limit state interface flags ge-0/0/3.0 32768 0 tagged WLAN-Client 1088 32768 0 Forwarding tagged default 1 32768 0 Forwarding untagged - 次に、APのMACアドレス(QRコードにも印刷されています)がスイッチのインターフェイスに期待通りに表示されるかどうかを確認します。
root@Switch1> show ethernet-switching table MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC) Ethernet switching table : 2 entries, 2 learned Routing instance : default-switch Vlan MAC MAC Age Logical NH RTR name address flags interface Index ID default 5c:5b:35:be:81:06 D - ge-0/0/3.0 0 0 default ee:38:73:9a:d4:a5 D - ae0.0 0 0
この時点で、APのポート認証ステータスも確認するのが適切です。APが接続されているスイッチに対して自分自身を承認することを意図している場合もあれば、これが必須でない場合もあり、誰かが誤って認証を有効にしたポートプロファイルを適用してしまうことがあります。
- 次に、APのMACアドレスがLLDPネイバーシャーシIDとして表示されているかどうかを確認します。ポート情報は、お使いのAPモデルによって異なる場合があります。ただし、システム名は、APの状態について詳細を判断するのに役立つ場合があります。
- LLDPシステム名が報告されない場合、APに接続に問題があります。例えば、DHCPリースを受け取ることができません。
- 以下の例のように、LLDPシステム名が「Mist」の場合、通常、APは稼働していますが、インベントリには割り当てられていません。
- LLDPシステム名がAPのMACアドレスまたはインベントリ名である場合、組織のインベントリですでに「接続済み」状態になっているはずで、さらに設定を適用できます。
root@Switch1> show lldp neighbors Local Interface Parent Interface Chassis Id Port info System Name ge-0/0/1 ae0 ec:38:73:9a:d5:24 ge-0/0/5 spoke1 ge-0/0/2 ae0 ec:38:73:9a:d5:24 ge-0/0/6 spoke1 ge-0/0/3 - 5c:5b:35:be:81:06 ETH0 Mist - スイッチで PoE を実行している場合は、AP の消費電力も確認する必要があります。ネゴシエートされるPoEモードは、APモデル(通常、802.3atでは802.3af)によって異なり、データシートで確認できます。設定状態と無線使用状況に応じて、実際の「消費電力」レポートに違いがあることがわかります。
root@Switch1> show poe interface . . root@Switch1> show poe interface ge-0/0/3 PoE interface status: PoE interface : ge-0/0/3 Administrative status : Enabled Operational status : ON Power limit on the interface : 19.5W (L) Priority : High Power consumed : 7.3W Class of power device : 4 PoE Mode : 802.3at (L) LLDP-negotiated value on the port.
- WAN ルーターでは、以下のチェックを行う必要があります。この例では、WANルーターとして機能するSRXシリーズファイアウォールへのリモートコンソールセッションを使用します。以下の例に示すように、APからのDHCPリースリクエストを探し、ジュニパーMistクラウドに向けたTCP/UDPのポート443に向かう2つのセッションが表示されることを確認します。
root@spoke1> show dhcp server binding IP address Session Id Hardware address Expires State Interface 10.33.33.12 3 04:5c:6c:6b:13:42 54553 BOUND ae0.0 10.33.33.15 6 5c:5b:35:be:81:06 48923 BOUND ae0.0 . root@spoke1> show arp interface ae0.0 MAC Address Address Name Interface Flags 04:5c:6c:6b:13:42 10.33.33.12 10.33.33.12 ae0.0 permanent 5c:5b:35:be:81:06 10.33.33.15 10.33.33.15 ae0.0 permanent Total entries: 2 . root@spoke1> show security flow session source-prefix 10.33.33.15 Session ID: 34359960425, Policy name: 01_Internet/20, State: Stand-alone, Timeout: 60, Valid In: 10.33.33.15/40267 --> 44.204.233.81/443;udp, Conn Tag: 0x0, If: ae0.0, Pkts: 45026, Bytes: 8408428, Out: 44.204.233.81/443 --> 192.168.173.145/23463;udp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 5524, Bytes: 407857, . Session ID: 34359962715, Policy name: 01_Internet/20, State: Stand-alone, Timeout: 1794, Valid In: 10.33.33.15/37165 --> 54.144.163.241/443;tcp, Conn Tag: 0x0, If: ae0.0, Pkts: 8997, Bytes: 4866046, Out: 54.144.163.241/443 --> 192.168.173.145/28185;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 5063, Bytes: 421001, Total sessions: 2
ダイナミックポートプロファイルを使用する場合と、NACインフラストラクチャを使用する場合
ポートプロファイルは、検出された有線クライアントに基づいて、静的または動的に割り当てることができます。どちらにも長所と短所がありますが、ここでは説明しません。動的なアプローチを選択する場合、ジュニパー Mist クラウドで管理される EXシリーズスイッチには、次の2つのオプションがあります。
- RADIUS/NACインフラストラクチャによる動的なVLAN/フィルター割り当て。この場合、通常、インターネットや企業リソースへのアクセスが制限されている隔離ネットワークに静的VLANを設定し、使用するポートプロファイルにデフォルトVLANとして割り当てます。これは、RADIUS 認証に失敗し、すべてのクライアントがネットワークにアクセスできなくなることを許容できない場合のフォールスルー設定用です。その後、ポートの802.1x認証または802.1x認証とMAB(MACアドレスベースの認証)もアクティブ化します。その後、有線クライアントがポートにログインすると、RADIUSサーバーはクライアントに関する次のような属性を受け取ります。
- ユーザー名や証明書などの認証パラメーター。
- スイッチ名とポート。
- 有線クライアントMACアドレス。
バックエンドの RADIUS サーバーは、access-accept メッセージにいくつかの認証パラメーターを含めることができ、ポートに動的に割り当てるものを指定します。
-
- クライアント用の単一アクセスVLAN。
- 複数のVLAN(1つはネイティブで、残りはタグ付きVLANです)。文献では、これは無色ポート割り当てとも呼ばれています。これは通常、接続されたデバイスが AP の場合に使用されます。
- 以下を適用するために使用できるフィルターID文字列:
- ローカルファイアウォール用のACLベースのフィルター。
- 有線クライアントに割り当てるGBPタグ。(IP Closファブリックにのみ適用できます。このオプションは、ブランチ設計について議論するこのJVDには関係ありません)。
- 無色ポート用のジュニパー Mist クラウドによるダイナミックポート設定(DPC)。名前が示すように、この機能はジュニパー Mist クラウドによって管理される EXシリーズ スイッチに限定されており、他の場所では動作しません。ユーザーがこの機能を有効にしたスイッチポートにクライアントデバイスを接続すると、スイッチはデバイスを識別し、適切なポートプロファイルをポートに割り当てます。ダイナミックポートプロファイリングは、クライアントデバイスの一連のデバイスプロパティを利用して、事前設定されたポートとネットワーク設定をインターフェイスに自動的に関連付けます。以下のパラメーターに基づいて動的ポートプロファイルを設定できます。
- LLDPシステム名
- LLDPの説明
- LLDPシャーシID
- RADIUSユーザー名
- RADIUSフィルターID
- MAC(イーサネットMACアドレス)もMAC OUIです。
可能な限り、RADIUS/NACインフラストラクチャによる動的VLAN/フィルター割り当てを使用することをお勧めします。特に、ジュニパーのMist Access AssuranceをRADIUS/NACインフラストラクチャとして使用する場合は、管理が容易なタスクになります。
これらのユースケースとその仕組みを確認してみましょう。
-
ユースケース1:ネットワーク内に存在するRADIUS/NACインフラストラクチャ
通常、ポートで認証を有効にするには、次の2つの目的があります。
-
- システムをゼロトラストにする
- デバイスを関連するネットワークセグメントに割り当てます。
-
RADIUSインフラストラクチャを利用するネットワークでは、すべてのポートをdot1x + MABポートプロファイルを有効にしたアクセスポートに設定することをお勧めします。ネットワーク/VLANの割り当てを取得し、ユースケースに基づいてポートをアクセスまたはトランクとして割り当てるには、RADIUSトランザクションに依存しています。クライアントは、dot1x(802.1x EAP認証サプリカント)が可能なデバイスの組み合わせであるか、すべてのデバイスMACアドレスがRADIUSデータベースで使用可能です。スイッチテンプレートで、必ず拡張タイマーを使用してRADIUSサーバーを設定してください。(拡張タイマーにより、dot1xからMABへのデフォルトのフォールバック時間が~120〜180秒から~10〜15秒に短縮されます。これは、良好なクライアントエクスペリエンスのために強く推奨されます)。
access-acceptメッセージの一部として送信することを推奨する、RADIUSの戻り値属性(AVP)のさまざまなユースケースについて説明しましょう。
- ポートがアクセス ポートのままで、特定の VLAN に割り当てる必要があるクライアント。ここでは、AVP=Tunnel-Private-Group-IDを使用します。以下の設定例を参照してください。
001094001123 Cleartext-Password := "001094001123" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = "VLAN1099", - 複数のVLANに割り当てる必要があり、トランクポートに移動する必要があるクライアント。ここでは、AVP=Egress-VLAN-IDまたはEgress-VLAN-Nameを使用します。以下の設定例をご覧ください。
# 4Byte tagged VLAN = 0x31+<000000padding>-<VLAN-ID in Hex> # 4Byte untagged VLAN = 0x32+<000000padding>-<VLAN-ID in Hex> 001094001177 Cleartext-Password := "001094001177" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Egress-VLANID += 0x32000001, Egress-VLANID += 0x31000440, . # first char of string 1 = Tagged , 2 = native/untagged 001094001144 Cleartext-Password := "001094001144" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Egress-VLAN-Name += "2default", Egress-VLAN-Name += "1VLAN1088", - ファイアウォールフィルター/ACL(上記の2つのAVPのいずれかに加えて)としてポリシーに割り当てる必要があるクライアント。ここでは、AVP=Filter-Id を使用します。
001094001142 Cleartext-Password := "001094001142" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = "1099", Filter-Id = "filter1"特定のフィルターIDを使用する前に、スイッチ自体にフィルターを作成する必要があることに注意してください。以下に、追加の CLI を使用した例を示します。
set firewall family ethernet-switching filter filter1 term supplicant1 from source-mac-address 00:10:94:00:11:42 set firewall family ethernet-switching filter filter1 term supplicant2 from source-mac-address 00:10:94:00:11:66 set firewall policer p1 if-exceeding bandwidth-limit 1m set firewall policer p1 if-exceeding burst-size-limit 1k set firewall policer p1 then discard set firewall family ethernet-switching filter filter1 term supplicant1 then cosunt counter1 set firewall family ethernet-switching filter filter1 term supplicant1 then policer p1 set firewall family ethernet-switching filter filter1 term supplicant2 then count counter2
- 別の方法は、ポートプロファイルに基づいて動的VLANを割り当てることですが、それでも少なくとも有線クライアントに対してはRADIUS経由の認証を実行する必要があります。したがって、この場合の RADIUS サーバーは、最終的な access-accept メッセージの一部として、上記の RADIUS AVP を送り返す必要はありません。必要なのはaccess-acceptメッセージのみで、VLAN設定はポートプロファイルから取得されます。次の図は、このオプション設定ができる場所を示しています。
上記のいずれのシナリオでも DPC を追加することは推奨しないため、このシナリオではどのポートでも DPC をオンにしないでください。これは、RADIUS/NACインフラストラクチャを使用している場合に最も好ましいシナリオです。
-
ユースケース2:RADIUS/NACインフラストラクチャを使用しているが、以下の理由により一部のデバイスをDPCで拡張している。
ユースケース1に示した上記のAVPはすべて、今でも当てはまります。しかし、ジュニパーのDPCは、LLDP情報とMAC OUI(MACアドレスのベンダー部分)をポート設定の識別子として使用することで、機能を拡張します。従来のRADIUSまたはNACベースの管理システムのみに依存している場合は、通常、このレベルの識別は利用できません。
このアプローチの動機:
-
- RADIUSユーザーデータベースに多数のMAC(APとカメラは通常ボリュームデバイスです)を追加することは避け、代わりにLLDPとMAC OUIを使用します。
- クライアント数が関係するため、RADIUS/NACインフラストラクチャのコストを削減します。
-
ジュニパーでは、特定のポートでDPCを介したVLAN割り当てを使用する場合、802.1XやMABなどの追加のセキュリティレイヤーを有効にすることを推奨しています。残りのポートでは、引き続き認証に 802.1X または MAB を使用しますが、DPC は組み込まないでください。
選択したデバイスがネットワークのどこに接続されるか予測できない場合は、すべてのポートを DPC および 802.1x または MAB に対して有効にする必要がありますが、これはあまり推奨されません。
ユースケース1とユースケース2の両方で、すべてのポートで802.1xとMABが有効になっている場合、認証が成功するまでMACアドレスは学習されないことに注意することが重要です。したがって、MACベースのルールを使用したDPCは機能しないため、設定しないでください。ポートが 802.1x および MAB で有効になっている場合にのみ、LLDP ベースのルールで DPC を使用することを推奨します。
- ユースケース3:RADIUS/NACインフラストラクチャなし、DPC + ポートプロファイルの静的割り当て
- RADIUS/NACインフラストラクチャがない場合、DPCをLLDPまたはMACベースのルールと共に使用してポートをプロビジョニングできます。推奨されるアプローチは、DPC 適格デバイスに割り当てられているポートを認識している場合は、それらのポートでのみ DPC を有効にすることです。残りのポートは静的に割り当てられます。
- あまり好ましくないアプローチは、DPC 対象デバイスが接続されるポートを認識しない場合は、すべてのポートで DPC を有効にすることです。
- また、DPCが有効になっているデフォルトプロファイルでは、ダミー(または少なくとも隔離)VLANを指し示すことを推奨します。これにより、接続されたときにIPを取得し、DPCルールに一致しないデバイスが取得されません。
ポートで多数のポートフラップが発生する場合は、DPCの使用を避けてください。各ポートフラップは、スイッチの設定変更(Junos OSコミット)をトリガーします。このような場合は、RADIUS経由で動的VLAN設定を適用することをお勧めします。
以下の図は、DPCがLLDPシャーシIDのベンダーMAC OUI部分を使用してジュニパーAPを特定する例を示しています。
.png)
以下の画像に示されているように、チェックボックスを使用して、ポートのDPCをアクティブにする必要があることを忘れないでください。
クライアントが認識されてからポートプロファイルがポートに適用されるまでに数分かかり、その後数分でポートプロファイルの割り当てステータスがポータルに表示されます。スイッチの再起動や、スイッチ上のすべてのポートに影響を与える大量のリンク アップまたはダウン イベントが発生した場合、すべてのポートが適切なプロファイルに割り当てられるまでに約 20 分かかります(すべてのポートで DPC が有効になっていると仮定)。
スイッチがJuniper Mist Cloudに向けてCloudXを利用する場合
スイッチがジュニパー Mistクラウドへの通信にCloudXを使用する場合、DPCの動作に対する次の変更に留意する必要があります。
- CloudXは、通常使用されている従来の静的構成データベースではなく、Junos for DPCの一時データベースとポートバウンス機能を活用します。
- DPCで有効になっているインターフェイスは、静的設定データベースからエフェメラルデータベースに移動します。これには、あらゆるスパニングツリープロトコル(STP)設定も含まれます。
- エフェメラルデータベースコミットは高速です。大規模なVCでも、静的設定データベースと比較してコミットに1〜2秒かかります。
- 静的構成データベースを参照する場合、一時データベースに加えられた変更は表示されません。したがって、DPC設定が適用されていないと勘違いしないでください。エフェメラルデータベースの設定を確認するには、以下に示すように、コンソールまたはリモートシェルセッションを介して以下のJunos OS CLIコマンドを実行します
show ephemeral-configuration instance mist-dpc
追加のJunos OS CLIコマンドによるDPCと802.1Xの設定の組み合わせの使用はサポートされていません。CloudXが有効になっている場合、DPCはエフェメラルデータベースに依存しており、追加CLIからの静的設定と混合すると、静的設定とエフェメラルデータベースに保存されているインターフェイス設定の間に不一致が生じます。
スイッチのDHCPスヌーピングを設定する
DHCP スヌーピングにより、スイッチはネットワーク上の信頼できないポートから開始されたすべての DHCP トラフィックを調べることができます。VLANでDHCPスヌーピングが有効になっている場合、システムはVLANに関連付けられている信頼できないホストから送信されたDHCPメッセージを検査し、そのIPアドレスとリース情報を抽出します。この情報は、DHCPスヌーピングデータベースの構築と維持に使用されます。このデータベースを使用して検証できるホストのみがネットワークへのアクセスを許可されます。このセキュリティ機能とその動作方法の詳細については、こちら https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/concept/port-security-dhcp-snooping-els.html をご覧ください。
デフォルトでは、アクセスポートは信頼できないポートとして扱われ、トランクポートは信頼できるポートとして扱われます。
ポータルでDHCPスヌーピング/ARPインスペクション/IPソースガードを設定できる場所は3つあります。
- スイッチデバイスの詳細ページ。
- サイト>スイッチ設定ページ
- 企業>スイッチテンプレート。
設定は、優先度の高い順で適用されます。最初に スイッチデバイスの詳細 ページ、次に サイト>スイッチ設定 ページ、最後に優先度が最も低い 組織>スイッチテンプレートから適用されます。
以下は、単一のネットワークで上記の設定を有効にすることができる例です。要件に応じて、すべてのネットワーク/単一のネットワークに対して有効にできる2つのオプションがあります。
以下の例では、Vlan24(vlan-id-24)>単一のネットワークに対してDHCPスヌーピングを有効にしています。
設定を有効にするには、スイッチ上にVLANが存在する必要があります。このため、ポートはポートプロファイルに関連付ける必要があります。アクセス ポート プロファイルでは、ポートが信頼できるか信頼できないかを指定できます。この設定が定義されていない場合、デフォルトは標準動作(信頼できない)になります。ポートネットワークは、標準データネットワークまたはVoIPネットワークのいずれかとして設定できます。デフォルトでは、トランクポートは常に信頼できるものとみなされます。
以下の例では、アクセス ポートを信頼できるものにしています。
ポートへのポートプロファイルは以下のようになります。
サイト設定とデバイス設定からDHCPスヌーピングのサイト/テンプレート設定を上書きするオプションがあります。
サイトの設定:
サイト設定とデバイス設定から、ポートプロファイルの信頼できる/信頼できない/デフォルトのオプションを上書きするオプションがあります。
サイトの設定:
デバイス設定:
DHCPスヌーピングを有効にすると、クライアントテーブルを確認するときにジュニパーMistクラウドにIPアドレス情報を表示できるようになります。キャンパスファブリックの導入とは異なり、このスイッチにはVRF設定はなく、純粋なレイヤー2フォワーダーです。そのため、スイッチは通常、デフォルトゲートウェイとしてARP解決を有効にしておらず、そのような情報を自動的に収集してジュニパー Mistクラウドに報告することはできません。
DHCP スヌーピングを設定するコマンド:
set vlans default forwarding-options dhcp-security
以下の例のように、スイッチ上でローカルにDHCPスヌーピングテーブルを確認するコマンド:
show dhcp-security binding
IP address MAC address Vlan Expires State Interface
10.33.33.10 d4:20:b0:xx:yy:zz default 0 REQUESTING ge-0/0/3.0
10.33.33.13 52:54:00:a1:d3:15 default 0 BOUND ge-0/0/5.0