YAMAHA RTXとCisco VPN Clientの接続性 ～ 7年目の真実 (2017/10/02) [ネットワーク機器]
IPSecにチャレンジしていることもあって、自分自身の書いた過去記事を見直していました。2010年5月にYAMAHA RTX1100とCisco VPN Clientの接続性について検証しており、当時は「接続不可」という結論を下しました。
概要としては、CISCO VPN Clientはクライアント側の識別子（IKE identification payload）としてID Type 11(KEY ID)を提示しますが、YAMAHA RTX1100はID Type 2(FQDN)としてチェックするので、不一致が発生し、うまく接続できないというものです。
ID Type 11(KEY ID)に何を埋め込むのかと言えば、CISCO VPN Clientに設定するグループ認証のグループ名なんですよね。
RTX1100のコンフィグだと、「ipsec ike remote name ～」に対応しており、～部分をチェック対象とします。
気になってRTXの最新マニュアル（for 後継機種）を見てみたのですが、該当部分の設定項目が増えているではありませんか。
http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_remote_name.html
・ipv4-addr ： ID_IPV4_ADDR
・fqdn ： ID_FQDN
・user-fqdn(もしくはrfc822-addr) ： ID_USER_FQDN(ID_RFC822_ADDR)
・ipv6-addr ： ID_IPV6_ADDR
・key-id ： ID_KEY_ID
・tel ： NGN 網電話番号(ID_IPV6_ADDR)
・tel-key ： NGN 網電話番号(ID_KEY_ID)
key-idってあるし。たぶんID Type 11なんでしょうね。これはもしかするともしかすると、RTX1100ではなく後継機種のRTX1200を使用して検証していたら、ちゃんと接続できていたかもしれません。
まぁ、今となってはCISCO VPN Client自体がEnd of Supportでガラクタソフトウェアになっていますが。
なぜこんな形で過去記事を掘り下げたかというと、AndoroidのIPSec接続を試している中で、グループ認証に対応できるようにAndoroid側でオプション設定項目が用意されていることが分かったからです。懐かしい気持ち半分で、当時の記事を読み返した訳です。
なお、CISCO VPN Clientは今となってはゴミ（後継のAnyConnectへの移行が推奨されている）ですが、CISCO機器として「グループ認証」は現役のコンフィグとして活用可能です。
概要としては、CISCO VPN Clientはクライアント側の識別子（IKE identification payload）としてID Type 11(KEY ID)を提示しますが、YAMAHA RTX1100はID Type 2(FQDN)としてチェックするので、不一致が発生し、うまく接続できないというものです。
ID Type 11(KEY ID)に何を埋め込むのかと言えば、CISCO VPN Clientに設定するグループ認証のグループ名なんですよね。
RTX1100のコンフィグだと、「ipsec ike remote name ～」に対応しており、～部分をチェック対象とします。
気になってRTXの最新マニュアル（for 後継機種）を見てみたのですが、該当部分の設定項目が増えているではありませんか。
http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_remote_name.html
・ipv4-addr ： ID_IPV4_ADDR
・fqdn ： ID_FQDN
・user-fqdn(もしくはrfc822-addr) ： ID_USER_FQDN(ID_RFC822_ADDR)
・ipv6-addr ： ID_IPV6_ADDR
・key-id ： ID_KEY_ID
・tel ： NGN 網電話番号(ID_IPV6_ADDR)
・tel-key ： NGN 網電話番号(ID_KEY_ID)
key-idってあるし。たぶんID Type 11なんでしょうね。これはもしかするともしかすると、RTX1100ではなく後継機種のRTX1200を使用して検証していたら、ちゃんと接続できていたかもしれません。
まぁ、今となってはCISCO VPN Client自体がEnd of Supportでガラクタソフトウェアになっていますが。
なぜこんな形で過去記事を掘り下げたかというと、AndoroidのIPSec接続を試している中で、グループ認証に対応できるようにAndoroid側でオプション設定項目が用意されていることが分かったからです。懐かしい気持ち半分で、当時の記事を読み返した訳です。
なお、CISCO VPN Clientは今となってはゴミ（後継のAnyConnectへの移行が推奨されている）ですが、CISCO機器として「グループ認証」は現役のコンフィグとして活用可能です。
AndroidでCISCO 841MJにIPSec接続してみる その3 （2017/10/03） [ネットワーク機器]
双方のプロポーザルを合致させることで、ISAKMP SAまでは接続できることを確認できました。しかし、Android上では、接続ボタンを押下→失敗しましたと瞬時に表示されます。まだまだこれからですね。
理論上はフェーズ2のXauth認証セクションに入っているはずですが、デバッグログには無数のXauthの文字列が表示され、ちゃんとセクションが進行しているのかよく分かりません。
ちなみにデバッグログは重要な情報源としての魔法の文字列ですが、私が理解できるのは1〜2割程度です。基本的に内部制御コードの羅列のため、素人が読んで分かるものではありませんし、無理に読もうとは思いません。
でも大丈夫です。デバッグログは、処理シーケンスとしてあるべき文字列が表示されているか、また、それに関連するキーワードとしてOK/NG/Success/Fail/match/mismatchなどが表示されていないか、という点を押さえればなんとかなります。
その2に書いたフェーズ1プロポーザルの不一致については、does not match policy、atts are not acceptableといった表示で判断できました。
今、手元にあるデバッグログからXauthの文字列は読み取れるので、Xauthのセクションに到達していることは分かりますが、OKやNGといった関連キーワードが読み取れず、行き詰まってしまいました。
そんな時に私が試してみることは、意図的に変化を発生させることです。具体的には、Xauthのユーザ認証がOKとなるデバッグログと、認証がNGとなった場合（わざとパスワードを間違える）のデバッグログを取得し、Diffツールで比較してみました。
もし双方のデバッグログに変化がなければ、Xauthシーケンスには達しているものの、根本的な問題が残っており、ユーザ認証は行われていないということが言えますし、明らかな変化が見えるのであれば、ユーザ認証の成功によって、さらにその次のシーケンスに進んでいるということが言えます。
･･･結果は、明らかな違いがありました。
つまり、ちゃんとユーザ認証の判定まで行われているということです。
確かによくよくデバッグログを眺めてみると、認証が成功している方はMODE_CFGセクションに突入しているような痕跡が見えました。そうなると、今度はMODE_CFG周りのコンフィグを作り込めば良いのです。
その4へ続く。
ISAKMP: (0):Checking ISAKMP transform 1 against priority 1 policy ISAKMP: (0): life type in seconds ISAKMP: (0): life duration (basic) of 28800 ISAKMP: (0): encryption AES-CBC ISAKMP: (0): keylength of 256 ISAKMP: (0): auth XAUTHInitPreShared ISAKMP: (0): hash SHA256 ISAKMP: (0): default group 5 ISAKMP: (0):atts are acceptable. Next payload is 3 ISAKMP: (0):Acceptable atts:actual life: 86400 ISAKMP: (0):Acceptable atts:life: 0 ISAKMP: (0):Basic life_in_seconds:28800
理論上はフェーズ2のXauth認証セクションに入っているはずですが、デバッグログには無数のXauthの文字列が表示され、ちゃんとセクションが進行しているのかよく分かりません。
ちなみにデバッグログは重要な情報源としての魔法の文字列ですが、私が理解できるのは1〜2割程度です。基本的に内部制御コードの羅列のため、素人が読んで分かるものではありませんし、無理に読もうとは思いません。
でも大丈夫です。デバッグログは、処理シーケンスとしてあるべき文字列が表示されているか、また、それに関連するキーワードとしてOK/NG/Success/Fail/match/mismatchなどが表示されていないか、という点を押さえればなんとかなります。
その2に書いたフェーズ1プロポーザルの不一致については、does not match policy、atts are not acceptableといった表示で判断できました。
今、手元にあるデバッグログからXauthの文字列は読み取れるので、Xauthのセクションに到達していることは分かりますが、OKやNGといった関連キーワードが読み取れず、行き詰まってしまいました。
そんな時に私が試してみることは、意図的に変化を発生させることです。具体的には、Xauthのユーザ認証がOKとなるデバッグログと、認証がNGとなった場合（わざとパスワードを間違える）のデバッグログを取得し、Diffツールで比較してみました。
もし双方のデバッグログに変化がなければ、Xauthシーケンスには達しているものの、根本的な問題が残っており、ユーザ認証は行われていないということが言えますし、明らかな変化が見えるのであれば、ユーザ認証の成功によって、さらにその次のシーケンスに進んでいるということが言えます。
･･･結果は、明らかな違いがありました。
つまり、ちゃんとユーザ認証の判定まで行われているということです。
確かによくよくデバッグログを眺めてみると、認証が成功している方はMODE_CFGセクションに突入しているような痕跡が見えました。そうなると、今度はMODE_CFG周りのコンフィグを作り込めば良いのです。
ISAKMP: (2008):checking request: ISAKMP: (2008):client configuration address IP4_ADDRESS ISAKMP: (2008): IP4_NETMASK ISAKMP: (2008): IP4_DNS ISAKMP: (2008): IP4_NBNS ISAKMP: (2008): MODECFG_BANNER ISAKMP: (2008): DEFAULT_DOMAIN ISAKMP: (2008): SPLIT_DNS ISAKMP: (2008): SPLIT_INCLUDE ISAKMP: (2008): INCLUDE_LOCAL_LAN ISAKMP: (2008): APPLICATION_VERSION
その4へ続く。
AndroidでCISCO 841MJにIPSec接続してみる その2 （2017/10/01） [ネットワーク機器]
「このコンフィグじゃないと絶対に動作しない」といったような、正解が1つしかない場合は逆に楽だったりします。最初からそこだけを目指していけばいいのです。しかし、そんな単純ならエンジニアなんて不要ですから、そうでないことは明かです。
CISCOルータとCISCO ASA（ファイアウォール）で微妙にコンフィグ表現が異なるため、似たような設定サンプルがあっても使えなかったり、ルータ同士であってものIOSバージョンや機種によってコンフィグ構造や概念が変更されており、参考ページが役に立たなかったりします。
一番悩むのは、馴染みのない機能を使う場合、コンフィグ1行1行が、どういった意味を持ち、どういった動きと連動しているのかよく分からず、うまく動作しないときに、そのパラメータを変更すべきか、据え置くべきか考えなければならない時です。初期値を変更すると、後続の動作がガラッと変わってしまうあたりは、まさにカオス理論のカオス状態と言えます。（そのパラメータが、動作に何の影響も与えていなかったというオチもザラです）
まぁ、どん底からどのように這い上がってくるかが、エンジニアの腕といったところでしょうか。
今回もいろいろとWebページのサンプルを参照していますが、本当に自分がやりたいことをピンポイントで説明しているWebページはなく、いろいろなサンプルから必要と思われる部分をピックアップしてコンフィグを入れてみました。
当然うまく繋がりませんので、ログと睨めっこをします。ログといっても大したログは残りませんから、ここはもう最初からデバッグモード全開です。CISCOはデバッグ情報をそれなりに吐き出してくれるので、問題発生時も対処しやすく、CISCOがCISCOたる所以なのではないかと思います。
まず分かったのは、ISAKMPの処理で、設定が不足しておりデフォルトのポリシが使用されているということです。普段は設定している下記のようなISAKMPコンフィグですが、今回は不要なのかと思って入れていませんでした。さっそくコンフィグを投入します。
次に表示されたデバッグは下記の通り。ISAKMPのポリシは設定した内容が参照されるようになりましたが、Android側と不一致を起こしているようです。デバッグを見れば一目瞭然ですが、意外とこの辺の情報ってインターネット上には転がっていなかったりしますね。ここは相手の要求値をサクッと追加して乗り越えます。
その3へ続く。
CISCOルータとCISCO ASA（ファイアウォール）で微妙にコンフィグ表現が異なるため、似たような設定サンプルがあっても使えなかったり、ルータ同士であってものIOSバージョンや機種によってコンフィグ構造や概念が変更されており、参考ページが役に立たなかったりします。
一番悩むのは、馴染みのない機能を使う場合、コンフィグ1行1行が、どういった意味を持ち、どういった動きと連動しているのかよく分からず、うまく動作しないときに、そのパラメータを変更すべきか、据え置くべきか考えなければならない時です。初期値を変更すると、後続の動作がガラッと変わってしまうあたりは、まさにカオス理論のカオス状態と言えます。（そのパラメータが、動作に何の影響も与えていなかったというオチもザラです）
まぁ、どん底からどのように這い上がってくるかが、エンジニアの腕といったところでしょうか。
今回もいろいろとWebページのサンプルを参照していますが、本当に自分がやりたいことをピンポイントで説明しているWebページはなく、いろいろなサンプルから必要と思われる部分をピックアップしてコンフィグを入れてみました。
当然うまく繋がりませんので、ログと睨めっこをします。ログといっても大したログは残りませんから、ここはもう最初からデバッグモード全開です。CISCOはデバッグ情報をそれなりに吐き出してくれるので、問題発生時も対処しやすく、CISCOがCISCOたる所以なのではないかと思います。
まず分かったのは、ISAKMPの処理で、設定が不足しておりデフォルトのポリシが使用されているということです。普段は設定している下記のようなISAKMPコンフィグですが、今回は不要なのかと思って入れていませんでした。さっそくコンフィグを投入します。
Router# show running-config crypto isakmp policy 1 encr aes hash sha256 authentication pre-share group 14
次に表示されたデバッグは下記の通り。ISAKMPのポリシは設定した内容が参照されるようになりましたが、Android側と不一致を起こしているようです。デバッグを見れば一目瞭然ですが、意外とこの辺の情報ってインターネット上には転がっていなかったりしますね。ここは相手の要求値をサクッと追加して乗り越えます。
ISAKMP: (0):Checking ISAKMP transform 1 against priority 1 policy ISAKMP: (0): life type in seconds ISAKMP: (0): life duration (basic) of 28800 ISAKMP: (0): encryption AES-CBC ISAKMP: (0): keylength of 256 ISAKMP: (0): auth XAUTHInitPreShared ISAKMP: (0): hash SHA256 ISAKMP: (0): default group 5 ISAKMP-ERROR: (0):Hash algorithm offered does not match policy! ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 3 ISAKMP: (0):Checking ISAKMP transform 2 against priority 1 policy ISAKMP: (0): life type in seconds ISAKMP: (0): life duration (basic) of 28800 ISAKMP: (0): encryption AES-CBC ISAKMP: (0): keylength of 256 ISAKMP: (0): auth XAUTHInitPreShared ISAKMP: (0): hash SHA ISAKMP: (0): default group 5 ISAKMP-ERROR: (0):Proposed key length does not match policy ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 3 ISAKMP: (0):Checking ISAKMP transform 3 against priority 1 policy ISAKMP: (0): life type in seconds ISAKMP: (0): life duration (basic) of 28800 ISAKMP: (0): encryption AES-CBC ISAKMP: (0): keylength of 256 ISAKMP: (0): auth XAUTHInitPreShared ISAKMP: (0): hash MD5 ISAKMP: (0): default group 5 ISAKMP-ERROR: (0):Hash algorithm offered does not match policy! ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 3 ISAKMP: (0):Checking ISAKMP transform 4 against priority 1 policy ISAKMP: (0): life type in seconds ISAKMP: (0): life duration (basic) of 28800 ISAKMP: (0): encryption AES-CBC ISAKMP: (0): keylength of 256 ISAKMP: (0): auth XAUTHInitPreShared ISAKMP: (0): hash SHA256 ISAKMP: (0): default group 2 ISAKMP-ERROR: (0):Hash algorithm offered does not match policy! ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 3 ... ... ...
その3へ続く。
AndroidでCISCO 841MJにIPSec接続してみる その1 （2017/10/01） [ネットワーク機器]
Androidの設定画面の中にVPNという項目があり、前々から気にはなっていたんですよね。そう思って開いてみると、予想通りIPSecの文字列が。がんばればCISCOルータと接続できるんじゃないかと。
本当はAnyConnectをやってみたかったのですが、CISCO 841MJで使えるのか使えないのかよく分からず、まぁIPSecでもいいかって感じです。（AnyConnectはおそらく対応しているんだろうけど、ライセンスを別で買うとかサポート窓口にバイナリファイルを提供してもらうなど、いろいろ面倒そうな感じだったので）
ただ、IPSecってかなりくせ者で、RFCで仕様が公開されているとは言え、実装の部分で各社ばらつきがあり、他ベンダ間の相互接続はかなり骨の折れる作業だったりします。最終的に接続状態にはなりましたが、私のブラウザのタブにはこれだけの参考資料が開いていました。（不要になったページは適宜閉じているので、ピークはこの数倍です）
http://www.infraexpert.com/study/ipsec16.html
http://www.infraexpert.com/study/ipsec18.html
http://asaq8.hatenablog.com/entry/2014/08/03/000000
http://bisonicr.ldblog.jp/archives/54147837.html
http://blog.bluedeer.net/archives/48
https://www.cisco.com/c/ja_jp/support/docs/network-management/remote-access/117257-config-ios-vpn-strongswan-00.html
https://www.cisco.com/c/ja_jp/support/docs/security-vpn/ipsec-negotiation-ike-protocols/46242-lan-to-lan-vpn-client.html
https://www.cisco.com/c/ja_jp/support/docs/security-vpn/ipsec-negotiation-ike-protocols/117259-trouble-ios-ike-00.html
https://supportforums.cisco.com/t5/vpn/how-can-i-use-vpn-on-android/td-p/1951553
最初はまるまる参考ページもあったので、L2TP/IPSec PSKにチャレンジしました。コンフィグはサクッと入ったのですが、私がブロードバンドルータのポート転送をUDP/4500（IPSec NAT-T）だけしか設定しておらず、当然何も反応しない訳で、ルータを再起動してゼロからやり直すことにしました。（再起動してから、ポート転送が不足していると気付いた）
なんとなくの感覚は掴めたので、いきなりIPSec Xauth PSKにチャレンジです。おそらく正常通信をさせるのはかなり難しい作業になると思われるので、最初の目標は「接続完了状態」 とさせることです。
私はIPSecの専門家ではありませんが、CISCOルータ間で接続するトンネルモードのIPSecコンフィグは何度か作成したことがあるので、少しの知識はあります。とりあえず今回のポイントは、
・MainモードではなくAggressiveモードでの接続となること
・Xauthを実装する必要があること
・…
・…
・…
ってあれ？ それ以上思いつきません。大したことない知識ですね。
とりあえずUDP/500（ISAKMP）、UDP/4500（IPSec NAT-T）をポート転送するようにしたら、CISCOルータが反応するようになったので、ログと睨めっこすることにします。
その2へ続く。
本当はAnyConnectをやってみたかったのですが、CISCO 841MJで使えるのか使えないのかよく分からず、まぁIPSecでもいいかって感じです。（AnyConnectはおそらく対応しているんだろうけど、ライセンスを別で買うとかサポート窓口にバイナリファイルを提供してもらうなど、いろいろ面倒そうな感じだったので）
ただ、IPSecってかなりくせ者で、RFCで仕様が公開されているとは言え、実装の部分で各社ばらつきがあり、他ベンダ間の相互接続はかなり骨の折れる作業だったりします。最終的に接続状態にはなりましたが、私のブラウザのタブにはこれだけの参考資料が開いていました。（不要になったページは適宜閉じているので、ピークはこの数倍です）
http://www.infraexpert.com/study/ipsec16.html
http://www.infraexpert.com/study/ipsec18.html
http://asaq8.hatenablog.com/entry/2014/08/03/000000
http://bisonicr.ldblog.jp/archives/54147837.html
http://blog.bluedeer.net/archives/48
https://www.cisco.com/c/ja_jp/support/docs/network-management/remote-access/117257-config-ios-vpn-strongswan-00.html
https://www.cisco.com/c/ja_jp/support/docs/security-vpn/ipsec-negotiation-ike-protocols/46242-lan-to-lan-vpn-client.html
https://www.cisco.com/c/ja_jp/support/docs/security-vpn/ipsec-negotiation-ike-protocols/117259-trouble-ios-ike-00.html
https://supportforums.cisco.com/t5/vpn/how-can-i-use-vpn-on-android/td-p/1951553
最初はまるまる参考ページもあったので、L2TP/IPSec PSKにチャレンジしました。コンフィグはサクッと入ったのですが、私がブロードバンドルータのポート転送をUDP/4500（IPSec NAT-T）だけしか設定しておらず、当然何も反応しない訳で、ルータを再起動してゼロからやり直すことにしました。（再起動してから、ポート転送が不足していると気付いた）
なんとなくの感覚は掴めたので、いきなりIPSec Xauth PSKにチャレンジです。おそらく正常通信をさせるのはかなり難しい作業になると思われるので、最初の目標は「接続完了状態」 とさせることです。
私はIPSecの専門家ではありませんが、CISCOルータ間で接続するトンネルモードのIPSecコンフィグは何度か作成したことがあるので、少しの知識はあります。とりあえず今回のポイントは、
・MainモードではなくAggressiveモードでの接続となること
・Xauthを実装する必要があること
・…
・…
・…
ってあれ？ それ以上思いつきません。大したことない知識ですね。
とりあえずUDP/500（ISAKMP）、UDP/4500（IPSec NAT-T）をポート転送するようにしたら、CISCOルータが反応するようになったので、ログと睨めっこすることにします。
その2へ続く。
CISCO841M/J IOSバージョンアップ （2017/08/09） [ネットワーク機器]
CISCO 841M/Jの新しいIOS 15.5(3)M5が2017/02/08に出ています。こういったファームウェアについては、新しいものに飛びつくと痛い目を見ることがあるのでしばらく放置していたのですが、さすがに6ヶ月経ちましたしもう大丈夫でしょう。アップグレートしてみることにします。
CISCOからIOSをダウンロードします。そうそう、ここはCISCO StartのサポートWebページになります。良くも悪くもすっきりしていますね。
IOS アップグレードの手順なるものも置いてあるようですが、過去に何度もチャレンジして成功していますので、今回は読みません。※初めての方はぜひ読むことを強くお薦めします
基本的にIOSファイルを装置内部のストレージに転送すれば良いだけです。転送するための手段は、USB Flashによるコピー、HTTP、FTP、TFTP、xmodemなどがあったはずですが。
最近ではscpなんかも使えるみたいですね。私の家にはFreeBSDのWebサーバがあるのでHTTPを使用することにします。Windowsオンリーの人でもBlackJumboDogといった便利なソフトがあるので、Webサーバを立てる場合であってもさほど苦労しないと思います。
CISCO IOSのダウンロードファイルはZIP化されていますが、本当に必要なファイルは中身のbinファイルなので、展開してWebサーバ上に設置しておきます。自分で言うのも何ですが、手慣れたものですよ。
copyコマンドを使ってコピーします。
最近は便利な世の中になったものでCISCOルータでハッシュ計算ができるのですね。
CISCOルータはストレージ中のbinファイルを探して自動的に起動してきてくれるので、古いIOSを削除しても問題ありません。ですが、初回はフォールバックできるよう古いIOSは消さずに、下記のように指定するのが無難でしょう。
CISCOからIOSをダウンロードします。そうそう、ここはCISCO StartのサポートWebページになります。良くも悪くもすっきりしていますね。
IOS アップグレードの手順なるものも置いてあるようですが、過去に何度もチャレンジして成功していますので、今回は読みません。※初めての方はぜひ読むことを強くお薦めします
基本的にIOSファイルを装置内部のストレージに転送すれば良いだけです。転送するための手段は、USB Flashによるコピー、HTTP、FTP、TFTP、xmodemなどがあったはずですが。
Router#copy ? /erase Erase destination file system. /error Allow to copy error file. /noverify Don't verify image signature before reload. /verify Verify image signature before reload. archive: Copy from archive: file system cns: Copy from cns: file system flash: Copy from flash: file system ftp: Copy from ftp: file system http: Copy from http: file system https: Copy from https: file system null: Copy from null: file system nvram: Copy from nvram: file system rcp: Copy from rcp: file system running-config Copy from current system configuration scp: Copy from scp: file system sdflash: Copy from sdflash: file system security: Copy from security: file system startup-config Copy from startup configuration system: Copy from system: file system tar: Copy from tar: file system tftp: Copy from tftp: file system tmpsys: Copy from tmpsys: file system xmodem: Copy from xmodem: file system ymodem: Copy from ymodem: file system
最近ではscpなんかも使えるみたいですね。私の家にはFreeBSDのWebサーバがあるのでHTTPを使用することにします。Windowsオンリーの人でもBlackJumboDogといった便利なソフトがあるので、Webサーバを立てる場合であってもさほど苦労しないと思います。
CISCO IOSのダウンロードファイルはZIP化されていますが、本当に必要なファイルは中身のbinファイルなので、展開してWebサーバ上に設置しておきます。自分で言うのも何ですが、手慣れたものですよ。
copyコマンドを使ってコピーします。
Router#copy http://192.168.0.1/c800m-universalk9-mz.SPA.155-3.M5.bin flash: Destination filename [c800m-universalk9-mz.SPA.155-3.M5.bin]? Accessing http://192.168.0.1/c800m-universalk9-mz.SPA.155-3.M5.bin... Loading http://192.168.0.1/c800m-universalk9-mz.SPA.155-3.M5.bin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 59023172 bytes copied in 85.208 secs (692695 bytes/sec)転送事故が起きるとファイルが途中で切れている場合がありますので、まずは大ざっぱにファイルサイズを確認しておきましょう。明らかに桁がおかしいといったことがなければ大丈夫です。
最近は便利な世の中になったものでCISCOルータでハッシュ計算ができるのですね。
Router#verify /md5 flash:c800m-universalk9-mz.SPA.155-3.M5.bin ............................MD5 of sdflash:c800m-universalk9-mz.SPA.155-3.M5.bin Done! verify /md5 (sdflash:c800m-universalk9-mz.SPA.155-3.M5.bin) = 459ed3d88cd440d887b528e866544787確認できました。こちらも大丈夫そうです。これで無事に転送が終わりました。
CISCOルータはストレージ中のbinファイルを探して自動的に起動してきてくれるので、古いIOSを削除しても問題ありません。ですが、初回はフォールバックできるよう古いIOSは消さずに、下記のように指定するのが無難でしょう。
Router(config)#boot system flash:/c800m-universalk9-mz.SPA.155-3.M5.bin Cisco IOS Software, C800M Software (C800M-UNIVERSALK9-M), Version 15.5(3)M5, RELEASE SOFTWARE (fc1)
NTTフレッツ光回線が遅い その3（2017/05/07） [ネットワーク機器]
インターネット回線の変更は来年に実施するとして、とりあえず今できる「何か」をやっておくことにしました。そこで改めて請求明細を見ていると、不思議な文字列が。
・リモートサポートサービス 500円
・セキュリティ機能見張り番 190円
何なんでしょうか。ざっと調べてみることにします。
まず、リモートサポートサービスとは、NTTインターネット回線業者の枠を超えた、パソコンサポート窓口のようなもののようですね。
NTTは回線業者ですから、通常、NTTはインターネット回線に関わる問い合わせだけを受け付け、「パソコンで年賀状を作りたいけどどうすればいいか」「WiFiの設定がよくわからない」といった類いの質問は「サポート範囲を超えているため、お客様にてお調べ願います」と言えば良いのです。
ただ、それだとお年寄りなんかは困るでしょうから、このサービスは上記のようなパソコン教室的な問い合わせをサポート窓口で受け付けてくれる契約のようです。また、説明しても分からないユーザには、NTTオペレータから直接ユーザのパソコンを操作する仕組みもあるようです。
これが月500円なんですね。パソコンに関する質問を何でも聞いてくれるようなので、一般のユーザさんやお年寄りにとってはとても良いサービスだと思います。
http://flets-w.com/remote_support/
ただ、うちの親はこの契約のことを"一切知りませんでした"
サービスとしては良いのですが、一般ユーザにちゃんと告知していないのであれば詐欺に近いものがあります。だって約2000万世帯から徴収すれば総額100億円ですから。。。
まぁ、少なくとも実家に関しては私自身が同等のサービスを提供しているので、不要なサービスであり、解約することにします。club NTT Westのサポートページから解約申請をしておきました。（親にはちゃんと説明しています）
次にセキュリティ機能見張り番です。
これがまたよく分からない機能なのです。Webでは「ウィルスに感染しても、出口でブロック！」と記載されており、盗聴やリモートオペレーションに関する振る舞い防御システムのようです。ブロードバンドルータにそんな機能を搭載しているのかと思ってよく見たら、パソコンに専用ソフトウェアをインストールしろと書いてありました。
これが1台190円なんですね。うーん。リモートサポートサービス以上に認知度は低いのではないでしょうか。
もちろん、実家のパソコンにはそんなソフトウェアはインストールしていません
こちらに関しては、お金を徴収することを目的としたNTTのゴミサービスのような気がします。そもそもソフトウェアのインストールが必要であることを分かっている人が少数のような気がしますし、さらにその中でこのソフトウェアによって救われた人が何人いるのか。高い、高すぎる料金です。
どっちにしろ、実家のパソコンは私がリモートからオペレーションするので、こんなものインストールしたら私自身がブロックされてしまいますよね。全く以て不要なサービスです。
ただ、こちらはclub NTT Westからはライセンスの追加しかできない最悪な仕様のようで、親がNTTサポートセンタに電話して解約の旨を伝えてもらいました。
・リモートサポートサービス 500円
・セキュリティ機能見張り番 190円
何なんでしょうか。ざっと調べてみることにします。
まず、リモートサポートサービスとは、NTTインターネット回線業者の枠を超えた、パソコンサポート窓口のようなもののようですね。
NTTは回線業者ですから、通常、NTTはインターネット回線に関わる問い合わせだけを受け付け、「パソコンで年賀状を作りたいけどどうすればいいか」「WiFiの設定がよくわからない」といった類いの質問は「サポート範囲を超えているため、お客様にてお調べ願います」と言えば良いのです。
ただ、それだとお年寄りなんかは困るでしょうから、このサービスは上記のようなパソコン教室的な問い合わせをサポート窓口で受け付けてくれる契約のようです。また、説明しても分からないユーザには、NTTオペレータから直接ユーザのパソコンを操作する仕組みもあるようです。
これが月500円なんですね。パソコンに関する質問を何でも聞いてくれるようなので、一般のユーザさんやお年寄りにとってはとても良いサービスだと思います。
http://flets-w.com/remote_support/
ただ、うちの親はこの契約のことを"一切知りませんでした"
サービスとしては良いのですが、一般ユーザにちゃんと告知していないのであれば詐欺に近いものがあります。だって約2000万世帯から徴収すれば総額100億円ですから。。。
まぁ、少なくとも実家に関しては私自身が同等のサービスを提供しているので、不要なサービスであり、解約することにします。club NTT Westのサポートページから解約申請をしておきました。（親にはちゃんと説明しています）
次にセキュリティ機能見張り番です。
これがまたよく分からない機能なのです。Webでは「ウィルスに感染しても、出口でブロック！」と記載されており、盗聴やリモートオペレーションに関する振る舞い防御システムのようです。ブロードバンドルータにそんな機能を搭載しているのかと思ってよく見たら、パソコンに専用ソフトウェアをインストールしろと書いてありました。
これが1台190円なんですね。うーん。リモートサポートサービス以上に認知度は低いのではないでしょうか。
もちろん、実家のパソコンにはそんなソフトウェアはインストールしていません
こちらに関しては、お金を徴収することを目的としたNTTのゴミサービスのような気がします。そもそもソフトウェアのインストールが必要であることを分かっている人が少数のような気がしますし、さらにその中でこのソフトウェアによって救われた人が何人いるのか。高い、高すぎる料金です。
どっちにしろ、実家のパソコンは私がリモートからオペレーションするので、こんなものインストールしたら私自身がブロックされてしまいますよね。全く以て不要なサービスです。
ただ、こちらはclub NTT Westからはライセンスの追加しかできない最悪な仕様のようで、親がNTTサポートセンタに電話して解約の旨を伝えてもらいました。
NTTフレッツ光回線が遅い その2（2017/05/06） [ネットワーク機器]
深夜1時に測定した速度測定では約2.5Mbpsでしたが、さきほど深夜23時（22時間後）に再測定したら1.8Mbpsでした。ま、そんなもんでしょうね。
あまりにひどいので、auひかりやケーブルテレビ系列に変えることを本気で考えています。ただ、変更手続きはいろいろと面倒なので、それなりのお土産を持って親を説得したいものです。
やはり一番分かりやすいのはコストメリットでしょうね。とりあえず今の月額料金がどのくらいかと聞くと、「よく分からない」とのこと。請求書の場所を聞いても「よく分からない」とのこと。
とりあえずアカウントID、パスワードを聞き出してこちらで調べてみることにしました。契約しているプロバイダはぷららなので、ぷららのサポートページに行ってみます。
…月額料金1080円。安っ！
いやいや、そんな訳ないでしょう。しかも契約しているメニューが"フレッツ 光ネクスト 隼"と記載されています。ハヤブサってなんだ。私の知っている名称は"Bフレッツ"なので、怪しい業者に騙されたのでは？と思ってしまうほどの衝撃でした。
私の感覚では、全ての料金が一括でプロバイダから引き落とされるイメージだったのですが、金額の安さからして、NTT系の料金は別で徴収されているようですね。
そのため、NTT関係の別のアカウントID、パスワードを聞き出し、それっぽいWebにログインしてみます。その名も"Myビリング"です。NTT西日本提供のサポートページのようなので、怪しいサイトではないようです。
が、MyビリングページにWebでログインしたら、
「Myビリング」と「Webビリング」のID連携を行うことで、ログインしやすくなりました。
とのこと。しきりにID連携を進めてきますが、ホントに何コレ状態です。えっ、えっ、MyビリングページにWebブラウザでログインしているけど、それがWebビリングページじゃないの？ 全くの意味不明です。（WebビリングはNTTファイナンス系のサイトのようです）
ちなみに、ブログの表記は「ビリング」に修正しましたが、ついさっきまで「リビング」って書いていました。私と同じようにリビングって読んでる人は大勢いると思われます。
とりあえずMyビリングで請求明細を確認することができ、約5,800円/月のようです。ぷららの料金1080円/月と合わせると月額約7,000円/月となり、何コレめっちゃ高い。しかも"Web光もっともっと割"の3年拘束状態となっており、1,590円割引いてこの値段なので、べらぼうに高いことが判明。
こりゃいよいよ変更するしかないですよね。NTTはさっさとやめちゃいましょう。
しかしWeb光もっともっと割の3年拘束は気に掛かります。下手に中途解約すると高額な違約金が必要となるからです。もし実家のインターネット回線を切り替えるとしたら、いつがベストなのか。と、調べたかったのですが、
Myビリングページには、どこにも契約期間の情報が書かれていないのです。
ネットを駆け回ること15分。どうやら更新月の数ヶ月前あたりから、請求明細に記載されるようになるらしい。いやいや、それでは遅いのです。私は今知りたいのです。
さらにネットを調べること15分。どうやらclub NTT Westページに記載されているのこと。私はさらにさらにアカウントIDとパスワードを聞き出し、club NTT Westページにログインしました。（たらい回し？）
調べた結果、2018年までは残契約期間があるようで、本格的に変更手続きをするのはそれを待ってからの方が良さげということが判明しました。
はい、という訳では今できることは一旦終了です。
それよりもNTT回線のひどさにはもうウンザリです。回線の重さもそうですが、非常に分かりにくい請求形態・サポート形態など、個人的には悪質と表現しても過言ではないぐらいです。（実家とは言え、お金を払っている側の立場なので、言うことは言わせて貰います）
少しIT関係の知識のある私でこんな状態なので、全国の一般家庭のユーザさんはちゃんと理解・管理できているのでしょうか。本当に疑問です。
あまりにひどいので、auひかりやケーブルテレビ系列に変えることを本気で考えています。ただ、変更手続きはいろいろと面倒なので、それなりのお土産を持って親を説得したいものです。
やはり一番分かりやすいのはコストメリットでしょうね。とりあえず今の月額料金がどのくらいかと聞くと、「よく分からない」とのこと。請求書の場所を聞いても「よく分からない」とのこと。
とりあえずアカウントID、パスワードを聞き出してこちらで調べてみることにしました。契約しているプロバイダはぷららなので、ぷららのサポートページに行ってみます。
…月額料金1080円。安っ！
いやいや、そんな訳ないでしょう。しかも契約しているメニューが"フレッツ 光ネクスト 隼"と記載されています。ハヤブサってなんだ。私の知っている名称は"Bフレッツ"なので、怪しい業者に騙されたのでは？と思ってしまうほどの衝撃でした。
私の感覚では、全ての料金が一括でプロバイダから引き落とされるイメージだったのですが、金額の安さからして、NTT系の料金は別で徴収されているようですね。
そのため、NTT関係の別のアカウントID、パスワードを聞き出し、それっぽいWebにログインしてみます。その名も"Myビリング"です。NTT西日本提供のサポートページのようなので、怪しいサイトではないようです。
が、MyビリングページにWebでログインしたら、
「Myビリング」と「Webビリング」のID連携を行うことで、ログインしやすくなりました。
とのこと。しきりにID連携を進めてきますが、ホントに何コレ状態です。えっ、えっ、MyビリングページにWebブラウザでログインしているけど、それがWebビリングページじゃないの？ 全くの意味不明です。（WebビリングはNTTファイナンス系のサイトのようです）
ちなみに、ブログの表記は「ビリング」に修正しましたが、ついさっきまで「リビング」って書いていました。私と同じようにリビングって読んでる人は大勢いると思われます。
とりあえずMyビリングで請求明細を確認することができ、約5,800円/月のようです。ぷららの料金1080円/月と合わせると月額約7,000円/月となり、何コレめっちゃ高い。しかも"Web光もっともっと割"の3年拘束状態となっており、1,590円割引いてこの値段なので、べらぼうに高いことが判明。
こりゃいよいよ変更するしかないですよね。NTTはさっさとやめちゃいましょう。
しかしWeb光もっともっと割の3年拘束は気に掛かります。下手に中途解約すると高額な違約金が必要となるからです。もし実家のインターネット回線を切り替えるとしたら、いつがベストなのか。と、調べたかったのですが、
Myビリングページには、どこにも契約期間の情報が書かれていないのです。
ネットを駆け回ること15分。どうやら更新月の数ヶ月前あたりから、請求明細に記載されるようになるらしい。いやいや、それでは遅いのです。私は今知りたいのです。
さらにネットを調べること15分。どうやらclub NTT Westページに記載されているのこと。私はさらにさらにアカウントIDとパスワードを聞き出し、club NTT Westページにログインしました。（たらい回し？）
調べた結果、2018年までは残契約期間があるようで、本格的に変更手続きをするのはそれを待ってからの方が良さげということが判明しました。
はい、という訳では今できることは一旦終了です。
それよりもNTT回線のひどさにはもうウンザリです。回線の重さもそうですが、非常に分かりにくい請求形態・サポート形態など、個人的には悪質と表現しても過言ではないぐらいです。（実家とは言え、お金を払っている側の立場なので、言うことは言わせて貰います）
少しIT関係の知識のある私でこんな状態なので、全国の一般家庭のユーザさんはちゃんと理解・管理できているのでしょうか。本当に疑問です。
NTTフレッツ光回線が遅い その1（2017/05/05） [ネットワーク機器]
ゴールデンウィークなので、久々に実家に帰ってきています。普段はリモートからメンテナンスしている家族パソコンですが、ここ数日に限っては直接いじったりなど、それなりに楽しくやっています。まぁ、家族と物理的な接点を持てるというのは言うべきにもあらずですが。
私は自宅でauひかりを契約していますが、実家はNTT系の回線を契約しています。実家のインターネット回線は私が特に口を出した訳ではなく、成り行きでそういったことになっています。家族という一般人が使うインターネット回線なので、普通にインターネット通信ができれば何でも良いと思っています。
今回、時間的な余裕もあったことから、私のMacBook Airを持ち帰ってきています。実家はBuffaloの無線APを置いてあるので、ちょちょいと設定して電波を借りることにしました。そう、実はこのブログも実家の無線LAN上で書いています。
…が、異変に気付くにはさほどを時間を要しませんでした。とにかく遅い。インターネット関係の通信が、ダウンロードも含め何から何まで遅いのです。
普段、遠方からリモート操作する際、Skypeのカメラ画像の著しい乱れや、Teamviewer（リモートデスクトップみたいなソフト）のもっさり動作や無反応動作が気になってはいました。
また、パソコン環境のメンテナンスのために数MB〜100MBのアップデートバイナリ（.exe）のダウンロードを試みるにも、ここ近年では珍しい、"ダウンロードの強制中断"や"ファイル破損"に何度も遭遇していました。
これらはてっきりパソコンの処理性能の問題や、無線LAN環境や無線NICの不良とばかり思っていました。
しかし実際、親の生の証言を聞いてみると、日中帯はそれほどでもないが、特に夜間がまともにインターネット通信できないとのこと。…有線LANで通信しているにもかかわらず。
Youtube等で動画を見ていると、読み込み待機中のクルクルばかりで、ろくに動画も見られないらしいのです。そんな親の対策方法は、「早く寝て、早朝にインターネット接続する」ことらしいです。悲しすぎます。
さて、私のイライラがピークに達したので、一旦手を休め、ちょっとマシに感じ始めて来たこの時間帯に速度測定をやってみました。
ちょっとマシに感じ始めたこの時間帯ですらMAX 2.5Mbpsです。bit per secondです。byte per secondではありません。私の体感では上限800Kbpsが良いところでしょうか。こんな数字、電波状況の悪いLTEでインターネット通信をしているようなものですよ。これがNTT法の呪いというやつでしょうか。
私は自宅でauひかりを契約していますが、実家はNTT系の回線を契約しています。実家のインターネット回線は私が特に口を出した訳ではなく、成り行きでそういったことになっています。家族という一般人が使うインターネット回線なので、普通にインターネット通信ができれば何でも良いと思っています。
今回、時間的な余裕もあったことから、私のMacBook Airを持ち帰ってきています。実家はBuffaloの無線APを置いてあるので、ちょちょいと設定して電波を借りることにしました。そう、実はこのブログも実家の無線LAN上で書いています。
…が、異変に気付くにはさほどを時間を要しませんでした。とにかく遅い。インターネット関係の通信が、ダウンロードも含め何から何まで遅いのです。
普段、遠方からリモート操作する際、Skypeのカメラ画像の著しい乱れや、Teamviewer（リモートデスクトップみたいなソフト）のもっさり動作や無反応動作が気になってはいました。
また、パソコン環境のメンテナンスのために数MB〜100MBのアップデートバイナリ（.exe）のダウンロードを試みるにも、ここ近年では珍しい、"ダウンロードの強制中断"や"ファイル破損"に何度も遭遇していました。
これらはてっきりパソコンの処理性能の問題や、無線LAN環境や無線NICの不良とばかり思っていました。
しかし実際、親の生の証言を聞いてみると、日中帯はそれほどでもないが、特に夜間がまともにインターネット通信できないとのこと。…有線LANで通信しているにもかかわらず。
Youtube等で動画を見ていると、読み込み待機中のクルクルばかりで、ろくに動画も見られないらしいのです。そんな親の対策方法は、「早く寝て、早朝にインターネット接続する」ことらしいです。悲しすぎます。
さて、私のイライラがピークに達したので、一旦手を休め、ちょっとマシに感じ始めて来たこの時間帯に速度測定をやってみました。
CISCO 841M 新しいIOSが出てる（2017/03/03） [ネットワーク機器]
2017/02/08付けで、新しいIOS 15.5(3)M5が出ているようですね。まぁ、特に問題がないのであれば無理してIOSをアップグレードする必要はないのですが。
以下にリリースノートが転がっていて、修正されたバグ（Resolved Bugs）や残存バグ（Open Bugs）が載っていますが、結構出入りが激しいですねぇ。双方共に多過ぎです。IOSバージョンアップ時にOpen Bugsが10～20個ぐらいになったら安定してきたと考えても良いのかな。
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/15-5m-and-t/release/notes/15-5m-and-t-book/155-3MCAVS.pdf
ただ、これにはカラクリがあって、このリリースノートはルータ系ラインナップ全てが一元管理されているため、CISCO 841M Jに関係ない他機種のバグ情報も全て混ざってるんです。だから実質該当するバグはもっと少ないかと思います。
以下にリリースノートが転がっていて、修正されたバグ（Resolved Bugs）や残存バグ（Open Bugs）が載っていますが、結構出入りが激しいですねぇ。双方共に多過ぎです。IOSバージョンアップ時にOpen Bugsが10～20個ぐらいになったら安定してきたと考えても良いのかな。
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/15-5m-and-t/release/notes/15-5m-and-t-book/155-3MCAVS.pdf
ただ、これにはカラクリがあって、このリリースノートはルータ系ラインナップ全てが一元管理されているため、CISCO 841M Jに関係ない他機種のバグ情報も全て混ざってるんです。だから実質該当するバグはもっと少ないかと思います。
タグ：cisco
CISCO 841M JのスループットとCPU使用率（2017/02/16） [ネットワーク機器]
Cactiもzabbixも安定してきたところで、CISCO 841M JのスループットとCPU使用率の関係を測ってみました。スループットについては、ワイヤレート転送や遅延値を調べた訳ではなく、パソコンのロングパケットの連続転送にちゃんと追従してきてくれるかといったところをざっくり見ています。だから実際は、パソコンやファイルサーバ（FreeBSD）側の処理性能（ハードディスクの読み込み書き込み速度や、NICの性能）で頭打ちしているはずです。
CISCO 841M Jは、IPv4、IPv6共に有効にしていますが、実際のファイル転送はIPv4上で行っています。また、アクセスフィルタやQoS機能、NAT機能は一切設定していません。ルーテッドポートとVLAN間の転送処理として見てもらって良いです。（が、NetFlowによるトラフィック集計機能は動かしています）
■Cacti
■zabbix
CPU使用率がそれなりに上昇するようですが、製品の価格帯を考えれば十分ではないでしょうか。ちゃんとスループットも出ているようですし。ただ、この状態でQoSやらアクセスフィルタ、最近のinspectセキュリティ機能を動かすとどうなるんでしょうかね。
CISCO 841M Jは、IPv4、IPv6共に有効にしていますが、実際のファイル転送はIPv4上で行っています。また、アクセスフィルタやQoS機能、NAT機能は一切設定していません。ルーテッドポートとVLAN間の転送処理として見てもらって良いです。（が、NetFlowによるトラフィック集計機能は動かしています）
■Cacti
■zabbix
CPU使用率がそれなりに上昇するようですが、製品の価格帯を考えれば十分ではないでしょうか。ちゃんとスループットも出ているようですし。ただ、この状態でQoSやらアクセスフィルタ、最近のinspectセキュリティ機能を動かすとどうなるんでしょうかね。
