ここでは SD-WAN で使われる OMP の大まかな流れと基本的なトラブルシュートのコマンドを紹介します。 OMP は各サイト内の経路情報をお互いが学習するのに SD-WAN では使われています。 上の図のように OMP によって学習される経路は Edge から vSmart、vSmart から他の Edge へと vSmart を経て配布されていきます。そのため OMP で経路が思ったように学習されないなどの場合は Edge だけでなく、vSmart も確認する必要があります。 例として、vSmart で経路を Edge から受け取っているか、vSmart は経路を Edge に広報しているかを確認してみましょう。 下記のように RECEIVED FROM と ADVERTISED TO というような表示があります。 vsmart# show omp routes 10.0.0.0/24 detail --------------------------------------------------- omp route entries for vpn 10 route 10.0.0.0/24 --------------------------------------------------- <snip> RECEIVED FROM: peer 10.10.10.1 path-id 81 label 1002 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.10.10.1 type installed tloc 10.10.10.1, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 10 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set ADVERTISED TO: peer 10.10.10.2 Attributes: originator 10.10.10.1 label 1002 path-id 75 tloc 10.10.10.1, default, ipsec ultimate-tloc not set domain-id not set site-id 10 overlay-id 1 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set <snip> また、Edgeでも show omp routes の RECEIVED FROM を参照することで経路を受け取っているかを確認することができます。 シスコへお問い合わせ頂く際にもこの辺りの情報を前もってそろえて頂けると非常に助かります。 参考： コマンドの出力例などはガイドにもありますので合わせて参照頂くと参考になると思います。 OMP Path Selection Problem when Egress Path is Enforced on vEdge Cisco SD-WAN Command Reference : Chapter: Operational Commands コマンドリスト： vSmart show omp routes show omp routes x.x.x.x/y detail cEdge show sdwan control connections show sdwan bfd sessions show ip routes vrf * show sdwan omp routes vEdge show control connections show bfd sessions show ip route show omp routes 以上。   ... View more

  ここでは SD-WAN で使われる OMP の大まかな流れと基本的なトラブルシュートのコマンドを紹介します。 OMP は各サイト内の経路情報をお互いが学習するのに SD-WAN では使われています。   OMP で経路が思ったように学習されないなどの場合は Edge だけでなく、vSmart も確認する必要があります。 vSmart で経路を Edge から受け取っているか、vSmart は経路を Edge に配布しているかを確認します。 下記のように RECEIVED FROM と ADVERTISED TO というような表示があります。 vsmart# show omp routes 10.0.0.0/24 detail --------------------------------------------------- omp route entries for vpn 10 route 10.0.0.0/24 --------------------------------------------------- <snip> RECEIVED FROM: peer 10.10.10.1 path-id 81 label 1002 status C,R loss-reason not set lost-to-peer not set lost-to-path-id not set Attributes: originator 10.10.10.1 type installed tloc 10.10.10.1, private1, ipsec ultimate-tloc not set domain-id not set overlay-id 1 site-id 10 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set ADVERTISED TO: peer 10.10.10.2 Attributes: originator 10.10.10.1 label 1002 path-id 75 tloc 10.10.10.1, default, ipsec ultimate-tloc not set domain-id not set site-id 10 overlay-id 1 preference not set tag not set origin-proto connected origin-metric 0 as-path not set unknown-attr-len not set <snip> また、Edgeでも  show omp routes の RECEIVED FROM を参照することで経路を受け取っているかを確認することができます。 シスコへお問い合わせ頂く際にもこの辺りの情報を前もってそろえて頂けると非常に助かります。 参考： コマンドの出力例などはガイドにもありますので合わせて参照頂くと参考になると思います。 OMP Path Selection Problem when Egress Path is Enforced on vEdge Cisco SD-WAN Command Reference : Chapter: Operational Commands 以上。   ... View more

NHRPに焦点を当てたシリーズです。 NHRP シリーズ : その1 NHRP とは？ その2、として実際の動作をMultipoint GRE(IPsecなしのDMVPN)構成で見ていきます。 NW構成は下記になります。   基本動作の確認 各ルータの状況は下記の通りです。 NHRPでTunnelのIPとNBMA(物理)のIPアドレスの紐づけができています。 NHRPのサーバであるHubに登録された状況です。 Spoke同士のLoopback 192.168.3.3と192.168.4.4のNexthopはHubの10.10.10.2になっています。 Spoke同士が通信するにはHubを経由する状況です。 [Hub] R2#sh ip route <snip> Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/3.10 L 10.10.0.2/32 is directly connected, GigabitEthernet0/0/3.10 C 10.10.10.0/24 is directly connected, Tunnel10 L 10.10.10.2/32 is directly connected, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets C 192.168.2.2 is directly connected, Loopback10 192.168.3.0/32 is subnetted, 1 subnets D 192.168.3.3 [90/27008000] via 10.10.10.3, 00:14:52, Tunnel10 192.168.4.0/32 is subnetted, 1 subnets D 192.168.4.4 [90/27008000] via 10.10.10.4, 00:13:37, Tunnel10 R2#sh ip nhrp 10.10.10.3/32 via 10.10.10.3 Tunnel10 created 00:16:39, expire 00:09:34 Type: dynamic, Flags: registered nhop NBMA address: 10.10.0.3 10.10.10.4/32 via 10.10.10.4 Tunnel10 created 00:15:37, expire 00:07:42 Type: dynamic, Flags: registered nhop NBMA address: 10.10.0.4 R2#sh ip cef | in 192.168. 192.168.2.2/32 receive Loopback10 192.168.3.3/32 10.10.10.3 Tunnel10 192.168.4.4/32 10.10.10.4 Tunnel10 [Spoke] R3#sh ip route <snip> Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/3.10 L 10.10.0.3/32 is directly connected, GigabitEthernet0/0/3.10 C 10.10.10.0/24 is directly connected, Tunnel10 L 10.10.10.3/32 is directly connected, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets D 192.168.2.2 [90/27008000] via 10.10.10.2, 00:17:10, Tunnel10 192.168.3.0/32 is subnetted, 1 subnets C 192.168.3.3 is directly connected, Loopback10 192.168.4.0/32 is subnetted, 1 subnets D 192.168.4.4 [90/28288000] via 10.10.10.2, 00:15:54, Tunnel10 R3#sh ip nhrp 10.10.10.2/32 via 10.10.10.2 Tunnel10 created 00:17:48, never expire Type: static, Flags: NBMA address: 10.10.0.2 R3#sh ip cef | in 192.168. 192.168.2.2/32 10.10.10.2 Tunnel10 192.168.3.3/32 receive Loopback10 192.168.4.4/32 10.10.10.2 Tunnel10 [Spoke] R4#sh ip route <snip> Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/2.10 L 10.10.0.4/32 is directly connected, GigabitEthernet0/0/2.10 C 10.10.10.0/24 is directly connected, Tunnel10 L 10.10.10.4/32 is directly connected, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets D 192.168.2.2 [90/27008000] via 10.10.10.2, 00:16:57, Tunnel10 192.168.3.0/32 is subnetted, 1 subnets D 192.168.3.3 [90/28288000] via 10.10.10.2, 00:16:57, Tunnel10 192.168.4.0/32 is subnetted, 1 subnets C 192.168.4.4 is directly connected, Loopback10 R4#sh ip nhrp 10.10.10.2/32 via 10.10.10.2 Tunnel10 created 00:17:18, never expire Type: static, Flags: NBMA address: 10.10.0.2 R4#sh ip cef | in 192.168. 192.168.2.2/32 10.10.10.2 Tunnel10 192.168.3.3/32 10.10.10.2 Tunnel10 <<R2がNexthop 192.168.4.4/32 receive Loopback10 NHRPの動作をみるために、 ここでR4からR3へTracerouteをしてみます。 Spoke同士なのでHubを経由しなくてはなりません。 初めはHubのR2を経由します。 R4#traceroute 192.168.3.3 so lo10 Type escape sequence to abort. Tracing the route to 192.168.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.10.2 0 msec 1 msec 0 msec 2 10.10.10.3 1 msec * 0 msec 2回目。 ここではR2:Hub:10.10.10.2を経由しなくなりました。 R4#traceroute 192.168.3.3 so lo10 Type escape sequence to abort. Tracing the route to 192.168.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.10.3 0 msec * 0 msec R4の状況を改めて確認してみましょう。 Routing tableには次のような変化があります。 H 10.10.10.3/32 D % 192.168.3.3 HはNHRPにより作られた新しいエントリです。 %はnext hop overrideでNHRPによりNexthopが上書きされます。 (sho ip routeにnext-hop-overrideのオプションを付けるとNHOの表示が出ます。) R4#sho ip route next-hop-override <snip> 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/2.10 L 10.10.0.4/32 is directly connected, GigabitEthernet0/0/2.10 C 10.10.10.0/24 is directly connected, Tunnel10 H 10.10.10.3/32 is directly connected, 00:00:18, Tunnel10 << L 10.10.10.4/32 is directly connected, Tunnel10 172.16.0.0/32 is subnetted, 1 subnets D 172.16.3.3 [90/28288000] via 10.10.10.2, 00:02:05, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets D 192.168.2.2 [90/27008000] via 10.10.10.2, 01:32:35, Tunnel10 192.168.3.0/32 is subnetted, 1 subnets D % 192.168.3.3 [90/28288000] via 10.10.10.2, 01:32:35, Tunnel10 [NHO][90/255] via 10.10.10.3, 00:00:18, Tunnel10 << 192.168.4.0/32 is subnetted, 1 subnets C 192.168.4.4 is directly connected, Loopback10 show ip nhrpではエントリが期限付きで追加されています。 R4#sh ip nhrp 10.10.10.2/32 via 10.10.10.2 Tunnel10 created 00:27:50, never expire Type: static, Flags: NBMA address: 10.10.0.2 10.10.10.3/32 via 10.10.10.3 << Tunnel10 created 00:00:25, expire 00:09:36 Type: dynamic, Flags: router nhop rib NBMA address: 10.10.0.3 192.168.3.3/32 via 10.10.10.3 << Tunnel10 created 00:00:25, expire 00:09:36 Type: dynamic, Flags: router rib nho NBMA address: 10.10.0.3 192.168.4.4/32 via 10.10.10.4 << Tunnel10 created 00:00:25, expire 00:09:36 Type: dynamic, Flags: router unique local NBMA address: 10.10.0.4 (no-socket) CEFでもR3宛ての192.168.3.3のNexthopがHub経由ではなく、 R3に変更されています。 R4#sh ip cef | in 192.168. 192.168.2.2/32 10.10.10.2 Tunnel10 192.168.3.3/32 10.10.10.3 Tunnel10 <<R3がNexthopに上書き 192.168.4.4/32 receive Loopback10 そのため2回目のtracerouteはHubのR2を経由せず、 直接R4からR3への通信するようになりました。 R3でも同様の変化が見られます。 Routing TableのHと%(next-hop-overrid)の違い 余談にはなりますが、 NHRPでRouting Tableに経路が追加される際に Hと%(next-hop-overrid)の違いについて触れてみます。 この差はNHRPで学習した経路のPrefixによります。 NHRPで学習した経路がRouting Tableに持っている経路より、 Prefixが長い場合（よりSpecificな場合）にはHとしてRouting Tableには追加され、 同じかPrefixが短い場合は%(next-hop-overrid)として学習します。 先の例では192.168.3.3/32は元々Routing Tableにあったため、 同じ/32で学習した経路は%(next-hop-overrid)として学習しています。 ではこれを意図的にHとして学習するようにしてみましょう。 Routing Tableに/32よりPrefixが短いエントリを作ってやります。 要はR3の拠点のアドレスをサマリしてEIGRPで広報するような場合になります。 R3でEIGRPでSummaryします。 router3#sh run int tu10 interface Tunnel10 ip address 10.10.10.3 255.255.255.0 no ip redirects ip mtu 1400 ip nhrp authentication w ip nhrp network-id 4 ip nhrp nhs 10.10.10.2 nbma 10.10.0.2 multicast ip summary-address eigrp 10 192.168.3.0 255.255.255.0 << 追加 tunnel source GigabitEthernet0/0/3.10 tunnel mode gre multipoint tunnel key 10 end R4のRouting Tableでは192.168.3.0/24になります。 route4#sh ip route <snip> Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/2.10 L 10.10.0.4/32 is directly connected, GigabitEthernet0/0/2.10 C 10.10.10.0/24 is directly connected, Tunnel10 L 10.10.10.4/32 is directly connected, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets D 192.168.2.2 [90/27008000] via 10.10.10.2, 02:53:29, Tunnel10 192.168.3.0/24 is subnetted, 1 subnets　<< /24になります。 D 192.168.3.0 [90/28288000] via 10.10.10.2, 00:00:07, Tunnel10 192.168.4.0/32 is subnetted, 1 subnets C 192.168.4.4 is directly connected, Loopback10  ここでR4からR3にTracerouteしますと、 Routing TableにはHで192.168.3.3/32が追加されます。 route4#sh ip route <snip> Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks C 10.10.0.0/24 is directly connected, GigabitEthernet0/0/2.10 L 10.10.0.4/32 is directly connected, GigabitEthernet0/0/2.10 C 10.10.10.0/24 is directly connected, Tunnel10 H 10.10.10.3/32 is directly connected, 00:00:09, Tunnel10 L 10.10.10.4/32 is directly connected, Tunnel10 192.168.2.0/32 is subnetted, 1 subnets D 192.168.2.2 [90/27008000] via 10.10.10.2, 02:53:56, Tunnel10 192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks D 192.168.3.0/24 [90/28288000] via 10.10.10.2, 00:00:34, Tunnel10 H 192.168.3.3/32 [250/255] via 10.10.10.3, 00:00:09, Tunnel10 << 192.168.4.0/32 is subnetted, 1 subnets C 192.168.4.4 is directly connected, Loopback10 以上。 NHRPシリーズその3はDebugコマンドを使ってNHRPの動作を見ていきたいと思います。 ... View more

NHRPに焦点を当てたシリーズです。 NHRP シリーズ : その2 動作確認及び H と % の違いについて その1、としてどんなプロトコルか大まかにまとめてみます。   NHRP とはどんなプロトコルか。 簡単に言えば ARP みたいなものです。 ARP は Address Resolution Protocol という名前のとおり、 IP アドレスと MAC アドレスを紐づけるのに使われています。 「この IP はどの MAC アドレス？」という ARP リクエストをブロードキャストでネットワークに送信し、 「私です。」というA RP リプライから IP アドレスと MAC アドレスを紐づけます。 Address を Resolution する Protocol、アドレスを解決してくれるプロトコル ARP ということになります。 NHRPは正式には Next Hop Resolution Protocolです。 ARPと同様に「Resolution Protocol」と入っていますので、 解決プロトコルの一種ということになります。 何を解決してくれるのか、というと Next Hop になります。 Next Hop を解決してくれるプロトコルが NHRP です。 NHRP はどんなところで使うのか。 Non-Broadcast Multi-Access (NBMA) での利用が想定されています。 ブロードキャストが使えないけど、複数のルータなどが繋がっているネットワークということになります。 1対1 (Point to Point) で繋がっているものが集まっているようなネットワークとも言えます。   A-B、A-C は1対1でお互いに通信できます。 では、B-C の通信は？ 同じネットワークにいて Ethernet なら ARP で直接通信できるように見えますが、 ブロードキャストが使えないで、つまりは ARP も使えません。 そんな時でも動的にアドレスを学習できるのが NHRP になります。 通信キャリアの拠点間の接続サービスでは同様に1対1の接続が前提のものがありますので、 そういったネットワークでも NHRP は使われます。 具体的には、1対1の接続が基本となる Tunnel (GRE) を用いた DMVPN で使うのが最も一般的です。 DMVPN を例に言えば、 Nexthop になっている Tunnel IP アドレスから、 Tunnel の送信元になっている物理 interface の IP アドレスを知ることができるのが NHRP の役割になります。 NHRP はどんな動作か。 NHRP にはサーバとクライアントがいるタイプのプロトコルになります。 Next Hop Server (NHS) Next Hop Resolution Protocol client (NHC) ※DMVPN では NHS が Hub で NHC が Spoke と呼ばれます。 簡単には、クライアント: NHC がサーバ: NHS に Nexthop のアドレス解決の問い合わせを送信、 サーバがクライアントにレスポンスを返して、 クライアントは Nexthop を解決するという動作です。 DNS のようなイメージに近いです。 もう少し具体的に書くと、 NHC は Virtual IP アドレス（Tunnel の IP アドレス）を問い合わせて、 NHS は対応する Real IP アドレス（Tunnel の送信元 IP アドレス）を回答します。 サーバがクライアントの問い合わせに答えるにはサーバに事前に登録が必要ですので、 NHC は NHRP Registration Request を送信して NHS に自身の持つ情報を登録します。 また、問い合わせというのは、 NHRP Resolution Request と呼ばれます。 NHC は Request を NHS へ送信して NHC は NHS から Reply を受け取ります。 以上、大まかに NHRP についてでした。 次回は Multipoint GRE (IPsec なしの DMVPN) 構成での動作を具体的に見ていきたいと思います。 参考： NHRP の設定 RFC2332 NBMA Next Hop Resolution Protocol (NHRP) ... View more

Cisco 800シリーズの C899G-LTE や IR829GW-LTE などは LTE(4G) に対応したルータです。 LTE 対応ルータには Cellular Interface があり、こちらを用いて LTE で接続が可能になっています。 この Cellular Interface は LTE 接続はルータに内蔵されている Cellular Modem (モデム) により制御されています。   このモデムがモデム自身の状況をチェックして好ましくない状況の場合に自動的にモデム再起動を行う機能があります。 その機能が Cellular Modem Link Recovery という機能になります。 lte modem link-recovery というコマンドで設定されています。   この Cellular Modem Link Recovery ですが、 IOS15.7(3)M からデフォルトで無効になっています。 設定としては予め下記のような設定になっています。 controller Cellular 0 lte modem link-recovery disable 有効に設定する場合は下記のように入力します。 controller Cellular 0 no lte modem link-recovery disable   lte modem link-recovery にはいくつかのパラメータがありますが、 基本的にはデフォルトのものをご利用頂ければ問題ございません。 デフォルトの設定値は下記になります。 controller Cellular 0 lte modem link-recovery rssi onset-threshold -110 lte modem link-recovery monitor-timer 20 lte modem link-recovery wait-timer 10 lte modem link-recovery debounce-count 6 ※ rssi onset-threshold -110：RSSI が-110以下になるとモデム再起動 monitor-timer 20：20秒毎に Link Recovery がモデム状態をチェック wait-timer 10 と debounce-count 6：Link Recovery がモデムの異常を検知後に10秒毎に6回までモデム再起動なしで復旧できるかチェック   最後に Cellular Modem Link Recovery によりモデム再起動が発生した場合は下記のようなログが出力されます。 %CELLWAN-4-MODEM_COMM_FAIL: Communication between Modem and IOS failed: link recovery resets modem   以上 参考 Cellular Modem Link Recovery   ... View more

ドメイン名に Ping を送信したりドメイン名を設定したりすると、Translating で始まる下記のようなメッセージが出力されていたと思います。 ISR4451-X/K9#ping cisco.com Translating "cisco.com"...domain server (255.255.255.255) この  Translating のメッセージですが、IOS-XE では 3.16S や 16.x などのバージョンから出力されなくなりました。こちらはIOS-XE における DNS 関連の実装変更による影響になります。特に不具合というわけではございません。   Translating のメッセージが表示されないだけで実際には DNS の名前解決を行っておりますので、しばらく応答がないようにも見えます。 ご留意頂ければと思います。   なお、IOSではTranslating のメッセージは表示されます。   以上。 ... View more

 ※ここではLTE(4G)ルータとしてはC899G-LTE、C819GW-LTEを想定しています。   -キャリアプロビジョニングファイル 日本ではドコモ、au、Softbankの3社のSIMカードがあります。 各社のSIMカードを使ってLTEルータを使用することができます。 利用する通信事業者に合わせてキャリアプロビジョニングファイルを変更する必要があります。 デフォルトはドコモになっています。   確認コマンド Router#show cellular 0 hardware Carrier = NTT docomoなどと表示されている部分があります。   キャリアプロビジョニングファイルの 変更方法については下記をご参考ください。 Cisco 4G LTE ルータ 初期セットアップガイド + (付録)MC7430モデム キャリアプロビジョニングファイル アップグレード手順 -モデムプロファイル 通信事業者へ接続するための情報を設定します。 正しく設定がされていないと通信ができませんのでご留意ください。   確認コマンド Router#show cellular 0 profile Profile 1 = INACTIVE* **と**がついているモデムプロファイルが使用されています。   モデムプロファイルの設定方法については下記をご参考ください。 Cisco 4G LTE ルータ 初期セットアップガイド + (付録)MC7430モデム キャリアプロビジョニングファイル アップグレード手順 -line3の設定 デフォルトでmodem InOutなどいくつか設定が入っています。 こちらは無線通信で使われますので特に変更の必要はありません。   確認コマンド Router#show running-config | s line 例） line 3 script dialer lte modem InOut no exec transport input all transport output all   -ルータのIOSバージョン   LTEルータでサポートされているIOSをご利用ください。 予期せぬ動作を引き起こす場合があり、LTEが利用できないこともあります。 デフォルトのOSであればLTEが動作するバージョンにはなっています。 既知の不具合を避けるためにも新しいIOSを利用することを推奨します。   各ルータでサポートしているIOSのバージョンはデータシートに記載があります。 例） C899G-LTE-JP-K9：モデム ファームウェアが 5.5.58.x の Cisco IOS ソフトウェア リリース 15.6(1)T または各モデム ファームウェアが組み込まれた以降の IOS リリース C819GW-LTE：2.14.3.x のモデム ファームウェアが組み込まれた Cisco IOS ソフトウェア リリース 15.6（2）T1 または対応するモデム ファームウェアが組み込まれたそれ以降のリリース”   確認コマンド Router#show version 例） Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.6(2)T1,    以上 ... View more

 LTE対応ルータのトラブルシューティングに役立つ show/debug コマンドを載せています。   問題が発生した場合に、どのようなコマンドがあるかという意味で作成したドキュメントとなり、 詳細な情報は記載せず、コマンドのみとしています。   ※IOSバージョンによりサポートしていないコマンドが含まれている場合があります。 ※Platformに依存したコマンドは載っていない場合があります。 ※一部Hiddenコマンドとなり、補完されないコマンドが含まれている場合があります。 ※debug取得は設定/環境によりCPU高負荷を引き起こす可能性があるため、実環境で取得する場合には事前に影響を検証の上、取得をご検討ください。 ※"0"でない場合は変更ください。   show commands show interface cellular 0 show cellular 0 network show cellular 0 radio show cellular 0 radio history all show cellular 0 profile show cellular 0 connection show cellular 0 hardware show cellular 0 firmware show cellular 0 all show line show ip route   debug commands debug chat debug modem debug cellular 0 messages [all | async | callcontrol | data | profile | qos | snmp] debug async [framing | state | packet] debug ppp [negotiation | error | packet | chap] debug dialer   モデムのリセット router(config)#service internal router(config)#end router#test cellular 0 modem-reset   モデムのリスタート router(config)#service internal router(config)#end router#test cellular 0 modem-power-cycle   DM log ※DM logはTACによる解析が必要になります。 有効化 router#conf t router(config)#controller cellular 0 router(config-controller)#lte modem dm-log rotation router(config-controller)#lte modem dm-log filesize 20 router(config-controller)#lte modem dm-log size 60 router(config-controller)#lte modem dm-log filter flash:XYZ.sqf <<<< Optional router(config-controller)#lte modem dm-log enable 無効化 router#conf t router(config)#controller cellular 0 router(config-controller)#no lte modem dm-log enable DM log作成確認 router#show cellular 0 logs dm-log Flashに作成されますのでTFTP等で取得ください。   (参考) 4G WAN の LTE DM ログの収集 Cisco 4G LTE ソフトウェア構成ガイド Cisco 4G LTE ルータ 初期セットアップガイド + (付録)MC7430モデム キャリアプロビジョニングファイル アップグレード手順   以上 ... View more

IOSでCBWFQを設定した際に次のようなエラーに出会ったことがある方もいらっしゃるかと思います。 % QOS - 4 - QLIMIT_HQUEUE_VALUE_SYNC_ISSUE : The sum of all queue - limit value is greater than the hold - queue value . これはCBWFQに設定された queue-limit（デフォルトは64パケット）の合計がCBWFQの設定されたInterfaceのhold-queueより大きくなったことを示しています。この場合はhold-queueを調整することが望ましい状況になります。 しかしながら、IOS-XEではInterfaceのhold-queueとQoS(CBWFQ)のqueue-limitsは関係がないため、このようなエラーが表示されることもありません。IOS-XEではhold-queueを調整する必要がございません。 参考： Understanding Queuing With Hierarchical Queueing Framework Cisco ASR 1000 Aggregation Services Routers Quality of Service (QoS) FAQ ... View more

その1：概要、その2：基本設定に続き、その3ではshow/debugコマンドで動作を確認する方法をご紹介します。その2で作った環境で試してみると良いと思います。 ここで取り上げるコマンドは下記の通りです。 - show コマンド show lisp site ：MS/MRでのMapping登録情報 show ip lisp database ：xTRで設定したMapping情報 show ip lisp map-cache ：xTRが持ってるMapping情報のキャッシュ show ip route - debug コマンド LISP制御パケット向け debug lisp control-plane all debug lisp detail LISPデータパケット向け debug ip cef packet <RLOCのInterface> output 143 rate 0 detail (access-list 143 permit udp any any eq 4341) 1）show コマンド 1.1）show lisp site MS/MRで使います。（厳密にはMS） その2でも掲載していますが、 xTRからのMap-RegisterでEIDとRLOCのMappingがMS/MRに登録されていることを確認します。自動的にMappingは登録されます。 R201#sh lisp site LISP Site Registration Information * = Some locators are down or unreachable Site Name Last Up Who Last Inst EID Prefix 　　　　　Register Registered ID R200 　　　00:00:12 yes 192.168.2.10 10.0.0.0/24 R201 　　　00:00:38 yes 192.168.2.11 172.19.0.11/32 未登録の場合は下記のようになりますので、 xTRやMS/MRでのkeyやeid-prefixの設定を確認しましょう。 R201#sh lisp site LISP Site Registration Information * = Some locators are down or unreachable Site Name Last Up Who Last Inst EID Prefix 　　　　　 Register Registered ID R200 never no -- 10.0.0.0/24 R201 never no -- 172.19.0.11/32 1.2）show ip lisp database xTRで使います。 EIDの情報が表示されます。 Stateを確認してみましょう。 自サイトのEID（10.0.0.0/24）へのルートがRouting Tableにあれば、 reachableと表示されます。 R200#sh ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 1 entries 10.0.0.0/24 Locator Pri/Wgt Source State 192.168.2.10 1/100 cfg-intf site-self, reachable 上のコマンド結果は、 “database-mapping 10.0.0.0/24 IPv4-interface Ethernet0/2 priority 1 weight 100” （Ethernet0/2：192.168.2.10） を自身に設定した内容です。 1.3）show ip lisp map-cache xTRで使います。 xTR（厳密にはITR）はLISPを用いた通信の際にはMap-RequestをMS/MRに送信して、RLOCとEIDのマッピング情報を得ます。 その情報をxTRは毎回Map-Requestを送信しなくて良いようにキャッシュします。 その2でも掲載しましたが、そのキャッシュ情報を確認できます。 R200#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:00:15, expires: never, via static send map-request Negative cache entry, action: send-map-request 172.19.0.11/32, uptime: 00:00:05, expires: 23:59:54, via map-reply, complete Locator Uptime State Pri/Wgt 192.168.2.11 00:00:05 up 1/100 余談ですが、このキャッシュにはTTLがありデフォルトは24時間となっています。 ipv4 etr map-cache-ttlで変更可能です。 1.4）show ip route 言わずと知れたRouting Table（以下、RIB）を確認するコマンドです。 ここであえて載せたのは、LISPでのRouting対象になるかどうかの判断にはRIBが使われるためです。 ITRは宛先のアドレスをRIBを確認して0.0.0.0/0もしくは経路がなく、 送信元アドレスがローカルEIDである、 ことを満たしている場合にLISP対象としてMap-cacheに従ってパケットを処理します。 逆に言えば、RIBに該当経路がある場合は、 LISPを使ってパケットを送信しないことになります。 2）debugコマンド 2.1）制御パケット向け 下の二つを有効にすればLISPの制御パケット（UDP4342）のやり取りを見ることができます。ただし、出力量が多いので注意ください。 debug lisp control-plane all debug lisp detail Map-RegisterやMap-Request/Map-Replyの交換がDebugレベルで見ることができます。 例えば、Map-Registerを抜粋してみます。 xTR1からの送信； *Oct 3 14:16:59.631: LISP-0: IPv4 Map Server IID 0 172.16.144.144, Sending map-register (src_rloc 172.16.13.1) nonce 0xFB5461D3-0x043EDCB4. MS_MRで受信; *Oct 3 14:16:59.632: LISP: Processing received Map-Register(3) message on Ethernet0/0 from 172.16.13.1:4342 to 172.16.144.144:4342 MS_MRに登録する処理が行われます。 *Oct 3 14:16:59.632: LISP: Processing Map-Register mapping record for IID 0 10.1.0.0/24, ttl 1440, action none, authoritative, 1 locator 172.16.13.1 pri/wei=100/100 LpR 2.2）LISPデータパケット向け LISPを使って転送されるデータパケット（UDP4341）を見るには、debug ip cef packetを使います。UDP4341のヘッダが付いたパケットを debug ip cef packetで出力 してみます。 まず、ACLでLISPのデータパケットに絞ります。 access-list 143 permit udp any any eq 4341 RLOC側のInterfaceを対象にしてDebugを設定します。 debug ip cef packet <RLOCのInterface> output 143 rate 0 detail すると、dst=4341のパケットがDebugで表示されます。 ITRからLISPでカプセル化されたパケットが送信されているのが確認できます。 *Mar 21 19:27:59.543: CEF-Debug: Packet from 10.0.0.2 (Nu0) to 10.0.0.6 (Et0/0) *Mar 21 19:27:59.543: ihl=20, length=136, tos=0, ttl=254, checksum=26708, offset=0 DF *Mar 21 19:27:59.543: UDP src=1536, dst=4341 , length=116, checksum=0 以上、その3でした。 （参考）LISP Deep Dive Resources... http://lisp.cisco.com/lisp_tech.html#CG ... View more

  ここでは最小構成、最小設定を見ていきます。 ※InterfaceのIPアドレスの設定は掲載を省略します。 ※ルータにルーティングの設定は必要ございません。 下記も合わせてご参照ください。 LISPの基本 その１:概要 LISPの基本 その３：トラブルシュートに使うコマンド   1) NW構成 ルータが2台あればLISPの動作を確認できます。 1台はMS/MR兼xTRになります。 片方のEIDには端末を他方はLoopback InterfaceをEIDとました。 （両方ともLoopback Interfaceでも構いません） 2) R200（xTR）の設定 R200をxTRとして設定します。 router lisp database-mapping 10.0.0.0/24 IPv4-interface Ethernet0/2 priority 1 weight 100 ipv4 itr map-resolver 192.168.2.11 ipv4 itr ipv4 etr map-server 192.168.2.11 key w ipv4 etr exit 2.1) EIDとRLCOのMapping設定 EID：10.0.0.0/24 をRLOC：Interface e0/2に紐づけています。 priorityやweightは複数のRLOCがあるときに優先順位や負荷分散の配分に使います。 database-mapping 10.0.0.0/24 IPv4-interface Ethernet0/2 priority 1 weight 100 2.2) ITRの設定 MRのアドレスとITRであることを設定します。 ipv4 itr map-resolver 192.168.2.11 ipv4 itr 2.3) ETRの設定 MSのアドレスとETRであることを設定します。 keyはMSにも設定します。MSと一致する必要があります。 ipv4 etr map-server 192.168.2.11 key w ipv4 etr 3) R201（xTR&MS/MR）の設定 R201をxTR兼MS/MRとして設定します。 EID-RLOCのMappingの設定方法を変えています。 router lisp locator-set R201_RLOC IPv4-interface Ethernet0/2 priority 1 weight 100 exit ! site R200 authentication-key w eid-prefix 10.0.0.0/24 exit ! site R201 authentication-key w eid-prefix 172.19.0.11/32 exit ! database-mapping 172.19.0.11/32 locator-set R201_RLOC ipv4 map-server ipv4 map-resolver ipv4 itr map-resolver 192.168.2.11 ipv4 itr ipv4 etr map-server 192.168.2.11 key w ipv4 etr exit 3.1) MS/MRの設定 EIDの情報を設定します。 authentication-keyはxTRのipv4 etr map-server x.x.x.x keyに一致させます。 site R200 authentication-key w eid-prefix 10.0.0.0/24 exit ! site R201 authentication-key w eid-prefix 172.19.0.11/32 exit MS、MRとして動作することを設定します。 ipv4 map-server ipv4 map-resolver 3.2) xTRの設定 ここではEID-RLOCのMappingをlocator-setで定義しています。 locator-set R201_RLOC IPv4-interface Ethernet0/2 priority 1 weight 100 exit EIDと locator-setを紐づけます。 database-mapping 172.19.0.11/32 locator-set R201_RLOC 内容としては下記と同じ設定になります。 database-mapping 172.19.0.11/32 IPv4-interface Ethernet0/2 priority 1 weight 100 ITR/ETRの設定はR200と同様です。 ipv4 itr map-resolver 192.168.2.11 ipv4 itr ipv4 etr map-server 192.168.2.11 key w ipv4 etr 4) 動作確認 4.1) MS/MR xTRからのMap-RegisterでEIDとRLOCのMappingが登録されていることを確認します。 自動的にMappingは登録されます。 R201#sh lisp site LISP Site Registration Information * = Some locators are down or unreachable Site Name Last Up Who Last Inst EID Prefix Register Registered ID R200 00:00:12 yes 192.168.2.10 10.0.0.0/24 R201 00:00:38 yes 192.168.2.11 172.19.0.11/32 未登録の場合は下記のようになります。 R201#sh lisp site LISP Site Registration Information * = Some locators are down or unreachable Site Name Last Up Who Last Inst EID Prefix 　 Register Registered ID R200 never no -- 10.0.0.0/24 R201 never no -- 172.19.0.11/32 4.2) xTR ノートPC（R200のEID）から対向のEID（R201のLoopback0）にPingを送信します。 R200およびR201はお互いのEIDのアドレスに対してのルーティングは知りません。 始めのPingは失敗します。 これはR200がMap-cacheを持っていないためです。 通信が発生した際にMap-RequestとMap-Replyの交換が行われてMap-cacheが作成されます。 PC#ping 172.19.0.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.19.0.11, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/5 ms Map-cacheは次のように確認できます。 0.0.0.0/0はDefault Routeのようなものです。 該当するEntryがないとMap‐requestを送信します。 R200#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:00:15, expires: never, via static send map-request Negative cache entry, action: send-map-request 172.19.0.11/32, uptime: 00:00:05, expires: 23:59:54, via map-reply, complete Locator Uptime State Pri/Wgt 192.168.2.11 00:00:05 up 1/100 以上、その2でした。 ... View more

LISPをご紹介いたします。 LISPはLocator Identity Separation Protocolの略です。 ホスト（端末）がいるLANとISPが管理するようなWANとを別々のIPアドレスで構成しています。 ホストがWANのどこにいるかを紐づけた管理情報があります。 下記も合わせてご参照ください。 LISPの基本 その2：基本設定 LISPの基本 その3：トラブルシュートに使うコマンド LISPの用語 LISPでは独特の用語が登場します。 EID (Endpoint Identifier) ホストのIPアドレス。 RLOC (Routing Locator) WANに面したLISPを有効のルータのIPアドレス。 ITR（Ingress Tunnel Router） LANからWANへの入口ルータ。 EIDとRLOCの紐づけ（Mapping）を問い合わせます。（Map-Request） LISPでカプセル化を行いWANへ送信します。 ETR（Egress Tunnel Router） WANからLANへの出口ルータ。 EIDとRLOCのMappingをMap-serverに登録します。(Map-Register) LISPのカプセル化を解除してLANへ送信します。 Map-Requestに応じてMap-Replyを返します。 xTR ITR/ETRの両方の役割を担います。 基本的にITRとETRを分けることはなくxTRで運用されます。 LISP siteのエッジルータとなります。 MS/MRと同居可能です。 PxTR（Proxy xTR） LISPサイトとnon-LISPサイト間の通信を担います。 LISPサイトとnon-LISPサイト間の通信はNATを利用することでも対応可能です。 ここでは取り上げません。 MS/MR（Map-Server/Map-Resolver） MSとMRを別々の機器にすることも可能ではあります。 MSはMap-Registerを受信してEIDとRLOCのMappingを管理します。 MRはMap-Requestを受信してMSへ転送します。 EIDとRLOCのMapping ここではノートPC側をITR、サーバ側をETRとします。 ETRからMS/MRへMap-Registerを送信しMS/MRにEIDとRLOCの紐づけを登録します。 MS/MRはEIDがどこのLISP site（RLOC）にあるのかを知っています。 ① ノートPCからサーバへ通信を行う際に、 ITRはサーバのIPアドレス（EID）がどこのETR（RLOC）にいるのかMap-RequestでMS/MRへ問い合わせをします。 ITRはキャッシュを持ちますので次回の通信ではMap-Requestしないこともあります。 ② MS/MRはITRからのMap-Requestを受けてサーバのEIDがいるETRへMap-Requestを送信します。 ③ ETRはMS/MRからのMap-Requestを受信してITRへMap-Replyを送信します。 ITRはETRからのMap-Replyを受け取ってサーバがどこにいるのかを把握します。 ITRはサーバのEIDとRLOCのMappingを知りえることになります。 LISPパケットと通信 ITRは前述のように宛先のEIDがどのRLOCに紐づくかを把握します。 そのMappingに基づいてITRやETRは外側ヘッダやLISPヘッダをつけてカプセル化したり解除したりして通信します。 流れを簡単に見てみると下記のようになります。 ITRはノートPCからのサーバEID宛てパケットを受け取ります。 ITRはEIDとRLOCのMapping情報から外側のヘッダとLISPヘッダでカプセル化します。 青いRLOC網内は外側ヘッダのIPアドレスを使ってルーティングされます。 ETRにパケットが到着します。 ETRは到着後に外側ヘッダとLISPヘッダを解除します。 内側ヘッダのアドレスつまりはEIDでルーティングしてサーバに到着します。   詳しくはLISPのRFC6830をご参照頂くとよいでしょう。 パケットフォーマットも詳しく記載があります。 以上、その１でした。 ... View more

異なるVRF間でNATを実行したい場合には、NVI(Nat Virtual Interface)を使用する必要があります。 VRFとグローバルとの間または同一VRFの内部でのNATは従来方式でNATが行えます。 ここではNVIを用いたNATを紹介します。 なお、ISR(IOS)では異なるVRF間のNATするにはNVIを使用しますが、 ASR1000(IOS-XE)ではVASIを使用します。ASR1000にはNVIはありません。 VASIはこちらをご参照ください。 【ASR1000】VASIとNATの設定例   NW構成 目的 R203でVRFを設定して、異なるVRFであるA-X間、B-X間でNATを行います。 つまりは、R201-R204間とR202-R204間でPing疎通を確認します。 R203で意図的にルーティング設定はしませんが、 R202、R201、R204ではデフォルトルートをR203へ向けます。 R203の設定（抜粋） ip vrf A ! ip vrf B ! ip vrf X ! interface Ethernet0/0 ip vrf forwarding B ip address 192.168.1.25 255.255.255.0 ip nat enable ! interface Ethernet0/1 ip vrf forwarding A ip address 192.168.2.25 255.255.255.0 ip nat enable ! interface Ethernet0/2 ip vrf forwarding X ip address 172.30.1.242 255.255.255.0 ip nat enable ! ip nat pool pool1 192.168.33.1 192.168.33.10 netmask 255.255.255.0 add-route ip nat source list 1 pool pool1 vrf A ip nat source list 1 pool pool1 vrf B ip nat source static 172.30.1.241 192.168.33.33 vrf X ! ! ! access-list 1 permit 192.168.2.0 0.0.0.255 access-list 1 permit 192.168.1.0 0.0.0.255 ! ! 解説 ip nat enableを設定すると自動的にNVI0が追加されます。 VRF間の通信はこのNVI0を介して行います。 R201、R202、R204からの通信はNVI0にルーティングされる必要があります。 192.168.33.0/24という架空のセグメントを想定します。 VRF間を繋ぐようなセグメントのイメージかと思います。 送信元及び宛先をこのセグメントのアドレスでNATします。 ip nat pool pool1 192.168.33.1 192.168.33.10 netmask 255.255.255.0 add-route を設定しますと、 Globalを含め各VRFのルーティングテーブルに S 192.168.33.0/24 [0/0], NVI0 が設定されます。 送信元NAT： こちらで送信元をNATします。 送信元アドレスがaccess-list1に該当した通信をpool1でNATします。 ip nat source list 1 pool pool1 vrf A ip nat source list 1 pool pool1 vrf B ※overload付けても可 宛先NAT： R202からは192.168.33.33宛てにPingを送信するものとします。 192.168.33.33はNATされて172.30.1.241となり、R204に届きます。 こちらの設定で宛先をNATします。 ip nat source static 172.30.1.241 192.168.33.33 vrf X 結果 R202から192.168.33.33宛てにPingを送信します。 R203でデバッグを取得してみると、次のようになります。 行き *Jul 27 02:23:36.091: NAT*: i: icmp (192.168.2.1, 14) -> (192.168.33.33, 14) [70] *Jul 27 02:23:36.091: NAT*: s=192.168.2.1->192.168.33.1, d=192.168.33.33 [70] *Jul 27 02:23:36.091: NAT*: s=192.168.33.1, d=192.168.33.33->172.30.1.241 [70] 帰り *Jul 27 02:23:36.093: NAT*: i: icmp (172.30.1.241, 14) -> (192.168.33.1, 14) [73] *Jul 27 02:23:36.093: NAT*: s=172.30.1.241->192.168.33.33, d=192.168.33.1 [73] *Jul 27 02:23:36.093: NAT*: s=192.168.33.33, d=192.168.33.1->192.168.2.1 [73] 詳しく見てみると、 行きのNAT下記は、ip nat source list 1 pool pool1 vrf A に対応して、送信元NATしています。 *Jul 27 02:23:36.091: NAT*: s=192.168.2.1->192.168.33.1, d=192.168.33.33 [70] 行きのNAT下記は、ip nat source static 172.30.1.241 192.168.33.33 vrf Xに対応して、宛先をNATしています。 *Jul 27 02:23:36.091: NAT*: s=192.168.33.1, d=192.168.33.33->172.30.1.241 [70] 帰りは逆になります。 R201からも 192.168.33.33へのPingが可能になります。 異なるVRFを跨いでNATを用いた通信ができました。 参考資料 NAT 仮想インターフェイスの設定 NAT と VRF/MPLS / NAT NVI 以上 ... View more