カテゴリー: Network

  • Netscreenのシリアル番号をコマンドで調べる方法

    Screen OSを使っているNetscreen、SSGでシリアル番号をコマンドで調べる方法

    以下のコマンドをTelnetやシリアルコンソールから実行する。

    get system
    

    このコマンドの上部に、シリアル番号や型番やライセンスなどが表示される。
    コマンドの結果は、長いので注意。
    備忘として。

  • Windows にスタティックルートを追加する

    Windows にNICが2つ(ネットワークが2つ)あり、別々のネットワークにつながっているとき、特定の宛先(通信先)だけ、特定のネットワークから通信を行い時がある。

    通信は、基本的にデフォルトゲートから外部に出ていくようになっている。同じセグメントの通信でなければ、ルーティング(経路制御)を行う必要がある。その時に、Windowsに設定するスタティックルートを追加する方法。

    ■現在の経路情報を表示する

    コマンドプロンプトで以下のコマンドを実行する

     ROUTE PRINT
    

    固定ルートがある場合は、“ROUTE PRINT”の固定ルートに経路情報の記載がある。

     C:\>ROUTE PRINT
     ===========================================================================
     インターフェイス一覧
      12...b8 6b 23 b2 d2 1c ......Intel(R) 82579V Gigabit Network Connection
      11...48 d2 24 c2 19 25 ......Atheros AR946x Wireless Network Adapter
       1...........................Software Loopback Interface 1
      18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
      19...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
      15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
      46...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
     ===========================================================================
     
     IPv4 ルート テーブル
     ===========================================================================
     アクティブ ルート:
     ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイ
     ス  メトリック
               0.0.0.0          0.0.0.0     192.168.43.1   192.168.43.127     25
             127.0.0.0        255.0.0.0            リンク上         127.0.0.1    306
             127.0.0.1  255.255.255.255            リンク上         127.0.0.1    306
       127.255.255.255  255.255.255.255            リンク上         127.0.0.1    306
          192.168.43.0    255.255.255.0            リンク上    192.168.43.127    281
      ~~~省略~~~
     
     ===========================================================================
     固定ルート:
       なし
     
      ~~~省略~~~
    

    ■ルーティング情報を追加する(経路情報を追加する)

    経路情報は、以下のコマンドで追加する

     route add -p [宛先のネットワーク] mask [サブネットマスク] [ゲートウェイアドレス] metric [優先順位]
    

    経路追加は、route add コマンドで追加できる。”-p”オプションを付けることで、Windows再起動後も有効な静的なルートを追加できる。(-pを付けない場合は、再起動すると経路情報が消える、route print時にも表示されない)

    例:デフォルトゲートを別のネットワークが持っている場合に192.168.100.0/24 宛の通信を、192.168.43.1のゲートウェイに送りたい場合

     route add -p 192.168.100.0 mask 255.255.255.0 192.168.43.1 metric 1
    

    ■ルーティング情報を削除する(経路情報を削除する)

     route delete -p [宛先のネットワーク] mask [サブネットマスク] [ゲートウェイアドレス] metric [優先順位]
    

    経路削除は、route delete コマンドで削除できる。

    例:上で設定した経路情報を削除する

     route delete -p 192.168.100.0 mask 255.255.255.0 192.168.43.1 metric 1
    

    Windowsもコマンドを使えば、いろいろとできる。情報が少なくて、一見するとかゆいところに手が届きにくいけど。

  • 仮想マシンからコピーした新しい仮想マシンでネットワークが動作しない

    VMware ESX上のWindows仮想マシンをコピー(複製)して、新しくWindows仮想マシンを作成したところ、NICの1つが正常に動作していないという現象が発生した。

    具体的には、仮想マシンのWindowsに2つのNICを設定しており、デフォルトゲートに指定されているネットワークは正しく動作していたが、もう1つのネットワークは自分以外との通信ができない状態で、外部からの応答もしない状態だった。

    この状態で、NICの問題と気が付くまでに時間がかかった。と、いうのも、デフォルトゲートを指定できないネットワークだったので、Windowsのルーティングの問題なのか、そもそもVMware ESX側のネットワークの問題だったのかの切り分けが大変だった。かつ閉鎖的なネットワークだったので、ネットワーク内の確認がめんどくさかった。

    ルーティングの問題かどうかは、同一セグメントの機器に対しても、PINGの応答がなかったので、ルーティングでは無さそうという区切りをつけられた。問題を簡潔にするため、静的なルートはすべて削除もした。

    次に、一応、Windows Firewallの設定を見直して、Firewallの機能をオフにしたり、明示的に穴をあけて試したが、応答なし。

    次に、ネットワーク機器の設定にVLANの確認をしていった結果、正常(予定委していた通り)であることを確認した。

    これで、残るはWindows自体なので、念のためSYSPREPをかけ、ネットワークの再設定をしたが状況は変わらなかった。ここまで来ると、該当のNICが腐っている(壊れている)としか思えない。なので、VMware ESX上で、新しくネットワークを1つ追加した。Windows上で、使えていないNICは設定を消して無効化して、新しく追加したNICに設定を行った。新しく追加したNICでは、ちゃんとネットワークの通信ができた。

    状況から考えると、元の仮想マシンからコピーした際にNIC情報が壊れたのではないか、もしくはWindows内部で何かおかしくなったのではないか、ということ。

    仮想マシンをコピーして、ネットワークがうまく動作していないときには、新しく作りなおす(追加しなおす)のがよい。

  • NetscreenとSRXのOID(MIB情報)

    調べたついでに、メモ書き。
    書いておかないと忘れるので。

    ■Netscreen のOID(MIB情報)

    1.3.6.1.4.1.3224.4   -> VPN系の情報
    1.3.6.1.4.1.3224.16  -> リソース系の情報
    

    ■Juniper SRX のOID(MIB情報)

    1.3.6.1.4.1.2636.3
    

    http://kb.juniper.net/InfoCenter/index?page=content&id=KB16545

    ■Juniper SSG のOID(MIB情報)

    Screen OSなので、Netscreenと同じようだ。

  • INTEROPで気になったもの:Splunk

    INTEROPに行って、フラフラと会場を彷徨って気になったもの。Splunkというマシンデータ分析プラットフォームのソフトウェア。有り体にいえば、単なるログ分析ツールだ。

    http://ja.splunk.com/product

    説明をきいたところで、気になったのはログの形式を選ばないということ。複数のログの形式、というかテキスト形式で送られてくるデータを溜め込んで、分類したり、インデックス化や検索ができるというところ。自分でルールを作ることも出来るし、CiscoのASAやJuniperのSSG/SRXなら最初から分析用のプラグインが存在している。Syslogで溜め込んで、あとから分析・・・するという形式よりも、Splunkに集めてリアルタイム分析したほうが早そう。まぁ、ログ分析のソリューションなら他にもあるわけだが、なんとなくコイツが気になった。

    導入がかんたんで、ビジュアル化も楽と言われるとね。ちょっと試してみたくもなる。気になるのは価格。Splunkは1日あたりのログの量でライセンス料が決まるとのこと。1日あたり500MBまではFree版で分析できる。あとは、1GB、2GB、5GBと言うようにライセンスが変わってくる。このライセンス形態も面白い。使う量が増えれば増えるほど、ライセンスが必要ということ。

    ログ解析自体が分散型アーキテクチャのMapReduceベースなので、ログが増えても台数を増やしていけばパフォーマンスが出るというのも面白い。ログ解析ソリューションだと、1台だけだったりして、大規模な解析ともなるとパフォーマンスが出なかったりするので。

    とりあえず、Free版を試してみようかと思う。

  • CiscoのCatalystでInterfaceにセカンダリIPアドレスを設定すると、ARPテーブルがおかしくなる

    CiscoのCatalystスイッチで、InterfaceにセカンダリIPアドレスを設定するとARPテーブルがおかしくなって通信ができなくなることがある。

    今回、ハマったのはPortChannelを使って、Cat3560にWLC(Wireless Lan Controler)を接続したところ、最初はWLCにPingが飛んだのだが、急にPingが飛ばなくなるという現象。接続が落ちたわけでもなく、リンクはアップしている。“sh ip arp”でARPを調べると、ちゃんとMACアドレスとIPアドレスが一覧にある。

    だが、Pingが飛ばない。

    ここで、“clear ip arp 192.168.0.XX”を実行して、ARPテーブルからWLCを削除してあげるとWLCにPingが飛ぶようになる。Pingを飛ばしたタイミングで、ARPテーブルにWLCのMACアドレスが登録されて正常な状態になる。

    おかしくなっているのは、Cat3560のARPテーブルなのだ。ちなみに、PortChannelをやめて、Active-Standby構成にしてみたが安定せず。セカンダリIPアドレスが設定されていない別のVLANにWLCを接続したところ、通信や挙動が安定するようになった。

    それで、ARPテーブルがおかしくなるのはなぜだ?と、いう話なのだが、Catalystで、InterfaceにセカンダリIPアドレスを設定するとARPテーブルが不可解な状態になるのは、ある程度有名なことらしい。

    こんなピンポイントでハマるとは・・・。こういう時もあるよね。

    おまけ。設定とか、いろいろ。

    ■InterfaceのセカンダリIPアドレス設定

     interface Vlan100
      description ServerSeg
      ip address 192.168.0.10 255.255.255.0 secondary
      ip address 192.168.0.1 255.255.255.0
     !
    

    ■ARPテーブルの表示

     cisco# show arp
    

    もしくは

     cisco# show ip arp
    

    ■ARPテーブルから、特定のIPアドレスのものだけを削除

     cisco# clear ip arp 192.168.0.XX
    
  • Windows 8 でAnyConnectを使用する方法

    Windows 8 では、Cisco のAnyConnectクライアントで接続できないというので、いろいろと調べて使えるようにしてみた。AnyConnectで使用するポートの名前に不具合があり、接続が確立できないようだ。Windows 8での接続は下記を参考に試してみてほしい。(稀に接続できないものもあるが、それはどっちかっていうと別の要因のようだ)

    ■検証に使ったもの

    AnyConnectのバージョン「2.5.2019」を使用して検証した。Windows は8のProを使用。

    ■表示されたエラーメッセージ

     AnyConnect was not able to establish a connection to the
     specified secure gateway. Please try connecting again.
    

    ■使用できるようにした手順。

    • AnyConnectのインストーラーを使用し、AnyConnectをWindows 8にインストール。この時、ウェブ画面からのインストールではなく、実行形式のインストールファイルをあらかじめ入手しておき、インストールを行う。
    • Windowsキー + R で「ファイル名を指定して実行」を開く。
    • regedit を入力し、レジストリエディタを開く。
    • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpnva] を開く。
    • [DisplayName]を右クリックし、修正を選択。%やらなんやらいろいろと入っているので、下記のように修正する(既に入力されている文字列を後ろから探すとこの文字列があるので、いらないところだけ消すとよい。)
     Cisco AnyConnect VPN Virtual Miniport Adapter for Windows x64
    • 編集したらOKをクリック
    • Windows 8を再起動する(再起動しないと、レジストリの情報をAnyConnectのクライアントが読み取ってくれず、エラーがつづく。)
    • すべてのアプリから、「Cisco AnyConnect VPN Client」を右クリックし、「管理者として実行」する。環境によるものかもしれないが、管理者として実行しないとVPN接続できなかった。なお、Windows8起動後に、AnyConnectを一般ユーザで起動してしまった場合、管理者として実行しなおしても、なぜか失敗する。その場合は、再起動からやり直す。
    • 接続先にASAのアドレスを入れて接続する。これで、接続できるはず。

    ■参考URL

    http://blog.exchangegeek.com/2012/03/windows-8-cisco-anyconnect-vpn-client.html

  • LaCie 2big NASをVMware ESXi にiSCSI接続する

    LaCie 2big NAS(LCN-2BN4TE)をVMware ESXi に接続しようと四苦八苦したときのメモ。

    LaCie 2big NAS は低価格でiSCSI接続もできるNASだ。簡単な設定でNASの領域とiSCSIで使う領域を変更することができ、1つのハードで両方とも使用することができて、結構便利なNASだ。

    LaCieのNASをESXi 5.1.0にiSCSIディスクとして接続させようとしたがどうしてもiSCSI接続し、ディスクとして使用することができなかった。失敗した手順は、以下のようになる。

    1. NASの管理画面から、iSCSIの設定を行う。
    2. ESXiにvSphere Clientで接続し、”構成タブ”の”ハードウェア”から”ストレージ アダプタ”を選択。
    3. デバイスに、iSCSI Software Adapterを追加(作ったときはvmhba32となった)
    4. 追加したアダプタを選択し、プロパティを開く。
    5. プロパティの”動的検出”のタブから、下のほうにある”追加”ボタンをクリックする。
    6. ここでiSCSIターゲットのアドレスを聞かれるので、サーバ名もしくはIPアドレスを入力し、OKをクリックする(ここで指定するのは、LaCieのNASのホスト名もしくはIPアドレスだ)。すると、ストレージアダプタの詳細欄に、追加したNASが表示されるはずだが、表示されない。ここにNASの名前(ESXiが割り振った名前)や識別子が表示されていれば成功。失敗した場合には、表示されていない。”イベントタブ”をクリックし、ログを確認する。すると以下のようなログが出力されていた。
    7. vmhba34 上の iSCSI ターゲット iqn.1995-05.com.lacie:LaCie-2big-NAS.localhost:target1 へのログインに失敗しました。 iSCSI イニシエータはターゲットへのネットワーク接続を確立できませんでした。
    8. CHAPなどのログイン設定を変えたり、そもそも認証をやめてしまっても同じエラーが出力されて接続できなかった。

    いろいろと調べたが、iSCSIターゲットであるLaCieのNASにログインするところで失敗しているということしかわからなかった。NAS側の設定画面で設定できる項目はほとんどなく、CHAP関連のところも設定を変えて試したが結局失敗した。

    NAS側の問題ということもあるので、Windows 7 からiSCSIでNASに接続を行ったが問題なく使用できた。ESXiもバージョン4.0.0のホストがあったので試しに接続を試みたところ、上記の手順で問題なく認識された。4.0.0のホストでは、そのiSCSIディスクをVMFS3でフォーマットし、実際に仮想マシンを作って稼働させてみた。これについても問題はなし。

    結論。

    VMware ESXi 5.1.0 でLaCie 2big NAS (LCN-2BN4TE)は、iSCSI接続できない。理由はログインできないことだが、詳しい原因は不明。相性問題ということありえる。

    なお、VMware ESXi 4.0.0を使用すれば、LaCie 2big NAS (LCN-2BN4TE)は、iSCSI接続し、使用することができる。(4.1.0系と5.0.0系は試していないのでわからない。)

    iSCSI接続できるNASなら、VMwareに接続できると思っていたけれど、実際には接続できないこともあるようだ。安いiSCSIのドライブでがんばろうと考える場合でも、安全のためにVMware Ready (CERTIFIED)の認定がされているiSCSIドライブを使用したほうがいい。

    ちなみに、このNASはiSCSI領域を1つしか作れない。iSCSI領域に2つ以上の機器から接続することもできない。安いNASなので、そこらへんは仕方ないだろう。

  • 中国のグレートファイアウォールが強化されVPN遮断かも?

    クリスマス・イブに届いたうれしくないニュースだ。中国のネットワークとインターネットの間にあるファイアウォール、それがグレートファイアウォール。(なんか変な表現だな・・・、他になんというべきだろうか。)これを使って、中国政府は都合の悪いウェブサイトへの通信を遮断する。最近だと、SNSやSkypeなどが規制されている(されたいた?)。数回、中国にいったことがあるが、このグレートな壁の所為で通信は安定しなかった。この迷惑な検閲システムが、さらに強化されるようだ。

    グレートファイアウォールが強化されて、今度はVPNについても 制限が行われるようだ。中身を傍受されることがあるのかないのかはわからない。ニュース記事によると、VPN接続の速度低下や切断があるとのこと。これが本当なら、中国の拠点と拠点間VPNを使用している企業は困ることになる。VPN上で、IP電話で通話していたものが使い物にならなくなったり、社外秘のデータのやり取りが困難になってくる。前々から、カントリーリスクの大きい国とは思っていたが、ここにきて更に危ない国になっている。中国での人件費もあがりつつし、この先、わざわざ中国でビジネスしなくてもいいだろう。

    ところで、Arcstar IP-VPNとかのサービスでも影響を受けているのだろうか。国内キャリアが提供しているサービスへの影響がとっても気になる。

    http://www.afpbb.com/article/environment-science-it/it/2917958/10022074

  • HTTP2.0のファーストドラフト公開の話

    もう1ヶ月も前の話だが、HTTPの次世代規格であるHTTP2.0のファーストドラフトが公開された。

    今、特に気にせずに使っているHTTPは1.1だ。これは1999年にRFCが提出された。自分がコンピュータを使い始めたのが2000年、HTMLやウェブについて勉強を始めたのが2001年だ。気にする前に決まっていれば、今のHTTP1.1が当たり前に感じるわけだ。そのHTTPの次世代規格がHTTP2.0だ。

    この10数年でHTTPを使った通信は、人々の暮らしを支えるものとして、無くてならないものになった。ウェブの閲覧はもちろんのこと、スマートフォンのアプリでつかっていたり、ゲームでもなんでも使っている。使い方も変わってきているし、今のHTTP1.1では限界が見えているから今、HTTP2.0の策定を行う必要があるのだろう。ユーザが使っている分には、HTTP1.1かHTTP2.0かは意識する必要はないだろうけど、エンジニアとしてはかなり大きな変化になるだろう。1.1から2.0への移行期の混乱やHTTP2.0を使ったアプリケーション開発、それからサーバの設定などなど。楽しそうな未来が待っていそうだ。

    まぁ、どこまでスムーズに移行されていくのかが心配だけど。時代に乗り遅れないように情報を集めたり、勉強したりしなくては。技術の世界は、ちょっとの油断でついていけなくなる。今でも、時代の最先端に追いつけていないわけで、これ以上、乗り遅れていきたくはないものだ。環境的な要因はあるものの最終的には個人の問題だし。

    また、HTTP2.0は利害関係なども含めて簡単には決まりそうも無い。いろいろな案があるので、まとめていくのは大変だろう。今のところ気になっているのは、HTTP2.0のベースになっているSPDYとHTTP2.0でTLSが必須になるのかというあたり。他はよくわからないので、何ともいえない。(ちゃんと調べろよ、といえばそれまでだけど。)

    ■参考URL

    今更とは思うが、HTTP2.0の話は書こうと思っていて仕事の忙しさを理由に書いていなかった。ブログなので、後から見返したり検索したりするので備忘録として書いておく。