[要約] RFC 8522は、ネットワークデバイスのリモート管理をサポートするためのLooking Glassコマンドセットを定義しています。このRFCの目的は、ネットワーク管理者がネットワークデバイスの状態を確認し、トラブルシューティングを行うための標準化された方法を提供することです。
Independent Submission M. Stubbig
Request for Comments: 8522 Independent
Category: Informational February 2019
ISSN: 2070-1721
Looking Glass Command Set
ルッキンググラスコマンドセット
Abstract
概要
This document introduces a command set standard to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.
このドキュメントでは、Webベースの「Network Looking Glass」ソフトウェアに標準のコマンドセットを紹介します。その目的は、Looking Glassサービスへの均一なアクセスをアプリケーションプログラマーに提供し、標準化された応答を分析することです。
The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.
インターフェースは、ウェブベースのインターフェースと同じレベルの情報を提供することになっていますが、コンピューターが読み取り可能な形式です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8522.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8522で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Method Parameters . . . . . . . . . . . . . . . . . . . . 4
2.2. Query Parameters . . . . . . . . . . . . . . . . . . . . 5
2.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Diagnostic Commands . . . . . . . . . . . . . . . . . . . 9
3.2. Informational Commands . . . . . . . . . . . . . . . . . 10
3.3. Organizational Commands . . . . . . . . . . . . . . . . . 14
3.4. Extensible Commands . . . . . . . . . . . . . . . . . . . 16
4. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Abuse Potential . . . . . . . . . . . . . . . . . . . . . 17
6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 17
6.3. Minimal Information . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. JSend . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
Many Internet service providers (ISPs) and Internet exchange points (IXPs) offer a complimentary web-based service to their customers and the general public that gives insights to the backbone routing table, BGP neighbor information, or offered routes. This service is known as a "Network Looking Glass". Because they utilize a web-based interface, it is hard to automate access to the services and make that automation transferable between different service implementations.
多くのインターネットサービスプロバイダー（ISP）とインターネットエクスチェンジポイント（IXP）は、バックボーンルーティングテーブル、BGPネイバー情報、または提供されたルートに関する洞察を提供する無料のWebベースのサービスを顧客と一般の人々に提供しています。このサービスは「ネットワーク・ルッキング・グラス」として知られています。それらはWebベースのインターフェースを利用するため、サービスへのアクセスを自動化し、その自動化を異なるサービス実装間で転送可能にすることは困難です。
This document describes a common command set to provide application programmers uniform access to Looking Glass services.
このドキュメントでは、アプリケーションプログラマーがLooking Glassサービスに均一にアクセスできるようにするための一般的なコマンドセットについて説明します。
The commands are intended to provide the same level of information as available via web-based interfaces, but to do so in a computer-readable format. The intention is that multiple implementers of Looking Glass services can provide access through these commands so that an application can make use of the different implementations.
コマンドは、Webベースのインターフェースを介して利用できるのと同じレベルの情報を提供することを目的としていますが、コンピューターが読み取り可能な形式で提供します。その目的は、Looking Glassサービスの複数の実装者がこれらのコマンドを介してアクセスを提供し、アプリケーションが異なる実装を利用できるようにすることです。
The command set is split into the following categories: mandatory to support, optional, and additional. The commands are extensible for new features and for value-add by implementations.
コマンドセットは、サポートに必須、オプション、および追加のカテゴリに分類されます。コマンドは、新機能および実装による付加価値のために拡張可能です。
The Looking Glass command set is described as a language-independent concept. Consequently, any programming language that satisfies the commands listed in the following sections is acceptable.
ルッキンググラスのコマンドセットは、言語に依存しない概念として説明されています。したがって、以下のセクションにリストされているコマンドを満足するプログラミング言語はすべて受け入れられます。
This work is not the output of the IETF and is presented in the hope that Looking Glass implementers will offer a common programmable interface.
この作品はIETFの出力ではなく、Looking Glassの実装者が共通のプログラマブルインターフェイスを提供することを期待して提示されています。
The requirement of a uniform access to a Looking Glass service becomes important when multiple Looking Glasses are part of a monitoring system. Implementing a web client and HTTP parser for every kind of web-based Looking Glass is a time-consuming workaround. However, the Looking Glass command set is a much more viable, compatible, and scalable solution.
複数のLooking Glassが監視システムの一部である場合、Looking Glassサービスへの均一なアクセスの要件が重要になります。あらゆる種類のWebベースのLooking GlassにWebクライアントとHTTPパーサーを実装することは、時間のかかる回避策です。ただし、Looking Glassコマンドセットは、実行可能性が高く、互換性があり、スケーラブルなソリューションです。
This specification uses the JavaScript Object Notation (JSON) of [RFC8259] arranged as JSend-compliant (Appendix A) responses.
この仕様では、[RFC8259]のJavaScript Object Notation（JSON）を、JSend準拠（付録A）の応答として配置して使用します。
All URLs in this documentation use the reserved sample domain of "example.net" as defined in Section 6.5 of [RFC6761].
このドキュメントのすべてのURLは、[RFC6761]のセクション6.5で定義されている「example.net」の予約済みサンプルドメインを使用しています。
The URLs further use the fixed [RFC5785] prefix of ".well-known/ looking-glass" to prevent a collision in the domain's namespace.
URLはさらに、「。well-known / looking-glass」の固定[RFC5785]プレフィックスを使用して、ドメインのネームスペースでの衝突を防止します。
IPv4 addresses use the documentation block of 192.0.2.0/24 [RFC5737] and IPv6 addresses reside in the reserved prefix of 2001:DB8::/32 [RFC3849]. BGP Autonomous System (AS) numbers are chosen from the private AS range defined in [RFC6996].
IPv4アドレスは192.0.2.0/24 [RFC5737]のドキュメントブロックを使用し、IPv6アドレスは2001：DB8 :: / 32 [RFC3849]の予約済みプレフィックスに存在します。 BGP自律システム（AS）番号は、[RFC6996]で定義されているプライベートAS範囲から選択されます。
The examples skip some required parameters for reasons of simplicity.
簡単にするために、例では一部の必須パラメータをスキップしています。
A client issues a query using the HTTP GET method to request specific resources from the server. The resource is a URI and can be informational or a command execution. The client must present all necessary parameters for the server to execute the command on the selected router. Every call is stateless and independent of the previous one.
クライアントは、HTTP GETメソッドを使用してクエリを発行し、サーバーから特定のリソースを要求します。リソースはURIであり、情報提供またはコマンドの実行が可能です。クライアントは、サーバーが選択されたルーターでコマンドを実行するために必要なすべてのパラメーターを提示する必要があります。すべての呼び出しはステートレスで、前の呼び出しから独立しています。
The path component of the resource URI must use the prefix of ".well-known/looking-glass" (see Section 5.1) to stay namespace neutral.
リソースURIのパスコンポーネントは、プレフィックス「.well-known / looking-glass」（セクション5.1を参照）を使用して、名前空間をニュートラルに保つ必要があります。
The "call" is a request from the client that specifies a predefined operation ("function") that the server will execute on a selected router. The "command" is a task executed on the router and initiated by the server on behalf of the client. The type and scope of all commands are defined and limited by the server. The client must not be able to execute random commands on the targeting router. There must not be any direct communication between the client and the router.
「呼び出し」は、サーバーが選択されたルーターで実行する定義済みの操作（「関数」）を指定するクライアントからの要求です。 「コマンド」は、ルーター上で実行され、クライアントに代わってサーバーによって開始されるタスクです。すべてのコマンドのタイプとスコープは、サーバーによって定義および制限されます。クライアントは、ターゲットルータでランダムなコマンドを実行できないようにする必要があります。クライアントとルーターの間に直接通信があってはなりません。
After the execution of the command on the selected router has finished, the server replies to the client if the operation has either succeeded, failed, or timed out. The response is sent to the client in JSON format. The communication protocol used between the server and router is not specified by this document; any method (e.g., Telnet, SSH, NETCONF, serial console) is acceptable.
選択したルーターでのコマンドの実行が終了した後、サーバーは、操作が成功したか、失敗したか、タイムアウトしたかをクライアントに応答します。応答はJSON形式でクライアントに送信されます。サーバーとルーターの間で使用される通信プロトコルは、このドキュメントでは指定されていません。任意の方法（Telnet、SSH、NETCONF、シリアルコンソールなど）を使用できます。
All parameters and their values are case insensitive.
すべてのパラメータとその値は大文字と小文字を区別しません。
Method parameters are mandatory components of the URI and are placed in the "path" section in terms of [RFC7320]. Basically, the method parameters specify the call and determine which command the client wants to be executed on the selected router.
メソッドパラメータはURIの必須コンポーネントであり、[RFC7320]の観点から「パス」セクションに配置されます。基本的に、メソッドパラメータは呼び出しを指定し、選択したルータでクライアントが実行するコマンドを決定します。
Query parameters are optional components of the URI and are placed in the "query" section in terms of [RFC7320]. Generally, the query parameters are additional instructions for the requested command.
クエリパラメータはURIのオプションコンポーネントであり、[RFC7320]の観点から「クエリ」セクションに配置されます。通常、クエリパラメータは、要求されたコマンドの追加の指示です。
protocol Restrict the command and method parameters to use the specified protocol and version. Protocol is selected as "Address Family Identifier" [IANA-AFN] [RFC4760] and optionally as "Subsequent Address Family Identifier" [IANA-SAFI] separated by a comma. Default value is 1,1 (IP version 4, unicast). JSON datatype is String. Examples:
protocolコマンドとメソッドのパラメータを制限して、指定したプロトコルとバージョンを使用します。プロトコルは、「アドレスファミリ識別子」[IANA-AFN] [RFC4760]として選択され、オプションで「後続のアドレスファミリ識別子」[IANA-SAFI]としてコンマで区切られます。デフォルト値は1,1（IPバージョン4、ユニキャスト）です。 JSONデータ型はStringです。例：
* protocol=2,1 (IP version 6, unicast)
* protocol = 2,1（IPバージョン6、ユニキャスト）
* protocol=26 (MPLS, no SAFI used)
* protocol = 26（MPLS、SAFIは使用されません）
router Run the command on the router identified by its name. This is not necessarily the router's hostname as long as the Looking Glass software recognizes it. Default value is the first router in the list of available routers. JSON datatype is String. Example: router=rbgn06.example.net
router名前で識別されるルーターでコマンドを実行します。これは、Looking Glassソフトウェアが認識できる限り、必ずしもルーターのホスト名である必要はありません。デフォルト値は、使用可能なルーターのリストの最初のルーターです。 JSONデータ型はStringです。例：router = rbgn06.example.net
routerindex Run the command on this router identified by its position in the list of available routers. Default value is "0". JSON datatype is Number. Example: routerindex=8
routerindex使用可能なルーターのリストでの位置によって識別されるこのルーターでコマンドを実行します。デフォルト値は「0」です。 JSONデータ型は数値です。例：routerindex = 8
random Append a random string to prevent the client (or an intermediate proxy) from caching the response. The server must ignore its value. No default value. JSON datatype is String. Example: random=517A93B50
randomランダムな文字列を追加して、クライアント（または中間プロキシ）が応答をキャッシュしないようにします。サーバーはその値を無視する必要があります。デフォルト値はありません。 JSONデータ型はStringです。例：random = 517A93B50
vrf Run the command from the selected routing table. This parameter is valid only on routers that support "Virtual Routing and Forwarding" (VRF). No default value. JSON datatype is String. Example: vrf=mgmt
vrf選択したルーティングテーブルからコマンドを実行します。このパラメーターは、「仮想ルーティングおよび転送」（VRF）をサポートするルーターでのみ有効です。デフォルト値はありません。 JSONデータ型はStringです。例：vrf = mgmt
runtime Stop executing the command after the runtime limit (in seconds) is exceeded. A value of 0 disables the limit. Default value is "30". JSON datatype is Number. Example: runtime=60
runtimeランタイム制限（秒単位）を超えた後、コマンドの実行を停止します。値0は制限を無効にします。デフォルト値は「30」です。 JSONデータ型は数値です。例：runtime = 60
format Request the server to provide the output (if any) in the selected format. Specify multiple formats separated by a comma in descending order of preference. See Section 3.3.2 for more details. Default value is "text/plain" (raw/unformatted output). JSON datatype is String. Example: format=application/yang,text/plain
format選択した形式で出力（ある場合）を提供するようサーバーに要求します。複数のフォーマットを、優先度の高い順にカンマで区切って指定します。詳細については、セクション3.3.2を参照してください。デフォルト値は "text / plain"（未加工/フォーマットされていない出力）です。 JSONデータ型はStringです。例：format = application / yang、text / plain
The HTTP response header contains an appropriate HTTP status code as defined in [RFC7231] with the Content-Type set to "application/json".
HTTP応答ヘッダーには、[RFC7231]で定義されているように、Content-Typeが "application / json"に設定された適切なHTTPステータスコードが含まれています。
The HTTP body contains details and error descriptions. The response text must comply with the JSON syntax specification JSend, which is briefly explained in Appendix A. Consequently, every response must contain a "status" field of either "success", "fail", or "error" as explained in the following sections.
HTTP本文には、詳細とエラーの説明が含まれています。応答テキストは、付録Aで簡単に説明されているJSON構文仕様JSendに準拠している必要があります。したがって、すべての応答には、以下で説明する「成功」、「失敗」、または「エラー」のいずれかの「ステータス」フィールドが含まれている必要がありますセクション。
A successful response must set the "status" field to "success". It must also contain a "data" object including the following information:
成功した応答では、「ステータス」フィールドを「成功」に設定する必要があります。また、次の情報を含む「データ」オブジェクトも含まれている必要があります。
performed_at Combined date and time in UTC ISO 8601 [iso8601] indicating when the operation finished. This information must be present.
perform_at操作がいつ終了したかを示す、UTC ISO 8601 [iso8601]の日付と時刻の組み合わせ。この情報が存在している必要があります。
runtime Amount of seconds (wallclock) used to run the command. This information must be present.
runtimeコマンドの実行に使用された秒数（ウォールクロック）。この情報が存在している必要があります。
router Name of the router that executed the command. This information may be present.
routerコマンドを実行したルーターの名前。この情報が存在する可能性があります。
output Output of the command in a format that was requested by the client; it otherwise defaults to raw output as it appeared on the router's command-line interface (CLI). It might even be blank if the command did not produce any output. This information should be present.
outputクライアントから要求された形式でのコマンドの出力。それ以外の場合は、ルーターのコマンドラインインターフェース（CLI）に表示されるとおり、デフォルトでraw出力になります。コマンドが出力を生成しなかった場合は、空白になることもあります。この情報が存在する必要があります。
format Selected output format by the server. The client might request multiple formats so that the "Looking Glass" server has to choose the best option and tell the client which format was selected. This information should be present (defaults to "text/plain" if missing).
サーバーによって選択された出力形式。 「Looking Glass」サーバーが最適なオプションを選択し、どのフォーマットが選択されたかをクライアントに通知するために、クライアントは複数のフォーマットを要求する場合があります。この情報は存在する必要があります（存在しない場合のデフォルトは「text / plain」です）。
Adding more information to the response is permitted and must be placed inside the "data" object.
応答への情報の追加は許可されており、「データ」オブジェクト内に配置する必要があります。
The HTTP status code should be 200.
HTTPステータスコードは200である必要があります。
Example:
例：
HTTP/1.1 200 OK
Content-Type: application/json
{
"status" : "success",
"data" : {
"router" : "route-server.lookingglass.example.net"
"performed_at" : "2014-10-15T17:15:34Z",
"runtime" : 2.63,
"output" : [
"full raw output from the observing router..."
],
"format" : "text/plain"
}
}
A status of "fail" indicates that the selected command was executed on the router but failed to succeed. The response message must set the "status" field to "fail" and must contain the "data" object with command-specific content listed in Section 2.3.1.
「失敗」のステータスは、選択したコマンドがルーターで実行されたが成功しなかったことを示します。応答メッセージでは、「ステータス」フィールドを「失敗」に設定する必要があり、セクション2.3.1にリストされているコマンド固有のコンテンツを含む「データ」オブジェクトを含める必要があります。
The HTTP status code should be 200.
HTTPステータスコードは200である必要があります。
Example:
例：
HTTP/2.0 200 OK
{
"status" : "fail",
"data" : {
"performed_at" : "2014-10-18T20:04:37Z",
"runtime" : 10.37,
"output" : [
"Sending 5, 100-byte ICMP Echos to 192.0.2.5",
".....",
"Success rate is 0 percent (0/5)"
],
"format" : "text/plain",
"router" : "route-server.lookingglass.example.net"
}
}
The status "error" represents either that the command timed out or that an error occurred in processing the request. The response message must set the "status" field to "error" and must contain the "message" key, which keeps a meaningful message, explaining what went wrong.
ステータス「エラー」は、コマンドがタイムアウトしたこと、またはリクエストの処理中にエラーが発生したことを表します。応答メッセージは「ステータス」フィールドを「エラー」に設定する必要があり、「メッセージ」キーを含める必要があります。これは、何が問題だったかを説明する意味のあるメッセージを保持します。
The response may contain the "data" key with required values listed in Section 2.3.1. It may also include a "code" field that carries a numeric code corresponding to the error.
応答には、セクション2.3.1にリストされている必要な値を持つ「データ」キーが含まれる場合があります。また、エラーに対応する数値コードを含む「コード」フィールドも含まれます。
The HTTP status code should be 400 in case of a client-side error, 500 in case of a server-side error, or 502 for errors occurring on the target router. Code 504 should be used when a command timed out.
HTTPステータスコードは、クライアント側のエラーの場合は400、サーバー側のエラーの場合は500、ターゲットルーターで発生したエラーの場合は502です。コマンドがタイムアウトした場合は、コード504を使用してください。
Example:
例：
HTTP/1.1 400 Bad Request
{
"status" : "error",
"message" : "Unrecognized host or address."
}
The Looking Glass command set provides functions that are either mandatory to support or optional to implement. The same principle applies to the web-based Looking Glass.
Looking Glassコマンドセットは、サポートするために必須であるか、実装するためにオプションである機能を提供します。同じ原理がウェブベースのLooking Glassにも当てはまります。
It is not possible for any function to modify the server's state. Therefore, all HTTP methods are GET operations.
関数がサーバーの状態を変更することはできません。したがって、すべてのHTTPメソッドはGET操作です。
Variables are templated and expanded in accordance with [RFC6570].
変数は[RFC6570]に従ってテンプレート化および拡張されます。
Send echo messages to validate the reachability of a remote host and measure round-trip time. The host can be a name or address.
エコーメッセージを送信して、リモートホストの到達可能性を検証し、往復時間を測定します。ホストは名前またはアドレスにすることができます。
Implementation of the ping command is mandatory.
pingコマンドの実装は必須です。
Syntax: https://example.net/.well-known/looking-glass/v1/ping/{host}
Example query:
クエリの例：
GET /.well-known/looking-glass/v1/ping/2001:DB8::35?protocol=2,1
Host: example.net
Example response:
応答の例：
HTTP/1.1 200 OK
{
"status" : "success",
"data" : {
"min" : 40,
"avg" : 41,
"max" : 44,
"rate" : 100,
"output" : [
"Sending 5, 100-byte ICMP Echos to 2001:DB8::35",
"!!!!!",
"Success rate is 100 percent (5/5)"
],
"format" : "text/plain",
"performed_at" : "2014-10-04T14:40:58Z",
"runtime" : 0.77,
"router" : "c2951.lab.lg.example.net"
}
}
Trace the path from the executing router to the destination host and list all intermediate hops. The host can be a name or address.
実行ルーターから宛先ホストまでのパスを追跡し、すべての中間ホップをリストします。ホストは名前またはアドレスにすることができます。
Implementation of the traceroute command is optional.
tracerouteコマンドの実装はオプションです。
Syntax: https://example.net/.well-known/looking-glass/v1/
traceroute/{host}
Example query:
クエリの例：
GET /.well-known/looking-glass/v1/traceroute/192.0.2.8?routerindex=5
Host: example.net
Example response:
応答の例：
HTTP/1.1 200 OK
{
"status": "success",
"data": {
"output": [
"Tracing the route to 192.0.2.8",
"",
" 1 198.51.100.77 28 msec 28 msec 20 msec",
" 2 203.0.113.130 52 msec 40 msec 40 msec",
" 3 192.0.2.8 72 msec 76 msec 68 msec"
],
"format": "text/plain",
"performed_at": "2018-06-10T12:09:31Z",
"runtime": 4.21,
"router": "c7206.lab.lg.example.net"
}
}
Retrieve information about a specific subnet from the routing table.
ルーティングテーブルから特定のサブネットに関する情報を取得します。
Implementation of the "show route" command is mandatory.
「show route」コマンドの実装は必須です。
Syntax: https://example.net/.well-known/looking-glass/v1/show/ route/{addr} Example query:
構文：https://example.net/.well-known/looking-glass/v1/show/ route / {addr}クエリの例：
GET /.well-known/looking-glass/v1/show/ [multiline]
route/2001:DB8::/48?protocol=2,1
Host: example.net
Example response:
応答の例：
HTTP/1.1 200 OK
{
"status": "success",
"data": {
"output": [
"S 2001:DB8::/48 [1/0]",
" via FE80::C007:CFF:FED9:17, FastEthernet0/0"
],
"format": "text/plain",
"performed_at": "2018-06-11T17:13:39Z",
"runtime": 1.39,
"router": "c2951.lab.lg.example.net"
}
}
Display a matching record from the BGP routing table. This should include networks, next hop, and may include metric, local preference, path list, weight, etc.
BGPルーティングテーブルから一致するレコードを表示します。これには、ネットワーク、ネクストホップが含まれる必要があり、メトリック、ローカルプリファレンス、パスリスト、重みなどが含まれる場合があります。
Implementation of the "show bgp" command is optional.
「show bgp」コマンドの実装はオプションです。
Syntax: https://example.net/.well-known/looking-glass/v1/show/
bgp/{addr}
Example query:
クエリの例：
GET /.well-known/looking-glass/v1/show/bgp/192.0.2.0/24 Host: example.net Example response:
GET /.well-known/looking-glass/v1/show/bgp/192.0.2.0/24ホスト：example.net応答例：
HTTP/1.1 200 OK
{
"status": "success",
"data": {
"output": [
"BGP routing table entry for 192.0.2.0/24, version 2",
"Paths: (2 available, best #2, table default)",
" Advertised to update-groups:",
" 1",
" Refresh Epoch 1",
" Local",
" 192.0.2.226 from 192.0.2.226 (192.0.2.226)",
" Origin IGP, metric 0, localpref 100, valid, internal",
"[...]"
],
"format": "text/plain",
"performed_at": "2018-06-11T21:47:17Z",
"runtime": 2.03,
"router": "c2951.lab.lg.example.net"
}
}
Print a summary of BGP neighbor status. This may include the neighbor BGP ID, autonomous system number, duration of peering, number of received prefixes, etc.
BGPネイバーステータスの要約を出力します。これには、ネイバーBGP ID、自律システム番号、ピアリングの期間、受信したプレフィックスの数などが含まれます。
Implementation of the "show bgp summary" command is optional.
「show bgp summary」コマンドの実装はオプションです。
Syntax: https://example.net/.well-known/looking-glass/v1/show/bgp/
summary
Example:
例：
GET /.well-known/looking-glass/v1/show/bgp/summary? [multiline] protocol=2&routerindex=3 Host: example.net Example response:
GET /.well-known/looking-glass/v1/show/bgp/summary？ [multiline] protocol = 2＆routerindex = 3 Host：example.net応答例：
HTTP/1.1 200 OK
{
"status": "success",
"data": {
"output": [
"BGP router identifier 192.0.2.18, local AS number 64501",
"BGP table version is 85298, main routing table version 85298",
"50440 network entries using 867568 bytes of memory",
"[...]",
"Neighbor V AS MsgRcvd MsgSent TblVer Up/Down",
"2001:DB8:91::24 4 64500 481098 919095 85298 41w5d"
],
"format": "text/plain",
"performed_at": "2018-06-11T21:59:21Z",
"runtime": 1.91,
"router": "c2951.lab.lg.example.net"
}
}
Provide detailed information on BGP neighbor connections. Available details may include neighbor BGP ID, advertised networks, learned networks, autonomous system number, capabilities, protocol, statistics, etc.
BGPネイバー接続に関する詳細情報を提供します。利用可能な詳細には、ネイバーBGP ID、アドバタイズされたネットワーク、学習されたネットワーク、自律システム番号、機能、プロトコル、統計などが含まれます。
Implementation of the "show bgp neighbors" command is optional.
「show bgp neighbors」コマンドの実装はオプションです。
Syntax: https://example.net/.well-known/looking-glass/v1/show/bgp/
neighbors/{addr}
Example query:
クエリの例：
GET /.well-known/looking-glass/v1/show/bgp/neighbors/192.0.2.226 Host: example.net Example response:
GET /.well-known/looking-glass/v1/show/bgp/neighbors/192.0.2.226ホスト：example.net応答例：
HTTP/1.1 200 OK
{
"status": "success",
"data": {
"output": [
"BGP neighbor is 192.0.2.226, remote AS 64500, internal link",
" BGP version 4, remote router ID 198.51.100.31",
" BGP state = Established, up for 01:24:06",
"[...]"
],
"format": "text/plain",
"performed_at": "2018-06-11T21:41:17Z",
"runtime": 1.87,
"router": "c2951.lab.lg.example.net"
}
}
The following organizational commands must be included in the implementation.
次の編成コマンドを実装に含める必要があります。
Provides a full list of routers that are available for command execution. This list includes the router ID and its name. It is equivalent to the common "router" HTML drop-down form element and contains the same information.
コマンドの実行に使用できるルーターの完全なリストを提供します。このリストには、ルーターIDとその名前が含まれています。これは一般的な「ルーター」HTMLドロップダウンフォーム要素に相当し、同じ情報を含みます。
Syntax: https://example.net/.well-known/looking-glass/v1/routers
Example response:
応答の例：
{
"status" : "success",
"data" : {
"routers" : [
"route-server.lookingglass.example.net",
"customer-edge.lookingglass.example.net",
"provider-edge.lookingglass.example.net"
],
"performed_at" : "2014-10-19T20:07:01Z",
"runtime" : 0.73
}
}
Lists additional information about the selected router specified by its router index. The response must contain the router's hostname and router index. The response may contain more details like output format, country code, city, administrative contact, vendor, and model.
ルーターインデックスで指定された、選択されたルーターに関する追加情報を一覧表示します。応答には、ルーターのホスト名とルーターインデックスが含まれている必要があります。応答には、出力形式、国コード、都市、行政連絡先、ベンダー、モデルなどの詳細が含まれる場合があります。
Available output formats are specified by Internet media type as of [RFC6838] and listed in [IANA-MT]. If the routers support multiple formats, they are separated by a comma.
利用可能な出力フォーマットは、[RFC6838]のインターネットメディアタイプによって指定され、[IANA-MT]にリストされています。ルーターが複数の形式をサポートしている場合は、コンマで区切ります。
The router might provide output formats that are not yet registered or listed in [IANA-MT]. For example, output in NETCONF format could use "text/x.netconf". [RFC6838] provides a tree for unregistered subtypes.
ルーターは、[IANA-MT]にまだ登録またはリストされていない出力形式を提供する場合があります。たとえば、NETCONF形式の出力では「text / x.netconf」を使用できます。 [RFC6838]は、未登録のサブタイプのツリーを提供します。
A missing output format defaults to "text/plain", which is a copy of the raw command-line output.
欠落している出力形式のデフォルトは、生のコマンドライン出力のコピーである「text / plain」です。
Syntax: https://example.net/.well-known/looking-glass/v1/
routers/{number}
Example query:
クエリの例：
GET /.well-known/looking-glass/v1/routers/1
Host: example.net
Example response:
応答の例：
{
"status" : "success",
"data" : {
"id" : 1,
"name" : "customer-edge.lookingglass.example.net",
"format" : "text/plain,text/x.netconf",
"country" : "de",
"autonomous_system" : 64512
}
}
Provides a full list of commands that are available for execution. The list includes mandatory to support, optional, and additional (Section 3.4) commands. It is equivalent to the "command" HTML drop-down or radio-button form element and contains the same information.
実行可能なコマンドの完全なリストを提供します。リストには、サポートに必須のコマンド、オプションのコマンド、および追加のコマンド（セクション3.4）が含まれています。これは、「コマンド」HTMLドロップダウンまたはラジオボタンフォーム要素に相当し、同じ情報を含みます。
The list is formatted as a "commands" array containing one object per command. This object contains informative strings about the current command: href, arguments, description, and command.
リストは、コマンドごとに1つのオブジェクトを含む「コマンド」配列としてフォーマットされます。このオブジェクトには、現在のコマンドに関する情報文字列が含まれます：href、引数、説明、およびコマンド。
Syntax: https://example.net/.well-known/looking-glass/v1/cmd
Example response:
応答の例：
{
"status" : "success",
"data" : {
"commands" : [
{
"href" : "https://example.net/.well-known/ [multiline]
looking-glass/v1/show/route",
"arguments" : "{addr}",
"description" : "Print records from IP routing table",
"command" : "show route"
},
{
"href" : "https://example.net/.well-known/ [multiline]
looking-glass/v1/traceroute",
"arguments" : "{addr}",
"description" : "Trace route to destination host",
"command" : "traceroute"
}
]
}
}
The list of commands discussed in Section 3.3.3 may be expanded as long as the principles of this document are observed.
セクション3.3.3で説明されているコマンドのリストは、このドキュメントの原則が守られている限り、拡張できます。
For example, a Looking Glass provider may not be offering BGP-related commands because of an OSPF-based network.
たとえば、Looking Glassプロバイダーは、OSPFベースのネットワークのため、BGP関連のコマンドを提供していない場合があります。
The sample command might be:
コマンドの例は次のとおりです。
GET /.well-known/looking-glass/v1/show/ospf/database
Host: example.net
The network traffic sent by a "Looking Glass" is not appropriate when measuring Service Level Agreements or validating Quality of Service settings.
「Looking Glass」から送信されるネットワークトラフィックは、サービスレベルアグリーメントを測定したり、Quality of Service設定を検証したりする場合には適切ではありません。
If a monitoring system uses the Looking Glass command set for reachability checks, it should not rely on the HTTP status codes but on the "status" message field inside the HTTP body.
モニタリングシステムが到達可能性チェックにLooking Glassコマンドセットを使用する場合、HTTPステータスコードではなく、HTTP本文内の「ステータス」メッセージフィールドに依存する必要があります。
This specification registers a Well-Known URI [RFC5785]:
この仕様は、既知のURI [RFC5785]を登録します。
URI Suffix: looking-glass
URIサフィックス：looking-glass
Change Controller: M. Stubbig
コントローラーの変更：M. Stubbig
Reference : This document, Section 2
参照：このドキュメント、セクション2
The use of HTTPS is required to ensure a high level of security, privacy, and confidentiality during transit.
輸送中の高度なセキュリティ、プライバシー、機密性を確保するには、HTTPSの使用が必要です。
The main goal of the Looking Glass command set is the automated usage of the Looking Glass service. This allows the scripting of API calls, which could be used as a Distributed Denial of Service (DDoS) attack. It is recommended that implementers of the Looking Glass API take steps to mitigate the above described abuse. The strategy can include blocking or rate-limiting by client IP address or target IP network.
Looking Glassコマンドセットの主な目的は、Looking Glassサービスの自動使用です。これにより、API呼び出しのスクリプトが可能になり、分散型サービス拒否（DDoS）攻撃として使用される可能性があります。 Looking Glass APIの実装者は、上記の悪用を軽減するための措置を講じることをお勧めします。戦略には、クライアントIPアドレスまたはターゲットIPネットワークによるブロッキングまたはレート制限を含めることができます。
Authentication is not a requirement because the current Looking Glass web services are usable without authentication. Requests to the proposed API service may be authenticated by any method. The decision is up to the implementer's security requirements.
現在のLooking Glass Webサービスは認証なしで使用できるため、認証は必須ではありません。提案されたAPIサービスへのリクエストは、任意の方法で認証できます。決定は実装者のセキュリティ要件次第です。
Some of the described commands provide a detailed insight into the provider's network. It is therefore up to the implementer's security policy to dismiss commands that are marked as "optional" or to restrict commands that are marked as "mandatory".
説明されているコマンドのいくつかは、プロバイダーのネットワークに対する詳細な洞察を提供します。したがって、「オプション」としてマークされたコマンドを閉じるか、「必須」としてマークされたコマンドを制限するかは、実装者のセキュリティポリシー次第です。
[IANA-AFN] IANA, "Address Family Numbers", <https://www.iana.org/ assignments/address-family-numbers/>.
[IANA-AFN] IANA、「アドレスファミリー番号」、<https://www.iana.org/assignments/address-family-numbers/>。
[IANA-MT] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.
[IANA-MT] IANA、「メディアタイプ」、<https://www.iana.org/assignments/media-types/>。
[IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) Parameters", <https://www.iana.org/assignments/safi-namespace/>.
[IANA-SAFI] IANA、「Subsequent Address Family Identifiers（SAFI）Parameters」、<https://www.iana.org/assignments/safi-namespace/>。
[JSend] OmniTI Labs, "JSend", 2014, <https://labs.omniti.com/labs/jsend>.
[JSend] OmniTI Labs、「JSend」、2014、<https://labs.omniti.com/labs/jsend>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。 rfc-editor.org/info/rfc4760>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<https://www.rfc-editor.org / info / rfc5785>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、DOI 10.17487 / RFC6570、2012年3月、<https：// www .rfc-editor.org / info / rfc6570>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[iso8601] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", December 2004.
[iso8601]国際標準化機構、「データ要素と交換フォーマット-情報交換-日付と時刻の表現」、2004年12月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, <https://www.rfc-editor.org/info/rfc3849>.
[RFC3849] Huston、G.、Lord、A。、およびP. Smith、「ドキュメント用に予約されたIPv6アドレスプレフィックス」、RFC 3849、DOI 10.17487 / RFC3849、2004年7月、<https://www.rfc-editor.org / info / rfc3849>。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.
[RFC5737] Arkko、J.、Cotton、M。、およびL. Vegoda、「ドキュメント用に予約されたIPv4アドレスブロック」、RFC 5737、DOI 10.17487 / RFC5737、2010年1月、<https://www.rfc-editor.org / info / rfc5737>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S。およびM. Krochmal、「特殊用途ドメイン名」、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<https://www.rfc-editor.org/info/rfc6761>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：//www.rfc- editor.org/info/rfc6838>。
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <https://www.rfc-editor.org/info/rfc6996>.
[RFC6996] Mitchell、J。、「私的使用のための自律システム（AS）予約」、BCP 6、RFC 6996、DOI 10.17487 / RFC6996、2013年7月、<https://www.rfc-editor.org/info/rfc6996 >。
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>.
[RFC7320]ノッティンガム、M。、「URIの設計と所有権」、BCP 190、RFC 7320、DOI 10.17487 / RFC7320、2014年7月、<https://www.rfc-editor.org/info/rfc7320>。
According to [JSend]:
[JSend]によると：
JSend is a specification that lays down some rules for how JSON responses from web servers should be formatted. JSend focuses on application-level (as opposed to protocol- or transport-level) messaging which makes it ideal for use in REST-style applications and APIs.
JSendは、WebサーバーからのJSON応答のフォーマット方法に関するいくつかのルールを定めた仕様です。 JSendは、アプリケーションレベル（プロトコルレベルまたはトランスポートレベルではなく）のメッセージングに焦点を当てているため、RESTスタイルのアプリケーションおよびAPIでの使用に最適です。
A basic JSend-compliant response must contain a "status" key and should contain "data", "message", and "code" keys dependent on the status value. The following table lists the required and optional keys.
基本的なJSend準拠の応答には「ステータス」キーが含まれている必要があり、ステータス値に応じて「データ」、「メッセージ」、および「コード」キーが含まれている必要があります。次の表に、必須およびオプションのキーを示します。
+---------+-----------------+---------------+
| Type | Required keys | Optional keys |
+---------+-----------------+---------------+
| success | status, data | |
| fail | status, data | |
| error | status, message | code, data |
+---------+-----------------+---------------+
Table 1: Type and Keys in JSend Response
表1：JSendレスポンスのタイプとキー
Author's Address
著者のアドレス
Markus Stubbig Independent Germany
Markus Stubbig独立ドイツ
Email: stubbig.ietf@gmail.com