ネットワークに近いフォーラムでは、「2、3、5、25のフルビューを保持する」機能を備えたBGPピアリング用の機器の選択に関する多数のブランチを簡単に見つけることができます。 これらのブランチの大部分は、Cisco vs. ジュニパーまたは何か悪い。 彼らのオフライン開発は、多くの場合、1つのシープスキンの6つの帽子についての漫画に似ています。 一般的に、それは面白いです。
そして、この全容の必要性の問題はめったに議論されません。
少しの「理論」
心配しないでください、私は最初からすべてを語り始めません。 ほとんどの読者は私の理論的紹介の内容をよく知っていると確信しています。 ご希望の方は安全にスキップできます。 しかし、次のことになると、私は定期的に実際の問題に非常に精通している人々の不確実性に遭遇します。 そのため、品目について説明する前に、用語を少し同期してみましょう。
インターネットBGPテーブルのトピックに直接関連しないもの、特にIGP、MPLS、VRF / VPNなどはすべて、写真から除外されます。
ルーティングと到達可能性
Fullviewは、インターネット全体のイエローページガイドです。 個人のノートブックではなく、イエローページのみ。 ここでの基本的な違いは、文字を数字に解決することに加えて-インターネットは全容として機能しませんが、DNS-定期的な参考書はオブジェクトの出現と消滅について知る機会を与えてくれることです。 このアドレスまたはそのアドレスが一般的にインターネット上にあることをどうにかして見つける必要があります。 さらに、突然リンクAを介してのみ利用でき、Bを介して利用できない場合は、それについても知りたいと思います。 これは到達可能性アラームです。 抽象化を深く掘り下げることはせず、到達可能性とルーティングは2つの異なるものであることを認識することの重要性にのみ注目します。
ルーティング（ルーティング）-特定の方向のトラフィックを転送する最適な方法を見つけます。 このプロセスは電話帳での検索に少し似ていますが、都市マップに関係しています。リンクAとリンクBを介して同じxxxxアドレスが利用できる場合、パケットの送信先を決定する必要があります。
読者がIPプロトコルに精通しており、プレフィックスが何であるか、なぜ長いのか、 最長マッハルールが何を食べているのかを知っているとします。
したがって、 上記の有名なbgp.potaroo.netグラフからわかるように、完全なインターネットルーティングテーブル（以降、主にIPv4と呼びますが、数字以外のほとんどすべてがIPv6でも有効です）には、約35万のエントリが含まれています。 この数は指数関数的かつかなり急速に増加しています。 実際には、各エントリはルートです。宛先IPプレフィックス（マスク付きサブネット）、neksthop（「送信先」とも呼ばれる次のノード）、およびこのルートの値を決定するその他のパラメーターです。 1つのプレフィックスに2つの（異なる近隣ルーターから受信した）ルートがある場合、これらの属性が使用されます。 どのネックストップを送信に使用するかを決定します。
例：
rviews@route-server.as8218.eu> show route 8.8.8.8
inet.0：343453宛先、1643368ルート（343453アクティブ、ホールドダウン0、非表示0）
+ =アクティブルート、-=最後のアクティブ、* =両方
/ *アクティブな（つまり、BGPの観点から最適な）ルートはアスタリスクでマークされ、
トラフィックの送信にのみ使用されます* /
> 8.8.8.0/24 * [BGP / 170] 6w2d 06：12：47、MED 200、localpref 3200、83.167.56.18から
ASパス：15169 I
> ge-0 / 0 / 0.0経由で83.167.56.240まで
[BGP / 170] 4w1d 04：00：53、MED 200、localpref 3200、83.167.56.6から
ASパス：15169 I
> ge-0 / 0 / 0.0経由で83.167.56.240まで
[BGP / 170] 4w2d 04：00：03、MED 200、localpref 3200、83.167.56.5から
ASパス：15169 I
> ge-0 / 0 / 0.0経由で83.167.56.240まで
[...]
ここには、3つの異なる近隣ルーターから受信したプレフィックス8.8.8.0/24への3つのルートが示されています。 何らかの理由で-ちなみに、この場合、自明ではありません-それらのうちの最初のものが最良として選択されました（例では、理由は示されていません）。 3つのルートすべてに同じnextopがあるという事実と混同しないでください。データは、通過トラフィックを送信しない非常に特定のルーターから取得されています。 そして、はい、近隣ルーターとnextopは同じものではありません。
ルーター間のルートはBGPプロトコルを使用してアナウンスされます。これは、ほとんどRSSフィードです（理論家は冒bl的な比較を許してくれます）。 実際、フルビューという用語はほとんどの場合私たちに人気があり、外国の同僚はしばしばフルBGP、フルテーブル、またはフルフィードと言います。
つまり、プロトコル自体は複雑なものではありません。コンテナのようなもので最高のプログラミングの伝統に包まれたデータを自動的に交換する方法であり、プロトコル標準では必要に応じて多少柔軟に拡張できます。 最適なパスを見つける（ルーティング）および接続を制御する（到達可能性）メカニズムは、プリミティブではないにしても非常に簡単です。 特に、BGPは、トラフィックはルーター間ではなく、大規模なエンティティ（AS、「a-es」と発音）の間で送信されると考えており、内部構造についてはほとんど何も認識していません。 10個の内部ホップ（ルーター）を考えてみましょう。BGPは、内部にそれぞれ2つのホップがある5つのスピーカーを通るパスよりも有利であると見なします。 さらに、BGPはリンク帯域幅についてほとんど何も知りません。 概算では、ルートを選択するときにこの側面はまったく考慮されていないと想定できます。
他のプロトコルと比較して、接続の変化を検出するのは速すぎず、今見たように、常により良い方法を最適に探しているとは程遠い。 ただし、これはすべて-マイナスだけでなく、BGPのプラスでもあります。これは、プロトコルが大量のルーティング情報を送信するのに適しているのは、比較的単純で「スミアの拡大」であるためです。
そのため、34万件のレコードと多数の属性を持つテーブルは非常に多くなります。 そして、そのようなテーブルは通常少なくとも2つ必要です（「neはセンスイスラよりも少ない」が、それについては後で詳しく説明します）。 これらすべてを保存するには、数百メガバイトのメモリが必要です。また、メモリの転送と保持に加えて、テーブルを「短縮」する必要があります。その結果、最適な（アクティブな）ルートを取得できます。
たとえば。 1つの近隣ルーターが、たとえばGoogleへのルートを知っていることを私たちに発表し、別の近隣ルーターもそれを発表しました。 これで、各ネイバーを介してGoogleが利用できること（到達可能性）がわかり、2つのルートのどちらをパケット送信（ルーティング）に使用するかを決定したいと思います。 これを行うために、BGPは測定値（ルートの異なる属性：Local Preference、AS-PATHなど）を比較し、決定を下します（現在意味を持たないいくつかの基準に従って）。 そして、各プレフィックスについて。 したがって、異なる近隣から受信したいくつかのテーブル（それぞれ34万件のレコードで構成されています）から、1つのテーブルが34万件のアクティブルートにコンパイルされます。
route-server> show ip bgp summary
BGPルーター識別子12.0.1.28、ローカルAS番号65000
BGPテーブルバージョンは22316128、メインルーティングテーブルバージョン22316128
41127295バイトのメモリを使用する339895ネットワークエントリ//アクティブプレフィックス：340千
324689872バイトのメモリを使用した6244036パスエントリ//合計プレフィックス：620万
メモリの58936220バイトを使用する420973/58130 BGPパス/ベストパス属性エントリ2164884バイトのメモリを使用する82551 BGP AS-PATHエントリ3600バイトのメモリを使用する150 BGPコミュニティエントリ0メモリの0バイトを使用するBGPルートマップキャッシュエントリ0 BGPフィルタ426921871の合計バイト数のメモリを使用して、0バイトのメモリBGPを使用してキャッシュエントリを一覧表示します。 1728履歴パス、1519減衰パスBGPアクティビティ3285644/2945748プレフィックス、85118539/78874498パス、スキャン間隔60秒[...]
または、ジュニパーの同じIPv6：
rviews@route-server.as8218.eu>ルート概要を表示
自律システム番号：8218
ルーターID：83.167.63.120
inet.0：343437宛先、1643129ルート（343437アクティブ、0ホールドダウン、0隠し）
直接：3つのルート、3つのアクティブ
ローカル：1ルート、1アクティブ
BGP：1642930ルート、343238アクティブ
静的：2つのルート、2つのアクティブ
IS-IS：193ルート、193アクティブ
[...]
inet6.0：4796宛先、20733ルート（4796アクティブ、0ホールドダウン、0隠し）
直接：4つのルート、4つのアクティブ
ローカル：2つのルート、2つのアクティブ
BGP：20577ルート、4640アクティブ
静的：1つのルート、1つのアクティブ
IS-IS：149ルート、149アクティブ
まだカウントされていないいくつかのBGPフィード（より正確には、それらだけでなく、他のプロトコルのデータ）の設計は、RIB（ルーティング情報ベース）と呼ばれます。 通常、最も一般的なランダムアクセスメモリに格納され、最も一般的なプロセッサによって処理されます。 したがって、RIBにプッシュできる完全なBGPテーブルの数になると、要件が作成されるのはまさにこれら2つの要素になります。 ここでのエントリの総数は、近隣から受信したすべてのルートの合計として決定されます。2つのフルビュー-ほぼ70万のプレフィックス、3つ-100万など
最初の結論。 外の世界とのセッションが1つしかない場合にフルビューを送信するのはナンセンスです。 この情報の配列を所有することは、トラフィックを一方向にのみ送信できるため、機器に負荷をかけるだけです。「アダム、これはイブです、あなたの妻を選んでください」。 Adamがイブの340千のパラメーターを最初に分析することを決めたと想像してみてください-私たちは今どこにいるでしょうか？ この規則にはまれな例外がありますが、どの規則がわからない場合、間違いではありません。
いくつかのフルビューを備えたRIBのメモリには、多くの直接的なだけでなく、数百メガバイト-数ギガバイト（フルビューの数、実装、および他の多くの側面に依存します）が必要です。 プロセッサは、 特にBGPスキャナを備えた実装では特に甘いものである必要がない場合もあります 。 たとえば、他のプラットフォームでフルテーブルが送信されるセッションの更新により、30分ほどプロセッサーの負荷が100％になる可能性があります。
ただし、ギガバイトのメモリとギガヘルツプロセッサの周波数が長い間特別なものでなくなっていることは明らかです。 そして、コンピューターのように従来のDRAMを宇宙機の価格で販売できることで有名なメーカーであるネットワーク機器のコンテキストにおいてさえ、2 GBが進歩の頂点であるふりをして、示されている数字はそれほど怖くはありません。 トピックの冒頭で述べたフォーラムのディスカッションの参加者は、この結論に頻繁に出ます。 同様に、主なことはより多くのメモリです。 一般的に、この声明は真実ですが、残念ながら問題はそこで終わりません。
次に、fullviewで何が起こるかを見てみましょう。 しかし、最初に、もう1つ小さな、しかし非常に重要な発言。
ルーティング情報は常にトラフィックに向けて送信され、トラフィックはそれに基づいて切り替えられます。 つまり 、フルビューに基づいて、スピーカーからのトラフィックが送信されます。 この論文の自明性にもかかわらず、その実用的な意義は常に完全に理解されているとはほど遠い。
転送
次に、アクティブなルートのこの「コンパイル済み」テーブルが使用されます
トラフィックの送信に使用されます。 これはFIB（転送情報ベース）と呼ばれ、その中のレコードの数は、大まかに言って、1つの全画面（340千）のレコードの数に等しくなります。 彼女にとってすべてがもっと面白い。
叙情的な余談。 一般的に、フルビューは（フルBGPフィードとは異なり）単なるFIBです。 つまり、ほとんどの場合、「3つのフルビューを保持できるルーターが必要」ではなく、「3つのフルビューを保持できるルーターが必要」と言う方が正しいでしょう。
ちなみに、投稿の冒頭にある大きくて恐ろしい写真の縦断署名は間違っています。 これはRIBではなく、FIBです。 内側のページの見出しもこれを示唆しています。
毎秒数ギガビット以上の速度でトラフィックを送信できる最新のルーターは、「ハードウェア」です。 彼らのハードウェアは、FIBとその属性が通常ではなく、特別なパケット処理プロセッサによってアクセスされる特別な、大まかに言って、「高速」スイッチングメモリ（SRAM、TCAM、RLDRAMなど）に配置されることです。 このメモリは、おそらくルーターで最も高価なリソースです。 そして、鉄の価格に影響を与える最も重要な要因は、確かにそれを扱うことの可能な洗練度です。
たとえば、24ギガビットポートへの切り替えは、ひどい力でトラフィックを送信することができます（同時に、すべてのインターフェイスの最大速度で）が、数千ドルまたはそれ以上の費用がかかります。 また、これは非常に「ハードウェア」であり、ほとんどの場合、プロセッサのパワーとその中のRAMの量は、RIBで4つのフルビューを問題なくしきい値処理するのに十分です。 さらに、多くの場合、そのソフトウェアは多くの異なる複雑な機能をサポートしています。 ただし、同じことを実行できる「本格的なルーター」は、約15倍のコストがかかるようです。 これは、スイッチでのあらゆる種類のマーケティングの微妙さに加えて、 10〜15,000のルートをスイッチングテーブルに配置でき、このテーブルで使用できるアクションのセットがはるかに狭いためです。 たとえば、各パケットについて、FIBのエントリを1回ではなく2、3回（これはあなたが思っているよりも頻繁に必要です）探す必要がある場合-2000ドルのスイッチはその方法がわかりません。
また、ソフトウェアボックス（大まかに言えば最大2ギガビット）があり、RIBなどのFIBが通常のRAMにそれぞれ格納されます。 一般に、彼らは多くの場合、そこに格納されているすべてのものが多すぎますが、これについては、主なことはそれ（RAM）がゴムではないということです。 さらに、最適な一致（最長一致）を見つける配列内のプログラム検索-まあ、明らかに、配列内の要素が多いほど遅くなりますが、このアルゴリズムは検索しません。
第二の結論。 フルビューBGPピアリング用のハードウェアルーターを選択する場合、最大FIBサイズについて販売者に問い合わせてください。 売り手が知らない場合- 彼の能力について 考える機会 。 可能なオプション：
- IPv4で50万未満-今日はこれを受け取らない方が良いでしょう。 これで十分ではない時期が近いです。 しかし、IPv6もあります。
- 〜50万-この数字は、いわゆる人気があります。 大きなL3スイッチ、大量のドープを含むスイッチ、および一連のスイッチング手順はかなり平凡です。 快適な例外がありますが。 ここでの「大」スイッチと「小」スイッチは、まずボックスサイズとラインナップのモデルの年功序列が異なり、次に重要なことはスイッチングメモリの量です。「小さな」 24ポートスイッチがFIBで50万エントリをサポートすることはまれです。 そのため、「大きな」L3スイッチには、今日のフルビューに十分なスイッチングメモリがあるように見えますが、パッケージで複雑なことを行う方法をほとんど知りません（実際、これがルーターとの主な違いです）。 一方で、本当にやりたい場合は、このタスクに使用できるように思われますが、一方ではしない方が良いでしょう。 非常に多くの種類のニュアンスがあります。 要するに、BGPピアリング用のL3スイッチをフルビューで購入する前に、売り手をよく考えて苦しめましょう。
- 100万以上はまともな数字です。
売り手が多かれ少なかれ自信を持ってRIBのサイズをアドバイスすることができれば-あなたが選択したデバイスで何人のピアをフルビューで保持できるか-これは彼が販売しているものについて多くを知っている売り手の確実なサインです。 彼が本格的なルーターと大きなL3スイッチの違いについて会話を続けることができ、BGPピアリングに大きなスイッチを使用した場合に考えられる結果について説明する準備ができている場合、あなたは正しい道を歩んでいます。
実用的な推論
次に、全文表示の利点と害についてタイトルに示されている質問に答える必要があります。 これを行うには、まず少し哲学をします。
集約と 細部
ルートの動的な転送には、ルーティング情報を操作する2つの対立する原則があります（ここでの「原則」という言葉は、「説得」または「傾斜」を意味するのではなく、意図された目的に使用される技術的手法）、詳細と集約です。 つまり、詳細：多くの長いプレフィックス、または簡潔：複数の長いプレフィックスの1つとしての表示が短くなります。
集計
一般的に言えば、ディテールから多くの害があることはすでに明らかです。各生徒は、情報が多くなるほど、保存するのが難しくなり、操作するのが高価になることを知っています。 ソフトウェアルーターと若者のIPの時代、ルートの数を最小限に抑える必要があるという主張は、議論すべきではない公理でした。 RIBとFIBの膨張による生産性の低下に対処するために、多くの興味深いものが発明されました。 たとえば、OSPFの無数の無慈悲なタイプのアリアとLSA、またはMPLS（はい、VPNやTEでまったく発明されていない）、Cisco Express Forwarding、および実際にはハードウェア転送など、さまざまな程度の有用性を持つその他のもの。
集約（要約）は、有能なセグメンテーション、アドレスプランの選択、あらゆる種類のIGPアリアを管理する能力、ルーティングルールを記述する際の手品などに関連するまったく小さな科学です。興味のある方は、たとえば、「企業IPネットワークの設計の原則」 A. Retans、D。Slice、およびR. White（Cisco Press）。
集約の極端な場合は、デフォルトルート（「デフォルト」）：0.0.0.0/0です。これは、「明示的なルートがあるものを除くすべて」を意味します。
詳細
残念ながら、インターネットはこのような素晴らしい技術であり、この素晴らしい集約技術はほとんど適用できません。 地理からの独立の原則、集中管理の欠如、自律システムの管理上の隔離、障害時の損傷領域の最小化などにより、212.90.0.0 / 19および212.90.32.0/19などの隣接するプレフィックスが1つの自律システムに属し（これは常に可能とはほど遠い）、共通のパラメーターを持つ集約されたプレフィックス212.90.0.0/18の形で想像することは不可能です。 一般的な場合、そのような要約は、ループまたは「ブラックホール」の出現につながる可能性があります。
ただし、「一般的な場合」イタリック体の強調は偶然ではありません。 明らかな例外は、前述のデフォルトルートです。 実際には、それがインターネットへのルートとして使用されているのは、それだけではありませんが、私たちが完全なビューを持っていない場合です。 つまり、これは実質的にfullviewに代わる唯一の選択肢です。インターネットの内部構造全体について気にしないでください。 これがいつ可能になるのか、また、デフォルトに基づく転送とフルテーブルに基づく転送の違いを見てみましょう。
誰が全体像を必要とし、その理由は？
デフォルトでは、すべてが明確です。特定の（独自の）ルート、つまりインターネットプロバイダー（アップリンク）akaのないものすべて。 そして、本質的に、ここで私たちに全容を与えるものは何ですか？ インターネット全体ではなく、個々のリソースに関する知識に基づいて、パッケージを送信するためのリンクを選択することを決定できます。 まず、例：ルートxxxx / xはリンクAおよびBを介してアクセス可能であり、ルートyyyy / yはリンクBを介してのみ利用可能です。そうである場合、yyyy / yへのトラフィックはBを介してのみ送信できます（到達可能性）。 第二に、トラフィックを送信する宛先プレフィックスとネイバー間の対応に影響を与えることができます。 トラフィックをプロバイダーA経由でGoogleに送信し、Yandex-B経由でルーティングします（ルーティング）。
なぜこれが必要なのでしょうか？
最初の否定できないケースは、アップストリームまたは等距離（アップリンク、IX）およびダウンストリーム（クライアント）の両方のACネイバーの存在です。 つまり、自律システムが移動中であり、何かを私たちにアナウンスするクライアントがそれに接続している場合です。 定義上ここでデフォルトを使用することは不可能です。なぜならこの場合、私たちは郊外ではなく、インターネットの「中間」にいるからです。 ここにルート集約が存在すると、ループバックが発生する可能性があります。 したがって、プロバイダーは、IPヘッダーに基づいてインターネットトラフィックを送信するすべてのルーターで完全なテーブルを保持する必要があります。 ここでは「cな発明のがらくた」オプションも可能であることを予約しますが、第一に、それらの議論はトピックの範囲を超えており、第二に、ネットワークの産業マスタブで操作するのは非常に困難です。 したがって、このテーマのバリエーションは人生でそれほど珍しいことではありませんが、ISPで使用することは多くの場合、メリットよりも多くの問題をもたらします。
第三の結論。 スピーカーが 移動中の 場合 は、 おそらくフルビューなしではできません。 ただし、おそらくこれはすべて自分で知っています。 MPLSおよびBGPフリーコアについても、何か聞いたことがあると思います。 そうでない場合、これらはさらに反映するためのキーワードです。
次のより興味深いタスクは、負荷を分散して、インターネット上のトラフィックがBGPの観点 （ 選択したとおりに 常に 正確 である とは 限り ません ）または希望する（および構成する） 観点のいずれかになるようにすることです。 AS（ギガビットまたは2つ以上）からの発信トラフィック（本当に発信 ： 発信トラフィック）が本当に多く、複雑な操作で経済的実行可能性がある場合、両方の要求は非常に正当です。 原則として、これは、上記のケースに該当する中継自律ネットワークを備えたプロバイダー、または偶然にも独自のASを備えたクライアントを備えている可能性が高い大規模なデータセンターのいずれかで発生します。 たとえそうでなくても、各プレフィックスのルートに関する個別の知識（これにより完全なビューが得られます）は損なわれません（たとえば、ゴールデンとの「戦争」についてのユーザーのシャパバイクを参照）。
ASが販売用のトランジットインフラストラクチャではなく、独自の小規模（世界標準）のデータセンターを備えた企業ネットワークである場合、発信トラフィック（数十メガビットまたは数百メガビット）が非常に少なく、Googleにのみトラフィックを送信するなどのタスクがありますルート、しかしYandex他へ-あなたはほとんど確実にそれを持っていません（好奇心のためだけの場合）。 ここで送信トラフィックに必要な最大値は、均等に、または複数のインターネットリンク間で望ましい割合でバランスをとることです。 一般的な信念に反して、これには全体像は必要ではなく、有害ですらあります-以下でさらに詳しく説明します。
3番目-少し面白く、比較的自明ではないケース-情報提供の「ヘルプ」としてのフルビュー。 多くの場合、どのスピーカーと最も激しいトラフィック交換があるかを知りたいと思うでしょう。 トラフィックを送信するために全画面表示が必要でない場合を含め、多くの場合、 さまざまな種類のトラフィックの傾向を評価するための統計情報を取得します 。 これらの場合、NetFlowなどのメカニズムでフルビューを使用して、トラフィック（発信および着信）に関する追加情報を取得します。 ただし、このような監視の実装には、ある程度の経験と、そのビューがどこにあるのか、何が含まれているのか、取得した統計を正しく解釈する方法を保存できる機器を理解する必要があることに注意してください。 要するに、これはトピックを超えた高度なテーマです。 さらに、トラフィックがギガビットでない場合は、ほとんどの場合必要ありません。 この問題に関する別のオプションは、上記のコンソール出力であり、通過トラフィックを送信しない特別なルーターから取得されます。 彼らはその分析の可能性についてのみ全容を示しています。
フルビューなしでできるのはいつですか？
自分のスピーカーとアドレスブロックがある場合は、完全なテーブルを受け入れる必要があるというのは非常によくある誤解です。 これがまさに問題です。
上記のように、フルビューの必要性の最も疑わしいケース（それは、非華麗な実装で最も大規模で豊富なものです）は、ACが独自のアドレスブロックを持つ必要があるため、インターネットを予約するときにプロバイダーに依存しない企業ネットワークですリソース（パブリックサーバー、VPNコンセントレータなど）ここでの主なタスクは、外部接続の1つが失われたときにインターネットからのトラフィックを受信できるようにすることです。 トラフィックはルーティング情報に向けて送信されるというルールを思い出してください。 質問：着信トラフィックについて話している場合、なぜフルビューが必要なのですか？ 回答：はい、なぜですか。
しかし、フルビューを拒否した場合、発信トラフィックをどのように送信しますか？ はい、いつものように！ ルーティングルールを記述し、プロバイダーと交渉して（通常はこれは問題ではありません）、機器を何もせずにレイプしないようにします（そして、理想的な場合、ORFメカニズムがこのために考案されました）。各プロバイダーからのデフォルトルートのみを受け入れます。 次に、ルートの1つのみを使用し、2番目のルートを保留（最初のルートが落ちた場合）にして、1つのリンクを介してすべての発信トラフィックを開始するか、負荷分散を設定します：機器の場合、BGP帯域幅コミュニティを使用して、または一定の割合でこれを行うことができます（ルーターとL3スイッチの違いに関する会話を思い出してください）。 プロバイダーが2つではなく、3、5、20、120の場合も同様です。
このアプローチのいくつかの（一般的に唯一の）マイナス点は、「グラニュラー」ルーティングとともに、到達可能性の制御も拒否したことです。インターネット上の特定のリソースとの接続のシグナリングはありません。 フルビュー内の個別のプレフィックスは、トラフィックを送信する必要があるリソースからの直接の情報です。 また、デフォルトはほとんどの場合、プロバイダー（まあ、またはプロバイダーのプロバイダーの方が良い）によって生成され、プロバイダーからデフォルトを取得することもありますが、実際にはインターネット（プロバイダー）がありません。 ルートアグリゲーションの結果としての「ブラックホール」の説明はこれで終わりです。
- - : , . , . -, - «-» (, ), : , , , , .
, , ? -? , ? ? ? — ( ). いや？ — , .
, , , ( —) , , VPN , ( ) ( ). ORF , - .
, ? - ? , ?
- , , ( ). « ». , . , , ́ () : «» , BGP, , , ́ «» . - , , , . , : 30%, — 70.
- : . , (), , FIB .
BGP- , . -, -, , , , , , URL, , , , . , , , - , , . — - . !
. ( ), , , — .
, ?
, . , . , show route summary 7 , — 700 . ?
(, ):
- , . . , ().
- BGP-, : . , () (), , , . .
- , , , route- (, , , ).