カテゴリー: Network

  • NWR100ほしい。

    YAMAHAの無線LANルーターのNWR100がほしい。家のBUFFALOの無線LANルーターが安定しない(買ってから2年だけど)。YAMAHAなら、安定するんじゃないかと。コマンドでいろいろと遊べるし。

    製品ページもみたけれど、良さそう。
    https://network.yamaha.com/products/routers/nwr100/index

    あとは、ahamo光で使えるかどうか。9月発売なので、11月くらいになれば事例が出ているだろうか。

  • AnyConnectで接続後、VPN接続先のシステムにアクセスするとタイムアウトする

    AnyConnectで接続後、VPN接続先のウェブのシステムにアクセスすると最初は利用できるが、何回か動作しているうちにタイムアウトする。一度発生すると、ブラウザを変えても同じような状況になる。

    Windows PCを再起動すると、一時的にアクセスできるようになるが、また同じ状況が発生する。

    Windowsのイベントログをみると「cscan.exe」のエラーが多数発生していた。

    この「cscan.exe」を調べると、CiscoのAnyConnectクライアントで使われているものだった。VPN接続時のみで発生しているもので、VPN接続もやや遅いことを考えると、「cscan.exe」が悪さをしているようだ。

    対応として、Cisco AnyConnectクライアントのインストーラーを起動して、「Repair」を選択して、AnyConnectクライアントの修復を行った。修復後に試すと、問題は解消された。AnyConnectクライアントが何らかの原因で壊れていたのが原因。

  • Cisco Nexusシリーズでソフトウェアアップグレード時のストレージ容量が足りないときはコンパクトインストールを行う

    古めのCisco Nexusシリーズの場合、本体のSSDストレージが少なく、通常のインストール方法だと容量が足りず、OSイメージをアップロードできない場合がある。これは、Nexus OSのサイズがバージョンアップにつれて大きくなっているからだ。

    複数バージョンのOSイメージをNexus上に保存できない場合には、「コンパクト NX-OS ソフトウェア」を利用する。このコンパクトイメージを使ったコンパクトインストールを行うことで、Nexus OSのバージョンアップを行う。

    参考: https://www.cisco.com/c/ja_jp/td/docs/switches/datacenter/nexus3000/sw/upgrade/93x/upgrade/guide/b-cisco-nexus-3000-nx-os-software-upgrade-downgrade-guide-93x/b-cisco-nexus-3000-nx-os-software-upgrade-downgrade-guide-93x_chapter_011.html#id_61530

    コンパクトインストールを行ったとしても、Nexusの本体容量が少ないことにはかわりはない。そのため、利用しないOSイメージは消しておくのがよい。

  • ahamo光にインターネット回線を切り替えた

    スマートフォンの回線をソフトバンクからamahoに切り替えたので、インターネット回線もソフトバンク光からahamo光に切り替えた。これで少しは月額コストを抑えられるはず。

    ahamo光に切り替えたときのメモを残す。

    ahamo光の申込みはキャンペーン(10,000ポイントバック)を使ったので、ahamoからキャンペーン用のサイトで申し込みをした。たぶん、これが間違いだったのかもしれない。キャンペーン用のところでなければ、もっとスマートに申し込みなどができていたかもしれない。

    キャンペーンでは、docomoコンサルティングからの電話での申込み確認が必須。この電話がとてもダラダラと長い。重要事項の確認が微妙で事前に書類を読めば終わるようなことを電話で1時間くらいかかった。20分とか言っていたのだが。不明なところの確認もあったのだが、不明なところを質問すると、まるで答えられない。切り替え元のソフトバンク光から切り替えるときの注意点で、もとがPPPoE方式でないと、切り替えに時間がかかると言われた。なぜそれが必要なのかを聞いても、答えられなかった。それから、切り替え日で、新しい回線に切り替わってから、実際に通信できるまでに数日かかるという説明もあった。でも、なぜ数日もかかるのかについては教えてもらえず。というか、数日かかるとしか言われない。実際に、謎に2日もかかったわけなんだが。

    ルータについては、レンタルではなくて、バッファローのルータ(WSR-1800AX4P-WH)を購入した。OCNバーチャルコネクト対応のルータを用意する必要があったので、バーチャルコネクト対応かつ、とりあえず安いバッファローのWiFi6対応のものを買った。

    切替日の朝には、自動的にソフトバンク光側は通信できなくなっている、という説明だったので、そのままにしていた。が、切替日の朝でもソフトバンク光は使えていた。ソフトバンク光のルータの電源を落とし、フレッツ光の終端装置も電源を落とし、20分くらい放置してから、新しいルータ(WSR-1800AX4P)で自動接続を試したが、切り替わらない。というかIPv6のアドレスも取得しない。数時間放置して、ルータを再起動したが接続できない。時間をおいて、何度か試したが接続できず。切替日の翌朝も同じことを試したが、接続できなかった。

    切替日の翌日の夜に、確認したところ、IPv6のアドレスは取得できるようになっていた。だが、接続がOCNバーチャルコネクトではなくて、別のものが表示された後に、接続がきれていた。そのため、バッファローのルータを本体側のスイッチでAutoからマニュアルに切り替えて、ブラウザでルータの設定画面を開き、インターネットの設定で、OCNバーチャルコネクトを選択した。(このマニュアルでの設定は、ルータの物理スイッチがAutoに設定されていると表示されないので注意。物理スイッチのAuto設定と、ソフトウェアとしてのAuto設定の2つがあり、これが両方ともマニュアルになっていないと設定できない。)ルータの設定で、OCNバーチャルコネクトを選択して、何回かルータを再起動したら、IPv4のアドレスを取得した表示がルータのステータス画面で表示されて、ahamo光でインターネットの通信ができるようになった。

    ネットで見かけていたAmazon Primeビデオが見れないという書き込みもあったが見れた。PCからも、PS4からも、タブレットからも、Amazon Prime Videoは見れた。スプラトゥーン3の通信も問題なし。ルータの性能もあるかもしれないが、ソフトバンク光よりも通信速度は出ている。下りで300Mbpsくらい。

    教訓をまとめると・・・

    • 理由は不明だが、切替日の当日はahamo光に接続できない(ことがある?)。
    • ahamo光の申込み仲介をしているコンサルティングサービスの言う事は当てにならない。
    • バッファローのルータの自動接続設定は、ahamo光と相性が悪いかもしれない。本体側のスイッチをマニュアルモードにしておく。
    • ルータの設定で、OCNバーチャルコネクトを手動で選択して接続する。
    • Amazon Prime Videoは、ahamo光でも見れる。
  • Meraki APからNPSへのRADIUS認証でエラーが発生するようになった

    NPSサーバ再起動後に、Meraki APからNPSへのRADIUS認証でエラーが発生するようになった。そのときの対応のメモ。

    Meraki側には、下記のログがあり、PEAPの認証でこけていることがわかった。

    802.1X	Failed authentication (EAP failure)

    一応、Meraki APの再起動をやってみたが効果なし。Merakiの管理画面から、RADIUS認証を試してみるとエラーになった。RADIUS認証が影響していることが分かったので、RADIUS認証サーバであるWindowsのNPSサーバ側を調べた。

    NPS(ネットワークポリシーサーバー)側のログは、イベントビューアーの「Windowsログ」の「セキュリティ」に下記のログがあった。

    サーバーで拡張認証プロトコル(EAP)の種類を処理できないため、クライアントを認証できませんでした

    RADUISであるNPSサーバまでの通信は行われており、RADUIS認証の中で、ユーザの認証ができていないため、接続が拒否されていることがわかった。NPSサーバに対象を絞って、調査した。

    NPSサーバの管理画面で、「NAPを構成する」をクリックしてウィザードを開始してみると、「認証方法の構成」で「NPSサーバー証明書」が「なし」で選択できないことがわかった。つまりサーバ証明書がない(失効していても同じ状態)のが原因なので、これを解消するために対応した。

    いろいろと試した結果、結論しては、先の作業で解消した。

    1. NPSのサーバで、管理ツールから「証明機関」を開く。

    2. ローカルの証明サーバを選んで、右クリック。

    3. 「すべてのタスク」から「CA証明書の書き換え」を選択する。

    4. 証明書の書き換えで再発行する。

    5. NPSサーバ(サービス)を再起動する。

    これで、NPSからADのディレクトリに対して、認証ができるようになり、PEAPの認証が正常に行えるようになった。

  • F5 BIG-IP 仮想ロードバランサで、一部のアプリケーションサーバにのみ通信ができない

    Cisco NEXUS でVPC構成(VLAN多数)、VMware ESXiによる仮想化、F5 BIG-IPの仮想ロードバランサ、ロードバランサの配下に複数のアプリケーションサーバ、という構成で、ロードバランサの下のAPサーバに通信がうまくできない、という状態が発生した。

    状況を切り分けしてみると、下記のような状態になった。

    端末→ESXi→Cisco NEXUS (A)→ESXi→BIG-IP→アプリサーバ(X) ・・・ 通信OK

    端末→ESXi→Cisco NEXUS (A)→ESXi→BIG-IP→アプリサーバ(Y) ・・・ 通信OK

    端末→ESXi→Cisco NEXUS (B)→ESXi→BIG-IP→アプリサーバ(X) ・・・ 通信NG

    端末→ESXi→Cisco NEXUS (B)→ESXi→BIG-IP→アプリサーバ(Y) ・・・ 通信NG

    ※Cisco NEXUSは、2台(AとB)で、VPC(Virtual Port Channel)構成で、L3の役割を行っている。基本的に、VLANを超えるときは、必ずL3のNEXUSを通過する。

    ※端末と、APサーバ、BIG-IP仮想ロードバランサは、それぞれ別のネットワークに属する。

    最初は、L3スイッチである、NEXUSの設定を疑ったのだが、AとBで差異はなく、VPCとしての動作も問題がなかった。BIG-IPを経由しなければ、AとBのどちらのNEXUSを通過しても問題発生しない。

    BIG-IPの仮想ロードバランサでの通信制御が不具合につながっている可能性が高いことがわかった。BIG-IP仮想ロードバランサの設定を見ていくと、「Auto Last Hop」の設定がONになっており、これが影響していることがわかった。上位のスイッチであるL3のNexusは2台あるので、アクセスしてきたアクセス経路に通信を返す、のが正しいように見える。しかし、VPC構成になっているで、仮想MACアドレスで制御されているのため、アクセス元のスイッチに返してしまうと、経路が途中で変わってしまい、アクセス元の端末までパケットが届かない。

    BIP-IPのほうも、上位スイッチが冗長構成を行っている場合は、「Auto Last Hop」の設定は、オフ(無効)にすることが推奨されている。「Auto Last Hop」の設定をオフにすることで、無事に、AとBのどちらのNexusを経由しても、BIP-IP仮想ロードバランサの下のAPサーバと通信できるようになった。

    「Auto Last Hop」の設定は、BIG-IP仮想ロードバランサの設定画面で、

    「System」→「Configuration」→「Local Traffic」

    の順に選択する。Generalのプロパティに、「Auto Last Hop」の項目があるので、「Enabled」のチェックを外して保存する。

    Auto Last Hopの説明

    https://www.infraexpert.com/infra/bigip29.html

  • 2023年3月のWindows Update後、MSPEAPの無線LANで接続エラー

    今月(2023年3月)のWindows Update後、MS PEAPで接続している無線で、急に接続できないエラーが多発した。メーカーや機種については、ばらつきがあるので、機種固有の問題ではなさそう。接続できているPCも多いので、トリガーをWindows Updateが引いただけで、今回のアップデートに何かがあるというわけでもなさそう。

    1回、無線LANの接続を消して、MS PEAP接続を再設定すると接続できるようになる。ただ、既存の接続設定だと、RADIUSの認証ではじかれてしまう。

    ちなみに、無線LANのAPは、Meraki。Merakiでは、下記のエラーが出ていた。

    Client made an 802.1X authentication request to the RADIUS server, but it did not respond.
  • クラウドの障害は忘れかけたころにやってくる

    今日の夕方くらいから、Microsoft Azureで大規模な障害が発生した。原因は、AzureのWANの設定変更によるものだそうだ。詳細は、今後、ニュースサイトで掲載されるであろう。

    設定変更の確認を行っていないわけじゃないのだろうけど、巨大なパブリッククラウドのネットワークなので確認しきれなかった、ということなのだろう。ネットワーク系の障害はAWSもやっているし、そのほかのクラウドサービスもやっている。それにしても、Azureの上とそのネットワークでつながっているMicrosoft365系のサービスも一緒に止まったわけで、なかなか大きい障害だった。まぁ、復旧するまで見ているしかないわけだが。

    忘れたころに発生するというよりも、忘れそうになる前に、どこかしらの大手のパブリッククラウドがやらかしている気がする。結局、コントロールしようと思うと、オンプレで環境をもっておくのがいいというわけだ。経済的かどうかは、規模や体制にもよるけれど。

  • Merakiの無線LANのアクセスポイントを再起動する方法

    Merakiの管理画面から無線LANのAPを再起動する手順は下記。

    1. Merakiの管理画面(ダッシュボード)にログインする。

    2. 「ネットワーク」の部分で、対象のアクセスポイントがあるネットワークを選択する。

    3. 「ワイヤレス」からアクセスポイントを選択する。

    4. 「アクセスポイント」の一覧から再起動するアクセスポイントを選択する。

    5. ツールを選択する。

    6. 「デバイスの再起動」にあるAP再起動ボタンをクリックする。

    7. 確認が表示されるので、再起動する場合は「今すぐ再起動」をクリックする。

    8. ステータスが表示されるので確認する。

  • Windows上で処理されたrrdファイルをLinuxのRRDToolで処理しようとしたらエラーになった

    Windows上で処理されたrrdファイルをLinuxのRRDToolで処理しようとしたらエラーになった。WindowsにRRD Toolをいれて、いろいろとやるのもめんどくさかったので、別のWindowsで蓄積されたRRDのファイルを、WSLのUbuntuにrrdtoolをインストールして処理しようとしていた。「rrdtool dump xxxx.rrd」を行うと下記のエラーが発生した。

    zen@PC:~/rrd$ rrdtool dump seg-Pkts.rrd 
    ERROR: reached EOF while loading header rrd->ds_def

    Windowsの改行コードがはいっているため、LinuxのRRD Toolで処理できないというエラー。

    WindowsのRRD Toolでrrdtool dump して、Linux上のRRDファイルにインポートしないといけないようだ。

    つまり、WindowsのRRD Toolで作られたRRDファイルを、Linux上のRRD Toolで直接処理することはできない。

    おまけ。同じRRDのファイルに対して、fetchをしても、項目はあっているのに取得できない。これも改行コードが影響しているためと思われる。

    zen@PC:~/rrd$ rrdtool fetch seg-Pkts.rrd OutOctets 
    ERROR: unknown consolidation function 'OutOctets'