Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 6835                                      D. Meyer
Category: Informational                                    Cisco Systems
ISSN: 2070-1721                                             January 2013
        
Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 6835                                      D. Meyer
Category: Informational                                    Cisco Systems
ISSN: 2070-1721                                             January 2013
        

The Locator/ID Separation Protocol Internet Groper (LIG)

定位器/ID分离协议Internet Groper(LIG)

Abstract

摘要

A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works.

可以使用名为定位器/ID分离协议(LISP)Internet Groper或“lig”的简单工具查询LISP映射数据库。本文档描述了它的工作原理。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6835.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6835.

Copyright Notice

版权公告

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2013 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Implementation Details . . . . . . . . . . . . . . . . . . . .  6
     4.1.  LISP Router Implementation . . . . . . . . . . . . . . . .  6
     4.2.  Public Domain Host Implementation  . . . . . . . . . . . .  8
   5.  Testing the ALT  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Future Enhancements  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Deployed Network Diagnostic Tools  . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Implementation Details . . . . . . . . . . . . . . . . . . . .  6
     4.1.  LISP Router Implementation . . . . . . . . . . . . . . . .  6
     4.2.  Public Domain Host Implementation  . . . . . . . . . . . .  8
   5.  Testing the ALT  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Future Enhancements  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Deployed Network Diagnostic Tools  . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12
        
1. Introduction
1. 介绍

The Locator/ID Separation Protocol [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate namespaces: Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed, among them: a Content distribution Overlay Network Service for LISP [LISP-CONS], a Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], and LISP Alternative Topology (LISP+ ALT) [RFC6836], with LISP+ALT being the system that is currently being implemented and deployed on the pilot LISP network.

定位器/ID分离协议[RFC6830]指定了一种体系结构和机制,用于将IP当前使用的地址替换为两个单独的名称空间:在站点内使用的端点ID(EID)和在构成Internet基础设施的传输网络上使用的路由定位器(RLOC)。为了实现这种分离,LISP定义了从EID映射到RLOCs的协议机制。此外,LISP假设存在一个数据库来全局存储和传播这些映射。已经提出了几个这样的数据库,其中包括:用于LISP[LISP-CONS]的内容分发覆盖网络服务、不太新颖的EID到RLOC数据库(LISP-NERD)[RFC6837]和LISP替代拓扑(LISP+ALT)[RFC6836],其中LISP+ALT是目前正在试点LISP网络上实施和部署的系统。

In conjunction with the various mapping systems, there exists a network-based API called LISP Map-Server [RFC6833]. Using Map-Resolvers and Map-Servers allows LISP sites to query and register into the database in a uniform way independent of the mapping system used. Sending Map-Requests to Map-Resolvers provides a secure mechanism to obtain a Map-Reply containing the authoritative EID-to-RLOC mapping for a destination LISP site.

结合各种映射系统,存在一个名为LISP映射服务器[RFC6833]的基于网络的API。使用地图解析器和地图服务器,LISP站点可以独立于使用的地图系统,以统一的方式查询并注册到数据库中。向映射解析程序发送映射请求提供了一种安全机制,用于获取包含目标LISP站点的权威EID到RLOC映射的映射回复。

The 'lig' is a manual management tool to query the mapping database. It can be run by all devices that implement LISP, including Ingress Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy-ITRs, Proxy-ETRs, Map-Resolvers, Map-Servers, and LISP-ALT Routers, as well as by a host system at either a LISP-capable or non-LISP-capable site.

“lig”是用于查询地图数据库的手动管理工具。它可以由实现LISP的所有设备运行,包括入口隧道路由器(ITR)、出口隧道路由器(ETR)、代理ITR、代理ETR、地图解析程序、地图服务器和LISP-ALT路由器,也可以由支持LISP或不支持LISP的站点上的主机系统运行。

The mapping database system is typically a public database used for wide-range connectivity across Internet sites. The information in the public database is purposely not kept private so it can be generally accessible for public use.

映射数据库系统通常是一个公共数据库,用于跨Internet站点的大范围连接。公共数据库中的信息故意不保密,因此可以供公众使用。

2. Definition of Terms
2. 术语的定义

Map-Server: a network infrastructure component that learns EID-to-RLOC mapping entries from an authoritative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server advertises these mappings in the distributed mapping database.

映射服务器:一种网络基础设施组件,它从权威源(通常是ETR,尽管可以使用静态配置或其他带外机制)学习EID到RLOC的映射条目。地图服务器在分布式地图数据库中公布这些地图。

Map-Resolver: a network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system.

映射解析器:一个网络基础设施组件,它接受LISP封装的映射请求(通常来自ITR),快速确定目标IP地址是否是EID命名空间的一部分;如果不是,则立即返回否定的映射答复。否则,映射解析器将通过查阅分布式映射数据库系统来查找适当的EID到RLOC映射。

Routing Locator (RLOC): the IPv4 or IPv6 address of an Egress Tunnel Router (ETR). It is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet. Thus, the topology is defined by the connectivity of provider networks, and RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.

路由定位器(RLOC):出口隧道路由器(ETR)的IPv4或IPv6地址。它是EID到RLOC映射查找的输出。EID映射到一个或多个RLOC。通常,RLOC从拓扑上可聚合的块中进行编号,这些块在其连接到全球互联网的每个点处分配给站点。因此,拓扑由提供商网络的连接性定义,并且RLOC可以被认为是提供商分配(PA)地址。可以将多个RLOC分配给同一ETR设备或一个站点的多个ETR设备。

Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a DNS lookup. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs must not be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system.

端点ID(EID):数据包第一个(最内部)LISP头的源地址和目标地址字段中使用的32位(IPv4)或128位(IPv6)值。主机获取目标EID的方式与今天获取目标地址的方式相同,例如,通过DNS查找。源EID通过用于设置主机“本地”IP地址的现有机制获得。EID从与主机所在站点关联的EID前缀块分配给主机。主机可以使用EID引用其他主机。EID不得用作LISP RLOC。注意,EID块可以独立于网络拓扑以分层方式分配,以便于映射数据库的缩放。此外,分配给站点的EID块可以具有用于在站点内路由的站点本地结构(子网);此结构对全局路由系统不可见。

EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings; the cache is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope.

EID到RLOC缓存:ITR中的一种短期按需表,用于存储、跟踪EID到RLOC的映射,并负责超时和验证EID到RLOC的映射。该缓存不同于EID到RLOC映射的完整“数据库”;缓存是动态的,在ITR中是本地的,并且相对较小,而数据库是分布式的,相对静态的,并且范围更全局。

EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses.

EID到RLOC数据库:包含所有已知EID前缀到RLOC映射的全局分布式数据库。每个潜在的ETR通常包含数据库的一小部分:路由器后面的EID前缀的EID到RLOC映射。这些映射到路由器自己的、全局可见的IP地址之一。

Encapsulated Map-Request (EMR): an EMR is a Map-Request message that is encapsulated with another LISP header using UDP destination port number 4342. It is used so an ITR, PITR, or a system initiating a 'lig' command can get the Map-Request to a Map-Resolver by using locator addresses. When the Map-Request is decapsulated by the Map-Resolver, it will be forwarded on the ALT network to the Map-Server that has injected the EID-prefix for a registered site. The Map-Server will then encapsulate the Map-Request in a LISP packet and send it to an ETR at the site. The ETR will then return an authoritative reply to the system that initiated the request. See [RFC6830] for packet format details.

封装的映射请求(EMR):EMR是使用UDP目标端口号4342用另一个LISP头封装的映射请求消息。它用于使ITR、PITR或启动“lig”命令的系统可以通过使用定位器地址将映射请求获取到映射解析器。地图解析程序解除对地图请求的封装后,它将在ALT网络上转发到已为注册站点注入EID前缀的地图服务器。然后,Map服务器将Map请求封装在LISP数据包中,并将其发送到站点的ETR。ETR随后将向发起请求的系统返回权威回复。有关数据包格式的详细信息,请参见[RFC6830]。

Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.

入口隧道路由器(ITR):ITR是一种路由器,它接受带有单个IP报头的IP数据包(更准确地说,是不包含LISP报头的IP数据包)。路由器将此“内部”IP目标地址视为EID,并执行EID到RLOC的映射查找。然后,路由器在“源地址”字段中为“外部”IP报头添加一个全局可路由RLOC,并在“目标地址”字段中添加映射查找的结果。注意,该目的地RLOC可以是一个中间代理设备,它对更接近目的地EID的EID到RLOC映射有更好的了解。通常,ITR在一端接收来自站点端系统的IP数据包,在另一端向Internet发送LISP封装的IP数据包。

Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.

出口隧道路由器(ETR):ETR是接受IP数据包的路由器,其中“外部”IP报头中的目标地址是其自己的RLOC之一。路由器剥离“外部”报头,并根据找到的下一个IP报头转发数据包。通常,ETR在一侧从Internet接收LISP封装的IP数据包,并将解封装的IP数据包发送到另一侧的站点端系统。ETR功能不必局限于路由器设备。服务器主机也可以是LISP隧道的端点。

Proxy-ITR (PITR): A PITR, also known as a PTR, is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.

代理ITR(PITR):PITR,也称为PTR,在[RFC6832]中定义和描述。PITR的作用类似于ITR,但它代表向LISP站点的目的地发送数据包的非LISP站点。

Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites.

代理ETR(PETR):在[RFC6832]中定义和描述了一个PETR。PETR的作用类似于ETR,但它代表向非LISP站点的目的地发送数据包的LISP站点。

xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint; it is used synonymously with the term "tunnel router". For example, "an xTR can be located at the Customer Edge (CE) router" means that both ITR and ETR functionality is at the CE router.

xTR:当数据流的方向不是上下文描述的一部分时,xTR是对ITR或ETR的引用。xTR是指作为隧道端点的路由器;它与术语“隧道路由器”同义。例如,“xTR可以位于客户边缘(CE)路由器”意味着ITR和ETR功能都位于CE路由器。

Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service-provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice.

提供商分配(PA)地址:PA地址是站点所连接的每个服务提供商分配给站点的地址块。通常,每个块都是服务提供商无类域间路由(CIDR)[RFC4632]块的子块,在发布到全球互联网之前聚合到更大的块中。传统上,IP多址是由每个多址站点获取自己的全局可见前缀来实现的。LISP仅为RLOC使用拓扑分配和可聚合的地址块,消除了这种明显不可扩展的做法。

3. Basic Overview
3. 基本概况

When the 'lig' command is run, a Map-Request is sent for a destination EID. When a Map-Reply is returned, the contents are displayed to the user. The information displayed includes:

运行“lig”命令时,将发送一个目标EID的映射请求。返回地图回复后,内容将显示给用户。显示的信息包括:

o The EID-prefix for the site that the queried destination EID matches.

o 查询的目标EID匹配的站点的EID前缀。

o The locator address of the Map Replier.

o 地图应答器的定位器地址。

o The Locator-Set for the mapping entry, which includes the locator address, up/down status, priority, and weight of each Locator.

o 为映射条目设置的定位器,包括定位器地址、向上/向下状态、优先级和每个定位器的权重。

o A round-trip-time estimate for the Map-Request/Map-Reply exchange.

o Map请求/Map应答交换的往返时间估计。

A possible syntax for a 'lig' command could be:

“lig”命令的可能语法可以是:

       lig <destination> [source <source>] [to <map-resolver>]
        
       lig <destination> [source <source>] [to <map-resolver>]
        

Parameter description:

参数说明:

<destination>: is either a Fully Qualified Domain Name (FQDN) or a destination EID for a remote LISP site.

<destination>:是远程LISP站点的完全限定域名(FQDN)或目标EID。

source <source>: is an optional source EID to be inserted in the 'Source EID' field of the Map-Request.

source<source>:是一个可选的源EID,将插入映射请求的“源EID”字段中。

to <map-resolver>: is an optional FQDN or RLOC address for a Map-Resolver.

to<map resolver>:是映射解析程序的可选FQDN或RLOC地址。

The 'lig' utility has two use cases. The first is a way to query the mapping database for a particular EID. The other is to verify if a site has registered successfully with a Map-Server.

“lig”实用程序有两个用例。第一种是查询映射数据库中特定EID的方法。另一个是验证站点是否已成功注册到地图服务器。

The first usage has already been described. Verifying registration is called "ligging yourself"; it happens as follows. In the 'lig' initiator, a Map-Request is sent for one of the EIDs for the 'lig' initiator's site. The Map-Request is then returned to one of the ETRs for the 'lig'-initiating site. In response to the Map-Request, a Map-Reply is sent back to the locator address of the 'lig' initiator (note the Map-Reply could be sent by the 'lig' initiator). That Map-Reply is processed, and the mapping data for the 'lig'- initiating site is displayed for the user. Refer to the syntax in Section 4.1 for an implementation of "ligging yourself". However, for host-based implementations within a LISP site, "lig self" is less useful since the host may not have an RLOC with which to receive a Map-Reply. But, 'lig' can be used in a non-LISP site, as well as from infrastructure hosts, to get mapping information.

已经描述了第一种用法。验证注册被称为“照亮你自己”;发生的情况如下。在“lig”启动器中,为“lig”启动器站点的一个EID发送映射请求。然后,Map请求返回到“lig”发起站点的一个ETR。为了响应Map请求,Map回复被发送回“lig”启动器的定位器地址(注意,Map回复可能由“lig”启动器发送)。将处理该映射回复,并为用户显示“lig”起始站点的映射数据。请参阅第4.1节中的语法,了解“自行照明”的实现。但是,对于LISP站点中基于主机的实现,“lig self”不太有用,因为主机可能没有用于接收映射回复的RLOC。但是,“lig”可以在非LISP站点中使用,也可以从基础设施主机中使用,以获取映射信息。

4. Implementation Details
4. 实施细节
4.1. LISP Router Implementation
4.1. LISP路由器的实现

The Cisco LISP prototype implementation has support for 'lig' for IPv4 and IPv6. The command line description is:

Cisco LISP原型实现支持IPv4和IPv6的“lig”。命令行说明如下:

       lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]
        
       lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]
        

This command initiates the LISP Internet Groper. It is similar to the DNS analogue 'dig' but works on the LISP mapping database. When this command is invoked, the local system will send a Map-Request to the configured Map-Resolver. When a Map-Reply is returned, its contents will be displayed to the user. By default, up to three Map-Requests are sent if no Map-Reply is returned, but, once a Map-Reply is returned, no other Map-Requests are sent. The destination can take a DNS name, or an IPv4 or IPv6 EID address. The <source-eid> can be one of the EID addresses assigned to the site in the default

此命令启动LISP Internet浏览器。它类似于DNS模拟“dig”,但在LISP映射数据库上工作。调用此命令时,本地系统将向配置的映射解析程序发送映射请求。返回地图回复时,其内容将显示给用户。默认情况下,如果没有返回Map应答,则最多发送三个Map请求,但一旦返回Map应答,则不会发送其他Map请求。目标可以采用DNS名称或IPv4或IPv6 EID地址。<source eid>可以是默认情况下分配给站点的eid地址之一

Virtual Routing and Forwarding (VRF) table. When <mr> is specified, then the Map-Request is sent to the address. Otherwise, the Map-Request is sent to a configured Map-Resolver. When a Map-Resolver is not configured, then the Map-Request is sent on the ALT network if the local router is attached to the ALT. When "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent.

虚拟路由和转发(VRF)表。当指定<mr>时,映射请求被发送到该地址。否则,映射请求将发送到已配置的映射解析程序。未配置映射解析程序时,如果本地路由器连接到ALT,则会在ALT网络上发送映射请求。当指定“计数<1-5>”时,会发送1、2、3、4或5个映射请求。

Some sample output:

一些示例输出:

router# lig abc.example.com Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.081468 secs

路由器#lig abc.example.com为192.168.1.1向10.0.0.1发送映射请求。。。以0.081468秒的rtt从10.0.0.2收到map回复

     Map-Cache entry for abc.example.com EID 192.168.1.1:
     192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58,
                     via map-reply, auth
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.2         13:59:59  up     1/100            0/14
        
     Map-Cache entry for abc.example.com EID 192.168.1.1:
     192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58,
                     via map-reply, auth
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.2         13:59:59  up     1/100            0/14
        

Using 'lig' to "lig yourself" is accomplished with the following syntax:

使用“lig”来“lig yourself”是通过以下语法实现的:

       lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]
        
       lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]
        

Use this command for a simple way to see if the site is registered with the mapping database system. The destination-EID address for the Map-Request will be the first configured EID-prefix for the site (with the host bits set to 0). For example, if the site's EID-prefix is 192.168.1.0/24, the destination-EID for the Map-Request is 192.168.1.0. The source-EID address for the Map-Request will also be 192.168.1.0 (in this example), and the Map-Request is sent to the configured Map-Resolver. If the Map-Resolver and Map-Server are the same LISP system, then the "lig self" is testing if the Map-Resolver can "turn back a Map-Request to the site". If another Map-Resolver is used, it can test that the site's EID-prefix has been injected into the ALT infrastructure, in which case the 'lig' Map-Request is processed by the Map-Resolver and propagated through each ALT-Router hop to the site's registered Map-Server. Then, the Map-Server returns the Map-Request to the originating site. In that case, an xTR at the originating site sends a Map-Reply to the source of the Map-Request (could be itself or another xTR for the site). All other command parameters are described above. Using "lig self6" tests for registering of IPv6 EID-prefixes.

使用此命令可以简单地查看站点是否已在映射数据库系统中注册。映射请求的目标EID地址将是站点的第一个配置EID前缀(主机位设置为0)。例如,如果站点的EID前缀为192.168.1.0/24,则映射请求的目标EID为192.168.1.0。Map请求的源EID地址也将是192.168.1.0(在本例中),并且Map请求被发送到已配置的Map解析器。如果地图解析器和地图服务器是同一个LISP系统,“lig self”正在测试地图解析器是否可以“将地图请求返回到站点”。如果使用了另一个映射解析程序,它可以测试站点的EID前缀是否已注入ALT基础结构,在这种情况下,“lig”映射请求由映射解析程序处理,并通过每个ALT路由器跃点传播到站点注册的映射服务器。然后,地图服务器将地图请求返回到原始站点。在这种情况下,源站点的xTR向Map请求的源发送Map应答(可以是自身或站点的另一个xTR)。所有其他命令参数如上所述。使用“lig self6”测试注册IPv6 EID前缀。

Some sample output for "ligging yourself":

“照亮你自己”的一些示例输出:

router# lig self Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Received map-reply from 10.0.0.3 with rtt 0.001592 secs

路由器#lig自发送环回映射请求到10.0.0.1,用于192.168.2.0。。。收到来自10.0.0.3的map回复,rtt为0.001592秒

     Map-Cache entry for EID 192.168.2.0:
     192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
                     via map-reply, self
       Locator       Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3      00:00:02  up     1/100            0/0
        
     Map-Cache entry for EID 192.168.2.0:
     192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
                     via map-reply, self
       Locator       Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3      00:00:02  up     1/100            0/0
        
     router# lig self6
     Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
     Received map-reply from 10::1 with rtt 0.044372 secs
        
     router# lig self6
     Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
     Received map-reply from 10::1 with rtt 0.044372 secs
        
     Map-Cache entry for EID 192:168:1:::
     2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
                      via map-reply, self
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3         00:00:01  up     1/100            0/0
       2001:db8:ffff::1 00:00:01  up     2/0              0/0
        
     Map-Cache entry for EID 192:168:1:::
     2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
                      via map-reply, self
       Locator          Uptime    State  Priority/Weight  Packets In/Out
       10.0.0.3         00:00:01  up     1/100            0/0
       2001:db8:ffff::1 00:00:01  up     2/0              0/0
        
4.2. Public Domain Host Implementation
4.2. 公共域主机实现

There is a public domain implementation that can run on any x86-based system. The only requirement is that the system that initiates 'lig' must have an address assigned from the locator namespace.

有一个公共域实现可以在任何基于x86的系统上运行。唯一的要求是,发起“lig”的系统必须具有从定位器命名空间分配的地址。

       lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]
        
       lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]
        

Parameter description:

参数说明:

-d: prints additional protocol debug output.

-d:打印附加协议调试输出。

<eid>: the destination EID or FQDN of a LISP host.

<eid>:LISP主机的目标eid或FQDN。

-m <map-resolver>: the RLOC address or FQDN of a Map-Resolver.

-m<map resolver>:映射解析程序的RLOC地址或FQDN。

-c <count>: the number of Map-Requests to send before the first Map-Reply is returned. The default value is 3. The range is from 1 to 5.

-c<count>:返回第一个映射答复之前要发送的映射请求数。默认值为3。范围从1到5。

-t <timeout>: the amount of time, in seconds, before another Map-Request is sent when no Map-Reply is returned. The default value is 2 seconds. The range is from 1 to 5.

-t<timeout>:当没有返回映射答复时,发送另一个映射请求之前的时间量(以秒为单位)。默认值为2秒。范围从1到5。

Some sample output:

一些示例输出:

% lig xyz.example.com -m 10.0.0.1 Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.04000 sec

%lig xyz.example.com-m 10.0.0.1为192.168.1.1向10.0.0.1发送映射请求。。。收到10.0.0.2的map回复,rtt为0.04000秒

Mapping entry for EID 192.168.1.1: 192.168.1.0/24, record ttl: 60 Locator State Priority/Weight 10.0.0.1 up 1/25 10.0.0.2 up 1/25 10.0.0.3 up 1/25 10.0.0.4 up 2/25

EID 192.168.1.1的映射条目:192.168.1.0/24,记录ttl:60定位器状态优先级/权重10.0.0.1向上1/25 10.0.0.2向上1/25 10.0.0.3向上1/25 10.0.0.4向上2/25

The public domain implementation of 'lig' is available at <http://github.com/LISPmob/lig>.

“lig”的公共域实现可在<http://github.com/LISPmob/lig>.

5. Testing the ALT
5. 检测ALT

There are cases where a Map-Reply is returned from a 'lig' request, but the user doesn't really know how much of the mapping infrastructure was tested. There are two cases to consider -- avoiding the ALT and traversing the ALT.

在某些情况下,映射回复是从“lig”请求返回的,但用户并不知道映射基础结构的测试量。有两种情况需要考虑——避免ALT和穿越ALT。

When an ITR sends a 'lig' request to its Map-Resolver for a destination-EID, the Map-Resolver could also be configured as a Map-Server. And if the destination-EID is for a site that registers with this Map-Server, the Map-Request is sent to the site directly without testing the ALT. This occurs because the Map-Server is the source of the advertisement for the site's EID-prefix. So, if the map-reply is returned to the 'lig'-requesting site, you cannot be sure that other sites can reach the same destination-EID.

当ITR向其映射解析器发送“lig”请求以获取目标EID时,映射解析器也可以配置为映射服务器。如果目标EID针对的是注册到此地图服务器的站点,则地图请求将直接发送到站点,而不测试ALT。这是因为地图服务器是站点EID前缀的播发源。因此,如果地图回复返回到“lig”请求站点,则无法确保其他站点可以到达相同的目标EID。

If a Map-Resolver is used that is not a Map-Server for the EID-prefix being sought, then the ALT infrastructure can be tested. This test case is testing the functionality of the Map-Resolver, traversal of the ALT (testing BGP-over-GRE), and the Map-Server.

如果使用的映射解析器不是要查找的EID前缀的映射服务器,则可以测试ALT基础结构。这个测试用例正在测试Map解析器的功能、ALT的遍历(在GRE上测试BGP)和Map服务器。

It is recommended that users issue two 'lig' requests; they send Map-Requests to different Map-Resolvers.

建议用户发出两个“lig”请求;它们向不同的映射解析程序发送映射请求。

The network can have a LISP-ALT Router deployed as a "ALT looking-glass" node. This type of router has BGP peering sessions with other ALT Routers where it does not inject any EID-prefixes into the ALT but just learns ones advertised by other ALT Routers and Map-Servers. This router is configured as a Map-Resolver. 'lig' users can point to the ALT looking-glass router for Map-Resolver services via the "to <map-resolver>" parameter on the 'lig' command. The ALT looking-

网络可以将LISP-ALT路由器部署为“ALT-looking glass”节点。这种类型的路由器具有与其他ALT路由器的BGP对等会话,其中它不向ALT中注入任何EID前缀,而只是学习其他ALT路由器和映射服务器播发的前缀。此路由器配置为映射解析程序。'lig用户可以通过“lig”命令上的“to<Map Resolver>”参数指向地图解析器服务的ALT looking glass router。这辆车看起来很漂亮-

glass node can be used to 'lig' other sites as well as your own site. When the ALT looking-glass is used as a Map-Resolver, you can be assured the ALT network is being tested.

glass节点可以用于“lig”其他站点以及您自己的站点。当ALT looking glass用作地图解析器时,您可以确信ALT网络正在测试中。

6. Future Enhancements
6. 未来的增强功能

When Negative Map-Replies have been further developed and implemented, 'lig' should be modified appropriately to process and clearly indicate how and why a Negative Map-Reply was received. Negative Map-Replies could be sent in the following cases: the 'lig' request was initiated for a non-EID address or there was rate-limiting on the replier.

当负面Map回复得到进一步开发和实施时,应适当修改“lig”,以处理并明确说明如何以及为什么收到负面Map回复。在以下情况下,可能会发送否定的Map回复:“lig”请求是针对非EID地址启动的,或者回复器上存在速率限制。

7. Deployed Network Diagnostic Tools
7. 部署的网络诊断工具

There is a web-based interface to do auto-polling with 'lig' on the back-end for most of the LISP sites on the LISP test network. The web page can be accessed at <http://www.lisp4.net/status>.

对于LISP测试网络上的大多数LISP站点,有一个基于web的界面可以在后端使用“lig”进行自动轮询。该网页可在以下网址访问:<http://www.lisp4.net/status>.

There is a LISP site monitoring web-based interface that can be found at <http://lispmon.net>.

有一个LISP站点监视基于web的界面,可以在<http://lispmon.net>.

At <http://baldomar.ccaba.upc.edu/lispmon>, written by the folks at Universitat Politecnica de Catalunya (UPC), shows a geographical map indicating where each LISP site resides.

在<http://baldomar.ccaba.upc.edu/lispmon>,由加泰罗尼亚理工大学(Universitat Politecnica de Catalunya,UPC)的人撰写,显示了一张地理地图,指明了每个LISP站点所在的位置。

8. Security Considerations
8. 安全考虑

The use of 'lig' does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [RFC6830], [RFC6836], and [RFC6833] for descriptions of the security properties of the LISP infrastructure.

“lig”的使用不会影响LISP基础设施的安全性,因为它只是一个方便诊断查询的工具。请参阅[RFC6830]、[RFC6836]和[RFC6833]以了解LISP基础结构的安全属性的描述。

'lig' provides easy access to the information in the public mapping database. Therefore, it is important to protect the mapping information for private use. This can be provided by disallowing access to specific mapping entries or to place such entries in a private mapping database system.

“lig”可方便地访问公共地图数据库中的信息。因此,保护地图信息以供私人使用非常重要。这可以通过禁止访问特定映射条目或将此类条目放置在专用映射数据库系统中来实现。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.

[RFC4632]Fuller,V.和T.Li,“无类域间路由(CIDR):互联网地址分配和聚合计划”,BCP 122,RFC 4632,2006年8月。

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.

[RFC6830]Farinaci,D.,Fuller,V.,Meyer,D.,和D.Lewis,“定位器/身份分离协议(LISP)”,RFC 6830,2013年1月。

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.

[RFC6832]Lewis,D.,Meyer,D.,Farinaci,D.,和V.Fuller,“定位器/ID分离协议(LISP)和非LISP站点之间的互通”,RFC 6832,2013年1月。

[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map Server Interface", RFC 6833, January 2013.

[RFC6833]Farinaci,D.和V.Fuller,“定位器/ID分离协议(LISP)地图服务器接口”,RFC 6833,2013年1月。

9.2. Informative References
9.2. 资料性引用

[LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.

[LISP-CONS]Farinaci,D.,Fuller,V.,和D.Meyer,“LISP-CONS:LISP的内容分发覆盖网络服务”,正在进行的工作,2008年4月。

[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.

[RFC6836]Farinaci,D.,Fuller,V.,Meyer,D.,和D.Lewis,“定位器/ID分离协议替代逻辑拓扑(LISP+ALT)”,RFC 68362013年1月。

[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013.

[RFC6837]李尔,E.“NERD:路由定位器(RLOC)数据库的一个不太新颖的端点ID(EID)”,RFC 6837,2013年1月。

Appendix A. Acknowledgments
附录A.确认书

Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and Vince Fuller for providing critical feedback on the 'lig' design and prototype implementations. To these folks, as well as all the people on lisp-beta@external.cisco.com who tested 'lig' functionality and continue to do so, we extend our sincere thanks.

感谢并赞扬John Zwiebel、Andrew Partan、Darrel Lewis和Vince Fuller为“lig”设计和原型实现提供了关键反馈。给这些人,以及所有口齿不清的人-beta@external.cisco.com世卫组织测试了“lig”功能并将继续这样做,我们表示衷心感谢。

This document is based on an individual contribution.

本文件以个人贡献为基础。

Authors' Addresses

作者地址

Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA

美国加利福尼亚州圣何塞市塔斯曼大道迪诺·法里纳奇思科系统公司,邮编95134

   EMail: farinacci@gmail.com
        
   EMail: farinacci@gmail.com
        

Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA

美国加利福尼亚州圣何塞塔斯曼大道170号Dave Meyer Cisco Systems

   EMail: dmm@cisco.com
        
   EMail: dmm@cisco.com