Junos ルーティングの基本 - juniper.net · 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA +1-408-745-2000 Worldwide Education Services Junos ルーティングの基本

Junosルーティングの基本9.b

受講者スタディガイド

1194 North Mathilda AvenueSunnyvale, CA 94089USA+1-408-745-2000www.juniper.net

Worldwide Education ServicesWorldwide Education Services

コース番号 : EDU-JUN-JRE

Juniper Networks、 Juniper Networks ロゴ、 Junos、 NetScreen、 ScreenOS は、米国およびその他の国における Juniper Networks, Inc. の登録商標です。 JunosE は、 Juniper Networks, Inc. の商標です。その他すべての商標、サービスマーク、登録商標、登録サービスマークは、それぞれの所有者に帰属

します。

Junos ルーティングの基本受講者スタディガイド、改訂番号 9.b

Copyright © 2009, Juniper Networks, Inc.

All rights reserved. Printed in USA.

改訂履歴 :

改訂 9.a － 2009 年 7 月

改訂 9.b － 2009 年 10 月

本書の記載情報は、上記日付において新のものです。

本書の記載情報は入念に検証されており、ソフトウェアリリース 9.6R1.13 に関して適正とされています。ジュニパーネットワークスは、本書の記載内

容の誤りに関する責任を負いません。ジュニパーネットワークスは、本書の欠陥や遺漏に起因する直接的、間接的、特別、懲罰的、付随的、結果的な

損害について、かかる損害の可能性について予め通知を受けていた場合も含め、いかなる場合も一切の責任を負いません。

ジュニパーネットワークスは、予告なく本書を変更、修正、移管、またはその他の手段で改訂する権利を有します。

西暦 2000 年問題に関するお知らせ (YEAR 2000 NOTICE)

ジュニパーネットワークスのハードウェアおよびソフトウェア製品には西暦 2000 年問題がなく、西暦 2000 年に対応しています。 Junos オペレーティ

ングシステムには、判明している限り、 2038 年まで時間に関連する制限事項はありません。ただし、 NTP アプリケーションでは、 2036 年に一部の問

題が発生することが判明しています。

ソフトウェアライセンス

ジュニパーネットワークスのソフトウェアのご使用に関する規約は、ソフトウェアに付随するソフトウェアライセンス、もしくは該当する場合にはお客様とジュニパーネットワークスまたはジュニパーネットワークス代理店との間で締結された契約に記載されています。お客様は、ジュニパーネット

ワークスのソフトウェアを使用することにより、そのライセンスの規約を理解し、同意したことを示すことになります。一般的に、ソフトウェアライ

センスは、ジュニパーネットワークスのソフトウェアに対して認められる使用方法を制限するもので、特定の使用方法の禁止が含まれていたり、ライセンスが自動的に解除される特定条件が記載されている場合があります。詳細については、ソフトウェアライセンスをご確認ください。

目次

第 1 章 : コースの紹介. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

第 2 章 : ルーティングの基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1ルーティングの概念 : ルーティングの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3ルーティングの概念 : ルーティングテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7ルーティングの概念 : ルーティング・インスタンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18静的ルーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25動的ルーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32ラボ 1: ルーティングの基礎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43

第 3 章 : ルーティングポリシーとファイアウォールフィルタ . . . . . . . . . . . . . . . . .3-1ルーティングポリシーの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3ケーススタディ : ルーティングポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23ラボ 2: ルーティングポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28ファイアウォールフィルタの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29ケーススタディ : ファイアウォールフィルタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44ユニキャスト・リバースパス転送のチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50ラボ 3: ファイアウォールフィルタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57

第 4 章 : クラス・オブ・サービス (CoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1CoS 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3トラフィック分類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10トラフィックキューイング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17トラフィックのスケジューリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20ケーススタディ : CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28ラボ 4: クラス・オブ・サービス (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38

付録 A: 略語リスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

付録 B: 解答例と解説 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-1

目次 • iii

iv • 目次

コース概要

このコースは、受講日数 1 日で、ルーティングの基礎知識と設定例を学習できるように

構成されており、学習内容は、一般的なルーティングの概念、ルーティングポリシー、ファイアウォールフィルタ、クラス・オブ・サービス (CoS) などを対象とします。

デモと実技ラボを通じて、 Junos オペレーティングシステム (Junos OS) の設定と監視、

および基本的なデバイス運用監視を実際に体験することができます。

目標

このコースを修了すると、次の技能を習得できます。

• ルーティングの基本動作と概念について説明する

• ルーティングおよびフォワーディングテーブルを表示して説明する

• 静的ルーティングを設定し、監視する

• OSPF を設定し、監視する

• ルーティングポリシーおよびファイアウォールフィルタのフレームワークについて説明する

• ルーティングポリシーおよびファイアウォールフィルタの評価について説明する

• ルーティングポリシーを適用するべき状況を識別する

• ルーティングポリシーを記述し、適用する

• ファイアウォールフィルタを適用するべき状況を識別する

• ファイアウォールフィルタを記述し、適用する

• ユニキャスト・リバースパス転送 (RPF) の動作と設定について説明する

• クラス・オブ・サービス (CoS) の目的と利点について説明する

• CoS の各種コンポーネントについて説明する

• CoS を実装し、適正動作を検証する

受講対象者

このコースは、 Junos OS 搭載デバイスの設定および監視を担当する人を対象としてい

ます。

コースレベル

「Junos Routing Essentials」 (Junos ルーティングの基本 ) コースは、受講日数 1 日の入門

コースです。

前提条件

ネットワークに関する基礎知識を持ち、 OSI モデルと TCP/IP プロトコルスイートについ

て理解していることを前提としています。また、本コース受講の前に、「Introduction to the Junos Operating System」 (Junos オペレーティングシステム入門 : IJS) コースを受講し

ていただく必要があります。

. コース概要 • v

コース内容

第 1 日

第 1 章 : コースの紹介

第 2 章 : ルーティングの基礎

ラボ 1: ルーティングの基礎

第 3 章 : ルーティングポリシーとファイアウォールフィルタ

ラボ 2: ルーティングポリシー

ラボ 3: ファイアウォールフィルタ

第 4 章 : クラス・オブ・サービス (CoS)

ラボ 4: クラス・オブ・サービス (CoS)

vi • コース内容

ドキュメントの表記規則

CLI および GUI に表示されるテキスト

このコース全体を通じて、コマンドライン・インタフェース (CLI) やグラフィック・ユー

ザーインタフェース (GUI) に表示されるテキストに言及している箇所が多くあります。本書では、記載内容をわかりやすくするために、次表に従って各章の本文と GUI/CLI テキ

ストの書式を区別しています。

入力テキストと出力テキスト

このコースでは、受講者によるテキス入力が必要となることがあります。本書では、多

くの場合、このような入力テキストをそのコンテキストとともに示しています。表示テ

キストに対して、入力するテキストには太字を使用して区別しています。

書式説明使用例

Franklin Gothic

通常のテキストラボガイドおよび受講者スタディガイドのほとんどのテキストにこの書式が使用されます。

Courier New

コンソールのテキスト :

• 画面表示

• コマンドに関係しない構文

GUI テキスト要素 :

• メニュー名

• テキストフィールドへの入力

commit complete

Exiting configuration mode

[File] > [Open] を選択し、

[Filename] テキストボックス

の [Configuration.conf] を

クリックします。


Normal CLI

Normal GUI

特に区別なし Physical interface:fxp0, Enabled

[Configuration] >

[History] をクリックして設定

履歴を表示します。

CLI Input

GUI Input

入力の必要なテキスト lab@San_Jose> show route

[File] > [Save] を選択し、

[Filename] フィールドに

config.ini と入力します。

ドキュメントの表記規則 • vii

定義済みおよび未定義の構文変数

このコースでは、通常のテキストと構文変数を区別するとともに、値がすでに割り当てられている構文変数 ( 定義済み変数 ) と受講者が値を割り当てる必要がある構文変数 ( 未

定義変数 ) を区別しています。これらの書式は、入力テキスト用の書式と組み合わせて使

用されている場合があるため、注意してください。


CLI Variable

GUI variable

変数値がすでに割り当てられている場合のテキスト

policy my-peers

ダイアログの [my-peers] をク

リックします。

CLI Undefined

GUI Undefined

受講者が任意の変数値を割り当てることができる場合のテキスト、ラボガイドに記載の変数値とユーザー入力値が異なる可能性がある場合のテキスト

set policy policy-name と入

力します。

ping 10.0.1.1

[File] > [Save] を選択し、

[Filename] フィールドに

filename と入力します。

viii • ドキュメントの表記規則

その他の情報

教育サービス

教育サービスが提供する各種サービスやコースの情報、開催日程、開催場所に関する詳細については、下記 Web サイトでご確認いただけます。 http://www.juniper.net/jp/jp/training

本書について

『Junos ルーティングの基本受講生スタディガイド』の作成およびテストは、ソフトウェ

アリリース 9.6R1.13 を使用して行っています。それより前または後のバージョンでは動

作が異なる可能性があるため、エラーをご報告いただく前に、必ずご使用のバージョンのマニュアルとリリースノートをご確認ください。

本書の執筆および管理は、ジュニパーネットワークス教育サービス開発チームが行っております。お問い合わせや改善のためのご提案は、 [email protected] までお寄せく

ださい。

各種技術資料

技術マニュアルやリリースノートは、次の手順で、インターネット上から各種形式で直接ダウンロードして印刷することができます。

• http://www.juniper.net/techpubs/ にアクセスします。

• 必要なソフトウェアまたはハードウェアのリリースとタイトルを探し、ドキュメントを表示または印刷する形式を選択してください。

各種資料および CD は、お近くのジュニパーネットワークス販売代理店やアカウント担

当者からお求めいただくことができます。

ジュニパーネットワークスのサポート

技術サポートについては、 Web サイト (http://www.juniper.net/customers/support/) 経由で

ジュニパーネットワークスにお問い合わせいただくか、お電話にて 1-888-314-JTAC ( 米国

国内からの場合 ) または +1-408-745-2121 ( 米国国外からの場合 ) までご連絡ください。

その他の情報 • ix

x • その他の情報

Junosルーティングの基本

第 1章 : コースの紹介

Junos ルーティングの基本

本章の内容 :

• 目標およびコース内容

• ジュニパーネットワークスが提供する各種コース

• ジュニパーネットワークス技術認定資格プログラム (JNTCP)

第 1 章 - 2 • コースの紹介


自己紹介

このスライドには、クラスでの自己紹介時にお答えいただく質問事項が記載されています。

コースの紹介 • 第 1 章 - 3


コース内容

このスライドには、このコースで取り上げるトピックが記載されています。



前提条件

このスライドには、このコースを受講するための前提条件が記載されています。



コースの各種事務・管理関連

このスライドには、コース・クラスにおける各種事務・管理に関する事項が記載されています。



トレーニングと教材

このスライドには、教育サービスにより提供されるクラス内およびオンラインで使用可能な教材が記載されています。



その他の各種リソース

このスライドには、ジュニパーネットワークス製品の設置、構成、運用に活用できるその他の各種リソースが記載されています。



ご満足度に関するフィードバック

ジュニパーネットワークスでは、受講者の皆様からご意見やご感想をお寄せいただき、その内容を分析するために、電子調査システムを使用しております。受講コースに応じて、コース終了時に調査にご協力いただくか、または、終了から約 2 週間後に送られる E メールに記載されているリンクからオンライン調

査フォームにアクセスしてご回答いただくこととなります ( そのため、必ずご

使用の E メールアドレスをお知らせください )。

コース修了証明書の発行には、フィードバックをお送りいただく必要があります。弊社の教育サービス改善のため、調査にご協力いただきますようお願い申し

上げます。



ジュニパーネットワークス教育サービスのカリキュラム

ジュニパーネットワークス教育サービスは、エンタープライズ環境やサービスプロバイダー環境において、コストパフォーマンスに優れた高性能ネットワークを配備および保守するための知識とスキルの確立をサポートしています。技術と業

界に関する豊富な知識を備えた専門トレーニング・スタッフを擁しており、インストラクタによるハンズオンコースに加え、ご自分のペースで学習を進められる便利な e ラーニングコースも提供しております。

ジュニパーネットワークス教育サービスが提供する、多彩なプラットフォームをカバーする各種サービスやコースに関する新情報は、http://www.juniper.net/jp/jp/training でご確認いただけます。



JNTCP

ジュニパーネットワークス技術認定資格プログラム (JNTCP) は、プラットフォー

ムに特化した複数段階のトラックで構成されており、習熟度を評価する筆記試験および設定とトラブルシューティングの実技試験に合格することにより、ジュニパーネットワークスの技術に対する技能を証明できるようになっています。認定

試験に合格するためには、インターネットとセキュリティ技術に加え、ジュニパーネットワークス・プラットフォームの設定とトラブルシューティングのスキルを十分に発揮することが求められます。 JNTCP の詳細については、下記 Web サ

イトをご参照ください。http://www.juniper.net/jp/jp/training/certification/



認定資格レベル

JNTCP の各トラックには、 1 ～ 4 段階の認定資格レベルが用意されています。アソシエートレベルおよびスペシャリストレベルの試験は、選択問題で構成されるコンピューターベースの試験です。これらの試験は、世界各国のプロメトリック

テストセンターで実施されており、前提条件となる認定資格要件はありません。

プロフェッショナルレベルおよびエキスパートレベルの試験は、実技のラボ問題で構成される試験で、指定のジュニパーネットワークステストセンターで実施されています。これらのレベルでの受験には、トラック内で当該レベルより 1 つ前

( 下位 ) のレベルの認定資格を取得していることが条件となります。試験の詳細、

料金、登録については、下記 JNTCP Web サイトでご確認いただけます。http://www.juniper.net/jp/jp/training/certification/



準備と学習

このスライドには、ジュニパーネットワークス認定資格の取得に向けた各種学習方法が記載されています。



ご質問

受講コース・クラスに関するご質問やご不明な点があれば、クラス内でインストラクタが対応するように努めますので、遠慮なくお申し出ください。



第 2章 : ルーティングの基礎


本章の内容 :

• ルーティングの基本動作と概念

• ルーティングテーブルとフォワーディングテーブル

• 静的ルーティングの設定と監視

• 基本 OSPF の設定と監視

第 2 章 - 2 • ルーティングの基礎


ルーティングの概念 : ルーティングの概要

このスライドには、この章で取り上げるトピックが記載されています。初に、

このスライドで矢印で示しているトピックについて説明します。

ルーティングの基礎 • 第 2 章 - 3


ルーティングの基本的な定義

ルーティングのも基本的な形態は、レイヤー 3 ネットワーク間のデータ移動

プロセスです。このスライドに示すトポロジー例は、ルーターに接続された複数

のレイヤー 3 ネットワークを示しています。ルーターはルーティングを実行する

も一般的なデバイスですが、スイッチやセキュリティデバイスがルーティング機能を提供する場合も多くあります。また、インターネットは単一のネットワー

クではなく、複数のネットワークの集合体であるということも認識する必要があります。

このセクションでは、以降のページで、ルーティングで必要なコンポーネントとJunos オペレーティングシステム (Junos OS) 搭載デバイスによるルーティング判

定について説明します。



ルーティングのコンポーネント

リモートネットワーク間で効果的なルーティングを実現するためには、さまざまなコンポーネントや要素に対する考慮が必要です。考慮するべき内容は、エンド

ツーエンドの通信パス、通信パス上の全レイヤー 3 デバイスが必要なルーティ

ング情報を確実に持つようにすること、という 2 つの要件に大別されます。

このスライドの例では、図示したネットワークとインターネットとの間に物理パスが存在しています。この物理パスが正しく設定されており、正常に機能してい

れば、初の要件は満たされたことになります。

2 番目の要件として、通信パス上の全レイヤー 3 デバイスが、必要なルーティン

グ情報を確実に持っていなければなりません。ユーザーネットワークやデーター

センター・ネットワーク内のデバイスには、適切に設定されたゲートウェイ ( こ

れらのネットワークやインターネットに接続しているルーター ) が必要です。ゲートウェイデバイスは、受信する通過トラフィックの各宛先プレフィックスに対する適切なネクストホップを決定します。 Junos OS 搭載デバイスは、ルーティ

ングテーブルのサブセットであるフォワーディングテーブルを使用してこの決定を行います。ルーティングテーブルおよびフォワーディングテーブルについて

は、次のセクションで説明します。



理解の確認

このスライドには、簡単なルーティングシナリオを示しています。ユーザー Aがデーターセンター・ネットワーク内のデバイスと通信するために必要なルーティング情報を考えてみましょう。

デバイスが、自身が直接接続されているサブネット外のデバイスと通信するためには、適切に設定されたゲートウェイが必要です。スライドのシナリオでは、

ユーザー A に関連付けられたデバイスは、ルーター IP アドレス 10.1.1.1 に設

定されているゲートウェイを必要とします。同様に、データーセンター・ネッ

トワーク内のデバイスも、適切に設定されたゲートウェイ (10.2.2.1) を必要と

します。

ユーザーネットワークやデーターセンター・ネットワークでゲートウェイとして機能するルーターは、接続ネットワーク間で送受信されるトラフィックの適切なネクストホップを決定するために所定のルーティング情報を必要とします。この

例では、ルーターはインタフェース設定を介して必要な情報を学習します。ルー

ターは、インタフェースが接続されているネットワークをルーティングテーブルおよびフォワーディングテーブルに追加し、自身のフォワーディングテーブルを

参照して受信トラフィックのネクストホップを決定します。



ルーティングの概念 : ルーティングテーブル

次に、このスライドで矢印で示しているトピックについて説明します。



ルーティング情報源

Junos OS のルーティングテーブルは、複数のルーティング情報源 ( 各種ルーティ

ングプロトコル、静的経路、直接接続経路など ) からのプレフィックスを統合し

たものです。

有効経路の選択

Junos OS 搭載デバイスが所定のプレフィックスに関して複数の経路を受信した

場合、デバイスは 1 つの経路を有効経路として選択します。ただし、 Junos OS で

は、追加設定を行えば、複数の等価コスト経路もサポート可能です。

フォワーディングテーブル

ルーターは、各宛先プレフィックスの有効経路をフォワーディングテーブルに格納します。フォワーディングテーブルは、 Junos OS 搭載デバイスにより転送され

る各パケットの送信インタフェースとレイヤー 2 書換え情報を決定します。

次ページに続く



複数のルーティングテーブル

Junos OS 搭載デバイスは、複数ルーティングテーブルの使用に対応しています。一次ルーティングテーブル inet.0 には、 IPv4 ユニキャスト経路が格納されま

す。また、 Junos OS が設定に応じて作成する inet6.0 などの定義済みルーティ

ングテーブルもあります。

Junos OS 搭載デバイスで一般的に使用される定義済みルーティングテーブルを

次に示します。

• inet.0: IPv4 ユニキャスト経路用

• inet.1: マルチキャスト転送キャッシュ用

• inet.2: リバースパス転送 (RPF) チェックを実行するための MBGP経路用

• inet.3: MPLS パス情報用

• inet.4: MSDP 経路エントリー用

• inet6.0: IPv6 ユニキャスト経路用

• mpls.0: MPLS ネクストホップ用



ルーティング情報源のプリファレンス

Junos OS は、さまざまなルーティングプロトコルやルーティング情報源から受

信した経路を差別化するために、ルートプリファレンス ( 優先度 ) を使用してい

ます。ルートプリファレンスは、他ベンダー装置におけるアドミニストレーティ

ブ・ディスタンス ( 管理上の距離 ) に相当します。

有効経路の選択

Junos OS は、さまざまなルーティング情報源から受信した経路に順位を付け、有

効経路を選択するための一次基準としてルートプリファレンスを使用します。

スライド下部の表は、一部のルーティング情報源でのデフォルトのプリファレンス値をまとめたものです。デフォルトのルートプリファレンス値をすべて記載し

た一覧は、次のページに掲載しています。




有効経路の選択 ( 続き )

ルートプリファレンス値は、 0 から 4,294,967,295 の範囲で設定され、この値が

小さい経路の方が値の大きい経路よりも優先されます。次のコマンド出力では、

プリファレンス値 5 の静的経路が、プリファレンス値 10 の OSPF 内部ルートよ

りも優先されていることを示しています。

user@host> show route 192.168.36.1 exact

inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

192.168.36.1/32 *[Static/5] 00:00:31 > to 10.1.1.2 via ge-0/0/10.0 [OSPF/10] 00:02:21, metric 1 > to 10.1.1.2 via ge-0/0/10.0

ほとんどのルーティング情報源のデフォルト・プリファレンス値は、要件に合わせて変更可能です。ただし、直接接続およびローカルの経路は、他のルーティン

グ情報源でのプリファレンス値の変更にかかわらず、常に優先されます。


デフォルトのルートプリファレンス値

直接接続 0 SNMP 50

ローカル 0 ルーター検出 55

システムルート 4 4 RIP 100

静的経路およびStatic LSP

5 RIPng 100

RSVP-signaled LSP 7 DVMRP 110

LDP-signaled LSP 9 集約経路 130

OSPF 内部ルート 10 OSPF AS 外部ルート 150

IS-IS レベル 1 内部

ルート

15 IS-IS レベル 1 外部ルート 160

IS-IS レベル 2 内部

ルート

18 IS-IS レベル 2 外部ルート 165

リダイレクト 30 BGP ( 内部および外部ルート ) 170

カーネル 40 MSDP 175



有効経路の選択 ( 続き )

同一の宛先に対して等価コストパスが存在する場合、ルーティング・プロトコル・プロセス (rpd) は、使用可能なパスのいずれかをランダムに選択します。これにより、宛先ごとのパケット順を維持しながら、パス間の負荷分散を図ることができます。次の出力例は、この点を説明したものです。

user@host> show route 10.1.0.0/16


10.1.1.0/24 *[Static/5] 00:00:25 to 172.20.66.2 via ge-0/0/2.0 > to 172.20.77.2 via ge-0/0/3.010.1.2.0/24 *[Static/5] 00:00:25 > to 172.20.66.2 via ge-0/0/2.0 to 172.20.77.2 via ge-0/0/3.010.1.3.0/24 *[Static/5] 00:00:25 to 172.20.66.2 via ge-0/0/2.0 > to 172.20.77.2 via ge-0/0/3.010.1.4.0/24 *[Static/5] 00:00:25 > to 172.20.66.2 via ge-0/0/2.0 to 172.20.77.2 via ge-0/0/3.0

必要に応じて、ルーティングポリシーを介して、複数の等価コストパスにおいてフロー単位で負荷分散させることもできます。負荷分散は、このコースの学習対

象外であるため、ここでは説明していません。



ルーティングテーブルの表示

このスライドには、ルーティングテーブルの全経路エントリーを表示する show

route コマンドの使用例を示しています。スライドに示すように、すべての有効

経路には、エントリーの横にアスタリスク (*) が表示されます。各エントリーに

は、当該経路の学習情報源とそのルートプリファレンス値が表示されます。

show route コマンドを発行すると、有効経路、ホールドダウン経路、隠し経路

のサマリーが表示されます。有効経路はトラフィック転送に使用される経路、ホールドダウン経路は当該経路が無効として宣言される前の停止状態の経路、隠し経路は無効ネクストホップや無効ルートポリシーなどの理由により使用できない経路のことをいいます。

コマンドの出力は、宛先プレフィックス、プロトコルタイプ、その他の識別属性によってフィルタリングすることができます。フィルタリングにプロトコルを使

用したコマンド出力例を次に示します。

user@host> show route protocol ospf


10.1.1.0/24 [OSPF/10] 04:57:41, metric 2 > to 172.18.25.2 via ge-0/0/13.0224.0.0.5/32 *[OSPF/10] 05:00:58, metric 1 MultiRecv



フォワーディングテーブル

フォワーディングテーブルには、ルーティングテーブルからの情報のサブセットが格納されます。学習した宛先プレフィックスや各宛先プレフィックスに関連付

けられている送信インタフェースなど、 Junos OS 搭載デバイスがパケット転送

に使用する情報が格納されています。

フォワーディングテーブルの内容を表示するには、 CLI の show route

forwarding-table コマンドを使用します。

user@host> show route protocol ospf Routing table: inetInternet:Destination Type RtRef Next hop Type Index NhRef Netifdefault user 0 0:17:cb:4e:ae:81 ucst 520 3 ge-0/0/0.0default perm 0 rjct 36 10.0.0.0/32 perm 0 dscd 34 1172.19.0.0/16 user 0 200.1.4.100 ucst 535 3 ge-0/0/3.0172.19.52.0/24 user 0 200.1.2.100 ucst 529 3 ge-0/0/1.0172.19.52.16/28 user 0 200.1.3.100 ucst 534 3 ge-0/0/2.0...




フォワーディングテーブル ( 続き )

Junos OS のカーネルも、いくつかの転送情報のエントリーを作成し、これらを

恒久的なものとみなします。その例として、合致するエントリーのないすべての

パケットに適用される default 転送エントリーがあります。パケットがこの

default 転送エントリーに合致すると、ルーターはそのパケットを破棄し、送

信元に ICMP 宛先到達不能メッセージを返信します。ユーザーがデフォルト経路

を定義した場合は、ルーターは恒久的な default 転送エントリーではなく、

ユーザー定義エントリーを使用します。

転送エントリーに関連する一般的な経路タイプの一部を次に示します。

• dest: インタフェースを介して直接到達可能なリモートアドレス

• intf: インタフェースの設定によって作成された経路

• perm: ルーティングテーブル初期化時にカーネルによって作成され

た経路

• user: ルーティング・プロトコル・プロセスや設定によって作成さ

れた経路

転送エントリーに関連する一般的なネクストホップ・タイプの一部を次に示します。

• bcst: ブロードキャスト

• dscd: ICMP 到達不能メッセージを送信せずに、暗黙的にパケットを

破棄

• hold: ネクストホップがユニキャストまたはマルチキャストタイプ

に解決されるのを待機している状態

• locl: インタフェースのローカルアドレス

• mcst: ワイヤー・マルチキャスト・ネクストホップ (LAN のみ )

• mdsc: マルチキャスト破棄

• recv: 受信

• rjct: パケットを破棄して ICMP 到達不能メッセージを送信

• ucst: ユニキャスト

• ulst: 負荷分散機能が設定されている場合に使用されるユニキャス

ト・ネクストホップのリスト



ネクストホップの決定

パケットが Junos OS 搭載デバイスに到達すると、デバイスはフォワーディング

テーブルのエントリーを参照してパケットの適切なネクストホップを決定します。パケットの宛先がローカルデバイスの場合は、 Junos OS はパケットをローカ

ル処理します。パケットの宛先がリモートデバイスで、フォワーディングテーブ

ルに一致するエントリーが存在する場合、 Junos OS 搭載デバイスはパケットを

エントリーに関連付けられたネクストホップのインタフェースに転送します。

パケットの宛先と一致する宛先プレフィックスが複数存在する場合、 Junos OSはも特定性のあるエントリー ( 長一致 ) を使用してパケットを宛先に転送し

ます。

一致するエントリーが存在しない場合、 Junos OS 搭載デバイスは送信元デバイ

スに対して宛先到達不能通知を送信します。



理解の確認

スライドに示すフォワーディングテーブルの例を使用して、ネクストホップ・インタフェースの決定方法を確認しましょう。宛先に対して複数のエントリーが一

致した場合、も特定性のあるエントリー ( 長一致 ) がパケットのネクスト

ホップ・インタフェースとして選択されます。

172.19.52.101 を宛先とするパケットの長一致となる転送エントリーは、宛先

プレフィックス 172.19.52.0/24 です。この宛先プレフィックスに関連付けられ

ているネクストホップは ge-0/0/1.0 です。

172.19.52.21 を宛先とするパケットの長一致となる転送エントリーは、宛先

プレフィックス 172.19.52.16/28 です。この宛先プレフィックスに関連付けられ

ているネクストホップは ge-0/0/2.0 です。

172.25.100.27 を宛先とするパケットに一致する唯一の転送エントリーは、ユー

ザー定義のデフォルト転送エントリーです。ユーザー定義のデフォルト転送エン

トリーに関連付けられているネクストホップは ge-0/0/0.0 です。



ルーティングの概念 : ルーティング・インスタンス




ルーティング・インスタンスの概要

Junos OS は、ルーティングテーブル、インタフェース、ルーティングプロトコ

ルのパラメータを論理的にグループ化して、固有のルーティング・インスタンスを生成します。デバイスでは、 1 つのルーティング・インスタンスに含まれる

ルーティング情報を論理的に保持し、他のルーティング・インスタンスと区別します。ルーティング・インスタンスの使用により、 1 つのデバイスで複数のデバ

イスを効果的に模倣することができるため、柔軟性に優れたルーティングを達成できます。



master ルーティング・インスタンス

Junos OS は、 master ルーティング・インスタンスと呼ばれるデフォルトのユニ

キャスト・ルーティング・インスタンスを作成します。この master ルーティン

グ・インスタンスは、デフォルトで、 IPv4 ユニキャスト・ルーティングに使用

される inet.0 ルーティングテーブルを含んでいます。 Junos OS は、 inet6.0

などその他のルーティングテーブルを作成してそれぞれのルーティング・インスタンスに追加し、設定により必要になった場合にはこれらのルーティングテーブルを表示します。

user@host> show route instance Instance Type Primary RIB Active/holddown/hidden__juniper_private1__ forwarding __juniper_private1__.inet.0 2/0/2 __juniper_private1__.inet6.0 1/0/0

__juniper_private2__ forwarding __juniper_private2__.inet.0 0/0/1

__master.anon__ forwarding

master forwarding inet.0 7/0/0



ユーザー定義のルーティング・インスタンス

一層の柔軟性を実現するために、 Junos OS では、 [edit routing-instances]階層でユーザー定義のルーティング・インスタンスを追加作成することも可能です。ユーザー定義のルーティング・インスタンスは、さまざまな状況に合わせて使用でき、個々の環境において優れた柔軟性を提供します。

ユーザー定義のルーティング・インスタンスを使用する一般的な例として、フィルタベース転送 (FBF)、レイヤー 2 およびレイヤー 3 の VPN サービス、システム仮想化などが挙げられます。

一般的なルーティング・インスタンスの種類の一部を次に示します。

• forwarding: 一般的なアクセス層アプリケーションのためのフィルタベース転送実装に使用される。

• l2vpn: レイヤー 2 の VPN 実装に使用される。

• no-forwarding: 大規模ネットワークをより規模の小さい管理単位に分割するために使用される。

• virtual-router: システム仮想化など、非 VPN 関連アプリケーションに使用される。

• vpls: VPN 内のサイト間でポイントツーマルチポイント LAN の実装に使用される。

• vrf: レイヤー 3 の VPN 実装に使用される。

使用可能なルーティング・インスタンスの種類は、 Junos OS 搭載プラットフォーム間で異なります。詳細については、必ずご使用製品の技術マニュアルでご確認ください。



設定例 : ルーティング・インスタンス

このスライドでは、基本的なルーティング・インスタンスの設定例を示しています。



ルーティング・インスタンスの使用 : パート 1

ルーティング・インスタンスを作成し、デバイスがインスタンス内のルーティング情報を学習すると、 Junos OS は自動的にルーティングテーブルを作成します。 IPv4 ルーティングを使用する場合、 Junos OS は IPv4 ユニキャスト・ルーティン

グテーブルを作成します。ルーティングテーブル名には、

instance-name.inet.0 という形式が使用されます ( ここで、

instance-name は、設定内のルーティング･インスタンス名です )。同様に、イ

ンスタンスで IPv6 を使用する場合は、 IPv6 ユニキャスト・ルーティングテーブ

ルが作成され、テーブル名の形式は、 instance-name.inet6.0 となります。

スライドに示すように、特定のルーティング・インスタンスに関連するルーティングテーブルの内容を表示するには、 CLI の show route table table-name

コマンドを使用します。



ルーティング・インスタンスの使用 : パート 2

CLI の show コマンドでは、特定のルーティング・インスタンス名を指定するこ

とにより、出力内容をフィルタリングすることができます。スライドの初の例

は、指定ルーティング・インスタンスに含まれるインタフェースを表示する便利な方法を示したものです。

特定のルーティング・インスタンス名を指定することにより、当該インスタンスからのトラフィックのみを表示することもできます。スライドの 2 番目と 3 番目

の例では、この方法を ping および traceroute の各ユーティリティと併用し

ています。



静的ルーティング




静的ルーティング

静的経路はネットワーク環境において、自律システム (AS) のデフォルト経路やカスタマーネットワークへの経路など、さまざまな目的に使用されます。動的ルーティングプロトコルと異なり、静的ルーティングでは、静的経路により提供されるルーティング情報を手作業でネットワーク内の各ルーターやマルチレイヤースイッチに設定します。静的経路の設定はすべて、 [edit routing-options] 階層レベルで行われます。

ネクストホップの指定

静的経路では、有効なネクストホップが定義されている必要があります。通常は、終宛先方向の隣接ルーターの IP アドレスがネクストホップとなります。ポイントツーポイントのインタフェースでは、リモートデバイスの IP アドレスではなく、出力インタフェース名を指定することができます。また、ネクストホップがビットバケットである場合もあります。ビットバケットとは、パケットをネットワークからドロップ ( 破棄 ) することを意味します。 Junos OS では、キーワード reject または discard を指定することにより、パケットがドロップ ( 破棄 ) されます。どちらのオプションを使用しても、パケットはネットワークから破棄されます。これら 2 つのキーワードの違いは、パケット破棄後のJunos OS 搭載デバイスの動作が異なる点にあります。ネクストホップ値にreject を指定した場合、システムは ICMP メッセージ ( ネットワーク到達不能メッセージ ) を IP パケットの送信元に返します。ネクストホップに discard を指定した場合、システムは ICMP メッセージを返さず、暗黙的にパケットを破棄します。




ネクストホップの指定 ( 続き )

Junos OS で設定されている静的経路のネクストホップ IP アドレスは、デフォル

トで、直接経路を使用して到達可能なものでなければなりません。他ベンダーの

ソフトウェアと異なり、 Junos OS はネクストホップの再帰的ルックアップをデ

フォルトでは実行しません。

静的経路は、ユーザーが明示的に削除するか、無効になるまでルーティングテーブルに保持されます。静的経路が無効になるケースの例として、ネクストホップ

に指定された IP アドレスが到達不能になった場合が挙げられます。



設定例 : 静的ルーティング

このスライドは、 IPv4 および IPv6 の静的経路の基本設定構文を示しています。この設定には、ルーティングポリシーを介して関連ルートを OSPF などの動的

ルーティングプロトコルに再分配することを禁止する no-readvertise オプ

ションも含まれています。静的経路では、トラフィックを管理ネットワークを

通じて管理イーサネットインタフェースから送出する no-readvertise オプ

ションを使用することをお勧めします。

IPv6 に対するサポートは、 Junos OS 搭載デバイス間で異なります。サポート情報

の詳細については、必ずご使用製品の技術マニュアルでご確認ください。



静的ルーティングの監視

このスライドには、静的ルーティングの適正な動作を検証する基本的な手順を示しています。



間接ネクストホップの解決

Junos OS では、デフォルトで、静的経路のネクストホップ IP アドレスが、直接

経路を使用して到達可能なものでなければなりません。他ベンダーのソフトウェ

アと異なり、 Junos OS はネクストホップの再帰的ルックアップをデフォルトで

は実行しません。

このスライドで示すように、デフォルトのネクストホップ解決処理の変更は、CLI の resolve オプションを使用して行えます。この場合、間接ネクストホッ

プへの経路も必要となります。間接ネクストホップは、他の静的経路または動

的ルーティングプロトコルを介して解決することができますが、可能な限り、

解決手段として動的ルーティングプロトコルを使用することをお勧めします。静的経路ではなく動的ルーティングプロトコルを使用して間接ネクストホップを解決すると、間接ネクストホップが使用できなくなった場合に、静的経路が動的に削除されます。



正規ネクストホップ

qualified-next-hop オプションを使用すると、同一宛先に対して存在する複

数の静的経路に、個別のプリファレンス値 ( 優先度 ) を設定することができま

す。このスライドには、 qualified-next-hop オプションの使用例を示してい

ます。

スライドの設定例では、ネクストホップ 172.30.25.1 にはデフォルト静的経路の

プリファレンス値 5 が割当てられ、正規ネクストホップ 172.30.25.5 にはプリ

ファレンス値 7 が割当てられています。この場合、この静的経路を使用するす

べてのトラフィックは、 172.30.25.1 が使用不可にならない限りこのアドレスを

ネクストホップとして使用します。 172.30.25.1 が使用不可になった場合、デバ

イスはネクストホップ 172.30.25.5 を使用します。この機能は、一部ベンダーで

はフローティング・スタティック・ルートと呼ばれています。



動的ルーティング




動的ルーティング

静的ルーティングは、経路数の少ない小規模ネットワークや、厳重なルーティング制御が必要なネットワークに適しています。ただし、静的ルーティングには欠点もあり、拡張や変更が頻繁に行われる大規模ネットワーク環境では管理が煩雑かつ困難になる可能性があります。通常、大規模ネットワークや定期的に変更が行われるネットワークでは、動的ルーティングの方が有利です。

動的ルーティングで設定が必要なのは、ルーティングプロトコルに参加するネットワークインタフェースだけです。ルーティングプロトコルを実行するデバイスは、相互に動的にルーティング情報を学習します。 1 つのデバイスが特定の通信デバイスのルーティング情報を追加・削除すると、他のデバイスも自動的にそれぞれの情報を更新します。

動的ルーティングの利点

動的ルーティングは、静的ルーティングが持つ制限や欠点の多くを補うものです。動的ルーティングの利点を次に示します。

• 管理オーバーヘッドが低い : デバイスは自動的にルーティング情報を学習するため、手作業による経路定義が不要です。

• ネットワーク可用性に優れいている : ネットワーク障害時、動的ルーティングでは、トラフィックを自動的に障害から回避させることができます ( 障害への対応能力が高いため、障害時のネットワーク稼動率が向上します )。

• ネットワークのスケーラビリティが高い : デバイスは動的に経路を学習し、ネットワーク規模で良パスを計算するため、ネットワーク拡張に対して柔軟な対応が可能です。



動的ルーティングプロトコルのサマリー

このスライドには、内部ゲートウェイプロトコル (IGP、自律システム内ルー

ティングプロトコル ) と外部ゲートウェイプロトコル (EGP、自律システム間

ルーティングプロトコル ) の概要を示しています。



OSPF プロトコル

OSPF は、自律システム (AS) 内での使用を前提に開発されたリンクステート型

ルーティングプロトコルであり、 IGP( 内部ゲートウェイプロトコル : 自律システ

ム内ルーティングプロトコル ) です。リンクステート型プロトコルは、コンバー

ジェンス時間が短く、大規模インターネットワークをサポートし、距離ベクトル型プロトコルと比較してルーティング情報の不備に対する耐性を備えています。

OSPF を実行するデバイスは、ネットワークリンクやリンクの状態に関する情報

を AS 内の他のルーターに送信します。この情報は、リンクステート広告 (LSA)によって、 AS 内の全ルーターに確実に転送され、各ルーターはこれらの情報を

受信してローカル保存します。これで、この情報セットには、ネットワーク内の

すべてのリンクが格納されます。

リンクステート型プロトコルは、 LSA のフラッディング、ネイバーの検出に加

え、もう 1 つの重要なタスクとして、リンクステート・データベースの構築を

行います。リンクステート ( トポロジー ) データベースは、 LSA を一連の記録と

して格納します。短パスの決定にあたって重要となる情報は、アドバタイズ

( 広告 ) ルーターの ID、接続ネットワーク、隣接ルーター、これらのネットワー

クまたは隣接ルーターに関連するコストです。




OSPF プロトコル ( 続き )

OSPF は、短経路優先 (SPF、ショーテスト・パス・ファースト ) アルゴリズム

( ダイクストラ・アルゴリズムとも呼ばれています ) を使用して、全宛先への

短経路を計算します。このアルゴリズムは、ツリー構造で各ノード間の短パス

を累積加算し、終的にそのツリーで短の経路を良候補として選択するものです。

OSPF では、エリア分割を使用してネットワークを階層的に管理することによ

り、スケーラビリティを実現します。 OSPF のエリアはルーターの論理グループ

です。 Junos OS は OSPF のエリアからルーティング情報を抽出し、デバイスはそ

の情報をネットワーク全体に転送します。エリアの使用により、各ルーターでの

リンクステート・データベースを小型化することができます。各 OSPF ルーター

は、それぞれが接続されている各エリアのリンクステート・データベースを個別に保持します。 1 つのエリア内のリンクステート・データベースは、そのエリア

内の全ルーターで同一です。

正確なルーティング情報と接続を保持するために、 OSPF にはバックボーンエリ

アと呼ばれる特別なエリアが保持されます。 OSPF のバックボーンエリアは Area 0.0.0.0 と呼ばれます。適正な接続を確保するためには、他の OSPF エリアがすべ

てこのバックボーンに接続されている必要があります。 OSPF エリア間のデータ

トラフィックは、必ずバックボーンを通過します。



ケーススタディ : 目標とトポロジー

このスライドには、ケーススタディの目標および使用するトポロジーが記載されています。



ケーススタディ : OSPF の構築

このスライドには、ホスト A に必要な OSPF 設定を示しています。スライドには含

まれていませんが、ホスト B およびホスト C も、隣接関係の確立と、ルーティ

ング情報の共有のために、同様の OSPF 設定を必要とします。



ケーススタディ : OSPF 隣接関係の検証

このスライドには、 OSPF の隣接関係を確認するために使用する CLI コマンドを

示しています。スライドのコマンド出力例から、ホスト A がホスト B およびホス

ト C の両方と隣接関係を確立していることが確認できます。以下に、コマンド

出力の各フィールドについて説明します。

• Address: ネイバーのアドレス

• Interface: ネイバーに到達するためのインタフェース

• State: ネイバーの状態 (Attempt、 Down、 Exchange、 ExStart、 Full、Init、 Loading、 2 Way のいずれか )

• ID: 隣接ルーターの ID

• Pri: 指名ルーターとなるための隣接ルーターの優先度 ( 指名ルー

ター選出時にブロードキャストネットワークにおいてのみ使用 )。デフォルトでは 128 に設定 ( この値が高優先度となり、指名ルー

ター選出の可能性がも高い )。

• Dead: ネイバーが到達不能になるまでの秒数



ケーススタディ : OSPF ルートの表示

このスライドには、ホスト A が学習した OSPF ルートを表示する show route

protocol ospf コマンドを示しています。ホスト A は、ルーティングテーブル

に直接接続のサブネットを OSPF ルートとしてではなく、直接経路として格納し

ています。



本章で学習した内容 :

• ルーティングの基本動作と概念

• ルーティングテーブルとフォワーディングテーブル

• 静的ルーティングの設定と監視

• 基本 OSPF の設定と監視



復習問題 :

1.

2.

3.

4.

5.



ラボ 1: ルーティングの基礎

このスライドには、このラボの目標が記載されています。





第 3章 : ルーティングポリシーとファイアウォールフィルタ


本章の内容 :

• ルーティングポリシーおよびファイアウォールフィルタのフレームワーク

• ポリシーとファイアウォールフィルタの評価

• ルーティングポリシー使用の典型的なシナリオ

• ルーティングポリシーの設定と適用

• ファイアウォールフィルタ使用の典型的なシナリオ

• ファイアウォールフィルタの設定と適用

• ユニキャスト・リバースパス転送

第 3 章 - 2 • ルーティングポリシーとファイアウォールフィルタ


ルーティングポリシーの概要



ルーティングポリシーとファイアウォールフィルタ • 第 3 章 - 3


ルーティングポリシーの概要

ルーティングポリシーは、ルーティングテーブルから / ルーティングテーブルへ

のルーティング情報フローを制御するために使用するもので、ルーティング情報

がルーティングテーブルを出入りする際に適用することができます。

ルーティングポリシーは、動的ルーティングプロトコルを実行するネイバーからの経路を許可 / 拒否する際の判断に使用されるほか、動的ルーティングプロトコ

ルを実行するネイバーへの送信経路の決定にも使用されます。ルーティングポリ

シーを使用して、テーブルに経路が追加や削除される際にその経路の属性を変更することもできます。

ルーティングポリシーは、フォワーディングテーブルへのルーティング情報フローも制御します。これにより、フォワーディングテーブルに格納する経路を制

御したり、これらの経路に関連付けられている属性を制御することができます。




ルーティングポリシーの概要 ( 続き )

ルーティングテーブルへの経路の取込みを制御するポリシーはインポートポリシーと呼ばれます。インポートポリシーは、経路がルーティングテーブルに格納

される前に適用されるため、ルーティングテーブルに存在する経路を変更した

り、ローカル経路選択プロセスに影響を与えます。

ルーティングテーブルからの経路の送信を制御するポリシーはエクスポートポリシーと呼ばれます。エクスポートポリシーは、ルーティングテーブルから動的

ルーティングプロトコルやフォワーディングテーブルに経路をエクスポートする際に適用されます。ルーティングテーブルからエクスポートできるのは有効経路

のみです。つまり、エクスポートポリシーは、エクスポート対象とする有効経路

を選択したり、経路の属性を変更することはできますが、無効経路がエクスポートされるようにすることはできません。

例えば、同一プレフィックスについて OSPF ルート ( プリファレンス値 10) と

BGP ルート ( プリファレンス値 170) がある場合、エクスポートポリシーは有効

な OSPF ルートを送信するかどうかを判定し、経路の送信時にその属性を変更し

ます。ただし、エクスポートポリシーは、無効な BGP ルートが送信されるよう

にすることはできません。

Junos オペレーティングシステム (Junos OS) は、ルーティングテーブルから経路

をエクスポートする際にエクスポートポリシーを適用するため、属性変更は、ローカルのルーティングテーブルではなく、エクスポートされる経路に対して行われます。



デフォルトのルーティングポリシー

各プロトコルには、デフォルトのインポートポリシーとエクスポートポリシーがあります。このスライドに掲載されている表は、一般的な各種ルーティングプロトコルのデフォルトのインポートポリシー / エクスポートポリシーをまとめたものです。

BGP のデフォルト・インポートポリシーでは、 BGP ネイバーからの全経路を許可し、ルーティングテーブルに格納するように規定されています。 BGP のデフォルト・エクスポートポリシーでは、すべての有効 BGP ルートをアドバタイズ( 広告 ) するように規定されています。 BGP では、インポートポリシー / エクスポートポリシーを、プロトコル、グループ、ネイバーの各レベルで設定することができます。

OSPF のデフォルト・インポートポリシーでは、すべての OSPF ルートをインポートするように規定されています。リンクステート型プロトコルである OSPFは、リンクステート広告 (LSA) のフラッディングにより、各 OSPF エリアで一貫したリンクステート・データベースを維持します。したがって、ローカルのリンクステート・データベース維持や LSA のフラッディングに影響を与えるようなポリシーを適用することはできません。また、ルーティングテーブルへの内部ルート ( エリア間ルートを含む ) の格納を禁止するようなポリシーも適用できません。 ( リンクステート型プロトコルは、一貫性のある転送決定を行うために全デバイスが内部ルートに関して同じルーティング情報を持つことを前提としています。ルーティングテーブルへの内部ルートの追加を禁止すると、ルーティングループが発生したり、特定プレフィックスが到達不能になるおそれがあります。) ただし、外部ルートをブロックするポリシーを適用することは可能です。




デフォルトのルーティングポリシー ( 続き )

OSPF のデフォルト・エクスポートポリシー ( すべて拒否するように規定 ) では、

エリア内の LSA のフラッディングはブロックされません。システムは、常に

OSPF エリア全域で LSA のフラッディングを実行し、ルーティングポリシーによ

りこの動作を制御することはできません。デフォルトのエクスポートポリシーで

は、他の送信元からの OSPF ネイバーに対する追加経路のアドバタイズ ( 広告 )をブロックします。 OSPF を通じて他の経路をアドバタイズ ( 広告 ) する場合は、

明示的なエクスポートポリシーを設定する必要があります。

リンクステート型プロトコルは、すべての参加デバイスが一貫したリンクステート・データベースを持つことを前提としているため、インポートポリシー / エク

スポートポリシーはプロトコルレベルでのみ設定可能です。

RIP のデフォルトポリシーでは、明示的に設定されているネイバーから学習した

全経路をインポートするように規定されています。設定内で明示的に定義されて

いないネイバーから学習した経路は無視されます。 Junos OS は、デフォルトで、

RIP ネイバーに対する経路 (RIP ルートを含む ) のエクスポートは行いません。したがって、 RIP ネイバーに対する任意の経路をアドバタイズ ( 広告 ) するために

は、次のコマンド出力例に示すように、 RIP ルートに合致し、 RIP ルートを許可

するエクスポートポリシーを設定する必要があります。

[edit policy-options]user@host# show policy-statement export-rip-routes { term match-rip-routes { from protocol rip; then accept; }}

RIP では、インポートポリシーはプロトコルレベルおよびネイバーレベルで適用

できますが、エクスポートポリシーは次の出力例に示すようにグループレベルでのみ適用可能です。

[edit protocols rip]user@host# show group my-rip-group { export export-rip-routes; neighbor ge-0/0/1.0; neighbor se-1/0/0.0;}



ルーティングポリシーの構成要素

ルーティングポリシーは、順序付けられた条件のグループで構成されます。ルー

ティングポリシーに名前を付けておけば、設定内のさまざまな場所でポリシーを簡単に識別することができます。

条件は、 Junos OS におけるすべてのポリシーの基本構成要素であり、基本的に

if...then ステートメントで定義されます。 from ステートメントで指定された一致

基準がすべて真である ( または from ステートメントが指定されていない ) 場合、

then ステートメントで指定されているすべてのアクションが実行されます。条件

にも名前を付けることができますが、付けた名前が条件の評価に影響を及ぼすこ

とはなく、条件を参照する際に便利な識別子として機能します。

Junos OS は、 from ステートメントの評価時に、単一の一致基準に対する引数間

の論理和 (OR) として評価を行い、さらに複数の一致基準間の論理積 (AND) とし

て評価を行います。つまり、 from ステートメントが真とみなされるためには、評

価対象のアイテムで、所定の各一致基準に対して少なくとも 1 つの引数が一致

している必要があります。




ルーティングポリシーの構成要素 ( 続き )

ある経路が、条件の from ステートメントに指定されているすべての基準に一致

する場合、 Junos OS は当該条件の then ステートメントに指定されているすべて

のアクションを実行します。指定アクションに終了アクションが含まれている場

合には、ポリシー評価は停止します。

経路の許可および拒否を制御するアクション (accept、 reject) は、終了アク

ションです。これらの終了アクションを使用すると、 first-match ポリシー評価が

有効になります。つまり、 Junos OS は指定アクションを即座に実行し、ポリ

シーの他の評価は実行しません。

Junos OS のポリシー評価では、各条件を順番に評価していきます。条件の順番

は、必要に応じて、 CLI の設定モードで insert コマンドを使用して変更するこ

とができます。



一般的な選択基準

このスライドには、 from ステートメントで指定できる経路選択基準を示してい

ます。経路は、プレフィックス、プロトコル、一部のルーティングプロトコル属

性、ネクストホップ情報に基づいて選択することができます。以降のページで

は、一致基準オプション route-filter および prefix-list について説明し

ます。

ポリシーやポリシーの条件で from ステートメントを省略した場合は、全経路が

then ステートメントで指定されているアクションの対象となります。

一致基準の一覧は、 CLI のインタラクティブヘルプおよび『Junos Policy Framework Configuration Guide (Junos ポリシーフレームワーク設定ガイド )』でご確認いただけます。



プレフィックスリスト

経路の選択は、プレフィックスに基づき、プレフィックスリストやルートフィルタを使用して行うことができます。

プレフィックスリストは、 [edit policy-options] 階層で設定される名前を

持つリストです。プレフィックスリストの利点の 1 つに、複数の場所で使用でき

ることが挙げられ、単一ポリシー内の複数条件または複数ポリシーでプレフィッ

クスリストを参照することができます。また、ルーティングポリシーやファイア

ウォールフィルタでの使用も可能です ( ただし、ステートフル・ファイアウォー

ル規則には使用できません )。このように、プレフィックスリストはざまざまな

場所で再利用できるため、状況によっては非常に有用です。

プレフィックスリストをルーティングポリシーの from ステートメントで使用す

る場合は、次の 2 通りの使用方法があります。リストを prefix-list ステート

メントで参照する場合は、経路がリスト内のいずれかのプレフィックスと完全に一致した場合にのみ、経路が合致したとみなされます。リストを

prefix-list-filter ステートメントで参照する場合は、プレフィックスリス

トに適用する一致タイプ (exact、 longer、 orlonger) を指定することができ

ます。また、フィルタが一致した場合に実行されるアクションを指定することも

できます。このアクションは一致評価の直後に実行され、 then ステートメントは

評価されません。一致タイプについては、この章で詳しく後述します。



ルートフィルタ

ルートフィルタは、単一のルーティングポリシーやポリシー条件内で設定されるプレフィックスのリストです。プレフィックスリストとは異なり、再利用性がな

く、設定されるポリシーや条件内で限定的に使用されます。ルートフィルタに

は、プレフィックスリストよりも多くの一致タイプがあります。これらの一致タ

イプについては、以降のページで詳しく説明します。 prefix-list-filter ス

テートメントの場合と同様に、 route-filter ステートメントに一致した場合

に実行する任意のアクションを指定することができます。このアクションは一致

評価の直後に実行され、 then ステートメントは評価されません。



exact

一致タイプ exact では、経路が指定プレフィックスに完全一致する場合に、

フィルタステートメントに合致するとみなされます。スライドの例では、プレ

フィックス 192.168.0.0/16 のみがフィルタステートメントに合致します。

orlonger

一致タイプ orlonger では、経路が指定プレフィックス範囲内で、プレフィッ

クス長が指定と同じかそれより長い場合に、フィルタステートメントに合致するとみなされます。スライドの例では、 192.168.0.0/16 は指定プレフィックスに完

全一致し、フィルタステートメントに合致します。さらに、 192.168.0.0/16 のサ

ブセットで、プレフィックス長が /17 から /32 の範囲内にある全経路も合致す

ることになります。例えば、 192.168.0.0/16、 192.168.65.0/24、

192.168.24.89/32、 192.168.128/18、 192.168.0.0/17 は合致するとみなされ、 10.0.0.0/16、 192.167.0.0/17、 192.168.0.0/15、 200.123.45.0/24 は合致すると

みなされません。



longer

一致タイプ longer では、経路が指定プレフィックス範囲内で、プレフィック

ス長が指定よりも長い場合に、フィルタステートメントに合致するとみなされます。 (longer と orlonger の違いは、 orlonger では指定プレフィックス自体

が合致とみなされるのに対して、 longer では合致とみなされないという点で

す。 ) スライドの例では、 192.168.0.0/16 のサブセットで、プレフィックス長が

/17 から /32 の範囲内の全経路は合致しますが、 192.168.0.0/16 自体は合致し

ません。

upto

一致タイプ upto は、 orlonger に類似するタイプですが、合致とみなすプレ

フィックス長の長制限が指定される点が異なります。 upto では、経路が指定

プレフィックスの範囲内で、プレフィックス長が所定のプレフィックスと同じかそれより長く、かつ、 upto で指定したプレフィックス長と同じかそれより短い

範囲内である場合に、フィルタステートメントに合致するとみなされます。スラ

イドの例では、 192.168.0.0/16 は指定プレフィックスに完全一致し、フィルタ

ステートメントに合致します。また、 192.168.0.0/16 のサブセットで、プレ

フィックス長が /17 から /24 の範囲内 ( それぞれの数値を含む ) にある全経路も

合致することになります。例えば、 192.168.0.0/16、 192.168.65.0/24、

192.168.128.0/18、 192.168.0.0/17 は合致するとみなされ、 192.168.0.0/25、

192.168.24.89/32、 10.0.0.0/16、 192.167.0.0/17、 200.123.45/24 は合致する

とみなされません。



prefix-length-range

一致タイプ prefix-length-range は、 upto に類似するタイプですが、合

致とみなすプレフィックス長の短と長の制限が指定される点が異なります。 prefix-length-range では、経路が指定プレフィックスの範囲内で、

プレフィックス長が初の指定プレフィックス長と同じかそれより長く、かつ、 2 番目の指定プレフィックス長と同じかそれより短い範囲内である場合

に、フィルタステートメントに合致するとみなされます。このスライドの例で

は、 192.168.0.0/16 のサブセットで、プレフィックス長が /20 から /24 の範

囲内 ( それぞれの値を含む ) にある全経路がステートメントに合致します。例えば、 192.168.0.0/20、 192.168.128.0/21、 192.168.64.0/24 は合致するとみ

なされ、 192.168.0.0/16、 192.168.24.89/32、 10.0.0.0/16、 192.167.0.0/17、

200.123.45/24、 192.168.128.0/18 は合致するとみなされません。




through

一致タイプ through は、他の一致タイプとは大きく異なります。 through で

は、指定された 2 つのプレフィックスの間の基数ツリー構造に直接沿った全プ

レフィックスを合致とみなします。ここで、指定された 2 つ目のプレフィックス

は、 1 つ目のプレフィックスのサブセットである必要があります。この一致タイ

プでは、 2 つ目の ( より特定性の高い ) プレフィックスと、このプレフィックス

をサブセットとして持ち 1 つ目のプレフィックスと同じかより特定性の高い全

プレフィックスが、ステートメントと合致するとみなされます。つまり、この一

致タイプでは、 2 つ目の ( より特定性の高い ) プレフィックス、それをサブセッ

トとするその次に特定性の高いプレフィックス、さらにそれをサブセットとするその次に特定性の高いプレフィックスと続き、 1 つ目のプレフィックスに到達す

る構成となります。このスライドの例では、 192.168.16.0/20 が合致します。 192.168.16.0/20 は、 192.168.0.0/19、 192.168.0.0/18、 192.168.0.0/17、

192.168.0.0/16 のサブセットであり、これらのプレフィックスはすべて

192.168.0.0/16 と同じかより特定性が高いため、合致するとみなされます。その

他のプレフィックスは合致するとみなされません。

もう 1 つの例として、 from route-filter 192.168.0.0/16 through

192.168.232.0/21 ステートメントを見た場合、 192.168.232.0/21、

192.168.224.0/20、 192.168.224.0/19、 192.168.192.0/18、 192.168.128.0/17、

192.168.0.0/16 は、このステートメントに合致します。



ルートフィルタの一致タイプ

このスライドの図は、ルートフィルタの各種一致タイプを説明したものです。

Junos OS 搭載デバイスでは、ルートフィルタに異なるマスク長を指定した場合の

一致評価には注意が必要です。 Junos OS は、ルートフィルタに指定したプレ

フィックスおよびマスクと、対象経路のプレフィックスおよびマスクの間に一致するものがあるかどうかを検索します。この検索では、ルートフィルタでも特定

性の高いエントリーから開始され、も特定性の低いエントリーに達するまで続行されます。一致する経路が見つかると、その経路が、ルートフィルタに指定され

た一致タイプに照らし合わせて評価されます。そこで一致すると、その経路はルー

トフィルタに合致するとみなされます。プレフィックスがルートフィルタに合致し

ない場合、そのプレフィックスがルートフィルタでより特定性の低いエントリーと一致する可能性があったとしても評価はフェイルします。ルートリストの使用に

あたっては、事前に『Junos Policy Framework Configuration Guide (Junos ポリシーフ

レームワーク設定ガイド )』の「How a Route List is Evaluated ( ルートリストの評価

方法 )」セクションを読まれることをお勧めします。

また、 test policy コマンドを使用して、ルートフィルタおよびプレフィック

スリストを含むポリシーの有効性を検証することができます。ただし、その際に

は、 test policy コマンドのデフォルトポリシーでは全経路を許可するように

規定されている点に注意する必要があります。



一般的なアクション

一般的なルートポリシー・アクションには、終了アクションである accept お

よび reject などがあります。これらのアクションが終了アクションと呼ばれる

のは、ポリシー ( またはポリシーチェーン ) 評価の停止と、経路の許可 / 拒否を

引き起こすためです。終了を伴わない同様のアクションとして、

default-action accept および default-action reject があり、これら

のアクションは、ポリシー評価を停止させず、デフォルトポリシーの許可 / 拒否

決定よりも優先されます。

また、その他の一般的なアクションとして、ポリシー評価フローに影響を及ぼすルーティングポリシー・アクションがあります。 next term、 next policy ア

クションが指定されている場合、 Junos OS では、それぞれ次の条件、ポリシー

が評価されます。

BGP コミュニティ、ルートプリファレンスなどのプロトコル属性を変更するア

クションも一般的に使用されます。



ルーティングポリシーの定義

ポリシーの適用は、 2 段階のステップに分けられます。初のステップとして、

ルーティングポリシーを定義します。 Junos OS では、ルーティングポリシーは

[edit policy-options] 階層で定義されます。このスライドでは、3 つの明確

な条件を持つポリシーの例を示しています。



ルーティングポリシーの適用

ルーティングプロトコルによっては、インポートポリシーおよびエクスポートポリシーを複数の階層レベルで適用することができます。例えば、 BGP セッション

のインポートポリシーは、設定階層内のネイバー、グループ、プロトコルの各階層レベルで設定することができます。

ただし、どのプロトコルでもすべての階層レベルでのポリシー設定が許可されるわけではありません。例えば、 OSPF は、全体で一貫性のあるリンクステート・

データベースを保持する必要があるため、インポートポリシーとエクスポートポリシーの設定はプロトコル階層レベルでのみ可能です。 ( 同じ理由で、 OSPF のイ

ンポートポリシーおよびエクスポートポリシーの変更数が制限されています。 )

Junos OS 搭載デバイスは、必ず、も特定性のあるインポートポリシーおよび

エクスポートポリシーのみを適用します。したがって、設定の上位階層で設定さ

れたインポートポリシーやエクスポートポリシーは、下位階層で独自のポリシー設定が行われていない限り、下位階層にも適用されますが、下位階層でポリシー

を設定した場合には、当該ポリシーのみが適用されます。



ポリシーのチェーン化

ポリシーをカスケードすることにより、ポリシー処理をチェーン化することができます。ポリシーチェーンを作成することで、複雑な経路操作タスクをモジュー

ル方式で行うことができます。

Junos OS では、ポリシーの評価は、ルーティングプロトコルに適用される順番

に基づいて、左から右に行われます。 Junos OS は、各ポリシーの一致基準を

チェックし、経路が合致すると、関連アクションを実行します。初のポリシー

に合致するものがないか、合致が非終了アクションと関連付けられていた場合、その経路はチェーン内の次のポリシーに照らし合わせて評価されます。このパ

ターンは、チェーン内の全ポリシーに対して繰り返されます。ユーザー定義のポ

リシーチェーンの評価で終了アクションが発生しなかった場合は、終的に対象プロトコルのデフォルトポリシーが適用されます。デフォルトのルーティングポ

リシーについては、この章で前述している該当項目をご参照ください。

ポリシー処理は、ブール演算子でポリシーをグループ化していない限り、経路が終了アクションに到達した時点で終了します。 AND や OR などの論理演算による

ポリシーのグループ化は、このコースの学習対象外であるため、ここでは説明してません。




ポリシーのチェーン化 ( 続き )

前述のように、個々のポリシーは複数の条件により構成されます。条件とは、

一致基準とアクションを組合せたもので、数字や記号で名前を付けることができます。

Junos OS では、上から下に順番に条件をリストアップして、順次評価します。各条件の一致基準に対して評価が行われ、合致すると、関連アクションが実行され

ます。初の条件で合致しない場合は、 2 番目の条件の評価が行われ、 2 番目の

条件で合致しない場合は 3 番目の条件の評価が行われます。このパターンは、全

条件に対して繰り返されます。後の条件でも合致しない場合、 Junos OS は次の

適用ポリシーをチェックし、終的にはプロトコルのデフォルトポリシーを適用します。

条件内で合致した場合には、 Junos OS が該当するアクションを実行します。その

アクションが終了アクションである場合は、条件の処理とポリシーの適用は停止されますが、それ以外の場合は処理が続行されます。

Junos OS では、ポリシー評価フローに影響を及ぼすフロー制御アクションもサ

ポートしています。 next term、 next policy アクションが指定されている場

合、 Junos OS では、それぞれ次の条件、ポリシーが評価されます。



ケーススタディ : ルーティングポリシー





このスライドには、ルーティングポリシーに関するケーススタディの目標とトポロジーが記載されています。ここでは、ルーティングポリシーを使用して、 R1のデフォルト静的経路を OSPF に対してアドバタイズ ( 広告 ) します。



ケーススタディ : ポリシーの定義

このスライドでは、このケーススタディの目標を達成するためのルーティングポ

リシー設定例を示しています。



ケーススタディ : ポリシーの適用

このスライドでは、前スライドで定義したルーティングポリシーの適用について示しています。スライドに記載されているように、ルーティングポリシーが適用

され、 commit 発行により新しい設定が有効になると、 R1 は OSPF エリア 0 内

の他ルーターに対して、デフォルト経路を外部 LSA としてアドバタイズ ( 広告 )します。次のページでは、この広告の検証について説明します。



ケーススタディ : 結果の検証

このスライドでは、ルーティングポリシーが想定通りに機能していることを確認するための検証手順例を示しています。 CLI の show route protocol ospf

exact 0/0 コマンドを使用して、 R4 がデフォルトの外部 OSPF ルートを自身の

ルーティングテーブルに追加したことが確認できます。



ラボ 2: ルーティングポリシー




ファイアウォールフィルタの概要




ファイアウォールフィルタ

ファイアウォールフィルタは、他ベンダーで通常「アクセス制御リスト (ACL)」と呼ばれているものです。 Junos OS のファイアウォールフィルタはステートレ

スであり、主に Junos OS 搭載デバイスの通過トラフィックを制御するために使

用されます。

ステートレスなファイアウォールフィルタは、各パケットを個別に検証します。接続状態を追跡して、フロー内の全パケットに対するアクションを指定できるステートフルなファイアウォールと異なり、ステートレスなファイアウォールフィルタは接続の概念を持ちません。そのため、ファイアウォールフィルタを記述す

る際には、ステートレスであることを念頭に置く必要があります。システムは接

続状態の情報を保持しないため、許可する各接続について、双方向のトラフィックに対する明示的な許可が必要です。これとは対照的に、ステートフルなファイ

アウォールフィルタは、接続初期化時に許可を与えるだけで、その接続における双方向の通信が自動的に許可されます。

ファイアウォールフィルタを使用することにより、ネットワークを通過する特定タイプのトラフィックを制限することができます。また、ファイアウォールフィ

ルタを使用して監視タスクを実行することにより、ネットワーク環境で効果的なセキュリティ戦略を構築することができます。



ファイアウォールフィルタの構成要素

ルーティングポリシーとファイアウォールフィルタは異なる目的を達成するためのもので、異なる一致基準やアクション基準を持ちますが、構造は同じです。

ルーティングポリシー同様、ファイアウォールの基本構成要素は条件です。 1 つ

の条件には、 0 以上の一致基準と 1 つ以上のアクションが含まれます。すべての

一致基準が真である場合、 Junos OS は条件に指定されたアクションを実行しま

す。一致基準が指定されていない場合は、すべてのトラフィックがファイア

ウォールフィルタの条件に合致するとみなされて、指定アクション実行の対象となります。フィルタを使用して複数の条件をグループ化し、条件が評価される順

序を設定することができます。 Junos OS のファイアウォールフィルタには 1 つ以

上の条件が必要です。

ファイアウォールフィルタは、常にデフォルト条件を含みます。このデフォルト条件は、ユーザー定義の条件で明示的に許可されない全パケットを破棄します。ファイアウォールフィルタを実装する際には、条件の順序の重要性と、評価結果に影響を与える可能性があることに注意する必要があります。



一般的な一致基準

パケットの一致基準は、ファイアウォールフィルタの条件内の from 句で指定します。多くのヘッダーフィールドが、一致基準として使用可能です。ただし、ファイアウォールフィルタの処理方法によっては、すべてのヘッダーフィールドが使用できるとは限りません。

ヘッダーフィールドを指定すると、 Junos OS はヘッダー内でそのフィールドが存在する位置で合致するものを検索します。ただし、そのヘッダーフィールドが所定のコンテキストで意味をなすかどうかまでは確認されません。例えば、 TCPヘッダーでの ACK フラグ検索を指定した場合、 Junos OS はフラグ位置でビットが立っているかどうかはチェックしますが、パケットが実際に TCP パケットであるかどうかはチェックしません。そのため、フィルタを記述する際にはこの点について考慮する必要があります。この例の場合は、パケットが TCP パケットであり、さらに、 TCP で ACK フラグが立っていることをチェックするための記述が必要です。

ファイアウォールフィルタがステートレスであることは、フラグメント化したパケットの処理で使用できる情報にも影響を与えます。ステートレスなファイアウォールフィルタでのフラグメント化パケットの処理は、ステートフルな環境での場合よりも複雑です。初のフラグメント化パケットはすべてのレイヤー 4ヘッダーを持ちますが、以降のフラグメントはこれらのヘッダーを持ちません。また、フラグメント化パケットでレイヤー 4 ヘッダーをチェックすることは、予期せぬ結果をまねくおそれがあります。前述したように、 Junos OS はレイヤー4 ヘッダーの評価を試みますが、 2 番目以降のフラグメントはこれらのヘッダーを持たないため、合致の予測ができなくなります。




一致基準の分類

一致基準は、基本的に、数値範囲、アドレス、ビットフィールドの 3 つに分類

されます。通常、特定分類内の各一致基準には同じ評価オプションを使用するこ

とができます。一致基準として機能する複数のテキストシノニムもあります。テキストシノニムの一致基準は、 1 つ以上の一致基準に相当します。 ( 例えば、

tcp-established という一致基準は、 tcp-flag ack および tcp-flag rst

という一致基準のテキストシノニムです。 )



一般的なアクション

アクションは、条件の then 句で指定します。ファイアウォールフィルタの一般的なアクションには、終了アクションやアクション修飾子が挙げられます。

終了アクションでは、ファイアウォールフィルタの評価が停止されます。 accept アクションでは、パケットが許可され、パケットの入出力処理が続行されます。 discard アクションでは、インターネット制御メッセージプロトコル(ICMP) メッセージが送信元アドレスに返されることなく、パケットが暗黙的に破棄されます。 reject アクションでは、パケットが破棄され、メッセージが送信元アドレスに返されます。システムにより送信されるデフォルトメッセージは、宛先到達不能タイプで管理上禁止を示すメッセージコードを持つ ICMP メッセージです。 reject アクションには、デフォルト以外のメッセージコードを持つ ICMP メッセージや TCP リセットメッセージが送信されるようにするための引数を指定できます。 tcp-reset オプションを指定した場合、システムは TCP パケットに TCP リセットで応答しますが、非 TCP パケットにはメッセージを返しません。

終了アクションやフロー制御アクションには、 1 つ以上のアクション修飾子を指定することができます。アクション修飾子を指定して、終了アクションを指定しない場合、システムは暗黙的に accept アクションを適用します。パケット情報を記録するには、 count、 log、 syslog の各アクション修飾子を使用します。クラス・オブ・サービス (CoS) 情報を指定するには、 forwarding-class および loss-priority アクション識別子を使用します。この章で後述するトラフィック・ポリサーを起動するには、 policer アクション識別子を使用します

ファイアウォールフィルタを適用し、いずれかの条件によりトラフィックを明示的に許可しない場合には、デフォルトでトラフィックが破棄されるため、注意する必要があります。



ファイアウォールフィルタの定義

ファイアウォールフィルタの実装は、 2 段階のステップに分けられます。初の

ステップとして、ファイアウォールフィルタを定義します。 Junos OS では、ファ

イアウォールフィルタは [edit firewall] 階層で定義します。 Junos OS では

複数のプロトコルファミリーをサポートしているため、設定の際には適切なファミリー階層まで移動する必要があります。スライドの例では、 IPv4 のファイア

ウォールフィルタを [edit firewall family inet] 階層レベルで定義して

います。 Junos OS では、各種プロトコルファミリーをサポートしています。詳細

については、ご使用製品のマニュアルをご参照ください。



インタフェースにおけるトラフィックのフィルタリング

ファイアウォールフィルタを、複数箇所でのトラフィックのフィルタリング目的で使用することは可能ですが、ファイアウォールフィルタの本来の目的は、インタフェースに到達する / インタフェースから送出されるトラフィックのフィルタリングであり、すべてのインタフェースに適用可能です。また、ファイアウォールフィルタを論理インタフェース lo0 に適用して、システムを宛先とするトラフィックをフィルタリングすることもできます。

インタフェースへの IPv4 ファイアウォールフィルタの適用は、 [edit interfaces interface-name unit unit-number family inet filter]階層で行います。単一の入力フィルタまたは出力フィルタを適用する場合は、設定オプション input filter-name または output filter-name を使用します。同一のインタフェースに対して入力フィルタと出力フィルタの両方を指定することも可能です。ただし、 IPv6 ファイアウォールフィルタを IPv4 インタフェースに対して指定することはできません。つまり、ファイアウォールフィルタのプロトコルファミリーとインタフェースは一致している必要があります。

[edit interfaces interface-name unit unit-number family inet filter]階層で設定オプションinput-listまたはoutput-listを使用して複数のフィルタを適用し、トラフィックをフィルタリングすることもできます。これらのオプションを使用する場合には、ポリシーチェーンを作成します。そうすると、 Junos OS が、他のポリシーチェーンと同様の方法でパケットをフィルタリングします。

リモートロケーションから設定変更を行う場合、変更後の設定を有効にする際には、必ず commit confirmed オプションを使用してください。ファイアウォールフィルタ設定のコミットを必ず実行するように習慣づけておけば、障害対応で夜中にあわててオフィスに戻るような事態を回避することができます。



理解の確認 : パート 1

このスライドは、ファイアウォールフィルタ適用に関する理解を確認するものです。 ge-0/0/1.0 インタフェースでのインバウンドのハイパーテキスト転送プロト

コル (HTTP) トラフィックをフィルタリングするために、入力フィルタとして

ge-0/0/1.0 インタフェースに適用する適切なフィルタを設定してみましょう。この要件を満足する設定例については、次のページで説明します。



理解の確認 : パート 2

このスライドに示す設定例と条件 allow-web-traffic により、 Junos OS は

172.27.102.100/32 を宛先とするインバウンドの HTTP トラフィックをのみ許可

します。また、条件 deny-other-web-traffic により、他の HTTP トラ

フィックはすべて拒否されます。ただし、明示的に許可されないトラフィックに

対するデフォルトアクションは discard であり、ここでの拒否は厳密には必要

ありません。



ローカルトラフィックのフィルタリング : パート 1

トランジット・ファイアウォールフィルタは、 Junos OS 搭載デバイス上のイン

タフェース間で送られるパケットを対象とするフィルタであり、システムを不正

アクセスやその他の脅威から保護します。さらに、不正管理アクセスや他の有害

な影響からシステムを保護するための方策として、ルーティングエンジン (RE)保護を目的としてファイアウォールフィルタを適用します。パケット転送エンジ

ン (PFE) は、トラフィックが制御プレーンに到達する前にこれらのフィルタを適

用します。

Junos OS では、 lo0 ファイアウォールフィルタにホールを自動的には作成しませ

ん。したがって、管理トラフィックだけでなく、ルーティングプロトコルや他の

制御トラフィックにも RE に到達するための許可が必要です。暗黙的な破棄 ( 定

義された条件により明示的に許可されない全パケットを破棄すること ) は、ネッ

トワークに望ましくない影響を及ぼすことが知られています。



ローカルトラフィックのフィルタリング : パート 2

このスライドには、ローカルシステムへの管理アクセスを制御する基本的なファイアウォールフィルタ limit-ssh-access を示しています。このフィルタは、lo0 インタフェースに入力フィルタとして適用され、ルーティングエンジンを宛先とするすべての受信トラフィックを評価します。

limit-ssh-access フィルタには、3 つの明確な条件が定義されています。初の条件 ssh-accept は、 trusted という名前の定義済みプレフィックスリストからの SSH トラフィックを許可します。プレフィックスリスト trusted の内容を次に示します。

[edit policy-options]user@host# show prefix-list trusted { 172.27.102.0/24;}

2 番目の条件 ssh-reject は、プレフィックスリスト trusted 以外からの他の SSH トラフィックをすべて破棄します。 3 番目の条件は、その他の全トラフィックを許可します。このファイアウォールフィルタでは、制御プレーンを宛先とするすべての管理トラフィックとプロトコルトラフィックを対象とする必要があります。スライドの例では、条件 else-accept によりこの要件が達成されます。

条件 else-accept がフィルタに含まれない場合、他の条件で明示的に許可されない制御トラフィックおよび管理トラフィックはすべて破棄されることになります。この動作は、 OSPF や BGP などの動的ルーティングプロトコルや、 SNMPや NTP などの管理プロトコルを使用する環境において、顕著な問題を引き起こすおそれがあります。



ポリシング

ファイアウォールフィルタは、パケットの破棄や許可に加え、トラフィックのポリシング ( レート制限 ) も実行します。レート制限のポリシングにより、インタ

フェースを通過するトラフィック量を制限することができます。レート制限のポリ

シングを実行するファイアウォールフィルタでも、アドレス、プロトコル、ポートなど通常の一致基準を使用して、インタフェース上のトラフィックのうちレート制限の対象となるものを判定します。通常と同様に、 from 句がない場合は、そ

れまでのファイアウォールフィルタの条件に一致しなかった全パケットが合致するとみなされます。ファイアウォールフィルタの初の条件に from 句がなく、ポ

リサーが指定されている場合には、インタフェース ( フィルタの適用によって入

力または出力 ) 上の全パケットがレート制限ポリシングの対象となります。

Junos OS では、特定インタフェースの特定論理ユニットにある特定プロトコル

ファミリーに直接適用するインタフェースベースのポリサーにも対応しています。このようなポリサーは、レイヤー 2 VPN トラフィックや MPLS および IPv6ファミリーを対象とし、ファイアウォールフィルタを呼び出すことなく動作します。サポートされるポリサーは、 Junos OS 搭載デバイス間で異なる可能性があり

ます。サポート情報については、ご使用製品のマニュアルをご確認ください。

ポリシングはトークンバケット・アルゴリズムを採用しており、平均帯域幅に対して制限を適用する一方で、指定した大値までのバーストを許可します。トラ

フィックには、帯域幅制限 ( 平均で許可される毎秒ビット数 )、大バーストサ

イズ ( 指定帯域幅制限を超過するデータのバーストに対して許可される合計バイ

ト数 ) という 2 種類のレート制限を設定することができます。




ポリシング ( 続き )

大バーストサイズの判定で推奨される手法は、インタフェース速度に当該帯域幅で許可するバースト時間を乗算する方法です。例として、ファストイーサネッ

ト・リンクで 5 ミリ秒 ( 妥当値 ) のバーストを許可する場合の計算を次に示しま

す。バーストサイズ = 帯域幅 ( 毎秒 100,000,000 ビット ) ~ 許可するバースト時間 (5/1000 秒 )

この計算により、バーストサイズは 500,000 ビットとなります。この数値を 8で除算してバイト数に変換すると、バーストサイズは 62500 バイトとなります。

帯域幅は、 bandwidth-limit ステートメントにビット数で指定します。大バー

ストサイズは、 burst-size-limit ステートメントにバイト数で指定します。

then 句にポリサーが指定されている条件に一致するパケットがあると、初に、

そのパケットがポリサーを超過しているかどうかがチェックされます。パケット

がポリサーを超過していない場合は、ポリサーが設定されていないものとして、ファイアウォールフィルタの then 句で指定されたアクションが実行されます。パケットがポリサーを超過している場合は、ポリサーの then 句で指定されたア

クションが実行されます。ポリサーの then 句によりパケットが破棄されない場

合は、ファイアウォールフィルタの then 句で指定された残りのアクションが実

行されます。指定のレート制限を超過しており、ポリサーの then 句およびファ

イアウォールフィルタの then 句の両方がアクション修飾子を定義している場合

は、ポリサーのアクション修飾子が使用されます。

例えば、次に示すファイアウォールフィルタは、バーストサイズ 62500 バイト、

10 Mbps を超過するすべての TCP トラフィックのポリシングを行います。これら

の制限を超過するトラフィックはベストエフォート型フォワーディングクラスに分類され、制限範囲内のトラフィックは相対的優先転送 (AF) フォワーディング

クラスに分類されます。

firewall { policer class-example { if-exceeding { bandwidth-limit 10m; burst-size-limit 62500; } then forwarding-class best-effort; } family inet { filter example1 { term policer-example { from { protocol tcp; } then { policer class-example; forwarding-class assured-forwarding; accept; } } } }}



ポリシングの例

このスライドに示す例では、指定平均帯域幅 400 kbps および指定大バースト

サイズ制限 100 KB を超過するトラフィックを破棄するポリサー p1 を定義して

います。ポリサーの定義後は、どのファイアウォールフィルタからでも呼び出す

ことができます。 Junos OS 搭載デバイスは、デフォルトで、ポリサー呼び出しを

個別に処理し、ポリサーを参照する条件の統計情報も個別に追跡します。ポリ

サーの定義は、任意のファイアウォールフィルタの条件で参照できるパラメータセットの定義としてとらえることができます。

ポリサーはフィルタ rate-limit-subnet で呼び出され、指定サブネットから

のトラフィックのポリシングを行います。指定サブネットからのトラフィックが

制限を超過すると、そのトラフィックは破棄されます。トラフィックが制限を超

過しない場合、そのトラフィックは許可されます。

千、百万、十億バイトおよびビットには、それぞれ k、 m、 g の略号を使用する

ことができます。



ケーススタディ : ファイアウォールフィルタ





このスライドには、ファイアウォールフィルタに関するケーススタディの目標とトポロジーが記載されています。



ケーススタディ : 出力フィルタの定義

このスライドには、ケーススタディの目標の一部を達成する出力フィルタの例を示しています。



ケーススタディ : 入力フィルタの定義

このスライドには、ケーススタディの目標の残りを達成する入力フィルタの例を示しています。



ケーススタディ : フィルタの適用

このスライドでは、ファイアウォールフィルタの適用について説明しています。



ケーススタディ : 結果の検証

このスライドでは、フィルタの動作検証に使用される show firewall コマンドの一般的な使用例を示しています。このケーススタディの設定では、アクション修飾子 count および log を使用しています。

カウンターは累積パケット数およびバイト数を示します。カウンターはフィルタごとに管理されるため、複数のフィルタで同一名のカウンターが定義された場合でも、それぞれのカウンターの統計情報は独立して管理されます。デフォルトで、 1 つのフィルタの各カウンターについて保持される統計情報は 1 セットのみであるため、複数インタフェースに同一フィルタが適用されている場合には、そのフィルタを使用するすべてのインタフェースからの全パケットが同一のカウンターで数えられます。カウンターの統計情報にアクセスするには、スライドに示すように、コマンドを使用します。カウンターの統計情報をリセットするには、clear firewall filter filter コマンドを使用します。また、 counter counter 引数を指定して、単一カウンターの統計情報のみをリセットすることもできます。

各フィルタについて、インタフェース別のカウンター統計情報を収集するように設定することもできます。このような設定を行った場合、フィルタが適用される各論理インタフェースごと、方向ごとに、カウンターが新規作成されます。

スライドに示すように、パケットのログを表示するには、 CLI の show firewall log コマンドを使用します。 RE がパケットを処理する場合には、フィルタ名または空白が表示されます。それ以外の場合は、パケットが PFE により処理されたことを示すために、フィルタ名ではなくダッシュ記号 (-) またはpfe が表示されます。ファイアウォールログの内容は、システム再起動時にクリアされます。



ユニキャスト・リバースパス転送のチェック




自動アンチスプーフィング・フィルタ

ユニキャスト・リバースパス転送 (RPF) のチェックでは、トラフィック受信が想定されるシステムで、インタフェースでのパケット受信を検証します。システムにパケット送信元への有効経路があり、パケット送信元への有効経路のネクストホップであるインタフェースでパケットを受信した場合に、デフォルトで、そのシステムは所定インタフェースでのトラフィック受信を想定することになります。

例えば、 Junos OS 搭載デバイスが送信元アドレス 10.10.10.10 のパケットをインタフェース ge-0/0/1.0 で受信し、そのインタフェースでユニキャスト RPFチェック実行が設定されている場合、ルーティングテーブルで 10.10.10.10 への

良経路がチェックされます。このルートのルックアップにより、ネクストホップが ge-0/0/1.0 となる 10.10.10.0/24 への経路が返された場合、パケットはユニキャスト RPF チェックに合格し、許可されます。同一インタフェースに対して、ユニキャスト RPF とファイアウォールフィルタの両方を組合わせて使用することも可能です。

Junos OS は、 PFE に追加情報をダウンロードすることによってユニキャスト RPFチェックを実行するため、このチェック機能を有効にすると、 PFE のメモリ使用量は増加します。

Strict モードと Loose モード

Junos OS 搭載デバイスは、デフォルトで、 strict モードの RPF チェックを実行します。その代替として、ルーティングテーブルに送信元への有効経路が存在することだけを確認する loose モードの RPF チェックを実行するように設定することもできます。ただし、デフォルト経路を持つネットワークでは、各 IP アドレスに必ず有効経路が存在するため、 loose モードのチェックを実行しても意味がありません。一般的には、デフォルトの strict モードの方が有用です。



有効パスと実行可能パス

Junos OS 搭載デバイスが RPF チェックを行う際は、デフォルトで、所定の宛先へ

の有効経路のみを対象とします。完全対称のルーティングが存在するネットワー

クでは、有効経路のみを対象とするこのデフォルト設定で十分に対応できますが、非対称ルーティングが存在する ( 転送パスとリバースパスが異なる ) 可能性

がある場合には、この動作により正常トラフィックが破棄されてしまうおそれがあります。このような問題を低減するために、 RPF チェック時には宛先までの実

行可能経路も対象とするように要求することができます。このモードでは、指定

された宛先プレフィックスまでの非有効経路も含め、受信する全経路が対象となります。非対称ルーティングが存在する可能性があるネットワークでは、必ずこ

のオプションを指定してください。

RPF チェックチェックの実行は、ネットワーク内の全デバイスで有効にする必要

はありません。通常は、すべてのインバウンドおよびアウトバウンドのスプー

フィングが通過するエッジデバイスのみにおいて RPF チェックの実行を設定し

ます。上記のネットワーク例では、 R1( エッジデバイス ) について、 3 つのイン

タフェースすべてで RPF チェックを実行するように設定します。

ユニキャスト RPF の設定オプションは、 Junos OS 搭載デバイス間で異なります。サポート情報の詳細については、ご使用製品のマニュアルをご確認ください。



フェイルフィルタ

Junos OS 搭載デバイスでは、 RPF チェックにフェイルしたパケットをデフォル

トで破棄しますが、フェイルフィルタを指定しておくと、 RPF チェックをフェイ

ルしたパケットが破棄される前に、そのフィルタでパケットを処理することができます。フェイルフィルタでは、 RPF チェックにフェイルしたパケットのトラ

フィックの許可も含め、ファイアウォールフィルタで指定できる全アクション修飾子を実行可能です。 ( ただし、入力ファイアウォールフィルタでパケットをロ

グに記録するように設定している場合、パケットが RPF チェックにフェイルす

ると、そのパケットはログに記録されません。このようなパケットのログ記録

は、 RPF フェイルフィルタで行う必要があります。 )

ほとんどの Junos OS 搭載デバイスでは、 DHCP およびブートストラップ・プロト

コル (BOOTP) リクエストは RPF チェックにフェイルします。これらのリクエスト

を許可するためには、送信元アドレス 0.0.0.0 および宛先アドレス

255.255.255.255 のトラフィックを許可するフェイルフィルタを設定する必要

があります。このスライドでは、 DHCP または BOOTP リクエストを許可するフェ

イルフィルタの定義例を示しています。



RPF 例

このスライドに示す例では、すべてのインタフェースで RPF チェックを strictモードで実行し、すべてのプレフィックスへの有効経路のみを対象とするように設定されています。フェイルフィルタ rpf-dhcp は、インタフェース ge-0/0/2および ge-0/0/3 に適用されます。この設定では、前のスライドで説明したフェ

イルフィルタ rpf-dhcp を定義しており、 DHCP および BOOTP リクエストを許

可します。すべてのインタフェースに対して RPF チェックを有効にしたため、

ファイアウォールフィルタにアンチスプーフィングの条件を含める必要はありません。




• ルーティングポリシーおよびファイアウォールフィルタのフレームワーク

• ポリシーとファイアウォールフィルタの評価

• ルーティングポリシー使用の典型的なシナリオ

• ルーティングポリシーの設定と適用

• ファイアウォールフィルタ使用の典型的なシナリオ

• ファイアウォールフィルタの設定と適用

• ユニキャスト・リバースパス転送



復習問題 :

1.

2.

3.

4.

5.



ラボ 3: ファイアウォールフィルタ






第 4章 : クラス・オブ・サービス (CoS)


本章の内容 :

• クラス・オブ・サービス (CoS) の目的と利点

• CoS で使用されるコンポーネント

• CoS コンポーネントの実装と検証

第 4 章 - 2 • クラス・オブ・サービス (CoS)


CoS 概要



クラス・オブ・サービス (CoS) • 第 4 章 - 3


クラス・オブ・サービス (CoS) の使用

Junos OS 搭載デバイスは、デフォルトで、すべての通過トラフィックを同等に

処理します。 Junos OS はデバイスに到達したトラフィックを先着順に処理しま

す。デバイスはすべての通過トラフィックを区別せず同じ入力 / 出力キューに

割当てるため、通過トラフィックの遅延や破棄の可能性はトラフィック間で同等となります。このメソッドは、ベストエフォート型トラフィック処理と呼ば

れます。

Junos OS 搭載デバイスは CoS 機能を備えており、ベストエフォート型処理では

ネットワークニーズに対応できない場合に、この機能を使用してトラフィックを差別化することができます。 CoS ツールキットは、複数のコンポーネントで構成

されます。まず、同一サービスを提供する各種カテゴリー ( フォワーディングク

ラス ) にトラフィックを分類するツールがあり、次に、各フォワーディングクラ

スのトラフィックを独自の方法で処理するツール、さらに、ネットワーク規模で

パケット分類が理解されるようにパケットにカテゴリー情報をマーキングするツールがあります。

CoS は、トラフィックのカテゴリーに対して低帯域保証、低遅延時間、低パ

ケット損失率を実現することにより、トラフィックの差別化を可能にします。つまり、 CoS の適用により、一部アプリケーションのパフォーマンスを向上させる

ことができます。ただし、 CoS によってリンクの合計帯域幅を増大させたり、光

速により決定される低遅延時間よりもさらに遅延時間を短縮するすることはできません。また、 CoS によりネットワークの輻輳を解消することはできません

が、ネットワークの輻輳が特定トラフィックに及ぼす影響を制御することは可能

です。



要件の達成

CoS の使用により、 Junos OS 搭載デバイスがトラフィックを転送する順序を制

御することができます。リンク容量に余裕のあるネットワークにおいても、回線

上の瞬時コンテンションは発生します。 2 つのパケットが出力インタフェースに

同時に到達した場合、システムは片方のパケットを転送し、もう一方のパケットをキューイングします。通常輻輳のないネットワークではキューの遅延は低限

に保たれますが、遅延時間の影響を受けやすい VoIP などのトラフィックではわ

ずかな遅延でも重大な影響を及ぼしかねません。このような場合、トラフィック

の優先処理を使用することにより、遅延時間の影響を受けやすいトラフィックを他のトラフィックに優先して転送することができます。この優先処理では、すべ

ての帯域保証の達成後に、さらに利用可能な予備帯域の割り当ても制御します。

多くの Junos OS 搭載デバイスは、輻輳を回避するためにランダム初期検知 (RED)アルゴリズムを使用します。 RED アルゴリズムでは、輻輳による支障が生じる前

に選択的にランダムパケットを破棄します。この処理で影響を受けた TCP セッ

ションはスロースタートモードに入り、クライアントが輻輳リンクで送信を試みるトラフィック量は低減されることになります。このアルゴリズムの使用により、

低帯域ストリーム ( ほとんどの対話型セッションなど ) と比較して、高帯域データ

ストリームの方がより大きな影響を受けます。

また、 Junos OS 搭載デバイスでは、トラフィック・クラスに対して一定帯域幅

を保証するように設定して、輻輳時でも低帯域保証を確保できるようにするこ

とも可能です。このようにして、各リンクにおいて、特定タイプのトラフィック

に対して低帯域保証を確保することができます。



フォワーディングクラス

フォワーディングクラスは、 Junos OS 搭載デバイスで使用される、共通処理を

必要とするトラフィックを識別するための抽象概念です。トラフィックは、分類

処理において、特定のフォワーディングクラスに関連付けられます。出力時に

は、フォワーディングクラスに基づいて、トラフィックが特定の出力キューに割り当てられ、動作集約マーカーが書換えられます。

通常、フォワーディングクラスと出力キューの間には 1 対 1 の関係が存在する

ため、フォワーディングクラスを出力キューと同一視しがちですが、一部プラッ

トフォームではサポートするフォワーディングクラス数がキューよりも多い場合もあるため、このような見方は厳密には誤りであり、混乱をまねくおそれがあり

ます。



損失優先度

パケットに損失優先度を関連付けることにより、輻輳時のパケット破棄優先度を設定することができます。 RED を適用する場合は、異なる損失優先度に対して異

なる破棄率を設定することができます。このような RED 設定は、このコースの

学習対象外であるため、ここでは説明していません。



CoS 処理

スライドの図は、 Junos OS における CoS 処理の概要を示すものです。矢印は、情

報の流れを表します。つまり、プロセスがフォワーディングクラスや損失優先度

を設定する場合は、フォワーディングクラスおよび損失優先度のボックスの方向( 図の中心方向 ) を指す矢印で表されます。また、プロセスがフォワーディング

クラスや損失優先度を入力値として使用する場合は、フォワーディングクラスおよび損失優先度のボックスを始点とする矢印で表されます。

Junos OS 搭載デバイスでは、 DiffServ コードポイント (DSCP)、 IP 優先度、 MPLS EXP、 IEEE 802.1p などのヘッダーフィールド値に基づいて、パケットのフォ

ワーディングクラスや損失優先度を設定することができます。これらのフィール

ドは通常エッジデバイスによって設定され、トラフィックの分類を示します。そのため、コアデバイスがエッジデバイスから受け取ったトラフィックを再分類する必要はありません。これらのフィールドは、パケットが属するトラフィック分

類を示すため、動作集約 (BA) クラシファイアと呼ばれています。

Junos OS 搭載デバイスでは、フォワーディングクラスと損失優先度を入力および

出力のマルチフィールド・クラシファイアで設定することもできます。マルチ

フィールド・クラシファイアは、ファイアウォールフィルタを使用して実装します。マルチフィールド・クラシファイアの使用により、ファイアウォールフィルタ

の選択基準を使用してパケットを選択したり、 then 句でフォワーディングクラス

や損失優先度を設定することができます。また、入力ポリサーおよび出力ポリサー

を使用してフォワーディングクラスや損失優先度を変更することもできます。




CoS 処理 ( 続き )

CoS ベースの転送の実装には、フォワーディングポリシーの各種オプションを使

用できます。 1 つの宛先に対して複数の等価コストパスが存在する場合、 CoSベースの転送を使用して、各等価コストパスがどのトラフィッククラスを使用するかを指定することができます。また、フォワーディングポリシーのオプション

を使用して、特定プレフィックスを宛先とするパケットのフォワーディングクラスや損失優先度をリセットすることもできます。

Junos OS 搭載デバイスでは、キューへのトラフィック割当て、 RED アルゴリズ

ムの実装、 BA ヘッダーの書換えに、出力のフォワーディングクラスおよび損失

優先度を使用します。

CoS に関するサポートは、 Junos OS 搭載プラットフォーム間で異なります。サポート情報の詳細については、ご使用プラットフォームのマニュアルをご確認ください。



トラフィック分類




CoS 配備モデル

CoS の配備モデルには、基本的に 2 種類あります。単一デバイスにおける転送

サービスを差別化するためのみに CoS を使用するモデルと、ネットワーク規模で

複数デバイスにおける転送サービスを差別化するために CoS を使用するモデル

です。

単一デバイス限定で CoS を使用する場合には、パケットは通過時にマルチ

フィールド・クラシファイアを使用して分類され、この分類に基づいて、設定されたサービスが提供されます。パケット転送時の BA マーキング (DSCP、 IP 優先

度など ) は行われません。一方、複数デバイスにわたって CoS を使用する場合に

は、異なる分類方法が使用されます。

ネットワーク内の複数デバイスで CoS を使用してサービスの差別化を行う場合、

エッジデバイスで初に分類を実行し、 BA を使用して分類をネットワーク内で

転送するのが効果的です。このモデルでは、トラフィックがネットワークに到達

した際にエッジデバイスがマルチフィールド・クラシファイアを使用してトラフィックを分類します。エッジデバイスがパケットをネットワークに転送する際

に、パケットには BA マーキングが行われます。ネットワーク内の他のデバイス

は BA を読込み、マルチフィールド・クラシファイアを使用せずに適切なフォ

ワーディングクラスと損失優先度を自動的に設定します。




CoS 配備モデル ( 続き )

ネットワーク規模の CoS 配備での BA 使用には、複数の利点があります。まず、

ネットワーク規模でトラフィックに対して一貫性のある CoS 処理が保証される

点が挙げられます。また、各システムで正確なマルチフィールド・クラシファイ

アを作成および管理する作業が簡素化されるという点もあります。 BA を使用し

ない場合、各デバイスではネットワークに到達するすべてのトラフィックを分類するマルチフィールド・クラシファイアが必要になります。また、 1 つのデバイ

スで分類変更が行われた場合には、他デバイスにも個別に適用する必要があります。 3 点目として、イーサネットの場合には、 802.1p ビットを BA として設定す

ることで、 CoS を認識するイーサネットのスイッチでもトラフィックに対して差

別化したサービスを提供できることが挙げられます。

レイヤー 3 ヘッダーの既存ビットを立てることでパケットの BA マーキングが行

われるため、付加的な作業は発生しません。



マルチフィールド・クラシファイア

マルチフィールド・クラシファイアの設定は、通常のファイアウォールフィルタの設定と同様に行うことができ、各条件の then 句でフォワーディングクラスと

損失優先度を指定します。デフォルトでは、フォワーディングクラス (BA クラシ

ファイアにより割当てられたフォワーディングクラス、パケットが BA クラシ

ファイアにより分類されない場合にはデフォルトのフォワーディングクラス ) は

変更されません。

Junos OS 搭載デバイスは、 BA クラシファイアの後にマルチフィールド・クラシ

ファイアを適用するため、マルチフィールド・クラシファイアは常に BA が割当

てたフォワーディングクラスと損失優先度を上書きします。



動作集約

Junos OS 搭載デバイスでは、アウトバウンドのインタフェースに書換え規則を

適用することにより、インタフェースからの送出パケットに BA マーカーを付加

するように設定することができます。デフォルトで、 Junos OS はパケット送信

時にレイヤー 3 の BA ヘッダーフィールドを変更しません。したがって、これら

のフィールドの設定は、通常エッジデバイスにおける 1 回だけで済みます。ただ

し、レイヤー 2 フィールド (MPLS EXP や IEEE 802.1p など ) は保持されないた

め、パケットが通過するインタフェースでレイヤー 2 の BA ヘッダーフィールド

を再設定するように設定する必要があります。

書換え規則は、 [edit class-of-service interfaces] 階層で適用されま

す。例えば、デフォルトの IP 優先度マーキングを適用するためには、 set interface-name unit logical-unit-number rewrite-rules

inet-precedence default と入力します。書換え規則は、レイヤー 2 とレイ

ヤー 3 の両方に適用できますが、 IP 優先度と DSCP 規則は IP ヘッダーの同一

ビットを使用するため、 1 つのパケットに対してこれらを同時に適用することは

できません。




動作集約 ( 続き )

パケットに BA マーキングが付加されたら、ダウンストリームのデバイスがこれ

らの情報を読込み、パケットに適切なフォワーディングクラスと損失優先度を自動的に割当てるように設定することができます。この処理を開始するには、 BAクラシファイアをインバウンドのインタフェースに適用します。この操作は

[edit class-of-service interfaces] 階層で行います。例えば、デフォル

トの IP 優先度の BA クラシファイアを適用するためには、 set interface-name unit logical-unit-number classifiers

inet-precedence default と入力します。 BA クラシファイアは、レイヤー 2とレイヤー 3 の両方に適用できますが、多くの場合、プラットフォーム固有の

制限により組合わせ可能なクラシファイアが決定されます。詳細については、

『Junos Class of Service Configuration Guide (Junos クラス・オブ・サービス設定ガ

イド )』をご参照ください。

デフォルト BA クラシファイアと書換え規則を使用することにより、確実に、

キュー 0 ～ 3 からのトラフィックがネットワーク全体で該当フォワーディング

クラスに正しく分類されます。常にネットワーク全体でトラフィックをキュー 0～ 3 以上に割当てる場合や、 CoS ヘッダーフィールドにデフォルト外のビット

パターンを使用する場合には、カスタムのクラシファイアや書換え規則を使用する必要があります。カスタムのクラシファイアや書換え規則を使用する場合は、

分類の一貫性を保つため、これらのクラシファイアや規則を必ずネットワーク内の全デバイスに適用してください。



ポリサー

ポリサーは、特定の種類のトラフィックを指定の帯域幅やバーストサイズに限定

することを可能にします。 Junos OS 搭載デバイスでは、設定されている制限を超

過するトラフィックに対して異なるフォワーディングクラスや損失優先度を割当てるように設定することができます。このようなポリサーの設定では、通常のト

ラフィックポリサーの場合と同様に、ポリサーの then 句に

forwarding-class および loss-priority ステートメントを記述します。ポリサーの forwarding-class および loss-priority ステートメントは、

ファイアウォールフィルタの then 句で指定した forwarding-class および

loss-priority ステートメントよりも優先されます。

例えば、スライドに示すポリサーは、指定レート制限の範囲内のトラフィックに

は expedited-forwarding フォワーディングクラス、この指定レート制限を

超過するトラフィックには best-effort フォワーディングクラスを割当てて

います。なお、スライドには含まれていませんが、トラフィック分類が正しく機

能するためには、適切なインタフェースに対して apply-cos-markings ファ

イアウォールフィルタを割当てる必要があります。

Junos OS 搭載プラットフォームによっては、ポリサーアクションの一部のみを

サポートしている場合があるため、ご注意ください。サポート情報の詳細につい

ては、ご使用製品の新版マニュアルをご確認ください。



トラフィックキューイング




キューイングの概要

トラフィックがアウトバウンドのインタフェースに到達すると、各フォワーディングクラスに関連付けられているトラフィックはそれぞれのキューに割当てられます。アウトバウンドのインタフェースでサポートされるキュー数はハードウェ

アに依存します。

Junos OS 搭載デバイスでは、各フォワーディングクラスに一意のキュー番号を関

連付けます。このスライドには、多くの Junos OS 搭載デバイスでのデフォルト

のフォワーディングクラスと、それに関連付けられているキュー番号を示しています。 Junos OS は、デフォルトで、特定のネットワーク制御トラフィック ( ルー

ティングプロトコル・メッセージ、 keepalive など ) を network-control フォワー

ディングクラスに関連付けられているキュー ( 通常はキュー 3) に割当て、他の

トラフィックはすべて best-effort フォワーディングクラスに関連付けられている

キュー ( 通常はキュー 0) に割当てます。その他のキューにトラフィックを送信す

るためには、明示的なクラシファイアの指定が必要です。

トラフィックが適切なキューに割当てられた後、スケジューラにより、インタフェースが各キュー上のトラフィックをどのように処理するかを決定します。



フォワーディングクラスの定義

フォワーディングクラスは、クラスを [edit class-of-service

forwarding-classes]階層のキューに関連付けることによって作成されます。ハードウェアで対応可能なキュー数を越えてフォワーディングクラスを作成しようとすると、設定コミット時にエラーメッセージが表示されます。キューを使用

するためには、フォワーディングクラス名をキューに関連付ける必要があります。 Junos OS を搭載する多くのプラットフォームでは、デフォルトのフォワー

ディングクラス名はキュー 0 ～ 3 と関連付けられます。

スライドに示すように、デフォルトのフォワーディングクラス名は変更可能です。デフォルトのフォワーディングクラス名を変更しても、 Junos OS は当該クラ

スに対応するキューにトラフィックを送信します。また、デフォルトの BA クラ

シファイアと書換え規則は、キューに関連付けられたフォワーディングクラス名に関係なく、トラフィックを関連キュー ( 通常はキュー 0 ～ 3) にマップします。デフォルトのフォワーディングクラス名の変更に加え、フォワーディングクラス名を非デフォルトのキューに割当てることもできます。

その他の CoS 規則は、キューではなくフォワーディングクラスを参照するため、

フォワーディングクラスは重要です。フォワーディングクラス名とキュー番号の

対応は、 [edit class-of-service forwarding-classes] 階層のフォ

ワーディングクラス定義でのみ保持されます。



トラフィックのスケジューリング




スケジューリングの概要

スケジューラとスケジューラマップの設定により、システムのキュー処理を制御することができます。スケジューラには、キューの処理方法を記述するパラメー

タ群が含まれており、スケジューラは、スケジューラマップを通じて、特定の

キューとフォワーディングクラスに関連付けられます。

パケットの転送順序は、フォワーディングクラスに優先度や転送速度を定義することで決定します。 Junos OS 搭載デバイスは通常、優先度の高い順にフォワー

ディングクラスやキューからパケットを取り出して送信します。デフォルトの優

先度の値は、 Junos OS 搭載デバイス間で異なります。

各フォワーディングクラスに転送速度を設定することで、当該フォワーディング

クラスに関連付けられているトラフィックが使用する帯域幅を制御することができます。デフォルトでは、 best-effort フォワーディングクラスに関連付けられて

いるキュー ( 通常はキュー 0) には帯域幅の 95 パーセント、 network-control フォ

ワーディングクラスに関連付けられているキュー ( 通常はキュー 3) には帯域幅

の 5 パーセントが割当てられます。その他のキューに割当てられる転送速度は 0です。一部キューが割当ての転送速度を使い切っていない場合には、転送速度が

exact オプションで指定されていない限り、残るキューが割当ての転送速度を超

過して使用することができます ( デフォルト )。




スケジューリングの概要 ( 続き )

各キューのサイズは、設定されているバッファサイズにより決定されます。デフォルトでは、 best-effort フォワーディングクラスに関連付けられているキュー

( 通常はキュー 0) には使用可能なバッファ領域の 95 パーセント、

network-control フォワーディングクラスに関連付けられているキュー ( 通常は

キュー 3) には使用可能なバッファ領域の 5 パーセントが割当てられます。デフォルトで、その他のキューにはバッファ領域は割当てられません (0 パーセン

ト )。したがって、 best-effort および network-control の各フォワーディングクラ

スに関連付けられているキュー以外を使用する場合には、それらのキューにバッファを割当てる必要があります。バッファの使用率が高くなると、 RED アルゴリ

ズムがパケットを破棄する確率が増加します。各キューに対して正確な RED 破

棄プロファイルを設定することは可能ですが、デフォルト設定では、キューの領域が完全に消費されるまでパケットは破棄されません。 Junos OS を搭載するプ

ラットフォームには、 RED をサポートしないものもあるため、ご注意ください。 CoS に関するサポート情報の詳細については、ご使用製品のマニュアルをご確認

ください。



キューの優先度

Junos OS は、低、中度低、中度高、高、高の 5 つのレベルの転送優先度をサ

ポートしています。この優先度構造により、 Junos OS は高い優先度のキューを

低い優先度のキューよりも先に処理します。優先度別スケジューリングによって

出力インタフェースがキューからトラフィックを取り出して送信する順番が決定されるため、重要なトラフィックを含むキューが確実に出力インタフェースに対して高いアクセス権を持てるようになっています。この処理において、 Junos OSはキューの優先度を確認し、各キューが指定の帯域幅プロファイルの範囲内であ

るかどうかを判定します。

優先度の高いキューは、そのフォワーディングクラスが十分な帯域を持つ限り、優先度の低いキューよりも先にパケットを送信します。高い優先度を持つキュー

に極めて大きい転送帯域を割り当てた場合、低い優先度のトラフィックがロックアウトされる場合があります。優先度キューイングの動作は、厳密にはプラット

フォームによって異なります。プラットフォーム固有の詳細および動作について

は、ご使用製品のマニュアルをご参照ください。

定義済みの帯域幅プロファイル設定例について、次のページで説明します。



スケジューラの設定

スケジューラは、 [edit class-of-service interfaces] 階層で設定しま

す。この場合、スケジューラの名前は特に重要ではありません。 Junos OS は、ス

ケジューラマップを使用して、スケジューラと個々のフォワーディングクラスおよびキューを関連付けます。このスライドの例は、 best-effort フォワーディング

クラスのトラフィック用のスケジューラであるため、その目的に併せてスケジューラに sched-best-effort という名前を付けていますが、別の名前を付

けたとしても、スケジューラマップで best-effort フォワーディングクラスに関連

付けることができます。

この例では、バッファサイズを転送速度と同じ値に設定しています。多くの場合

は、この設定で良好に機能しますが、異なるバッファサイズを設定した方が適切である場合もあります。詳細については、『Junos Class of Service Configuration Guide (Junos クラス・オブ・サービス設定ガイド )』をご参照ください。

また、この例では、カスタム破棄プロファイルを設定していません。多くの場合

は、デフォルトの破棄プロファイルで十分に対応できます。カスタム破棄プロ

ファイル作成による RED パラメータの調整は、きわめて複雑ですが、この点に

ついては、『Junos Class of Service Configuration Guide (Junos クラス・オブ・サー

ビス設定ガイド )』で詳述されています。



スケジューラマップの作成

スケジューラマップは、スケジューラとフォワーディングクラス、対応するキューを関連付けます。 Junos OS は、関連付けられているフォワーディングクラ

スの名前を使用してキューを参照します。スケジュラーマップは、 [edit

class-of-service scheduler-maps] 階層で設定します。

このスライドの例では、 4 つのスケジューラを 4 つのデフォルトキューに関連付

けています。



インタフェースへのスケジューラマップの適用

Junos OS 搭載デバイスにおけるキュー処理の設定での後の手順は、スケジュー

ラマップをアウトバウンドのインタフェースに関連付けることです。パケットが

出力インタフェースに到達すると、そのパケットはトラフィックのフォワーディングクラスに関連するキューに割当てられます。所定のキューに関連付けられて

いるスケジューラに設定されているパラメータを参照することにより、キューからパケットを転送する順番が決定されます。システムは、スケジューラマップに

より、どのスケジューラが特定インタフェースのどのキューに関連付けられているかを理解します。異なるインタフェースに対して異なるスケジューラマップを

使用することにより、キューに関連付けられるスケジューリング・パラメータをインタフェースごとに指定することができます。

スケジューラは、 [edit interfaces] 階層でインタフェースに per-unit-

scheduler を設定しない限り、物理インタフェースの全トラフィックに適用され

ます。この場合、パケットはユニット単位でスケジュールされます。また、各ユ

ニットに異なるスケジューラマップを定義することもできます。ユニット単位のス

ケジューラのサポートは、 Junos OS 搭載プラットフォーム間で異なります。



CoS 処理のまとめ

このスライドの図は、本章の初の方で紹介したものと同じです。これまでに学

習した CoS の概念の復習として、ここでもう一度各コンポーネントとネット

ワークにおけるその動作を確認しましょう。



ケーススタディ : CoS




目標とトポロジー

このスライドの例は、ネットワーク規模で CoS を適用する比較的単純なトポロ

ジーを示しています。ここには、トラフィック分類やスケジューリング規則、

フォワーディングクラスとキューのマッピングについて記載されています。

わかりやすくするために、全インタフェースの全トラフィックに同じスケジューリング規則を適用するとします。トラフィックがキュー 0 またはキュー 3 以外の

キューに関連付けられている場合には、そのキューのスケジューラをすべてのインタフェースで設定しなければならない点に注意する必要があります。この設定

を怠ると、スケジューラが指定されていないキューを通じてインタフェースからトラフィックが送信されることになり、ネットワーク性能に重大な支障をきたすおそれがあります。

CoS に関するサポートは、 Junos OS 搭載プラットフォーム間で異なります。この

例での R1 および R2 は、 J シリーズのルーターです。



R1 入力マルチフィールド・クラシファイア設定

このスライドには、 R1 に指定の分類規則を適用する場合に必要な設定を示して

います。



R2 入力マルチフィールド・クラシファイア設定

このスライドには、 R2 に指定の分類規則を適用する場合に必要な設定を示して

います。



フォワーディングクラスとスケジューラの設定

このスライドには、両ルーターのフォワーディングクラス、スケジューラ、スケジューラマップ設定を示しています。



BA とスケジューラの適用

このスライドには、両ルーターの BA クラシファイア、書換え規則、スケジュー

ラマップの設定を示しています。



結果の検証 : パート 1

show class-of-service interface interface コマンドで、インタ

フェースのほとんどの CoS 設定を簡単に表示することができます。このコマンド

出力には、デフォルト値をはじめとする有効設定が表示されています。また、

CoS 設定の各種コンポーネントの詳細を表示するには、他の show

class-of-service コマンドを使用します。例えば、ipprec-default クラシ

ファイアによる IP ヘッダー中の type-of-service フィールドとフォワーディングク

ラス間のマップを表示するには、 show class-of-service classifier

name ipprec-default コマンドを実行します。

CoS 設定が意図通りに機能しているかどうかは、トラフィックが適切な送信

キューに割り当てられているかどうかでチェックできます。ほとんどのインタ

フェースでは、各キュー統計サマリーは show interfaces detail および

show interfaces extensive コマンドで表示されます。一部のカプセル化タ

イプでは、このコマンドで統計情報を表示できない場合があります。



結果の検証 : パート 2

show interfaces queue コマンドで、トラフィックのキューイング状態を表

示することができます。このコマンドは、各キューに関するさらに詳細な統計情

報を表示するもので、すべてのインタフェースで使用できます。このスライドと

前ページのスライドに示した内容から、トラフィックが正しくキューイングされていることが確認できます。




• CoS の目的と利点

• CoS で使用されるコンポーネント

• CoS コンポーネントの実装と検証



復習問題

1.

2.

3.

4.



ラボ 4: クラス・オブ・サービス (CoS)



付録 A: 略語リスト

ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . アクセス・コントロール・リスト (access control list)AS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .自律システム (autonomous system)BA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .動作集約 (behavior aggregate)BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ブートストラップ・プロトコル (Bootstrap Protocol)CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . クラス・オブ・サービス (class of service)DSCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .DiffServ コードポイント (DiffServ code point)EGP . . .外部ゲートウェイプロトコル、自律システム間ルーティングプロトコル (exterior gateway protocol)FBF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . フィルタベース転送 (filter-based forwarding)HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ハイパーテキスト転送プロトコル (Hypertext Transfer Protocol)ICMP . . . . . . . . . . . . . . . . . . . . インターネット制御メッセージプロトコル (Internet Control Message Protocol)IGP . . . . 内部ゲートウェイプロトコル、自律システム内ルーティングプロトコル (interior gateway protocol)JNTCP. . . . . . . ジュニパーネットワークス技術認定資格プログラム (Juniper Networks Technical Certification Program)JTAC . . . . . . . . . ジュニパーネットワークス技術支援センター (Juniper Networks Technical Assistance Center)LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . リンクステート広告 (link-state advertisement)PFE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . パケット転送エンジン (Packet Forwarding Engine)RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ルーティングエンジン (Routing Engine)RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ランダム初期検知 (random early detection)rpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ルーティング・プロトコル・プロセス (routing protocol process)RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . リバースパス転送 (reverse path forwarding)SPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 短パス優先、ショーテスト・パス・ファースト (shortest path first)VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ボイス・オーバー・インターネット・プロトコル (voice over IP)

略語リスト • A - 1

A - 2 • 略語リスト

付録 B: 解答例と解説

第 1 章 : コースの紹介この章には、復習問題はありません。

第 2 章 : ルーティングの基礎

1.

この章で説明したように、 2 つのリモートデバイス間のトラフィックをルーティングするにあたっての主な考慮点は、エンドツーエンドの通信パスと、通信パス上の全レイヤー 3 デバイスが必要なルーティング情報を持つことの 2 点です。

2.

デフォルトの IPv4 および IPv6 ユニキャスト・ルーティングテーブルは、それぞれinet.0 と inet6.0 です。

3.

ルーティングテーブル内で有効経路を決定するための一次基準は、ルートプリファレンス値です。プリファレンス値の小さい経路の方が、プリファレンス値の大きい経路よりも優先されます。

4.

CLI の qualified-next-hop オプションを使用すると、同一宛先に対して存在する複数の静的経路に、個別のプリファレンス値を設定することができます。

5.

動的ルーティングの利点として、管理オーバーヘッドが低い、ネットワーク可用性およびスケーラビリティに優れている点が挙げられます。

第 3 章 : ルーティングポリシーとファイアウォールフィルタ

1.

ルーティングポリシーは、ルーティングテーブル内のルーティング情報を制御するために使用され、動的プロトコルで送受信される経路やフォワーディングテーブルに格納されている経路の許可、拒否、属性変更を行います。

2.

ルーティングポリシーとファイアウォールフィルタはどちらも、 from および then ステートメントで構成される条件を使用します。 from ステートメントは、定義されたアクションを実行するために合致しなければならない一致基準を記述します。 then ステートメントは、パケットまたは経路が指定の一致基準を満たした場合に実行されるアクションを定義します。then ステートメントは、パケットまたは経路が指定の一致基準を満たした場合に実行されるアクションを定義します。

3.

ポリシーやフィルタを実装する際の 2 つの主要な手順は、定義と適用です。まず初に、ポリシーやフィルターを適切な階層レベルで定義します。ポリシーまたはフィルターの定義が完了したら、それを適用します。

解答例と解説 • B - 1

4.

ファイアウォールフィルタで明示的に許可されないパケットに対するデフォルトのアクションは、 discard です。

5.

ユニキャスト RPF は、 Junos OS 搭載デバイスでアンチスプーフィングを自動化します。

第 4 章 : クラス・オブ・サービス (CoS)1.

CoS は、 VoIP など遅延の影響を受けるトラフィックの優先、 SLA 保証のための輻輳制御、各種トラフィッククラスに応じた異なる帯域幅の割当てなどの方法によってネットワークの性能要件を達成します。

2.

ファイアウォールフィルタにマルチフィールド・クラシファイアを実装することにより、トラフィックをファイアウォールフィルタの一致基準に基づいて分類することができます。動作集約クラシファイアは、パケットヘッダーの動作集約マーキングに基づいてトラフィックを分類します。通常、マルチフィールド・クラシファイアは、ネットワークエッジで初にトラフィックを分類するために使用されます。動作集約マーキングは、ネットワーク内で分類情報を保持するために使用されます。

3.

Junos OS がトラフィックを処理する際、トラフィックは特定のフォワーディングクラスに分類されます。トラフィックが出力インタフェースに到達すると、そのトラフィックはフォワーディングクラスに基づいて適切なキューに割当てられます。一部ハードウェアでは、フォワーディングクラスとキュー間で多対 1 の関係が存在する場合があります。したがって、この 2 つの概念を明確に区別することは重要です。

4.

スケジューラは、キュー処理に使用する CoS パラメータを定義します。スケジューラマップは、これらのパラメータを特定のキューと関連付けるものです。 Junos OS 搭載デバイスでは、特定インタフェースやユニットでスケジューラマップを使用するように設定することができます。

B - 2 • 解答例と解説

Documents

Junos ルーティングの基本 - juniper.net · 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA +1-408-745-2000 Worldwide Education Services Junos ルーティングの基本