セミナーのお申し込みはこちら！

本セミナーは終了しました。

【トレノケート共催】
回線切替じゃ不十分？ 90 分で体感する DevNet で拡げるインフラ管理の可能性！
【生実演】QoS 最適化も Automate ～要素検証、導入ステップ～

https://community.cisco.com/t5/-/-/ec-p/4498289

日時：2021年12月8日（水）10:00～11:30

費用：無料 

会場：オンライン（WebEx）

このような方におすすめです！

・DevNetを知りたいネットワークエンジニア
・ネットワーク管理のプログラマビリティに関心のある方
・ネットワークエンジニアとしてスキルアップしたい方　　　など

セミナー概要

本セミナーはCisco様との共催セミナーです。

●DevNetで何ができるか

●DevNetでどういう恩恵があるのか

を「回線トラブルとQoS変更」 を例に、弊社講師、吉田聡志によるオートメーション実装のデモンストレーションをご覧いただきながら理解できるセミナーです。

これからはNW業界もプログラミング時代に突入します。

ですが、どこから着手するかお困りの方もいらっしゃるかと思います。

勉強したい気持ちはあるが、自分の現状の職務内容と流行りの技術を比較してスキルアップをどうするか迷ってしまう、そんなお悩みを持つ方はぜひご参加ください

アジェンダ

1.　Cisco IOS XE で API を動かそう (RESTCONF、Postman)
2. 　Cisco ルータ を Linux にしよう (GuestShell、Python)
3. 　GuestShell に便利ツールをインストールしよう (requests、Git)
4. 　回線障害時に Python スクリプトを起動しよう (EEM、IP SLA、Track)
5. 　チャット bot で管理者に通知しよう (Webex Teams API)

スピーカー紹介

吉田 聡志 (Satoshi Yoshida)

トレノケート株式会社
Cisco 認定インストラクター CCSI
#2021DevNet 部門

プロフィール

SIerでコンピュータ インフラの構築業務に従事した後、現職に至る。 Cisco や Microsoft などのサーバー/ネットワーク インフラの研修コースを担当。 「楽して学ぶ、楽をするからたくさん学べる」を目標に、わかりやすい講義ができるように心がけている。

デモンストレーション内容について補足ご案内（2021年12月27日　追記）

セミナーでご紹介したデモンストレーション内容について、補足情報をこの場でご案内します。

技術要素の主たる領域はセミナー動画内もしくは資料のなかに収録してありますが、時間の都合で解説しきれなかった箇所やお手元で検証を進めるエンジニアがハマりがちな落とし穴について、文書という形式でこの場で補足させていただければ幸いです。

RESTCONFの自己署名証明書

CiscoルータでRESTCONFを有効化するためには、https通信のサポートが必要です。

RESTCONFそれ自体の仕組みとしては平文httpも許容されますが、Cisco IOS-XEとしては、SSL暗号化されたhttps通信のみをRESTCONFで容認する仕様であるようです。


そこで課題となるのが、SSLの証明書です。

Ciscoルータがhttpsサーバーとしてhttps通信を終端するため、秘密鍵とセットになったサーバー証明書が求められます。

幸いにして、Cisco IOS-XEは、秘密鍵とペアになった公開鍵を含む自己署名証明書を自動生成することができます。

デモンストレーション資料の中でもご紹介している次のコマンドを実行してください。


restconf
ip http secure-server


コマンドを実行すると、自己署名証明書の生成やhttps通信に必要なWebプラットフォームの設定が暗黙的に完了します。

しかし、あくまでここで生成しているのは自己署名証明書であり、PKIフレームワークとしての正道から外れたものであることに注意してください。

トラストアンカーとしてのCA保証のつかない証明書であるため、ご存じのとおり、いわゆる「警告がでる」類の証明書です。

人間が操作するWebアクセスであれば手作業で警告を無視するステップでこれを乗り切ることができるでしょう。

しかし、本セミナーのテーマである自動化の局面においては、警告が表示される通信というのはすなわちプログラム的にはNG通信として扱われます。

そのままでは、PostmanやPythonでhttps通信ができません。すなわちRESTCONFが動きません。


セミナーのなかではご紹介しきれませんでしたが、実は、デモンストレーション環境にはこの課題を回避するための措置が盛り込まれています。

Postman SSL certificate verification

PostmanからCisco IOS-XEルータにRESTCONF通信を成立させるためには、SSL証明書の検査を無効化する必要があります。

Postmanの[Settings]-[General]において、[SSL certificate verification]をOFFにしてください。

この変更により、Ciscoルータの自己署名証明書をPostmanが容認する挙動になり、RESTCONF通信が成り立ちます。

Python requestsライブラリのオプション

Postmanと同様の事情は、Python requestsライブラリにも演繹されます。

PythonからWebサーバー(Ciscoルータ)にhttps通信を開始した際にサーバーが自己署名証明書を提示した場合、デフォルトの挙動としてPythonはこれをErrorと判断して通信を強制終了させます。

これはPKIフレームワークの思想として正しい動作です。


ただ、今回のデモンストレーションのように、自己署名証明書の発行元サーバー(Ciscoルータ)を管理者が信頼しているならば、このErrorを回避したいところですね。

そのためのチューニング項目が、Pythonのrequestsライブラリには用意されています。

requestメソッドを実行する際の verifyオプションです。

verify=Falseとパラメータを指定することで、通信相手が提示した証明書に対する検証工程(verify)をSkip(無効化)することができます。

これにより、上でご案内したPostmanの[SSL certificate verification]をOFFにした措置と同等の挙動をPythonでも再現することができます。

GuestShellの有効化

IOS-XEのGuestShellを有効化するためには、IOS-XE側でapp-hosting（アプリケーション ホスティング）の構成が必要であることは、セミナーのなかでもご紹介しました。

オンプレミス環境におけるCisco IOS-XE搭載ハードウェアでGuestShellを検証するには、セミナー資料に記載した手順をそのまま踏襲していただけます。


ただし、一部のプラットフォームにおいては、GuestShellの検証を行う際にいくつかの事前情報を備えておいたほうが安全です。

今回のセミナーで私が利用したMicrosoft　AzureサービスにおけるCisco CSR 1000v ルータは、まさにその代表例といえるケースでしょう。


実は、AzureにおけるCSR1000vルータには、仮想マシン(ルータ)作成直後から利用できるGuestShell環境がすでにセットアップされています。

app-hostingを何も構成せずとも、

guestshell enable
guestshell

コマンドを実行するだけで、GuestShell環境を起動することができてしまいます。

その理由は、show runをご覧いただくことで明らかになります。

AzureでCSRを作成した直後にshow runを実行すると、app-hostingのconfigがすでに構成済みになっています。

これは、CSRにおけるプログラマビリティを普及させたいCisco社の親切設計であると言えるでしょう。

デモンストレーションでご覧いただいたとおり、app-hosingの構成には何ステップかの手順が求められます。


さて、このAzure Default GuestShell(勝手に命名)の構成コマンドですが、注意深く眺めていただくと、おもしろい箇所があります。

あえて VirtualPortGroup0 インタフェースにVRFを割り当てて、VRF間NATで物理NWと通信する仕様になっているんです。

はて。VRFは必要なのだろうか？ という疑問がわきあがってきます。

GuestShellから物理NWに通信するための要件としてNATの必要性は明白です。

しかし、VirtualPortGroup0インタフェースをわざわざグローバル ルーティングテーブルから分離したVRFに割り当ててVRF間NATを構成するのは、どうも冗長であるような印象がぬぐえません。


そこまでは、要らないんじゃない？ VRFなしでも動くでしょう？ ただでさえ面倒くさいGuestShellの有効化コマンドをこれ以上にややこしくするのは歓迎する気にならない。全インタフェースをグローバル ルーティングテーブルのまま単純にNATを構成してGuestShellの接続性を構成して済ませよう、それがイチバン簡単だ――……。


そう結論付けて行動するのは、ちょっと待ってください。

いや、やってみてもいいんですが、お手元で試す際には、必ず覚悟をきめてから、試してください。

VRFなしで単純NATを構成してみると、不思議な事件が発生します。
AzureのCSRにSSH接続ができなくなるんです。

一切合切の何もかもがつながりません。
ungともsungともpingともつながりません。


interface GigabitEthernet1
 ip nat outside


これを実行した途端、あなたは絶望に身をよじることになるでしょう。
説明する理屈がつかないですね。物理インタフェースでNATするこのip nat outside コマンドは、Azure Default GuestShellの構成でも入力されているコマンドです。

であるのに、それを手入力すると、CSRに対するあらゆる通信が途絶するんです。

なぜでしょう……？

これは残念ながら、 Azureクラウドのネットワークの仕様に基づく動作です。

Azureクラウドの基盤について私たち外部の人間が詳細を知ることはかないません。

しかし、公開されているAzureの仕様と検証結果から、私たちにとって腹落ちできそうな推測をたてて飲み干すことはできます。


Azureは、仮想マシンが勝手にIPアドレスを保有することを認めない挙動になっています。

「仮想マシンが通信で使用するIPアドレスは、Azureの管理ポータル側のconfigで指定したアドレスであること。いくらプライベートなNWとはいえ、無断でプライベートIPアドレスを使用することは認めない…」という制約です。


これは私の推測であると断ったうえで記述しますが、おそらくGratuitous ARPを発信した際に自身のIPアドレスとMACアドレスがAzureテナント基盤の登録と食い違っている場合、スイッチ側で通信を即座に遮断します。

これはMicrosoftがAzureのサービスを安定稼働させるための安全措置として設計したものなのでしょう。


そして、これはCSRのNATとひどく相性が悪いようです。
VRF間でない単純NATを構成すると、それをトリガーとして物理インタフェースからお目覚めのARPが発信されて、Azure側からは不穏なconfigを保有したものと危険視されてNWが全停止状態になるようです（事実です）。

VRF間NATであれば、Azureから訝しがられないARPを発信するような、微妙な違いがそこにはあるようです（推測です）。


単純NATをAzureで構成したとたんにSSHが途切れて涙したことのある人は、ぜひ試しにVRF間NATを構成してみてください。

不思議なもので、VRF間NATであれば、Azureの監視を潜り抜けて疎通を保つことができます（検証できる事実です）。


つまり、Azure Default GuestShellが仕込んでいるVRFを含めたapp-hostingのためのNATは、これらの状況を踏まえたうえで選択された最適解の構成であるといえるわけですね。

これを知らずにAzureでCSRの検証にいそしむと、滂沱の涙を舐めることになるでしょう。

では、お気をつけて、いってらっしゃいませ。