ひよっこエンジニアの備忘録

日常とかSEとしての備忘を書いていきます。

CDP/LLDP

[CDP/LLDPとは]

隣接する機器に対して、自分の機器情報をアドバタイズするために使用するL2プロトコル

・CDP(Cisco Discovery Protocol)
シスコ独自プロトコル、デフォルトで有効。
・LLDP(Link Layer Discovery Protocol)
IEEE802.1ABで定義されたマルチベンダ対応プロトコル、デフォルト無効。

LLDPの拡張版としてLLDP-MED(LLDP Media Endpoint Discovery)がある。
LLDP-MEDはエンドポイントデバイス(IP Phone等)とネットワークデバイス(スイッチ等)の間で
動作するプロトコル

CDPとLLDPの機能差異
f:id:nrlay00:20170201234637j:plain


⇛あまりにもまとめ方が適当すぎたので下記追記
取得可能な情報は以下
CDP
→version1と2で取得内容に差異あり
デフォルトでversion2が有効

info description
Device-ID 隣接デバイスのホスト名
Local Interface 自身のインターフェース情報
Holdtme CDP情報を保持する時間 (デフォルト:180秒)
Capability 隣接デバイスのデバイスタイプ (スイッチの場合:S)
Platform 隣接デバイスのモデル情報(例:CISCO2921)
Port ID 隣接デバイスのインターフェース情報(例:Gig0/1)
Address 隣接デバイスネットワーク層のアドレス
IOSSoftware 隣接デバイスIOSソフトウェア、バージョン情報

↓以下version2のみ対応↓

VTP Domain 隣接デバイスのVTPドメイン名(only CDPv2)
Native VLAN 隣接デバイスのネイティブVLANの情報(only CDPv2)
Full/Half Duplex 隣接デバイスのインターフェースのDuplexの情報(onlyCDPv2)

[CDP/LLDPのメリット・デメリット]

メリット
 IPアドレス/機種/自分&対向機器の接続ポート/IF情報などが知れる。
 隣接機器の情報が知れるため、実質L1レベルの確認も可能(ケーブル接続が正しいか)
デメリット
 cdp/lldpパケットは暗号化されないため、設定情報が盗聴されるリスクあり。
 必要なければ無効にしておくこと推奨。

[コマンド]

コマンドはCDP/LLDPで結構酷似している。

設定コマンド
・機器全体で有効にする
cdp lldp
(config)# cdp run/(config)# lldp run

・ポート単位で有効にする
cdp    lldp
(config-if)# cdp enable/(config-if)# lldp enable

基本的に無効にしたければ先頭に「no」をつけるだけだが、
ポート指定でLLDPの送受信を無効にする場合は、、

(config-if)# no lldp receive(受信)
(config-if)# no lldp trancemit(送信

と若干書き味が違うので注意。


確認コマンド
下記コマンドで知りたいことは大体わかるかと。

sh cdp nei
sh cdp nei de
sh lldp nei
sh lldp nei de

cdpとlldpで若干取得結果は違うようです。
f:id:nrlay00:20170202001301p:plain


簡単ですがCDP/LLDPはこんな感じ。
Cisco独自、マルチベンダがそれぞれどちらを覚えて
なおかつHellotimeとHoldtimeの違いを理解できれば大丈夫かと思います。
(正直実務では無効に設定しているところが多いかと思うので)

AAA(AuthenticationAuthorizationAccounting)

[AAAとは]

Authentication(認証)、Authorization(認可)、Accounting(アカウンティング)の略称。
これら3つの異なるセキュリティ機能を設定するためのアーキテクチャ上の枠組みのこと。

Authentication

→ユーザー名/パスワードを確認しネットワークにアクセスするための認証。

※認証オプション
サービスタイプ
・login(コンソール、telnetssh
・ppp(ppp認証)
方式リスト
・任意のリスト名(特定のinterface、lineに適用される。)
・default(全interface、lineに適用される。)
認証方式
・local(ローカルデータベース)
・group radius(RADIUSサーバ)
・group tacacs(TACACS+サーバ)
・none(認証なし)
・group (任意のグループ名にAAAサーバ軍を関連付けたもの)

Authorization

→何の実行を許可するかの権限割当て

Accounting

→ユーザの履歴を記録(ログ情報収集や課金管理等)
※AAAの実装は、IEEE802.1X認証とセットでよく使用されるのでIEEE802.1Xもあわせて覚えておくこと。

AAAがCiscoルータやCatalystなどで実装される場合、セットで
RADIUSサーバやTACACS+サーバが使用される。

またRadiusサーバなどリモートサーバ認証だけでなくローカル認証も可能。
(ルータのコンソールポート、補助ポート、vtyポートへのアクセス認証など)
ただしローカル認証ではAAAで実装できる範囲、拡張性、柔軟性が乏しい。

AAAのイメージ図
f:id:nrlay00:20170109042732p:plain

用語

サプリカント(Supplicant)

IEEE802.1Xにおけるクライアントのこと。またはクライアントに
インストールするソフトウェア。
認証を受けるクライアントはPCにインストールする必要があるが、
最近のPCには標準搭載されている。

認証装置(Authenticator)

サプリカントと認証サーバの仲介役となるネットワーク機器
IEEE802.1X対応のLANスイッチまたは無線LANアクセスポイントのこと。
(イメージ的にはサプリカントと認証サーバ間のプロキシとして動く)

これらの機器はサプリカントと認証サーバとの認証結果を受けて、ネットワークへの
アクセス制御を行う。Ciscoは有線/無線LANスイッチともにIEEE802.1Xに標準対応。

認証サーバ(Authentication Server)

ユーザ認証を行うサーバのこと。IEEE802.1X/EAPに対応したRadiusサーバを使用する。

EAP(Extensible Authentication Protocol)

PPP(Point-to-Point Protocol)を拡張したプロトコルであり、
データリンク層プロトコルと認証プロトコルの仲介役となる。

CA(認証局

証明書を発行するための機関。

AAAを実装するメリット

集中管理 その1

CiscoルータやCatalystへのログイン認証用として、
ローカルにline vty やenableパスワードを設定せずに
認証用のユーザID/パスワード情報を認証サーバ側で
一括管理することができる。
※AAAを実装してローカルで管理する設定も可。

集中管理 その2

ネットワークにアクセスする認証用のユーザ/パスワードを
ローカルデータベースで管理せずにRADIUSサーバで
一括管理することができる。
※ AAAを実装してローカルで管理する設定も可。

RADIUSのサポート

AAAを実装することにより、標準規格であるRADIUSプロトコル
サポートされるようになる。(TACACS+はcisco独自)
これによりCisco ISEなどのRADIUSサーバだけでなく、MSなど
他メーカーのRADIUSサーバを使用して認証ができるようになり
マルチベンダーの認証、認可環境を構築することができる。


AAAフロー


f:id:nrlay00:20170110075224p:plain

設定

1. AAAの有効化

(config)#aaa new-model
※AAAが無効の状態だとaaa authentication等のAAA関連のコマンドが弾かれる。

2. 認証を行うRadiusサーバのIPアドレスとキーの指定

(config)#radius-server host {IPアドレス} [key {キー}]

3. IEEE802.1xの認証方法を定義

(config)#aaa authentication dot1x default group radius
※通常はradiusを指定し、2で指定したRadiusサーバにて認証を行う)

4. IEEE802.1xをグローバルで有効化

(config)#dot1x system-auth-control

5. インターフェースのアクセスポート化(IEEE802.1xはアクセスポートにのみ設定可能)

(config)#interface {インターフェース}
(config-if)#switchport mode access

6. IEEE802.1xのポートの状態を指定

(config-if)#dot1x port-control {auto | force-authorized | force-unauthorized}

・auto 
radiusでの認証が成功すれば許可ステートへ
 認証失敗となれば無許可ステートへと移行する。
・force-authorized 
→強制的に許可ステートへ移行しフレームを送受信する。
 (つまり認証不要でサービスが使える)
・force-unauthorized
→強制的に無許可ステートへ移行しフレームを送受信させない。
 (authorizedの逆でどの端末を繋いでもサービスは使えない。)




#AAAに関しては、正直自分の理解力が足りず完全に理解できていない。
 あとでしっかり見直さないとだめですね。。

SPAN(Switched Port ANalyzer)

[SPANとは]

パケットキャプチャを行う際にCatalystスイッチに実装するミラーリング機能のことです。
Catalystではポート上またはVLAN上を流れるトラフィックを、SPANを利用することにより
Wiresharkが入ったPCに接続しているポートに、トラフィック(パケット)のコピーを送信できる。
※STP(SpanningTreeProtocol)と雰囲気似ているが別のプロトコルなので注意。

▼SPAN用語

・送信元ポート      パケットキャプチャの対象となるポート。VLANを送信元とすることも可能。
・宛先ポート      ネットワークアナライザを接続するポート。SPAN専用ポートにする必要がある。
・NWアナライザ WireSharkSnifferなどのパケットキャプチャソフトがインストールされたPC。

パケットのコピーを送信するだけなのでコンフィグ設定を間違えない限り、SPANの設定が
既存通信に影響を与えることはない。(宛先ポートの指定先があっている前提だが)
#PCにアドレスをいようがなかろうが問題ない(コンソール接続を想像すればいいかも)

この宛先ポートはSPAN専用ポートにする必要がある。SPAN専用ポートではSPANセッションの
トラフィック以外を受信したり送信したりすることはない。
送信元にVLANを指定することもできるが、VLANと物理ポートの双方を設定することはできない。

簡単に図を作ってみたがこんなイメージ
f:id:nrlay00:20170109004829p:plain

PC1..SPAN送信元の入力部分(モニタ対象)
PC2..SPAN送信元の出力部分(モニタ対象)
PC3..SPAN宛先(モニタポート)


SPANには大きく分けて以下2種類がある。
・ローカルSPAN
 →単一スイッチ上の送信元/宛先ポートをサポート
・リモートSPAN(RSPAN)
 →複数スイッチを介した送信元/宛先ポートをサポート
※ちなみに上図はローカルSPAN

[リモートSPAN(RSPAN)概要]

RSPANは複数スイッチ上で行うSPANのこと。RSPANで指定する送信元ポート or 送信元VLAN、
宛先ポートはNW上の複数のスイッチにまたがることが可能。

RSPANではRSPAN用のVLANを存在させる必要があり、RSPANを行う全てのスイッチ上で
RSPAN用VLANを作成する必要がある。(なおRSPAN VLANはトランクポートで伝達する必要あり)


f:id:nrlay00:20170109021646p:plain

[SPAN設定]

ローカルSPAN設定

新しくSPANセッションを作成するためには下記を指定する。
・送信元ポート/VLAN(モニターされる側)
・宛先ポート(モニターする側)
※既存のSPAN設定が存在する場合は、no monitor sessionによって既存SPAN設定を削除しなければならない。 

◆ 送信元ポート・送信元VLAN - monitor sessionコマンド

(config)# monitor session number source [ interface id | vlan id ] [ , | - ] [ both | rx | tx ]

number    :SPANセッションのセッション番号。1 ~ 66 まで指定することができる。
interface id :モニターする対象となるポート番号。
vlan id    :モニターする対象となるVLAN番号( interface を指定した場合は vlan は指定しない )
both    :送受信トラフィックをモニターする ( デフォルトの設定 )
rx    :あるいは、受信トラフィックのみをモニターする。
tx    :あるいは、送信トラフィックのみをモニターする。

◆ 宛先ポート - monitor sessionコマンド

(config)# monitor session number destination [ interface id ] [ , | - ] [ encapsulation replicate ]

number    :SPANセッションのセッション番号。sourceで指定したものと同じ値を指定する。
interface id :ネットワークアナライザが接続するポート番号。
encapsulation replicate:
  タグ付きのトラフィックを受信したい場合に指定する。これを指定しない場合
  デフォルトでタグなしの状態でパケットが宛先ポートに転送されることになる。

filter vlanコマンドを使用することにより、トランクポート上で受信するトラフィック対象の
VLANトラフィックを指定することができる。

ex)2-6までのVLANをフィルタリング
Catalyst(config)# monitor session 1 source interface FastEthernet 0/1
Catalyst(config)# monitor session 1 filter vlan 2 - 6
Catalyst(config)# monitor session 1 destination interface FastEthernet 0/24 encapsulation replicate

リモートSPAN設定

1.RSPAN用のVLANを新規作成(RSPANを実装する全てのCatalystにRSPAN用VLANを作成すること)

 SW1(config)# vlan [vlan id]
 SW1(config-vlan)# remote-span

2.RSPAN送信元|宛先セッション番号を送信元ポートorVLAN|宛先ポートに関連付ける。

▼送信元
SW1(config)# monitor session number source [ interface id | vlan id ] [ , | - ] [ both | rx | tx ]
▼宛先
 SW2(config)# monitor session number source remote vlan id

3.RSPAN送信元|宛先セッション番号をRSPAN VLANに関連付ける。
 
▼送信元
SW1(config)# monitor session number destination remte vlan id
▼宛先
 SW2(config)# monitor session number destination [ interface id ] [ , | - ] [ encapsulation replicate ]


特筆すべきローカルSPANセッションとRSPANセッションの仕様
・同じSPANのセッションにモニター対象ポートの「送信元ポート」と「送信元VLAN」を混在させられない。
・1つのSPANセッションに複数の宛先ポートを設定できるが、指定できる最大の宛先ポートは「 64 」個。
Catalystスイッチは最大2つの送信元セッション( ローカルSPANとRSPANの送信元セッションの2つ )を
サポートする。従って、同じスイッチ内でローカルSPANの実行とRSPANの実行が1つずつ可能である。
・SPANでキャプチャされる受信トラフィックは、スイッチが変更または処理を行う前のパケット
・SPANでキャプチャされる送信トラフィックは、スイッチが変更または処理を行った後のパケット

★LAGインターフェースは送信元には設定できるが、宛先には設定できない。
★宛先に指定したインターフェースはSTPに参加できない。
★異なるセッションでは送信元は同じポートを指定できる、宛先は共有することができない
→例えば下記configを投入するとセッション1は正しく設定されるが、セッション2は
 後から重複した宛先を指定したため宛先が設定されず不完全となる。

 ----------------------------------------------
 monitor session 1 source int fa0/1
 monitor session 1 destination int fa0/24
 monitor session 2 source int fa0/1
 monitor session 2 source int fa0/2
 monitor session 2 destination int fa0/24
 ----------------------------------------------


[確認コマンド]
SPANステータスの確認
→show monitor session [session number]

RSPAN VLANの確認
→show vlan remote-span

宛先ポートはshow int上で line protocol is down(monitoring)と表示される。


#SPANについてはpackettracerでもgns3でもコマンドが検証できなかった。
どの書籍みてもRSPAN VLANは999で作成してるみたいだけど
たまたまなのか、999でしかできないのか分からない。。。
999が予約vlanと聞いたことはないので多分なんでも良さそうは気はするけど。。


12月は仕事が残業ばかりで終電帰りが多くほとんど勉強できてなかったのですが、
勉強を再開します。
(上司に資格取得状況を聞かれ、勉強できてないことを白状したらブチ切れられました^^;)

FWとかACLのチェックツール的なもの

がほしいと思う今日この頃。

最近維持管理の業務としてSSG5のポリシー追加/削除を担当することが多い。
どこの会社もそうだと思うけど、機器の設定変更作業はこんな流れで行うと思う。
①要件確認
②作業資料作成(手順書、config、その他)
③レビュー
④作業

レビューでは責任ある立場の方へ要件、手順、設定configの内容を説明し、
作業実施の承認をもらわなければならない。

当然要件確認や作業資料が適当だと死ぬほど怒られるので
要件確認や既存config確認には結構力を入れるのだが、ビジネスで
利用しているだけあって既存configが尋常じゃなく長い。。

更にpermitのみではなく途中行にdenyの設定がちらほら入っているため、
確認に手間がかかってしょうがないのだ。。
(もちろん手間をかけるべき工程であることは理解しているが。。)


既存configの必要な部分とパケットに必要な情報を読み込ませて、
このパケットはちゃんと透過できますとか、ここで弾かれますとか
確認できるツールないかな。。

アプリの知識があれば自作できそうな気がしなくもないので、
検索のロジックを少し調べてみるか。。

EtherChannel

[EtherChannelとは]
複数の物理リンクを束ねて1つの論理リンクとして扱える技術のこと。

以下図のイメージだと物理的に3本リンクがあるが、これを論理的に1本に見立てて利用する。
f:id:nrlay00:20161117222655p:plain

一般的にはLAG(Link Aggregation)と呼ばれ、「IEEE802.3ad」にて標準化されている。
これをCiscoではEtherChannelと呼ぶ。
ちなみにリンクの速度によって、GigabitEtherChannel=「GEC(ゲック)」、
FastEtherChannel=「FEC(フェック)」と表記される場合あり。FAと間違えないように!

更にややこしいのが、CiscoスイッチのCatalystではこれをPort-Channelと呼ぶので注意。。

[EtherChannelのメリデメ]
まずメリットとしては以下
・利用可能な帯域幅を増やせる。
 →例えばGigabitethernet(1Gbps)3ポートでEtherChannelを組むと、、
  単純計算で3Gbps使えることになる。
・障害に強くなる。
 →1本に障害が発生しても残りの物理リンクで通信が継続できるようになる。
  リンク3本のEtherchannelで1つのポートの故障した場合、当然リンクダウンが
  発生するのだが、残りの2リンクで通信を継続することができる。 
・複数リンクを論理的に束ねて1リンクと見立てるので、ループの考慮は不要。

デメリットとしては複数ポートを消費してしまうことぐらいか。

帯域幅および障害耐性がアップするため、通信が集中する重要箇所に
適用される技術ということが想像できる。

[EtherChannelの種類]
大きく2つに分けると以下
・手動EtherChannelを有効にするスタティック
・スイッチ間でネゴシエーションプロトコルを利用し動的に
 EtherChannelを有効にするダイナミック

またダイナミック型はIEEE802.3adで標準化されている「LACP」と
Cisco独自プロトコルの「PAgP」がある。

PAgPは1つのEtherChannelに最大8のポートをバンドル(束に)出来る。
Cisco独自プロトコルのため、非Cisco機器とは接続できないので注意。

LACPはMAX16のポートをバンドルできるが、実際にアクティブなポートになるのは
最大8つのプライオリティ値の低いポートとなる。プライオリティ値の高いポートは
スタンバイ状態となり、アクティブなポートがダウンした場合に有効なる。
なおLACPは標準プロトコルなので、非Ciscoバイスとの接続にも使用可能。

【EtherChannelのモード】
f:id:nrlay00:20161117233815j:plain

【EtherChannelモードと組み合わせ】(○がEtherChannel形成)
f:id:nrlay00:20161117233833j:plain

ネゴる際はactive,desirableが主導、passive,autoは受動的。
LACPの場合、active-activeまたはactive-passiveであればLAGを組めるが
passive-passiveの場合はどちらもネゴりにいかなくLAGを組めない。

【ロードバランシング方式】
(config)#port-channel load-balance {src-ip | dst-ip | src-dst-ip | src-mac | dst-mac | src-dst-mac}

f:id:nrlay00:20161117233839j:plain

【EtherChannelでポートをバンドルする際に共通にする必要がある設定】
・イーサーネットメディアタイプ
・速度とデュプレック
・スイッチポートの種類(アクセスポート/トランクポート/レイヤ3ポート)
・割り当てるVLAN(アクセスポートの場合)
・ネイティブVLANと搬送するVLANの範囲(トランクポートの場合)
・トランキングモード(トランクポートの場合)
EtherChannelを形成した後にポートで上記の設定を変更すると、そのポートはバンドルから外れる。

DHCP

[DHCPとは]
ネットワーク接続するのに必要なIPアドレス等の情報を自動的に割り当てる
アプリケーション層プロトコル

構成要素としては以下2種類に分けられる。
IPアドレス等を割り当てる側のDHCPサーバ(bootps/UDP:67)
IPアドレス等を割り当てられる側のDHCPクライアント(bootpc/UDP:68)
#server..s cliant..cで覚える

[設定項目]
IPアドレスの割り当て範囲(アドレスプール)
サブネットマスク
デフォルトゲートウェイアドレス
DNSサーバアドレス
・リース期間(アドレスの貸出期間)
IPアドレスの除外範囲(一部のアドレスレンジを配布しないよう設定可)


[DHCPの動作]
DHCP Discover
Cliant:68→Server:67(ブロードキャスト)
 ブロードキャストでネットワーク全体に問い合わせ。
  (DHCPサーバを見つける)
DHCP Offer
  Server:67→Cliant:68(ユニキャスト)
   サーバがクライアントへ割り当てるアドレスを提案。
   (DHCP Discover送信者への返信になるのでユニキャスト)
DHCP Request(ブロードキャスト)
  Cliant:68→Server:67(ブロードキャスト)
クライアントが提案されたIPを使用する事をNW全体へ通知。
DHCP Ack(ユニキャスト)
  Server:67→Cliant:68(ユニキャスト)
  サーバが設定情報をクライアントへ送信。

DHCPメッセージはブロードキャストを使用するためLAN内でのみ使用できる...のだが、
セグメントごとにDHCPサーバを置くのは運用が大変だし何よりお金がかかりまくる。。


そんなときに"DHCPリレーエージェント"を使うことで上記の悩みを解決できる。

DHCPリレーエージェントとは、サーバとクライアントが別セグに設置されていても
クライアントから受信したブロードキャストをユニキャストへ変換することができる機能。
※飽くまでも道路を作るだけの機能なので、別途サーバ側でセグメントごとにPool等設定が必要。

今はデータセンターのDHCPサーバを利用するために、拠点のルータとかL3SWに
リレーエージェントの設定を入れているような企業がほとんどかと思う。


[設定例]

CiscoルータをDHCPサーバとして利用する

(config)# service dhcp
    → DHCPサービスの有効化(デフォルトで有効?)
(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.20
    →クライアントに付与しないアドレス範囲を設定
        #この例だと192.168.10.1~20は割り当て対象から除外される。)
(config)# ip dhcp pool OA-LAN-A
    →プール名の指定
(dhcp-config)# network 192.168.1.0 255.255.255.0
    →貸出範囲のアドレス/サブネットマスクを定義。
#ちなみにexcludedで定義したアドレス範囲は除外される。
(dhcp-config)# default-router 192.168.10.254
デフォルトゲートウェイの設定
(dhcp-config)# domain-name TEST-OA
DNSドメイン
(dhcp-config)# dns-server 192.168.200.254
DNSサーバアドレス
(dhcp-config)# lease 3
→貸出時間制限(ここでは1日) 割り当て後、1日はアドレスを使用可能。
      infiniteと入力することで時間無制限にできる。

★リレーエージェント設定
(config)# service dhcp
     → DHCPサービスの有効化(デフォルトで有効?)

(config)# interface Gi0/0
(config-if)# ip helper-address 192.168.100.100
DHCPサーバのアドレスを指定。
      (interfaceはクライアント側を指定すること)







gns3 検証環境作成

今後の学習用に軽く検証環境を作ってみた。

f:id:nrlay00:20160923000556p:plain



上記の構成をざっくり説明すると各ルータ間はEIGRPで通信させ、

testRT010-01にはNTPサーバの設定を入れている。

検証内容によって適宜変更する予定だが、この検証環境をベースに必要な箇所を弄る感じで良いでしょう。

  • testRT001-01



  • testRT000-01


  • testRT010-01

※testRT001-02はtestRT001-01とほぼ同一configなので割愛


ちなみにtestRT000-01はIOUを使ってL3スイッチとして動作させているのだが

はじかれるコマンド(設定/確認双方)が多く少し落胆…

また、一回プロジェクトを保存してからプロジェクトを再回すると
かなり面倒であることがわかってしまった。


何が面倒かというと…
gns3のプロジェクトは以下操作でプロジェクトを保存できる。
※全機器write memory→全機器停止→プロジェクト保存
 (全機器停止させなければ保存/終了はできない)

プロジェクト再開すると各機器のcofigはIOU以外残っているのだが、

時刻設定が狂ってしまう…

まあNTPの勉強時以外あまり時刻を気にする必要はないし、
常時起動しっぱなしって訳でもないので仕方ない気はしてるが…


問題は上にちらっと書いたがIOUのconfigは初期化されてしまう:(
おそらくVMに依存するためだと思うが、testRT000-01は時刻設定だけでなく
全設定やり直しが必要なのだ。


という訳でtestRT000-01のみリブート対応用に投入cofig作成。


IOU以外の機器はちゃんとwrite memしていればconfigが消えることはないと思っているが、
一応gns3起動時と終了前にそれぞれログを取ることに決めた。


機種別にログ取得コマンドを作成したものの、いちいちログ取得開始からの
コマンド貼り付けするのも面倒なのでいずれマクロでも作る予定。


teratermマクロは詳しくないけど、gns3には仮想環境と物理環境を
接続する機能があるみたいですね。

とりあえず以下のイメージでいけるんじゃないかと構想はしている。
①仮想環境側の機器別ipアドレスリストを作成
②物理環境側でターミナルソフト(teraterm)立ち上げ
③物理環境側のターミナルソフト(teraterm)からマクロ実行
ipアドレスリストを開き順次telnet&ログ取得コマンド入力実施

teraterm のマクロって言語的には何にあたるんだろう…?)

本当はNTPの動きを色々見てみようと思っていたのだが、それはまた後日やろうと思う。
今日はひとまず基本動作確認までで終了。


IOUのL3はルータの多ポート版と割り切ったほうが良さそうです。
(少なくとも私の持っているバージョンでは。。。新しいIOSであれば
 もしかしたら改善されているのかもしれないが。)
まあたかだか検証だしやりたい動きが実装できればまあいいか…