8/30/2015

テキストの未来

テキストの未来」というWHOOPSの記事がとても面白かった。メッセージプラットフォームはパーソナルアシスタント化していくが、その時の入力は音声ではなくテキストだという。

そういえば、FacebookはメッセンジャーアプリにMというパーソナルアシスタント機能を組み込んでいるという。そして、入力はSiriやCortanaのような音声ではなくテキストで、まさにこの記事に書かれている通りだ。将来、メッセージプラットフォームは単独のアプリではなく、OSに組み込まれて(iOSでいえば、Spotlight的に統合される)、サードパーティにボットAPIが提供され(様々な入力・表示が可能)、より専門的なパーソナルアシスタントが可能になったりしたら面白そう。記事中にある通り、メッセージプラットフォームはGoogleやAppleにとっての収益源を脅かす可能性があるが、より汎用的にしていくのも彼らなのだろう。

Hacker News

天気が悪いと私はバスで職場に行きます。私は停留所でバスが今どこにいて、いつ到着するかをニューヨークのMTAサービスにメッセージを送ることで調べられることを情報提供してくれた人に感謝します。確かに、地図上にバスを示すアプリはもっと情報が豊富ですが、バス時間を送信して私は考えました。「私は別のクXアプリをダウンロードしなくていいだけよかった」と。

各やり取りのルール(ルールというのはストレスがたまるアプリからアプリへの切り替え)を定義するGUIとは対照的で、テキストベースでは対話のやり取りはよく知られていて自由です。いろいろあるうちの一例にすぎませんが、私がタイプするテキストが右に表示され、他の誰かがタイプしたテキストが左側にあります。そして、下部に私がメッセージを作成する入力フィールドがあります。

「アプリはそのためにある」というパラダイムに代わる他の方法にGoogle NowやSiriがあります。しかし、私は音声でコンピュータとコミュニケーションを行うようになるという未来には懐疑的です。「2001年宇宙の旅」の中の映像や、彼女の語る音声はほとんどがごく自然な会話でした。しかし、マウスの操作やキーボードのタイピングあるいはアプリのアイコンをタップするなどUIをナビゲートするよりも、音声は多くの認知や肉体的な努力が要求されます。音声ならずっと速く片付けてくれるのに、あなたが計画を立てるのに誰かと膨大なテキストの交換をする時間を想像してみて下さい。たとえ多少不便であっても、テキストは多くの場合より快適です。

私は便利さではなく快適さを考えます。それがソフトウェアではもっとも重要なことで、テキストは信じられないほど快適な媒体なのです。テキストベースの意思の疎通が速く、楽しく、おかしく、自由で、くつろげ、はっきりしていて、首尾一貫した方法でもあります。一方、音声やユーザインタフェースは多くの場合そうではありません。いつもテキストに期待しています

テキストはもっともソーシャルで便利なコミュニケーション技術です。1:1、1:N、M:Nとどのモードでもうまく働きます。効率的にインデックス化や検索ができ、手動でもできます。翻訳もできます。自由な速さで生産され消費されます。非同期です。比較し、差分を取り、クラスタ化し、訂正し、要約し、アルゴリズムでフィルタができます。会話を枝分かれさせ、読み出しのみ(ラーキング)、注釈、引用、レビュー、要約、構造化された応答、解釈、更にパロディ。人々がテキストを使う幅、規模や深さは、他に並ぶものはありません。

「Bus Time」としての使いやすさと快適さはもしかしたら、このインタラクションはまだ最適化の余地があります。ボットの言語は不自然だし、何ヶ月も情報をやり取りして、私が尋ねたのがバスだけにも関わらず、私のバスだと分かりませんでした。これは実際にはアプリとサービスの間の基本的な違いを強調しています。我々は、入力/出力のための単なる評価項目としてサービスを見る一方、セッションからセッションへ状態を保ち続けるアプリも期待します。私はサービスがサービスからアプリに変化していくのを心待ちにしています。私はバスで席を使い、会話を続けます。

他の明らかな問題点はこのインタラクションがコマンド行と同じように厳格だという点です。もし、私が "23& 8ht 23M"と入力したら、うまく動かないかも知れません。メッセージ経由でのインタラクションを主にアプリを働かせるには、自然言語処理はまだ十分ではなく、ユビキタスではありません。

自然言語処理が成功するまで、現在の欠点を緩和するいくつかの方法がありますが、我々はちょうど今それらが少しづつ起きているのを見ることができます。

GUI支援チャット

Lark for iPhone」はiPhone上でHealthKitとインタフェースを持つバーチャルヘルスコーチです。彼らは、GUIでの折り込みフリー形式のチャットで素晴らしい仕事をしています。

Larkはメッセージデザインも素晴らしいです。トーンは自然で、テンポは速いですが、あなたの応答のように感じさせてくれて、そんなに速くはありません。

これらのスマート機能の一部はすでにiOSのメッセージアプリに組み込まれています。iOS 8の新しい機能QuickTypeは、T9やSwypeのような入力補助とさほど違いません。SMSからプロンプト("Send: 1 or 2")が一連の1タップ入力("1"、"2"、"Not sure")に変わるのはとても見事です。これはPhotoshopで加工されていません。

私はQuickTypeの利便性を活用するチャットエージェントがまだ見当たらないことに少し驚いています。主な障害はおそらくSMSが遅くて高価だからで、OTTメッセンジャーによるペルソナモデルのアプリなら理解できます。

ペルソナとしてのアプリ

ここ欧米市場では、電話でサービスと情報のやり取りをしたいなら、モバイルウェブサイトを訪れるよりはむしろアプリをダウンロードします。中国のWeChatやアジア全域の他サービスで、情報をやり取りするサービスがすぐそこ、メッセンジャーの中にあります。アプリをダウンロードする必要はありません。まるで、あなたがApp Storeの中でアプリをタップしたみたいに、App Storeアプリの中で使い始めます。

ペルソナとしてのアプリは私が前にBus Timeについて説明した問題をより見事に解決します(例えば、決してM23が私のバスだと状態を保持しません)。Bus Timeの簡単なオルタナティブは、ユニークな電話番号としてM23を提示し、私が代わりにメッセージを送ります。

欧米のWeChatになる明らかな候補はFacebook Messengerで、それらの方向性(「若者よ、ルックイースト」から新たに「若者よ、ルックウェスト」)に沿って何かをするためにデービッド・マーカスを迎えました。彼らは最近、アプリ開発者が自然言語を解析するのに助けとなるAPIを提供するWit.aiも買収した。おそらく、Facebookはすでにこれを試みるために、開発者を燃え尽きさせたという過去を非常に後悔しています。それでもなお、メッセンジャー体験で我々の交流に受け入れられるサービスを簡単に想像できます。

その一方で、Path(Appleの買収標的との噂)は友人の住所録の中に並ぶサービスや現場となるメッセンジャーを構築するため、TalkToを買収しました。KikとSnapchatは同じ市場に関心を持っています。今週末、舞台に到着したのはMagicで、完全にSMSで情報をやり取りするバーチャルアシスタントです。

欧米ではペルソナとしてのアプリのモデルが現れました。少なくともGoogle(なぜなら、検索を切り取ってしまうため)とApple(なぜなら、App Storeを切り取ってしまうため)にとって多少混乱をもたらすかも知れません。カードの台頭が実を結び、全てのコンテンツがアプリにロックされ、ウェブがチャットの中から急速に消費されるなら、それは特にそうです。次がワイルドカードSDKで実現された構想です。

今になって情報サイトProduct Huntに現れたカード型のメッシュチャットLukaをよく考えてみて下さい。

AppleとGoogleが次に考えるのは、1) Messengerの中で全てのサービスをバンドルするFacebookの企みを抑えようとする、あるいは 2) 叩こうとする、のがもっともあり得ることだと思うでしょう。

GoogleとAppleのもっとも確かな方向性は、メッセンジャーの一つを叩いて、自身のメッセンジャーHangoutsとMessagesを広げようとすることです。それは彼ら自身のモデルにある程度の混乱を引き起こすでしょう。しかし、手に負えないメッセンジャーを阻止するかも知れないもう一つの代替手段があります。それが、OSを超えて全てのテキストの中に組み込まれたサービスです。

より深いセマンティックス

私がこのポイントで示した全ての例は、ほとんどが個別のインタラクションの個別(discrete)モードを表現します。GUI支援チャットは率直な応答でエンドユーザに伝えるのに対し、ペルソナとしてのアプリは、あなたのメッセンジャーの連絡先リストへのスプリングボードから「ローンチ」アクションの開始にシフトしたに過ぎません。より早く列挙すると、コンピューティングの開始以後、主要なインタラクションモデルはとても個別的です。

もし次のモデルが滑らかなで会話的なら、大きく変わっていくのでしょうか? アプリをローンチするルールを定義するOSよりむしろ、ユーザは本来必要性やコンテキストに従ってサービスと一緒にインタラクションを走らせます。

我々は今日マーケット上でこのモデルの始まりを見ることができます。デスクトップでは、ChatGrapeがあなたのデータやドキュメントを得て実行するセパレートタブあるいはアプリをオープンする必要性を取り除いています。ただ'#'を入力し、あなたが探しているデータやドキュメントをそれに続けて入力します。

そうです。ここで見る例は、サードパーティ製アプリの中でファイルを開く事が必要ですが、ここからアプリをローンチせずにデータへすぐにアクセスできます。今はファイルにロックされるデータをメッセージで送る中に埋め込むことで作られるため、大きな生産性の上昇があります。

おそらく、Slackと同じくらいうまい入力手法としてメッセージを送ることを、誰も受け入れていません。Slackでは例えば、別の古典的な味気のない形式では、あなたは決してプロフィール情報を書き込みません。あなたはSlackbotとチャットするだけです。

Slackへの統合は素晴らしいです。例えば、あなたは単に/appearと入力すると、appear.in ビデオチャットがローンチします。

前述同様、appear.in アプリをローンチしますが、インタラクションモデルとはすぐ近くで、遍在するバーチャルアシスタントの鏡により近いです。あなたはエスケープ文字で支援されたかなり普通の言葉で表現します。そして、ビデオ通話をローンチしたり、ビデオ通話を受け入れたりします。

どのようにこれが電話で働くのかを想像するのは難しくありません。事実、すでにあります。

今、OSが特定できるキーワードの範囲は拡大しています。

ここではOSが電話を掛け、直ちに電話を初期化するキーワードとして "talk this out" を認識します。これがFaceTimeのローンチあるいは連絡先の中にある小さな "Call on Facetime" アイコンをタップすることで、余計な手順を省きます。

今、さらにもっと裾野を広げ、あらゆるオブジェクトに応答できるアプリやサービスを考えてみると、日付、動作、名前、ブランドなどがあります。OSに私がFoursquareユーザだと伝えると、私はFoursquareに直接レコメンドを問い合わせることができます。

サービスが私の入力に直接応答するとどうなるか、

あるいはメッセンジャーの外側で、テキストの選択で意味的に関連するコンテンツを応答するサービスを想像してみて下さい。

これについて興味がそそられることは、コンテンツを明示的にリンクすることの責任をどのようにコンテンツ制作者からOSやサービス自身へシフトするかです。もしかしたら、上記の例の中で、名前が強調される人が問題の中で語っているかも知れません。可能性は言語自身と同じくらい広がりがあります。

はじまりの終わり

メッセージを送ることは、あなたが通信を行う方法にとても似た方法で、マシンがあなたと通信を行う唯一のインタフェースです。もし、この投稿の中で述べられているトレンドのいくつかが広がるようなら、どのように我々がコンピュータと対話をするか質的な変化を示しています。今までコンピュータインタラクションが個別についてであったのに対し、コマンド行の入力、ファイルのクリック、ハイパーリンクのクリック、アイコンのタップなどの意図的なイベントがメッセージあるいは会話ベースのUIへの変化や暗黙のハイパーリンクがコンピュータインタラクションをずっと滑らかで自然なものにするだろう。

その上、メッセージを送る人工知能が明らかなフィードバックループから利益を得ます。我々はもっとボットやメッセージのUIで対話するようになり、より良くなっていきます。それはおそらくGUIにもいえることですが、ずっと小さいレベルです。一方、メッセージを送る人工知能は、決してGUIの世界では見られない速さでより良くなっていきます。しっかりつかまって下さい。

更新 (2016.01.07)

まず、FacebookがチャットのSDKを公開し、ボットを開発できるようになった。

8/27/2015

Google Fiのネットワークハンドオーバー

Googleの「Project Fi」は単なるMNOやMVNOではなく、複数のキャリア(SprinとT-Mobile)を使ったMVNOで、売りはその場所で最適のネットワーク(4G LTE)に自動的に繋がることだ。どんな具合かをテストして報告してくれた人がいる。その結果(概略)は、

  • Google Fi SIMは二つのプロファイルを持つ
  • アクティブプロファイルがネットワーク間をスイッチする
  • ネットワークのスイッチは高速だが、即時ではない (10秒程度)
  • 通話はWi-Fiからセルラーへハンドオーバーする
  • ...しかし、途切れないわけでなく... (2〜5秒途切れる)
  • ...そして、戻らない(Wi-Fi→セルラー→WiFiとはならない)
  • 通話はセルラーネットワーク間はハンドオーバーしない
  • データ通信はネットワーク間はハンドオーバーしない
  • Google Fi SIMは他の電話機では働かない
  • グローバルローミングはT-Mobile通じてのみ

Hacker News

8/25/2015

VIRLでBGPを調べる (6) - ルートリフレクタ その2

ルートリフレクタはフルメッシュIBGPと同じ経路を選択するとは限らない。フルメッシュの数を劇的に減らして管理しやすくしてくれるが、いくつか問題点が指摘されている。ループについては既に指摘したが、それ以外にも、MEDオシレーション問題や、最適化されない経路という問題が指摘されている。今回、MEDオシレーション問題を考えてみる。

1. BGPのベストパス決定

まず、BGPルータがベストパスをどのように決定するかだが、次のように3段階のフェーズで考えられている。

  • フェーズ1 (Adj-RIBs-In): ネイバーから受け取った経路の優先度(Weight、LOCAL_PREFなど)を計算する。優先度が最も高い経路を自ASのBGPスピーカーに広報する。
  • フェーズ2 (Loc-RIB): 経路の優先度が決まると、ベストパスが選択されてLocal-RIBがその都度更新される
  • フェーズ3 (Ajd-RIBs-Out): 隣接ASに広報する経路が選択される
Bgp decision process

いわゆるベストパスが選択されるのはフェーズ2の段階である。Ciscoの実装では、BGPは最初の有効なパスが現在のベストパスとなる。そして、届いた経路順に順番にタイブレーク方式で評価され、BGPテーブルに登録されていく。ベストパスが決定されると、それ以降はベストパスと、新しく届いた経路が比較されることとなる。

2. 決定論的MED処理

MEDやIGPコストは、LOCAL_PREF、AS-PATH、ORIGINなどの属性と違って、同じように比較されない。MEDは同一ASの場合は比較されるが、異なるASでは比較されないし、(Next Hopへの)IGPコストはBGPルータの場所によって変化する。そのため、最初は安定していてもルータやピアリングが再起動すると、MEDやIGPコストはルータによって優先経路が変わり、MED値が大きいパスが選ばれたり、IGPコストが遠くてもベストパスになる可能性がある。これはループを引き起こす原因にもなる。特にルートリフレクタはベストパスのみをクライアントに送るため、ルータは全てのパス(複数パス)を知ることができず、評価する情報が少なくなる。そのため、AS内で一意ではなくなり、MEDやIGPコスト次第でループを簡単に引き起こしてしまう。

このような状況を防ぐため、AS毎に比較する経路をグループ化して同一AS内でのベストパスを選択した後に、異なるASのベストパスと比較する振る舞い(決定論的)が実装されている。ほとんどのルータはデフォルトで決定論的MED処理を行うが、Cisco IOSは "bgp deterministic-med" コマンドが必要となる。

3. MEDオシレーション問題

この決定論的MEDの処理を行っても、経路が大きく変動(オシレーション)する問題が指摘されている。特にMEDの場合が顕著で(RFC 3345)、二つの階層化されていないクラスタがあり、EBGPで同一経路を違うASパス、MEDでそれぞれのクライアントが受信するChurn Type 1のモデルでは、経路が次のように変遷し、激しく振動してしまう。

Med oscillation
  1. リフレクタ(B、C)はクライアントから経路を受信する: BはY0、CはY1を選択

  2. ASパス MED IGP
    B * Y 0 10
    C X
    *Y

    1
    3
    2

  3. BとCが経路を交換: CがXを選択

  4. ASパス MED IGP
    B Y
    * Y
    1
    0
    3
    10
    C *X
    Y
    Y

    1
    0
    3
    2
    11

  5. CがBにWithdraw、CがEに広報: BがXを選択

  6. ASパス MED IGP
    B *X
    Y

    0
    4
    10
    C *X
    Y
    Y

    1
    0
    3
    2
    11

  7. BがCにWithdraw、BがAに広報: CがY1を選択

  8. ASパス MED IGP
    B *X
    Y

    0
    4
    10
    C X
    *Y

    1
    3
    2

  9. CがBにWithdraw、CがDに広報: BがY0を選択 最初に戻る

  10. ASパス MED IGP
    B *Y 0 10
    C X
    *Y

    1
    3
    2

4. VIRLで確認

実際にこのようなことが起きるのか、VIRLを使って確かめてみる。まず、VIRLで先ほどの次のネットワークを作成し、iosv-4(AS 65200)とiosv-5(AS 65100)から1.0.0.0/8を広報する。リフレクタにIOSvを使う場合は、bgp deterministic-medを有効にする。

Med oscillation virl

シミュレーションを開始すると、リフレクタとクライアント間、リフレクタ間のBGPメッセージのやり取りが増えて、経路が頻繁に変わり、MEDオシレーションが起きることが分かる。

RP/0/0/CPU0:iosxrv-2#show bgp summary 
Mon Aug 24 15:07:30.371 UTC
BGP router identifier 192.168.0.4, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 2866
BGP main routing table version 2866
BGP NSR Initial initsync version 6 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker            2867       2867       2867       2867        2867           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
192.168.0.1       0 65000    2857    2860     2866    0    0 00:06:43          5
192.168.0.3       0 65000      13    2862     2866    0    0 00:07:17          5
192.168.0.5       0 65000      14    2862     2866    0    0 00:07:18          3

5. ワークアラウンド

オシレーションが発生すると経路が不安定化する上にルータに負荷が掛かる。ワークアラウンドとしては、次のようなものがある。一番簡単なAS間のMEDの比較(bgp bestpath med always)をリフレクタに投入するとこのMEDオシレーションはおさまった。

  • リフレクタ間のコストをクラスタ内のコストよりも大きくする(このテストの場合、コストを20にしておけば良い)
  • MEDを無視(set metric 0)
  • bgp always-compare-med (AS間でもMEDを比較)
  • 経路に優先度を付ける
  • 複数パスを広報する(ADD-PATH): IBGPフルメッシュに近づける

8/24/2015

2015年ヒューゴー賞長編部門

今年のヒューゴー賞長編部門は中国のSF作家、劉慈欣(りゅう じきん)《地球往事》三部作の第1作『三体』(英語名: The Three Body Problem)が受賞した。中国語での出版は2008年だが、2014年11月に英訳が出た。邦訳はまだ無し。

8/23/2015

VIRLでBGPを調べる (5) - ルートリフレクタ その1

BGPは、IBGPで受け取った経路を他のIBGPピアに広報しないルール(BGPスピリットホライゾン)になっている。必然的に、IBGPは全ルータをフルメッシュで接続する必要が出てくる。台数が少なければ、フルメッシュが一番確実な方法だが、AS内のBGPルータ数が増えてくると「n*(n-1)/2」でピアリング数が増えるため、管理が難しくなる(200台のIBGPルータがあると、19900のBGPセッションができる)。そこで、フルメッシュを避けるために、ルートリフレクタとコンフェデレーションという機能が追加された。どちらかというと、もっともよく利用されるのがルートリフレクタである。

1. 基本動作

ルートリフレクタ(RR)はルータ群をクラスタと呼ぶグループに分け、クラスタ内で中心となるリーダルータを決定し、それをルートリフレクタとする。クラスタ内のその他のルータはリフレクタのクライアントとなる。リフレクタはBGPプロトコルを大きく変更せず(属性追加のみ)、リフレクタとなるルータのIBGPの挙動を変えたもので、その名の通りIBGPの経路をリフレクト(反射)する。リフレクトというのは、リフレクタはクライアントから受け取った経路(自分が持つ経路とEBGPで学習した経路)を収集し、ベストパスを計算した後に、そのベストパスをRRクライアントに広報することをいう(この時、リフレクタは属性を変更しない)。

ルートリフレクタのネットワーク構成の約束事をまとめると次のようになる。

  • クライアント同士はIBGP接続できない
  • リフレクタ同士は非クライアント
  • 非クライアントとはIBGPフルメッシュ
  • リフレクタがクライアントになれる(階層構成)
  • クラスタはオーバーラップ可能

そして、基本動作をまとめると次のようになる。

  • EBGPからの経路は、クライアント・非クライアントに送る
  • クライアントからの経路は、クライアント・非クライアントにリフレクト、EBGPに送る
  • 非クライアントからの経路は、クライアントにリフレクト、EBGPに送る
  • リフレクトするのはベストパス
  • 属性を変更しない(NEXT_HOP, AS_PATH, LOCAL_PREF, MED, ...)
Route reflector network

2. リフレクタの属性

リフレクタは同一AS内であるため、経路ループの検出をBGP属性では判定できないため、次の属性が追加されている。

  • Orignator-ID: リフレクタが生成するオプション非通過属性。最初のリフレクタが受信経路に自ルータIDを入れる。リフレクタは自分のルータIDの経路が広報されてきたら、経路が戻ってきたと判断し、そのUPDATEを無視する。また、同じ経路が複数ある場合は、Originator-IDが小さい経路を優先する
  • クラスタリスト: リフレクタを冗長化したり階層化する際に必要となるオプション非通過属性。クラスタID(通常はルータID)は同じクラスタであることを示し、クラスタを通過するとそのIDをクラスタリストに追加していく。受信経路に自クラスタIDが含まれていれば、その経路はループしていると判断して無視する。また、同じ経路が複数ある場合はクラスタリストが短い経路を優先する

3. リフレクタの構成(冗長化の動き)

下図のようなネットワーク構成での動きを考えてみる。

Reflector redundant

3.1 クラスタIDが同じ場合

  1. CがFから経路pを受信し、AとBに広報
  2. Aはクラスタリスト属性を作成し、クラスタID(Bと同じ)を挿入。Originator IDにCをセット。そして、AはB、D、Eにpを広報
  3. Bはupdateを受信するとクラスタID(B)がリストに含まれているため、広報を破棄
  4. BもCからupdateを受信、クラスタリスト属性作成し、クラスタIDを挿入。Originator IDにCをセット。BはD、E、Aにpを広報
  5. AはBからupdateを受信すると、クラスタID(A)がリストに含まれているので破棄
  6. AとBは一つの経路のみ保持する

3.2 クラスタIDが異なる場合

  1. CがFから経路pを受信し、AとBに広報
  2. Aはクラスタリスト属性を作成し、クラスタID(A)を挿入。Originator IDにCをセット。AはB、D、Eにpを広報
  3. Bはupdateを受信するとクラスタIDがリストに含まれていないので、広報を受け付け、リストにクラスタIDを付け加える
  4. BもCからupdateを受信、クラスタリスト属性作成し、クラスタIDを挿入。Originator IDにCをセット。Bはベストパスアルゴリズムを実行し、C経由の直接パスを選択し、D、E、Aにpを広報
  5. AとBは異なるクラスタIDを使っているので、DとEはお互いにUpdateのコピーをAとBから受ける

4. ルートリフレクタにおけるループ

ルートリフレクタが冗長化されていたり、階層構成になる場合、物理トポロジーを理解しておかないとループを起こす可能性が常にある。定常時は問題が無くても、障害が起こると発生するケースも考えられる。現実にはあり得ないが、典型的なループを起こす構成は下図のような構成で簡単にループが起こる。

Reflector loop
  • AとDは10.1.1.0/24をeBGPで受け取る
  • BはDを優先、CはAを優先
  • ループになる!!

4. VIRLでルートリフレクタをシミュレーション

VIRLでルートリフレクタをシミュレーションしてみる。リフレクタの設定は、AutoNetKitを使えばとても簡単である。

  1. ルータを下図のように配置して結線
  2. AutoNetKitタブでIGP、アドレスファミリーを選択
  3. ルータにASNを設定
  4. 一番上位のリフレクタとなるルータを選択し、iBGP Roleを"RR"に設定し、識別用の数字あるいは名前を設定
  5. その下位のリフレクタ/クライアントとなるルータを選択し、iBGP Roleを"HRR"に設定して、RR Clusterに上位の識別IDを、HRR Clusterに下位の識別IDを設定
  6. そして一番下のルータを選択し、iBGP Roleを"RRC"に設定し、HRR Clusterに識別IDを設定
  7. 最後に"Build initial configurations"をクリックして完了

階層RRを作る際は、上からRR→HRR→RRCと設定すればよい。階層化リフレクタは2段構成までで、これ以上の段数を設定する場合は手動になるようだ。

Reflector virl

シミュレーションを行い、iosv-4でiosv-8から届いた経路を確認してみる。iosv-8から届いた経路にiosv-3のOriginator-ID、クラスタリストに3つのクラスタIDが入っていることが分かる。

iosv-4#show ip bgp 192.168.0.17
BGP routing table entry for 192.168.0.17/32, version 20
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100
    192.168.0.7 (metric 5) from 192.168.0.2 (192.168.0.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.0.7, Cluster list: 192.168.0.2, 192.168.0.1, 192.168.0.3
      rx pathid: 0, tx pathid: 0x0

iosv-2とiosv-4の間のパケットを調べてみると、確かにその通りである。

Reflector packet

ジェブ・ブッシュ氏、暗号化に反対表明

共和党の大統領候補ジェブ・ブッシュ氏は警察が犯罪者を追跡するのを難しくするからと暗号化に反対を表明(Slashdot)。この主張で支持が増えると思っているのかしら?

大統領候補ジェブ・ブッシュ氏はテック企業に諜報機関ともっと協調して動けと呼び掛けた。サウスカロライナの遊説で、ブッシュ氏は「あなたが暗号化をしたら、市民の自由を守りながら、アメリカ政府が犯罪者が我々の中にいないかどうかを確かめる仕事を行うのが難しくなる」と暗号化への主張を明確にした。彼は最近のパトリオット法(米国愛国者法)縮小は行き過ぎだと感じていることも表明した。ブッシュ氏は、市民の自由を侵害する通話のメタデータの大量収集を暗示したものではないと語った。

8/21/2015

NTPセキュリティ・プロジェクト

安全で、確かなNTPサーバを作る目的で「NTPセキュリティ・プロジェクト」が設立されるとのこと。2015年8月24日に立ち上げ予定。Linux財団のCore Infrastructure Initiative (CII)はNTP(ntpd)の開発者Harlan Stenn氏の支援を1年延長することを決めたが、NTPコードのモダナイズのためにPoul-Henning Kampと、NTPのセキュリティ・プロジェクトを創設したAmar Takhar氏にも支援を行うことを決めていた(InformationWeek)。

Hacker News

8/20/2015

Ciscoが不正なROMMONに入れ替えるハイジャック攻撃を警告

Ciscoが、ROMMONイメージを入れ替えることで、ネットワーク機器をハイジャックする攻撃を公式に警告しているとのことだ(ars technica)。攻撃者は有効な管理資格を使ってデバイスにアクセスし、ROMMONのフィールドアップグレードし、不正なROMMONをインストールするという。Ciscoからの情報は少ないが、シュナイアー氏はブログで「This is serious (これは深刻だ)」と書いている。

スノーデン文書にあった、NSAが輸出前のCisco製品にバックドアを仕込んでいた話と関係しているのか? 我々にできることは、最初にROMMONイメージのハッシュを比較するくらい?

8/19/2015

新しいDDoSリフレクション攻撃の標的はPortmapperか?

Level 3が新しいDDoS攻撃方法を見つけたとして、ブログで発表している。今まで使われてきたDDoS/DRDoS攻撃は、どこにでも存在し、応答が送りつけたパケットよりも増幅されるプロトコル(DNS、NTP、SSDP)が選ばれている。今回、見つかったのはPortmapper(rpcbind、portmap、RPC Portmapperなど実装によって呼び名は異なる)を使ったもの。小さいもので68バイトのクエリで486バイトの応答があり、増幅率は7.1倍。大きなもので1930バイトの応答があり、増幅率は28.4倍あった。トップトーカ300の平均応答サイズは1241バイト。明らかにこれらの増幅率であれば問題が起こりうると評価している。Portmapperのトラフィックは増え続けているが、DDoSに使われる一般的なUDPサービスと比較するとまだ小さい。NFS、NISなどのRPCサービスを使わない限り、Portmapperを落とす。使うにしても、ファイアウォールで相手を特定する、またTCPに切り替えることで緩和させることができる。

Portmap highres1

8/18/2015

OS Xのsudoに気を付けよう

Appleはsudoのtty_ticketsを無効にして出荷しているそうだ(Rondam Ramblings)。ということは、マルウェアを含めすべてのプロセスがsudoセッションを使うことが可能になるということだ。二つのターミナルを開いて、一方でsudoを使ってから、もう一方で使うとパスワードを尋ねられない(デフォルトでは15分間)。防ぐのは簡単で、visudoで「Defaults tty_tickets」を加えておくこと。「timestamp_timeout=0」にすればパスワードキャッシュも無効になり、毎回パスワードを聞くようになる。

Hacker News

8/17/2015

VIRL Aug 2015リリース

結局、VIRL Aug 2015(virl.0.9.280)がリリースされていたので書き直し。VIRLのコンポーネントとイメージだけではなく、UbuntuとOpen Stackもアップグレードした方がいいので、full_upgradeスクリプトを実行した方がいい。そして、VIRL v0.9.242のサポートは9月14日で終了。

Package/VM image Description Version
VIRL-CORE STD/UWM Core package 0.10.17.7
AutoNetkit Configuration engine package 0.18.1
AutoNetkit-Cisco Configuration engine package - Cisco extensions 0.18.9
Topology Visualization Engine Engine for rendering network topology views 0.12.3
Live Network Collection Engine Data collection and processing framework 0.6.11
VM Maestro VIRL UI installer 1.2.3-288
CSR1000v Cisco IOS XE reference platform 3.16
IOSv Cisco IOS reference platform 15.5.3.M
IOSvL2 Cisco IOS reference platform 15.2.4055
NX-OSv Cisco NX-OS reference platform 7.2.0.121
lxc_iperf Light-weight server running in LXC with IPerf 2.0.2
lxc_server Light-weight server running in LXC 14.04.2

8/16/2015

VIRLでBGPを調べる (4) - AIGP

プロバイダの買収や、IGPのスケーラビリティの問題から複数のAS(厳密にはAutonomousではないが)に分割するなどして、複数ASを一つのネットワークとして管理しなければならない場合がある。BGPはAS内メトリック(コスト)を運ぶ専用の属性を持たないため、複数ASをIGP的な最短パスで運用するにはテクニックが必要だった。一番多いケースはIGPメトリックをMED値に変換して、隣接ASに広報する方法かもしれない。ただし、MEDは評価順位が低いため、思ったようなコントロールが難しい。そこで、IGPメトリックをBGPで運び、更にIGPメトリックを積んで(accumulate)評価する方法が考えられ、RFC 7311(The Accumulated IGP Metric Attribute for BGP)として標準化された。AIGPはASパス長の評価よりも優先されるため(CiscoでもJunosでも4番目でASパス長の評価の前)、ASパス長が長くてもAIGP値が小さければ、そちらが優先される。

下図のようなネットワークをIOSvで作ってみた。リンク上の数値はOSPFのコストである。

スクリーンショット 2015 08 12 6 35 47

例えば、AS65100から上の回線にMED=20、下の回線にMED=10で広報すると、当然PE1から見ると、下の回線が優先される。

PE1#show ip bgp 192.168.0.13
BGP routing table entry for 192.168.0.13/32, version 42
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100
    192.168.0.2 (metric 41) from 192.168.0.2 (192.168.0.2)
      Origin IGP, metric 10, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

次にPE2でAIGP属性を加えた経路を設定してみる。AIGP属性を加えるには、Ciscoの場合はredistributeあるいはnetworkを使う。また、ピアリングでneighbor aigpを設定して、AIGP属性が送受できるようにしておく必要もある。

router bgp 65100
 address-family ipv4
  network 192.168.0.13 mask 255.255.255.255 route-map set-aigp
:
route-map set-aigp permit 10
 set aigp-metric igp-metric

この状態でPE1でPE2の経路(192.168.0.13/32)を確認すると、トータルAIGP値が小さい上の回線が優先される。IOSvの表示はちと分かりにくいのだが、metric値とaigp-metric値の合計(21+31)がトータルAIGP値となる(Accumulatedと言われる所以)。ちなみに、IOS-XRvの方はちゃんと"Total AIGP metric"が表示される。

PE1#show ip bgp 192.168.0.13
BGP routing table entry for 192.168.0.13/32, version 44
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100
    192.168.0.1 (metric 21) from 192.168.0.1 (192.168.0.1)
      Origin IGP, aigp-metric 31, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65100
    192.168.0.2 (metric 41) from 192.168.0.2 (192.168.0.2)
      Origin IGP, aigp-metric 21, metric 10, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

上の回線にASパスを加えてみても、変わらず上の回線がbestになっていることが分かる。

PE1#show ip bgp 192.168.0.13
BGP routing table entry for 192.168.0.13/32, version 46
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100 100 100 100
    192.168.0.1 (metric 21) from 192.168.0.1 (192.168.0.1)
      Origin IGP, aigp-metric 31, metric 20, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65100
    192.168.0.2 (metric 41) from 192.168.0.2 (192.168.0.2)
      Origin IGP, aigp-metric 21, metric 10, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0

AIGP属性のパケットを付け加えておく(ASBR11-ASBR21間でキャプチャ)。

Bgp aigp capture

AIGPのデプロイには注意が必要。

  • AIGP属性は各BGPスピーカが複数の経路から選択できる方がより効果的なので、Best ExternalやADD-PATH手法を併用することが強く推奨されている
  • Route Reflectorがクライアントへの全パスを通過させないなら、Route Reflector自身から一番小さいNext HopへのIGP距離へのパスを選択してしまうため、最適ではない経路を選択をする可能性がある
  • IGPメトリックはたびたび変化するので、BGP UPDATEがその度に送られる
  • AIGP属性を持つ経路の優先度は高くなるが、たとえメトリック値が大きくても、AIGP属性を持たない経路より優先度を高くなってしまうので注意。AIGP属性を持たない経路があるなら、比較しない方がいいだろう(Ciscoの場合、bgp bestpath aigp ignore)

8/15/2015

Googleのデータセンターネットワーク技術

Googleは自社のデータセンターネットワーク内部をあまり明らかにして来なかったが、競合先のAmazonとの違い(優位性)をアピールする必要が出たきたためもあるのか、今年の6月に開催された「Open Network Summit」で、Googleのネットワーク技術について講演を行った。いろいろなところで報じられているが、少しまとめておきたい。

今までのデータセンターネットワークはブラウザからWebサーバにリクエストが届いて、サーバはそれに応答するという形だったので、ネットワークの様式は南北指向ネットワークと呼ばれ、外部(インターネット)との通信が中心だった。そのため、トポロジーはファットツリーと呼ばれるものでよかった。ところが、WebページがリッチになりAPIサービスを使ってバックエンドに大量の通信が発生するようになり、ネットワークの様式は南北からデータセンター内部(サーバ間)あるいはデータセンター間の通信が中心となり東西指向ネットワークになった。そこで、コアスイッチを頂点とするファットツリー構造では頂点がボトルネックとなってきた。この問題にいち早くぶつかったのがGoogleだったので、独自に解決策を探ったということだろう。Googleが採った解決策は次のとおり。

  • Closトポロジーを採用し、小型で安価なスイッチの集合を作ることで、大きな論理的なスイッチを作っている
  • SDN技術を使って数千のスイッチ(ホワイトボックス)をセンターでコントロールしている
  • インターネットの標準プロトコルは(OSPF、ISIS、BGPなど)、代替パスを念頭においていない(最適パスを選択するうよううにできている)ので、Google自身が開発したプロトコルを使っている。そのため、ソフトウェアもハードウェアもGoogle自身が作っている

Googleの現世代のネットワークアーキテクチャはJupiterと呼ばれ、容量は初代の100倍に増えており、毎秒1ペタビット/秒とのこと(10万台のサーバがお互いに10Gbpsの通信ができる)。インターネット全体の通信容量が200テラビット/秒と考えると、Googleデータセンター内部の通信がいかに大きいかが分かる。それでも、ネットワーク容量はまだ足りず5ペタビット/秒は必要と考えているそうだ。

最後に、ネットワークに関するこれまでのGoogleのイノベーションは、

  • Google Global Cache (2006): Google版CDN
  • Watchtower (2008): 第3世代データセンターネットワーク
  • Freedome: キャンパスレベルの相互接続
  • Saturn (2009): 第4世代データセンターネットワーク
  • Onix (2010)
  • BwE (2010)
  • B4: 世界中のデータセンターを接続するSoftware Defined WAN
  • Jupiter (2012): 第5世代データセンターネットワーク、高帯域のデータセンタースケールネットワーク
  • Andromeda (2014): ネットワーク仮想化 (バランサ、DDoS防御、ACL、VPNなどが仮想化されている)
  • QUIC
  • gRPC: Google内部で使われているマルチプラットフォームRPCで、ロードバランス、アプリレベルでのフロー制御、コール・キャンセレーション、シリアライズ、HTTP/2。オープンソースで公開されている
Image02

GoogleブログHigh ScalabilityThe PlatformHacker News

8/14/2015

なぜ、BGPの最大メッセージサイズは4096バイトなのか?

Network Engineering Stack Exchangeに面白い質問があった。BGPのメッセージ長を表すフィールドは2バイトなのに、最大メッセージサイズが2^16(65535)ではなく、4096バイトなのはなぜか?という質問。BGPの天才トニー・リーの回答が公式回答になっていた。

1a) プロトコルの実装が楽なので、固定サイズが良い。プラスがなければ、実装を複雑にするだけで無駄である。パス属性と関連するプレフィックス情報を運ぶのに十分な大きさは必要だが、大きなメッセージはすごいメリットをもたらさない。この4Kという提案がおそらく最適である。

1b) 歴史的に、4Kは少しもったいないと考えられた。いうまでもなく、フラグメントされたパケットを使っていたEGPと比較すると驚くほど扱いやすかった。16Kジャンボグラムを解析したいか? それをデバッグしたいか? 本当だ。それはつまらない。

2) 4KメッセージサイズはTCPのウィンドウサイズと完全に独立している。実装はメッセージをいくらでも作成するのが、それぞれ4K制限内で完全に自由である。実装はTCPのバッファ制限までTCPソケットの中にメッセージをいくらでも詰め込むことができた。

2a) 従って、実装が実際にメッセージをいっぱいにする以外、メッセージサイズが性能制限の要因ではない。これをどう見るかについて、現在の実装を管理している人々は同意するかも。

つまり、手短かにいうと、その通り、メッセージサイズ制限はBGPにとって素晴らしく、その方法で効果があり、役目が果たせた。他のプロトコル(例えばOSPF)では必ずしも、もっとも一般的なMTUを上回る4Kが一般的ではない。そのような場合には、あなたならフラグメントで落ち着いただろうし、それはまずい。

以前も触れたとおり、今はBGPの最大メッセージサイズは4096バイトだが、IETFではメッセージサイズの拡張が議論されており、ドラフト(draft-ietf-idr-bgp-extended-messages)が提出されている。新しいAFI/SAFI、ケーパビリティ(BGPSECなど)をサポートするために、メッセージサイズの上限を65535バイトに拡張するというもの。そのために、BGP Extended Message Capabilityを定義している。このケーパビリティが交換された場合に、BGPの最大メッセージ長が65535バイトに拡張される。

8/12/2015

ローレンス・レッシグ氏が大統領選に出馬しようとしている

なんとローレンス・レッシグ氏が米大統領選に出馬しようとしているとのことだ。Slashdotを引用すると次の通り。ちなみに、サポートというのはレイバー・デーまでに100万ドル以上の資金集めができるかってことのようだ。

ハーバードの法学教授ローレンス・レッシグ氏が米大統領への立候補を検討する意向を表明しました。レイバー・デー(9月第1月曜日)までに、民主党に入るのに必要となるサポートが得られるかで判断することになるでしょう。彼の目標はかなり独特です。彼は「私は異なる種類の大統領になりたい。異なる(Different)とは決して古い政治的な謳い文句の意味ではありません。異なる(Different)はまさに文字通りの意味です。我々の民主主義がどうしても必要とする根本的な改革の使命を打ち立てたいのです。それが叶った時、私は辞任します。そして、副大統領が大統領になるでしょう」。彼の副大統領候補の選択としては、エリザベス・ウォーレン氏とバーニー・サンダース氏がある。レッシグ氏は、国民へ権限を戻し強化するために「国民投票で大統領を」と呼び掛けている。

Hacker NewsワシントンポストITmedia

2015.09.09

資金集めは100万ドルを超え、約束通り民主党から正式に出馬表明

2015.11.3

レッシグ氏、大統領選を断念(Vox)。次のディベートの資格を得られないようにルールを変更したと民主党を批判している。「本日、私は民主党候補者指名のキャンペーンを終わらせなければならない」

Kali Linux 2.0がリリース

ペネトレーションテスト、フォレンジック、ハッキング、リバースエンジニアリングに便利なLinuxディストロ「Kali Linux」の最新版2.0がリリースされた。Backtrackから誕生して10周年らしい。Debian Jessieをベースに、カーネル4.0、ハードウェアやワイヤレスドライバの対象を改良、様々なデスクトップ環境をサポートし、デスクトップ環境やツールをアップデート、最先端のワイヤレスペネトレーションツール、Ruby 2.0でMetasploitのロードが高速化したそうだ。ARMイメージやChromebookイメージも提供されている(Chromebook Flipでも動作!)。これらは、Offensive Securityからダウンロードできる。

Kali LinuxをVIRLの中で動かしたい。

政府が抱える借金は世界全体で60兆ドル

世界全体で政府が背負っている借金の総額はなんと59兆7000千億ドル(約7471兆円)とのこと(BoingBoing)。先進国は借金だらけ。

  • 米国は世界経済の23.3パーセントだが、借金は世界全体の29.1パーセント。対GDP率は103.4パーセント
  • 日本は世界総生産の6.18パーセントだが、借金は19.99パーセント
  • 世界第2位の経済大国、中国は総生産の13.9パーセントを占める。借金は6.25パーセントで、対GDPの割合は39.4パーセント
  • 上位借金15カ国のうち7カ国がヨーロッパ。ロシアを除いて、ヨーロッパ全体の借金は世界全体の26パーセント
  • 米国、日本、ヨーロッパを合わせると借金の75パーセント
  • World debt 60 trillion infographic

8/11/2015

IPv6と振り子のように揺れる技術

Ivan Pepelnjak氏の面白いエッセイ

35年前、自由になったプライドを持つ筋金入りのSDN伝道師を作ったメインフレーム、一つのプロトコルネットワーク(SNAあるいはDECnet)、そして中央集権型アーキテクチャが大流行している。もし、あなたがIBM SNAを覚えている年齢なら、私が話そうとしていることは分かるだろう。

数年後、全てが変わった。

ローカルエリアネットワーク(安価なARCnetで始まり、イーサネットに至る)、パーソナルコンピュータ、そしてx86ベースのサーバが全体的にネットワーキングの景色を変えてしまった。前触れもなく、我々はたくさんのプロトコルや予測不能なピアツーピアのトラフィックに対応する必要が出てきた。

ほとんどのネットワークエンジニアは最終的に適応し、マルチプロトコルネットワークを動かす運用経験を得た。そして、ピアツーピアトラフィックの処理を開始し、当たり前としてエンドツーエンド原則を受け入れた。

最近になると、我々は別の状況変化を経験した。これは全く方向性が違っていた。IP以外の全てのネットワーク層プロトコルが死に、アプリケーションアーキテクチャはこれまで以上により中央集権型になった(クラウドは他ならず分散された内部アーキテクチャを持つメインフレームである)。そして、エンドツーエンド原則は、NATやALGからDPIやWANアクセラレーションまでその場しのぎの解決策によってじわじわとゆっくりと死に向かった。

人々は10年以上マルチプロトコルネッットワークを動かす運用経験を持たなくなる。そして、アーキテクチャの単純化に変わり、セキュリティホールとしてエンドーツエンド原則を考えるようになり、その役割を果たすため、NATへの依存が大きいネットワーク設計をするようになった。我々は、約20年の進歩を失った(あるいは追放した)。

この点を考慮して、我々がIPv6の必要性を明白に否定するのも不思議ではなく、エンタープライズネットワークでIPv6の採用は暗い。それらを走らせている多くの人々は、エンタープライズネットワークでIPあるいはIPXをデプロイすることが避けられないと受け止めた時のSNAネットワークエンジニアと全く同じ立場にいる。

Gigamon GigaSECURE

Gigamonがタッピングしたトラフィックをフィードして、セキュリティ機器と連携する配信プラットフォーム「GigaSECURE」を発表した(PacketPusher)。GigaSECUREはNetFlow/IPFIXの生成、セッションフィルタ、SSLの復号化、インラインバイパスなど行い、様々なセキュリティ機器にトラフィックをフィードする。Cisco、Check Point、RSA、ExtraHop、Lance、Palo Altoなどとパートナーシップを結んでいるとのこと。なかなか面白い。

Gigasecure sdp components of the platform

8/10/2015

VIRLでBGPを調べる (3) - ROUTE REFRESH

BGPメッセージのうちもっとも基本的ものは、OPEN(TYPE 1)、UPDATE(TYPE 2)、NOTIFICATION(TYPE 3)、KEEPALIVE(TYPE 4)の4つである。他にメッセージタイプが無いのかというと、もう一つROUTE-REFRESH(TYPE 5)というメッセージがある。今回はそれを調べて見る。ROUTE-REFRESHは、ピア相手が持っているAdj-RIB-outの経路を送ってくれという要求である。Cisco IOS-XRなら"clear bgp ipv4 unicast soft in"コマンドで送出できる。

但し、各ピアから受信した経路情報を一旦キャッシュに溜め、そこから入れ直す方法を採るルータが多い(Juniperなど)。Ciscoの場合、"soft-reconfiguration inbound"を設定することで、キャッシュ方式になる。

Route Refreshは、OPEN時にケーパビリティを交換しておく。Cisco同士のケーパビリティを見るとTYPEが2と128があり、2はIETF標準(RFC 2918)、128はCisco独自のもので今は使われていない(おそらく後方互換のためだろう)。ROUTE-REFRESHメッセージは、AFI、Subtype、SAFIが指定され、SubtypeはRFC 2918の中でリザーブになっていて、実際に使われる時は"0"が指定される。下記がIOS-XRから送出されたROUTE-REFRESHメッセージだ。

RFC 2918のROUTE-REFRESHには、ピア先から経路送出の始まりと終わりを示すものは返らない、ピア先から送り始めと送り終わりを返すようにしたEnhanced Route Refresh (改良版Route Refresh)が、RFC 7313として標準化されている。Ciscoの中でEnhanced Route Refreshが実装されているのは、IOSとIOS-XEだけでIOS-XRには実装されていない。そこで、IOSvでこの機能を確認してみる。IOSv同士をピアリングをし、ケーパビリティを見ると確かに有効になっていることが分かる。

iosv-2#show ip bgp neighbors 10.0.0.1
BGP neighbor is 10.0.0.1,  remote AS 65000, external link
:
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received

次に、"clear bgp neighbor in"を実行してみると、ROUTE-REFRESHメッセージが送出され、ピア相手からもROUTE-REFRESH(Subtype=1)が返され、UPDATEメッセージが続き、送り終わるとROUTE-REFRESH(Subtype=2)が送られているのが分かる。

8/09/2015

VIRLでBGPを調べる (2) - TCP-AO

以前、TCP-AO(RFC 5925)のことを書いたが、VIRL(XRv)で試してみることにした。以前書いた設定をしたところ接続できない。Keychainが有効になっていないようなので、Key IDを1に、期限をちゃんと設定してみたところ、接続できるようになった。

key chain bgp-auth
 key 1
  key-string cisco
  cryptographic-algorithm hmac-sha1-12
  send-lifetime 00:00:00 january 1 2015 infinite
  accept-lifetime 00:00:00 january 1 2015 infinite
router bgp 65000
 neighbor 192.168.0.1
  keychain bgp-auth

これをパケットキャプチャしたところ、TCPオプションのKindが29にならないといけないのに、254になっていることが分かった。passwordで設定するTCP MD5((RFC 2385)は問題無いので(キャプチャ的にも)、IOS-XRはTCP-AOをサポートしていないようだ。IOSv、IOS-XEv、NX-OSvにもBGP keychainコマンドがなくサポートしてなさそう。残念。

8/08/2015

ファンタスティック・フォーの評価がかなり酷いらしい

昨日、「ファンタスティック・フォー」のリブート版が全米で公開された。その評価がかなり酷い。Slashdotによると、ローリングストーン誌は「マルウェアと同等の映画」と呼び、手堅い役者でも失敗を救えないだろう、NYタイムスは「特殊効果が水準にも達していない」と評価。ロッテントマトの評価は10パーセントにも満たず非常に悪い。監督のジョシュ・トランクでさえ問題を持っているようで、こんなツイートをして、速攻で削除された。ジョシュは撮影半ばで、事実上の降板だったという噂は本当だったのかも知れない。

1年前、僕はこいつのファンタスティックなバージョンを作った。そして、素晴らしい評価を受けただろう。でも、あなたはそれを決して見ることはない。まぁそれが現実だけどね。

どれだけ酷いのか、是非観てみたい。

更新 20150810

週末のBox Officeの速報が出た。ファンタスティック・フォーは2620万ドルで2位。

RFC 7607: AS 0の取り扱いの成文化

Autonmous System (AS) 0の扱いを成文化する目的でRFC 7607が発行された。概要は、RFC 4271のアップデートの位置付けで、OPENやUPDATEメッセージの中のAS_PATH、AS4_PATH、AGGREGATOR、AS4_AGGREGATOR属性ではAS 0を使うことを禁止するというもの。

通知の新たな未来

スマート通知サービスを展開しようとしているLatis社のブログより。面白そうだったので超訳。

我々は「通知問題」にぶつかっているというコンセンサスがあるのに、解決策はやや見つけにくいように思われる。ここで6月にさかのぼり、NYCメディアラボのイベント「通知の未来」での議論の中を明確にしてみた。

デジタルメディア会社は、取捨選択されるということにもっとも敏感である。彼らにとって、特に彼らには、注意(アテンション)がお金である。プッシュ通知は多くの約束(プロミス)をのせてやって来るとはいえ、いまだに我々の頭をひっかくようなものである。まだ我々は完全に解明したとはいえなかった。

エンドユーザがこれを行動で示しくれている。結局、通知疲れが事実で、不都合な傾向がプッシュオプトイン率で起きていることにある。

これを理解するのに今さら動機付けを必要とはしないが、玄関前での緊急通知の流行もある。そう、考えとして緊急はそれほど悪くはない。ウェアラブルIoTが、より多くの情報を(願わくは便利であればいいが)投げることで、火に油を注ぐようなものになるだろう。そして、一連の無機質な物体がおそらく通知ハブになるだろう。

しかし、将来の悪化を脇に置いておくとして、通知がアプリにとってエンゲージメントやリテンションの頼りになる手段となっているという事実があるので、被害の程度を考えるだけでも十分に厄介である。ユーザは、今のところアプリを初めて開くとすぐに、プッシュ通知のオプトインを指示されるが、ユーザは半分以上の確率で要求を拒否している。

型通り、これは単に面倒なことというだけではない。結果が現実である。Localyticsの報告によれば、一旦プッシュを有効するユーザが、保持し続ける傾向は倍以上ある。43パーセントのプッシュ通知を断るユーザは二度とアプリをオープンしない傾向は2倍ある。その一方で、プッシュが有効のユーザは11回アプリに戻る傾向は2倍ある。

考えてみると、ユーザがインストールする前に我慢してしまうせいで、通知を送らないアプリは処分されてしまう。BuzzFeedのノア・チェストナット氏の言葉を引用すると、「人々は納得させる機会を与えようとさえしない。彼らはノーいうだけだ」。

なぜ人々が通知に未来があるように見えるかの理論立てするのに時間を費やすかついて、確かに少し疑問は残る。しかし、効果的な入力にもかかわらず、展望をざっと見ると、明確なソリューションは漠然としたものだけだ。誰が最初に問題を解決する責任を負うのかというような、いくつかの未解決な疑問がある。

プラットフォームの問題のせいにしている人たちは、GoogleあるいはAppleに修正してほしいと希望している。他の人たちは、理論や制限の組み合わせで自身のコンテンツを流通する方が良いとしているアプリ製作者を欲している。もし、我々が一定水準のプライバシーを失うことに同意するなら、人工知能が助けになるケースがある。我々は、ユーザにツールを与えるべきで、アプリ内の通知設定の調整、あるいは目的を作成する指定アプリに通知を集約することを許可するアイデアもある。思い切った手段で当たるには、規制が強める時だと提案されてもいる。

これらのアイデア全て(粗雑な規制を除く)が、ロバの絵にしっぽをつけるの巨大なゲームとして解釈できる。最終的には、ロバはスマート通知として歓迎され、しっぽはそれが意味するのは所有者を明確して追い詰める取り組みである。

そのようなアプローチに多様で様々な影響があるのは不思議ではない。多様性の考えは、この難しい問題の全ての側面にわたる共通のテーマであるように見え、問題の複雑性の中核である。

まず、あなたの注意を奪い合う多数のアプリが存在する。あなたは、タブレット、ラップトップ、スマートフォン、そしてスマートウォッチと多数のデバイスを持っており、同じアプリを共有し、アプリから通知を全て受け取っている。それと同時にこれらのデバイス各々はあなたを引きつけるために多くのチャンネルを持っている。当たり前だが、それはプッシュだけなく、メール、アプリ内メッセージ、そしてSMSと、あなたの注意を引こうと使われる、どんな理由でもあなたに通知する。皮肉にも、それらがプッシュ通知を生成していることもあり得るのだ。

我々がこのゲームを戦う上で、緊急の課題はここで成功するためのコモンビジョンの欠如である: 真のスマート通知を解放し解き放つのに求められる結果はなんだろうか? 我々は前進していても、多様な要因があることを自覚していない、そしてどんなソリューションも開発者からユーザまで痛みを感じる多様な人々が事態を改善するよう努力していない。代わりに、提案されたソリューションは、隔絶していてそれを解決する結果とは関係なく、とても小さな問題に対処する。

これは私たちの考え方を占めるものだ。私たちは、開発者、マーケット担当、エンドの配信通知サービス、そして紛れもなくもっとも重要なユーザ、関係者全員にとって優れた通知エコシステムを作る素晴らしい機会があると考えている。エコシステム全体をうまく作ることが、ソリューションを確かめることを意味し、近づきやすくもある。自身の社内ソリューションを作成できるチームに莫大な予算を準備しておく、あるいはこの手のインフラに高額を支払うものだけではない。結局、他による疲れのためにユーザはアプリを選択しないという事実は、どのようにそこに向け実際に我々がやっていくかを示している。あらゆる企業はそれを正しく理解する機会が必要である。

それでは、どのように我々は問題を解決するの見込みある出発点を組み立てていけばいいのか? 我々はまず最初に新しい通知の未来をよく考え、明確にすることだと考えている。それは全ての側面から仕事を解決し、強化するためにデザインされた真のスマート通知の重要性である。

来週以降、我々はよりスマートな通知を作ればどのように全ての人が得し、なぜ理想に到達するまでやめないのかを証明する一連の投稿を発表する。

困難な問題の答えを具体化するための誘因をよく考えられるべきだ。ソリューションは成功の完成図を示す期待に取り組むよう設計されている。それは、Latisで作るソリューションの中で広範囲にわたる我々の目標である。

そして、我々がこのシリーズの中で発表した4つの投稿に向けると、各投稿は異なるステークホルダーに対する我々のビジョンを特に説明したものである。最初は開発者、そしてマーケット担当、そして通知サービス、最後にエンドユーザに向けたものだ。それぞれを正しく理解することが、全てを正しく理解するために重要な意味を持つ。結局、我々はすべてこれに一緒である。

Hacker News

8/06/2015

DoD 11.0.0.0/8がインターネットに広報されている

Nanog MLより。11.0.0.0/8はDoDのIPv4アドレスで、インターネットへは経路が広報されていなかったのだが、6日あたり前から広報されるようになったとのことだ。確かに、RouteViewsで確認するとAS23352(Server Central Network)から広報されている。Server Centralは、この経路が本物と言っている。一体何が...

route-views>show ip bgp 11.0.0.0/8 bestpath 
BGP routing table entry for 11.0.0.0/8, version 28000650
Paths: (36 available, best #24, table default)
  Not advertised to any peer
  Refresh Epoch 1
  2914 23352
    129.250.0.11 from 129.250.0.11 (129.250.0.12)
      Origin IGP, metric 75, localpref 100, valid, external, best
      Community: 2914:410 2914:1003 2914:2000 2914:3000 23352:41216
      rx pathid: 0, tx pathid: 0x0
:
% whois 11.0.0.0/8
:
NetRange:       11.0.0.0 - 11.255.255.255
CIDR:           11.0.0.0/8
NetName:        DODIIS
NetHandle:      NET-11-0-0-0-1
Parent:          ()
NetType:        Direct Allocation
OriginAS:
Organization:   DoD Network Information Center (DNIC)
RegDate:        1984-01-19
Updated:        2007-08-22
Ref:            http://whois.arin.net/rest/net/NET-11-0-0-0-1

Hacker News

8/05/2015

エンジニアリング文化

素晴らしいエンジニアリング文化とは?

Facebookの投資家へのマーク・ザッカーバーグ氏の2012年次書簡から、私はどのように文化がビジネスを推進するかについて特にテック業界で興味を持っています。

昨年、アジャイルを葬る時が来たというデイブ・トーマスの投稿を読んだ後、エンジニアリング文化を探してきました。プロセス、手法やツールの代わりに文化に頼ることがより簡単です。そして、長く続けられます。

Amazon、Google、Facebook、Twitter、Rackspace、NetflixやSpotifyは本当に素晴らしいエンジニアリング文化原則を持っています。一例としてSpotfiyを取り上げるので、以下の二つのビデオを見て下さい ;)

素晴らしいエンジニアリング文化に共通する基盤


1. 信頼

ソフトウェアエンジニアリングは科学と技能のパーフェクトミックスです。技量を成長させるため、皆の信頼を得る必要があります。ラズロ・ボックが素晴らしい「ワーク・ルールズ!」という本で、述べているところによると: あなたが楽にそれらを与えるよりも、皆にはちょっとした信頼、自由や権限を与えて下さい。あなたが緊張感を持っていなければ、それらを十分に与えられません。」

2. 責任の共有

強い文化を持つ企業は創業者として働く従業員がいます。彼らはお金だけが目的ではありません。彼らは目標や技術改良することに心を動かされます。Facebook本社にある看板の一つを引用します:「問題無いは誰かの問題だ (no problem is someone else's problem)」。ダニエル・ピンクの2009 TED Talkへのリンクを張る時です。でしょう?

3. 実務尊重

皆がソフトウェアを着想し、作り、配布する方法は絶えず変化します。最先端や現状維持は簡単にはありません。実用主義文化が役立ちます。ドグマはダメです。

4. テーラーメイド

「万能薬はない (One size does not fit all)」そして「特効薬はない」は、ソフトウェアエンジニアリングの古い引用句です。それらもエンジニアリング文化を確立するための真実でもあります。よく知られたエンジニアリング文化は良い出発点は、ガイドラインよりも、ひらめきがより役に立ちます。あなたのエンジニアリング文化を実行する前に、ひと休みして、あなたの組織の独自性を発見して下さい。

5. ダイバーシティ

強い文化は一般に企業のアーリーステージで始まり、この先大きな変更はありません。直感に反し、どのようにあなたの文化を実行するか、どのようにあなたの文化が会社の毎日の活動すべてに関連するか、あなたが正しく理解するまで絶えず変化します。それで構いません。強い文化を実践することは、あらゆる種類の多様性を真に受け入れる環境を必要とします。様々な人々と一緒であることが革新を後押しします。多様性はあなたのカルチャーが生き続け、更新されるための重要なポイントです。

8/04/2015

Apple MVNOの可能性

Business Insiderが、AppleがGoogleの「Project Fi」に続いて、モバイルキャリアになるかも知れないと報じている(9to5Mac)。米国内で密かにMVNOサービスを試験していて、ヨーロッパの通信会社に対しても交渉中とのことだ。過去、iPhoneを発売する前、ジョブズはMVNOビジネスをやりたいと思っていたらしい。Apple SIM、eSIM、パテント、... 近いうちにApple MVNOの発表があっても驚かない。

Dave WiskusがTwitterで、「もしAppleがワイヤレスキャリアになるなら、ステータスバーのキャリア名は何になる?」(DF) :-)

John Gruber氏、Dan Moren氏の推測を取り上げている

Appleが自身のモバイル仮想ネットワーク事業者(MVNO)をローンチする気にさせられるいくつかの理由が考えられる。しかし、最重要なことは哲学である。周知のごとく、ビジネスに関する全てをコントロールしたいのがAppleという会社である。当初、統一された全体を作るためにハードウェアとソフトウェアの両方を開発するという意味だったが、ここ数年、それはAからZまで、フルコースの、何もかもすべてという意味にますますなってきている。つまり、Apple Watchのために冶金家を雇用し、サファイアガラスを作るための工場(現在は機能していない)に大量に投資する会社である。そして、純粋に愚かのように思われた時、小売店の出店で大成功を収めている。

更新(20150805)

AppleはMVNOの噂を否定。計画もなければ、交渉もしていないとのこと。それに対して、John Gruber氏は

いつもは噂を無視なのに、なぜこの件について一生懸命否定しようとするのか? 私の考えは、世界中の様々なキャリアと友好関係を維持するためだろう。常に「Appleが自身の電話サービスに向かう」という問題がある。表向きは、携帯電話メーカーであり、AppleはiPhoneをサポートする世界中のキャリアすべてのパートナーである。彼らと提携している限りは競合するわけにはいかない。そして、Appleはキャリアパートナーと競合しようと企んでいるわけではないと明確にシグナルを送りたいのだと思う。

TechCrunch

8/02/2015

VIRLでBGPを調べる (1)

VIRLを使ってBGPプロトコルを調べてみることにしました。パケットキャプチャーで実際に流れるパケットを眺めると理解が深まるので、VIRLのようなシミュレータは便利です。今回は、単純に2台のIOS-XRvをEBGPで接続し、その間をキャプチャします。1台はFlatネットワーク経由でMacからbgpsimpleを使ってRouteViewsの経路(bgpdumpで変換したもの)を2000ほど注入してみます。

BGPセッションの確立

BGPセッションの確立手順は、まずTCP接続を確立(一方から一方に接続し、双方向ではありません)。その後、お互いにOPENメッセージを送り合い、KEEPALIVEメッセージで応答することで、BGP接続が確立されます。そして、UPDATEメッセージで経路交換が行われ、その後経路に変化が起こらなければ、KEEPALIVEが定期的に交換され続けます。

BGPヘッダ

BGPメッセージのヘッダ部はユニークです。最初に16バイトもの全て'1'のマーカーと呼ばれる部分があります。このマーカーの役割は、TCPストリーム中を流れるBGPメッセージの区切りです。となると、こんなに大きくなくてもいいような気がします。BGPが考えられた当初、マーカーは2バイトでしたが、認証的な役割を持たせようとして巨大化したようです。その後、認証機能は付加されておらず、今後もされることはないと思われます(TCP-OAやIPsescを使っている)。また、BGPヘッダは16バイトのマーカ、2バイトのメッセージ長、1バイトのタイプコードからなる。

ちなみに、BGPの最大メッセージサイズは4096バイトに定義されていますが、今後新しいAFI/SAFIやケーパビリティをサポートできるよう、最大メッセージサイズ長が4096バイトから65535バイトに拡張されるようです(draft-ietf-idr-bgp-extended-messages)。そのためのケーパビリティオプションが定義されます。

OPENメッセージ

次にOPENメッセージを見てみます。OPENメッセージには自分のAS番号が入ります。自ASが4バイトASの場合、ここには23456が入り、AS番号はケーパビリティオプション(FOUR_BYTES_ASN)で設定されます。但し、2バイトASを使っていても、FOUR_BYTES_ASNケーパビリティを交換すると、自ASが交換されるので、後方互換のためとはいえ二重に交換しているように見えます。

UPDATEメッセージ

BGP(RIB)の経路交換はUPDATEメッセージで行われます。最初に削除する経路(無ければWithdraw length 0)、次に新しい経路という順番です。削除する経路は、プレフィックスだけを指定するものですが、新しい経路はパス属性が一致する経路が送られます。通常、あっても数個のプレフィックスです。Wiresharkを見ると、一つのTCPパケットの中に複数のBGP(UPDATE)メッセージが送られていることが分かります。考えてみると当たり前で、BGPメッセージ単位にTCPパケットが交換されるわけではなく、TCPストリームの中にBGPメッセージが順次交換されています。従って、BGP接続確立時に多数の経路交換が行われると、BGPメッセージが次々と送られます。TCPはBGPのことなんて知りませんから、パケット単位で見ると途中で途切れるようにもなります。Wiresharkは組み立ててくれるので、一見するとメッセージが入っているように見えますが、"Allow subdissector to reassemble TCP streams"を無効にすると、メッセージが途切れているのが分かります。

また、BGPメッセージを眺めていると、経路交換の最後に「Withdrawn Routes Length 0、Total Path Attribute Length 0」という空のUpdateメッセージが送られていることに気付きます。これは、Graceful Restartが有効になっている場合に、自分が持っている経路を全部送ったことを相手に伝えるためのメッセージ(End-of-RIB)だと分かります(RFC 4724)。

次期VIRLリリースについて (Aug 2015)

先週行われたVIRLのウェビナーで、VIRLの次期リリースの内容が紹介された(30'10"あたりから)。まず、新しいイメージ。iOSvのCPU負荷が軽くなっている(?)そうだ。各イメージのバージョンは次の通り。

  • CSR1000V - 3.16
  • IOS XRv - 5.4.0
  • ASAv - 9.4.1
  • NXOSv - 7.2.0.D1.1
  • IOSv 15.5(3)M
  • IOSLv2 - new DSGS image

新しい機能としては、

  • UWMでのGitリポジトリの統合
  • Linuxコンテナ(LXC)のサポート: サーバを動かしても軽い
  • UWMでのシミュレーションインタフェース: ウェブブラウザ上でシミュレーションが可能(マエストロを動かす必要がない)
  • AutoNetKitでMgmt-VRFが使える
  • VMマエストロ: GNS3のJSONフォーマットをimport/export

また、開発中の機能のスニークピークとして、VMマエストロのアクティブキャンバス、ウェブでのトポロジエディタのデモが紹介された。アクティブキャンパスはシミュレーション中に、ノードやリンクを停止させたり、パケットキャプチャも可能になるというもの。トポロジエディタは、今回追加されるウェブベースのシミュレータのプレビューの中でトポロジー編集が可能になる機能だ。

ウェビナーで使われたトポロジーファイルがGit上に公開されている(他のサンプルもある)。

MLB、マイナーリーグでボールストライクの判定をマシンにやらせた

ベースボール/野球は人間の誤判定をある程度許容して、それもゲームのうちだと思っていたが、他のスポーツで導入されているコンピュータ判定を取り入れる実験を始めたようだ。MLBは、7/28のSan Rafael PacificsとVallejo Admiralsの試合で、PITCHf/xシステムによるボールストライク判定を採り入れたそうだ(WIREDVerge)。PITCHf/xシステムは、投手の球速や軌道を追跡するシステムとして、メジャーリーグ全球団の本拠地に設置されているので、やろうと思ったら、いつでも可能になっている(選手と審判の労組を説得できればだが)