FYI. Dino Begin forwarded message:
From: Dino Farinacci <dino@cisco.com> Date: March 19, 2008 10:40:07 AM PDT To: lisp-beta@external.cisco.comCc: David Bannister <db@cisco.com>, Randy Bush <randy@psg.com>, "lispers list)" <lispers@cisco.com>, Venu Venugopal <vn@cisco.com>Subject: Some status on LISP testing 1) The Titaniums were sent out on Monday to Peter, Andrew, and DaveM.2) See picture enclosed. Some of you have old Titaniums and some of you have new ones. The new ones have a different port numbering scheme. There is no way to tell what is new versus old, so you have to connect up a port configure an IP address and see if you can ping the other side.3) Most of you have older images. We have images that I build. The first build you may see is called dino-lisp-24. The way we are going to release code is to give Darrel, DaveM, Vince, and Shep the code first to try out. Then we'll announce on this alias.4) Each release I will tell you what LISP related stuff I have put in or fixed. Other main DC-OS stuff won't be included unless it affects us and is applicable to our testing. We want this effort to be focused on testing LISP first and foremost rather than testing DC- OS.5) For starters, we will tell you how to load images. There is a process that is not like IOS that you'll learn to live with but hate. ;-)6) DaveM, Vince, and Darrel are working on a new topology to start the pilot deployment. See the topology enclosed we presented last week at IETF. Red circles are LISP-ALT routers, the green circles are xTRs that are also LISP-ALT routers and the violet circle is a xTR only (the low OpEx LISP box).7) I have one last Titanium to give out, and Dave Bannister is slated for it. We are figuring where to get one for Randy so he can jump on. If someone can come up with $1800, you can buy one and we'll get you a DC-OS CD to load up on it. You cannot run this code on any Linux platform, it is a spec'ed platform that we have been testing and using in development. We want to keep this process simple so we test LISP and not get involved in any other distractions.8) Enclosed is the latest LISP commands file. To give you an idea what we support and how to configure it. When you get your boxes, Dave will tell you how to address things according to his design. See our IETF slide below on what we presented at IETF last week.9) We will send frequent updates to we can educate you on what the implementation does and what we are planning to implement, with your feedback and opinions considered.Any questions, send to this list 'lisp-beta@external.cisco.com'. And thanks a lot for your support and effort spent on this. We are going to learn a lot and have fun like the good ole days. ;-)Dino/DaveM/Vince/Darrel/Shep
Attachment:
titanium.pdf
Description: Adobe PDF document
----
LISP Command Support in DC-OS
-----------------------------
Tue Mar 4 09:44:01 PST 2008
This document specifies the CLI command support for configuring LISP
in ITRs
and ETRs.
Global Commands
---------------
[no] {ip | ipv6} lisp itr
Configures LISP Ingress Tunnel Router (ITR) functionality on an
incoming interface. If a packet is received which does not
match a
route in the routing table or does match the default route, the
packet
will be LISP encapsulated. When this occurs, an EID cache
lookup is
performed and the Locator associated with the cached entry will
be used
as destination address in the outer header. Otherwise, the inner
destination address is copied to the outer header destination
address.
[no] {ip | ipv6} lisp etr
Configures LISP Ingress Tunnel Router (ITR) functionality on an
incoming interface. If a packet is received which does not
match a
route in the routing table or does match the default route, the
packet
will be LISP encapsulated. When this occurs, an EID cache
lookup is
performed and the Locator associated with the cached entry will
be used
as destination address in the outer header. Otherwise, the inner
destination address is copied to the outer header destination
address.
[no] {ip | ipv6} lisp etr database-mapping <eid-prefix> <locator>
priority <priority>
weight <weight>
This command configures the LISP database parameters so the ETR
can send ICMP EID-to-RLOC Reply messages. The <locator> is
typically the IP address of loopback interface (but can be the
IP address of any interface) used as a Locator address for the
<eid-prefix> assigned for the site. Associated with the locator
address is a priority <priority> and weight <weight> which will
be advertised with in the ICMP Reply. Multiple commands are used
to configure multiple locators for a given EID-prefix.
When one ETR router is used, make sure the local addresses
configured
are ones that come from different provider blocks. If more than
one
ETR router is used, each with a configured address from a
different
provider block, all ETRs must be configured with this command for
all Locators.
[no] {ip | ipv6} lisp etr locator-down <eid-prefix> <locator>
Configures a locator from a locator-set associated with the EID-
prefix
database mapping to be down. When a locator is configured down,
the
corresponding loc-reach-bit will be cleared when encapsulating
packets
to remote sites. Remote sites, in turn, suspend from using this
locator
to reach the local site. The default setting is that all
locators are
considered reachable unless an IGP routing protocol indicates
it is
down (not implemented yet).
[no] {ip | ipv6} lisp itr cache-mapping <eid-prefix> <locator>
priority <priority> weight
<weight>
Configures a static EID-prefix to Locator set mapping. This
mapping takes precedent over any dynamic mapping learned. Up to
4 Locator 3-tuple sets can be configured. This mapping is used
in the ITR. This command can be entered multiple times to
configure multiple locator addresses for a given EID-prefix.
[no] {ip | ipv6} lisp itr drop-on-cache-miss
This configures the ITR to drop packets when there is no cache
entry for the EID lookup. The default for this command is
disabled, meaning desire to use LISP 1 and 1.5 functionality.
[no] {ip | ipv6} lisp itr forward-on-cache-miss
This configures the ITR to forward packets unencapsulated when
there
is no cache entry for the EID lookup. The default for this
command is
disabled, meaning the desire to use LISP 1 and 1.5 functionality.
[no] {ip | ipv6} lisp itr forward-on-lat-miss
This is used only when the "ip lisp use-vrf" command is in use
and
is part of the LISP-ALT mapping database support. When an EID is
not found in the mapping cache, rather than encapsulating the
packet
(making it a Data Probe packet) to send on the LISP-ALT
topology, the
packet will be sent natively when the following conditions are
met:
1) The longest match lookup for an EID, from the routing table
of the
VRF specified by the "ip lisp itr use-vrf" command, fails, the
destination is considered to be in a non-LISP site and packets
destined to the site will not be LISP encapsulated.
2) If longest match lookup for an EID matches on the default
route
0.0.0.0/0 or 0::/0 is considered a lookup failure and packets
will not be LISP encapsulated.
[no] {ip | ipv6} lisp itr incomplete-cache-rate <pps>
This is the rate in packets-per-second the ITR should send
packets
while a mapping is waiting to arrive.
[no] {ip | ipv6} lisp itr send-map-request [<lisp-alt>]
This command is used when an ITR needs to find an EID-to-RLOC
mapping
for a packet it needs to encapsulate. Rather than sending the
packet
as a Data Probe, a LISP Map-Request is sent for the EID instead.
When <lisp-alt> is not specified and the ITR has a BGP
connection
on the LISP-ALT topology (uses the "use-vrf" command), the Map-
Request
is sent on the LAT (the LISP Alternate Topology). When an
address
is supplied for <lisp-alt>, this is the case when the ITR is not
running BGP and is not directly attached to the LISP-ALT
topology.
In this case, the Map-Request is sent to a LISP-ALT router
that is
assigned the locator address <lisp-alt>. The default setting
is to
send Data Probes and not send Map-Requests.
[no] {ip | ipv6} lisp use-vrf <vrf-name>
In an ITR, when there is no mapping for a outer DA of a packet
(the EID), a LISP header is prepended with the outer DA equal
to the
inner DA. Then the packet is forwarded based on the routing
table for
VRF <vrf-name>. In an ETR, when such a packet is received and
decapsulated, the inner header is processed against the routing
table
for VRF <vrf-name>. This command defaults to using the default
VRF
which results in LISP 1.0 operation. When this command is
configured with a non-default VRF, then LISP 1.5 is in effect.
[no] {ip | ipv6} lisp etr glean-mapping
When configured in the ETR, when decapsulattion is done, the
ETR will
add the inner header's source address (the EID) to the EID-to-
RLOC
cache with a locator address equal to the outer header's source
address (the locator). The priority for the entry will be 1 and
the
weight will be set to 100.
This can be used when a host moves from one ITR to another. The
new
ITR that encapsulates the packet to the ETR, in the data path,
can
tell the ETR about the new locator information for the moved
host's
EID.
[no] {ip | ipv6} lisp etr verify-roaming
Used in conjunction with gleaning. If the source locator in a
recevied
packet is not in the locator-set for an EID-prefix the packet's
source
EID matches, the ETR will use this locator to return traffic
after a
verification check is performed. In this case, the ETR will
send a
LISP Map-Reqeust message for the EID to the candidate loactor. If
a Map-Reply is returned from the locator device with the same
nonce
sent in the Map-Request, then the locator will be used. When this
command is configured, packets will be dropped until the Map-
Reply
is returned.
[no] {ip | ipv6} lisp translate inside <nrEID> outside <rEID>
Configures a LISP translation mapping. When this additive
command is
configured, an ITR, when it detects a non-routable EID <nrEID>
in the
source address field on an IP or IPv6 header, it will replace
it with
the routable EID <rEID> address while fixing up the TCP or UDP
pseudo
header checksum. In the opposite packet direction, an ETR will
replace
the destination address <rEID> with the <nrEID> address.
Debug Commands
--------------
[un]debug {ip | ipv6} lisp packet [<eid-prefix>] [detail] [all]
Logs packets that are encapsulated by the ITR or decapsulated
by the ETR.
When keyword "detail" is used the debug output will show ITR/ETR
processing messages as well as cache lookup hit or miss
activity. When
"all" is specified all the forwarding debugs available are
displayed.
[un]debug {ip | ipv6} lisp mapping
Logs ICMP EID-to-RLOC Request and Reply activity.
Show Commands
-------------
show {ip | ipv6} lisp [vrf <vrf-name>]
Displays LISP ITR or ETR status, configuration, and statistics.
show {ip | ipv6} lisp map-cache [<eid> | <eid-prefix>] [vrf <vrf-
name>]
Displays the EID-to-RLOC cache of dynamic or static entries. When
<eid> is specified an IP or IPv6 address is taken to do a longest
match lookup in the cache. When <eid-prefix> is specified as a
prefix
in slash format, an exact match lookup in the cache is performed.
show {ip | ipv6} lisp data-cache [<eid> | <eid-prefix>] [vrf <vrf-
name>]
Displays the EID-to-RLOC data cache created by the IP or IPv6
processes.
These processes create incomplete entries while awaiting Map-
Reply to
be returned in response to a Data Probe or Map-Request message.
show {ip | ipv6} lisp locator-hash <source-eid> <dest-eid>
Displays for a given IPv4 or IPv6 EID pair of addresses, what
source
and destination locators are used for the packet. The source
locator
is chosen based on the source EID from the EID-prefix database
configured
via the "{ip | ipv6} lisp etr database-mapping" command. The
destination
locator is selected by finding the destination EID in the EID-
to-RLOC
mapping cache database.
show {ip | ipv6} lisp tranlate-cache [<nr-eid>]
Displays the configured LISP translation cache and statistics
associated with using each entry. When an <nr-eid> is selected,
only
the single address translation is displayed.
Clear Commands
--------------
clear {ip | ipv6} lisp [vrf <vrf-name>] map-cache [<eid-prefix>]
Clears the EID-to-RLOC mapping for all locators that matches
the EID-
prefix <eid-prefix> within the specified VRF. When <eid-prefix>
is
not specified, the entire cache is cleared including static
entries.
To get the static entries cache again, you must re-type the "ip
lisp
itr cache-mapping" commands.
clear {ip | ipv6} lisp [vrf <vrf-name>] data-cache [<eid>]
Clears the EID-to-RLOC mapping in the forwarding data-cache.
These
entries are present in two case. The first being when a data
probe
is sent awaiting for a Map-Reply to be returned. The second is
when
an ETR is gleaning information. When <eid> is not specified, the
entire data cache is cleared.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------