cSRX IP の構成
CSRX でこの基本設定を構成します。正しい IP アドレスを割り当てるには、kubectl の MAC/IP アドレスマッピングを使用して pod コマンド出力について説明するだけでなく、デフォルトのセキュリティポリシーを設定して、すべてを許可するようにします。
set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/24 set interfaces ge-0/0/0 unit 0 family inet address 10.20.20.2/24
set security zones security-zone trust interfaces ge-0/0/0 set security zones security-zone untrust interfaces ge-0/0/1 set security policies default-policy permit-all commit
CSRX に割り当てられている IP アドレスを確認します。
root@csrx1-sc> show interfaces Physical interface: ge-0/0/1, Enabled, Physical link is Up Interface index: 100 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:71:f4:f2:8d, Hardware address: 02:84:71:f4:f2:8d
Logical interface ge- 0/0/1.0 (Index 100) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.10.10.0/24, Local: 10.10.10.2
Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 200 Link-level type: Ethernet, MTU: 1514 Current address: 02:84:8b:4c:18:8d, Hardware address: 02:84:8b:4c:18:8d
Logical interface ge- 0/0/0.0 (Index 200) Flags: Encapsulation: ENET2 Protocol inet Destination: 10.20.20.0/24, Local: 10.20.20.2
左ポッドで ping テストを実行しても、ルートが存在しないため失敗します。
左と右ポッドに静的ルートを追加してから、ping を再試行してください。
ルーティングにも対応しているため’、サービスチェーンを作成したので ping に失敗しています。私’たちのパケットに何が起こったのかを見てみましょう。
’CSRX にセッションがありません。Ping の問題をトラブルシューティングするには、このコンテナをホストするコンピュートノード cent22 にログインして、TShark を使用してトラフィックをダンプし、ルーティングを確認します。コンテナのリンクを取得するには、次のようにします。
[root@cent22 ~]# vif -l Vrouter Interface Table Flags: P=Policy, X=Cross Connect, S=Service Chain, Mr=Receive Mirror Mt=Transmit Mirror, Tc=Transmit Checksum Offload, L3=Layer 3, L2=Layer 2 D=DHCP, Vp=Vhost Physical, Pr=Promiscuous, Vnt=Native Vlan Tagged Mnp=No MAC Proxy, Dpdk=DPDK PMD Interface, Rfl=Receive Filtering Offload, Mon=Interface is Monitored Uuf=Unknown Unicast Flood, Vof=VLAN insert/strip offload, Df=Drop New Flows, L=MAC Learning Enabled Proxy=MAC Requests Proxied Always, Er=Etree Root, Mn=Mirror without Vlan Tag, Ig=Igmp Trap Enabled ...<snipped>... vif0/3 OS: tapeth0-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.252 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10760 bytes:452800 errors:0 TX packets:14239 bytes:598366 errors:0 Drops:10744 vif0/4 OS: tapeth1-89a4e2 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.1 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13002 bytes:867603 errors:0 TX packets:16435 bytes:1046981 errors:0 Drops:10805 vif0/5 OS: tapeth0-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.249 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:10933 bytes:459186 errors:0 TX packets: 14536 bytes:610512 errors:0 Drops:10933 vif0/6 OS: tapeth1-7d8e06 Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.1 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:12625 bytes:1102433 errors:0 TX packets:15651 bytes:810689 errors:0 Drops:10957 vif0/7 OS: tapeth0-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.47.255.248 Vrf:3 Mcast Vrf:3 Flags:PL3DEr QOS:-1 Ref:6 RX packets:20996 bytes:1230688 errors:0 TX packets:27205 bytes:1142610 errors:0 Drops:21226 vif0/8 OS: tapeth1-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.10.10.2 Vrf:6 Mcast Vrf:6 Flags:PL3DEr QOS:-1 Ref:6 RX packets:13908 bytes:742243 errors:0 TX packets:29023 bytes:1790589 errors:0 Drops:10514 vif0/9 OS: tapeth2-844f1c Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:10.20.20.2 Vrf:5 Mcast Vrf:5 Flags:PL3DEr QOS:-1 Ref:6 RX packets:16590 bytes:1053659 errors:0 TX packets:31321 bytes:1635153 errors:0 Drops:10421 ...<snipped>...
Vif0/3 と vif0/4 は、右ポッドにバインドされ、tapeth0-89a4e2 および tapeth1-89a4e2 にそれぞれリンクしていることに注意してください。Vif0/5、vif 0/8、Vif0/9 が cSRX1 に結び付けられている場合、左ポッドの場合も同様です。これにより、インターフェイスをヒットするパケット/バイトの数と VRF も確認できます。VRF 3 はデフォルトのクラスターネットワーク用であり、VRF 6 は左ネットワーク用、VRF 5 は適切なネットワーク用です。図10.3 では、すべての視点 (コンテナ、Linux、vr) からのインターフェイスマッピングを見ることができます。
左’ポッドから右ポッドへ ping を再試行し、右ポッドのタップインターフェイス上で tshark を使用して、さらに詳しく調査してみましょう。
Ping が右ポッドに’到達していないように見えます’。 cSRX’の左ネットワークタップインターフェイスを確認してみましょう。
パケットを見ることができますが、このパケットをドロップすると考えられる cSRX セキュリティはありません。
次のネットワーク VRF のルーティングテーブルをチェックして、コンピュートノードの vrouter_vrouter agent_1 コンテナにログインします。
[root@cent22 ~]# docker ps | grep vrouter 9a737df53abe ci-repo.englab.juniper.net:5000/contrail-vrouter-agent:master-latest "/entrypoint.sh /usr…" 2 weeks ago Up 47 hou rs vrouter_vrouter-agent_1 e25f1467403d ci-repo.englab.juniper.net:5000/contrail-nodemgr:master-latest "/entrypoint.sh /bin…" 2 weeks ago Up 47 hou rs vrouter_nodemgr_1 [root@cent22 ~]# docker exec -it vrouter_vrouter-agent_1 bash (vrouter-agent)[root@cent22 /]$ (vrouter-agent)[root@cent22 /]$ rt --dump 6 | grep 10.20.20. (vrouter- agent)[root@cent22 /]$
6が、左ネットワークのルーティングテーブル VRF であることに注意してください。同様に、適切なネットワーク VRF ルーティングテーブルにも同じことが言えますが、ルートが欠落しています。
したがって、すべてのポッドが同じコンピュートノードでホストされている場合’でも、それらを相互に接続することができます。また、これらのポッドがいくつかの異なるコンピュートノードでホストされている場合、解決すべき大きな問題が発生しています。サービスチェーン’では、コンテナのルートを調整するだけでなく、ポッドの位置に関係なく、コンピューティングノード間の vrouter 間のルート交換を行うこともできません。 (pod が別の計算ノードに移動した場合に自動的に調整されます)。Labbing サービスチェーン’が、この種の CLI トラブルシューティング…のファンではないネットワーク管理者にとって重要な懸念事項を解決する前に、Contrail コントローラ GUI を使用して同じトラブルシューティングを実行できます。
Contrail コントローラ UI から、> Infrastructure > 仮想ルーターを監視してから、次の画面Figure 2キャプチャに示すように、そのポッドをホストしているノードを選択します。
Figure 2は、vrouter_vrouter agent-1 コンテナで vif-l コマンドを実行した場合と同等の [Interface] タブを示していますが、さらに多くの情報を示しています。インスタンス ID の最初の6文字は常にタップインターフェイスの名前に反映されています。この名前とタップインタフェイスとの間のマッピングに注目してください。
Cowboys は、GUI を使用しています。’Figure 3のように、[ルート] タブに移動し、表示する VRF を選択して、各 VRF のルーティングテーブルを確認してみましょう。
左側のネットワークを選択します。この名前には、ドメイン (およびプロジェクト) が含まれているため、より長い時間がかかります。適切なネットワークからの 10.20.20.0/24 プレフィックスがないことを確認できます。また、左側のネットワークで学習した MAC アドレスを確認するには、L2 を選択する必要があります。 (rt--dump 6--family bridge コマンドと同等の GUI を使用します)。