From: Dino Farinacci <dino@cisco.com>
Date: July 2, 2008 1:50:51 PM PDT
To: LISP Beta <lisp-beta@external.cisco.com>
Cc: "lispers(mailer list)" <lispers@cisco.com>, "lisp-alpha(mailer
list)" <lisp-alpha@cisco.com>
Subject: We have new code for you!
Hey LISP beta folks, we know we haven't contacted you in a while but
we have been pretty busy getting features done. We have a new
release for you.
You all should be on release dino-lisp-35 and we are releasing dino-
lisp-43 today. See below for the fix descriptions and features added
in releases 36-43.
You can find images at:
beta@paren.lisp.uoregon.edu:images/dino-lisp-43-titanium-d1-
kickstart.4.0.2.54.gbin
beta@paren.lisp.uoregon.edu:images/dino-lisp-43-titanium-
d1.4.0.2.54.gbin
You should save your configuration file to bootflash by doing:
copy run bootflash:save-config
Then do a "write erase" after you load the two images into your
Titanium. When the system comes up, enter a temporary admin password
and answer "no" to the setup dialogue. Then do:
copy bootflash:save-config run
Can you please send a quick email to lisp-beta so we know when you
have upgraded.
Also at the end I have included the latest lisp-commands.txt file.
What you need to know for this release:
1) You need to configure "ip lisp alt-vrf lisp" since we changed
several times
the name for this command. If you do not do this, LISP-ALT
will not work for
you.
2) "ip lisp forward-on-alt-miss" has been deprecated. So if you
see the command
go away after you upgrade, no worries, we do this by default.
Thanks in advance for your effort and feedback. Dave will follow up
on the boxes he has upgraded and give you guidelines for deploying
IPv6 on the LISP-ALT infrastructure.
Dino/DaveM/Vince/Darrel/Scott/DaveO/Eliot/Dana/Elizabeth
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-43: Wed Jul 2 03:08:38 PDT
2008
Released to lisp-alpha and lisp-beta
o Fix "debug {ip | ipv6} mapping data" so you don't get both IPv4
and IPv6
debugging when turning one or the other on.
o Do test for ip_lisp_initialized in ip_input() so the LISP API
isn't called
when the LISP is not configured.
o Fix not returning an IPv6 Map-Reply. The Map-Reply building code
for IPv6
had two problems. It was reutrning a NULL mbuf pointer when
processing
a legit Map-Request. So we had an mbuf leak. And it allocated two
buffers
for the Map-Reply. One for the IPv6 header and one for the Map-
Reply payload
(including UDP header). Only the second one was sent with garbage
in the
first 40 bytes. This could have caused a potential crash as well.
o Updated to DC-OS 4.0(2.54) (the post-released version). Hopefully
we picked
up some bugfixes we have seen (and no new bugs).
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-42: Wed Jun 25 20:49:52 PDT
2008
Released to lisp-alpha
o Fixed crash in netstack, we were trying to do a hash on a
destination
NULL pointer when getting the source locator for a Map-Reply. Busted
for IPv6 only.
o When copying the source address and destination address of a Map-
Request
over IPv6, we copied to wrong variables and hence swapped them. Nice
finds Dave!
o Needed "key ip ipv6" for "debug .. mapping .." commands.
o When finding all more specific matches for a EID-prefix in a Map-
Reply,
don't look at entrries in complete state and entries in incomplete
state
that don't match should not be considered as a spoof alert if one
entry
does have a nonce match.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-41: Tue Jun 24 14:33:14 PDT
2008
Released to lisp-alpha
o Print out correct debug entry "data probe packet" or "Map-Request
message"
when either is done. Was always printing "data probe packet".
o Fix double free problem in sending an IPv6 Map-Request.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-40: Sun Jun 22 18:30:31 PDT
2008
Released to lisp-alpha
o When building either a data-triggered or request-triggered Map-
Reply,
print the source and destination addresses in "debug {ip | ipv6} lisp
mapping".
o Change equality check to inequality check to determine if Map-
Request
came in on the ALT VRF. If so, go get a locator for the EID to use as
the Map-Reply source.
o Do a locator-based spoof detection when processing a Map-Reply. That
means that if the source address of a Map-Reply is not in every
locator-set for each EID record in a Map-Reply, we assume the source
is spoofing the real ETRs for the site. Print a "debug {ip | ipv6}
lisp mapping" invoked debug message when this happens.
o Add "key ip ipv6" for all configuration commands that have per
address family parameters, so we don't have the same replacement
semantic problem we did with "{ip | ipv6} lisp alt_vrf".
o Source address of Map-Request could also be bogus when mix-locators
are configured in a database-mapping command. Fixed that.
o In ip_lisp_encapsualte() and ipv6_lisp_encapsulate(), check to see
if
"ip lisp itr" and "ipv6 lisp itr" is configured, respectively. If
not,
don't encapsulate.
o Remember seeing at times where we saw a locator treated like an
EID and
we tried to encapsulate a packet that had locators in the header?
Well,
passing mbuf flags from the LISP process through the IP API are not
passed.
Therefore, Map-Requests built by the LISP process was going through
"ITR processing". Now fixed.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-39: Fri Jun 20 12:16:43 PDT
2008
Released to lisp-alpha
o Fix bug where you can't have both "ip lisp alt-vrf" and "ipv6 lisp
alt-
vrf" in the configuration at the same time.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-38: Thu Jun 19 12:16:43 PDT
2008
Released to lisp-alpha
o Fixed crash when building a Map-Reply. We compute the wrong
locator count
because we use the same loop to select a source address for the Map-
Reply
which errorneous filters the locators we count. Happens only with
mixed
locators in database-mapping commands.
o "no ipv6 route <prefix> null0" isn't removing routes from the
U6RIB. Fixed
now.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-37: Wed Jun 18 18:02:08 PDT
2008
Released to lisp-alpha
o Do not allow configuration of a PTR when an ETR or database-
mapping commands
are configured. Don't allow configuration of an ETR or allow
database-mapping
comamnds when a PTR is already configured.
o Remove code for above bullet. ;-) We decided later the restriction
isn't
necessary. You can have a PTR be an ETR.
o Change command "{ip | ipv6} lisp proxy-itr" to "{ip | ipv6} lisp
proxy-itr
<local-rloc>" so when a PTR is configured and now that we require no
"{ip | ipv6} database-mapping" commands, we need a locator
configured for
sending encapsulated packets and Map-Requests.
o Fix crash of doing recursive encapsulation in the ITR when an EID
is not
in the ALT VRF and you don't have "ip lisp forward-on-alt-miss"
configured.
This was probably the hard to chase problem that Andrew, Darrel,
and Dave
all had too when we were changing command names and the above
command was
not configured in the ITR for a short window of time.
o Map-Replies were not be forwarded through a PTR. When Map-Replies
are not
address to local system, they need to be forwarded on the default
VRF.
o Moved redundant calls to LISP decapsulation code in IP and IPv6
where we
want to deliver packets to local clients.
o Don't stop LISP process when both "no ip lisp itr" and "no ip lisp
etr" is
typed and "ip lisp proxy-itr" is still configured.
o Brought in Rick's patch for MSDP and BGP which supports multi-AS
in one
process.
o Removed command "{ip | ipv6} lisp itr forward-on-alt-miss". We do
this by
default now. Having it was a way to do LISP 1.0 and LISP-ALT at the
same
time. If you want to use LISP 1.0, just don't configure "{ip |
ipv6} lisp
alt-vrf" command. Think it's better to be all or nothing here. More
clear
behavior. PLEASE REMOVE THIS FROM YOUR CONFIGURATION FILES.
o A lot of restructing in ip_lisp_decapsulate() and
ipv6_lisp_decapsulate() to
minimize LISP API calls and doing extra checks. Z and I went
through an
entire test suite for this. ITRs, PTRs, and ETRs are fully
functional using
LISP+ALT.
o Fixed a bug in lisp_verify_nonce() which causes a nonce spoof
alert for
received Map-Replies for IPv6 EID-prefixes with long mask-lengths
(i.e. 112).
o Fix bug where we would select a v4 locator when building a v6 Map-
Reply.
o Added more debug for why a nonce is not matched when processing a
Map-Reply.
-------------------------------------------------------------------------------
Release for LISP beta version dino-lisp-36: Sun Jun 15 20:12:36 PDT
2008
Released to lisp-alpha
o Fix "ipv6 route ... null0" problem. We were treating null0 as a
candidate
for recursive resolution when we had all the info we needed to add
the
route to the U6RIB when the command was configured.
o Add tag support ot the "ipv6 address" command. The "ipv6 route"
command
didn't have it either. So added tag to that too.
o Mixed locator support. Up to now we supported v4-EIDs with v4-
RLOCs. Now
we can support v4-EIDs with a mixed locator-set of v4 or v6 RLOCs
or all
v6 RLOCs and v6-EIDs with a mixed locator-set of v4 or v6 RLOCs or
all
v4 RLOCs. Note that if you use mixed-locators on the ITR, the ETR
must
have "ip lisp {itr,etr}" and "ipv6 lisp {itr,etr}" commands
configured.
o Fixed bug when packets are sent and recieved in the management VRF
and LISP is enabled on the box, it will drop packets rather than let
IP or IPv6 forward them. The high-level symptom is that scp doesn't
work until "no feature lisp" is typed.
o Change printing "Inner header ..." debug from "debug {ip | ipv6}
lisp packet"
to "debug {ip | ipv6} lisp packet detail".
o Added "debug {ip | ipv6} lisp packet encap" to just show "LISP
encapsualte
..." debug messages and "debug {ip | ipv6} packet decap" to just
show "LISP
decapsulate ..." debug messages.
-------------------------------------------------------------------------------
LISP Command Support in DC-OS (NX-OS)
------------------------------------
Thu Jun 19 11:51:20 PDT 2008
This document describes how you configure and manage the LISP
protocol on
NX-OS (aka DC-OS).
Global Commands
---------------
[no] {ip | ipv6} lisp itr
Configures LISP Ingress Tunnel Router (ITR) functionality. 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-to-RLOC map cache lookup
is
performed and the Locator associated with the cached entry will
be
used as the destination address in the outer header. Otherwise,
the action that is taken depends on the mapping database
algorithm
used. If "{ip | ipv6} lisp alt-vrf <vrf-name>" is used, then the
ITR has been configured to use LISP-ALT where a Data Probe or a
Map-Request is sent depending if the "{ip | ipv6} lisp itr
send-map-request" command is configured.
[no] {ip | ipv6} lisp etr
Configures LISP Egress Tunnel Router (ETR) functionality. When an
ETR is configured, it should also be configred with database
mapping entries (from the "{ip | ipv6} lisp etr database-mapping"
command) so the ETR knows what EID-prefixes and corresponding
locators are used for the LISP site. It is recommended that an
ITR
and ETR be configured in the same device. However, the LISP
architecture doesn't require it and the functionality can occur
in
different devices.
[no] {ip | ipv6} lisp proxy-itr <locator>
Configures the router as a Proxy ITR (PTR) used to inject a very
coarse prefix into the underlying core routing to attract packets
from non-LISP sites destined for LISP-sites. When this command is
used any packet received by this PTR destined for a prefix in the
default VRF's routing table with a next-hop of null0 will be LISP
encapsulated proivded the destiation is in the LISP-ALT routing
table. The default setting for this command is disabled. The
address <locator> is used as a source address, from the locator
namespace, when a PTR encapsulates a data packet, sends a Data
Probe, or a Map-Request message.
This command implements LISP PTRs according to Internet Draft
draft-lewis-lisp-interworking-xx.txt.
[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 Map-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 Map-Reply. Multiple commands are used
to configure multiple locators for a given EID-prefix. When
multiple
ETRs are used at a site, these command must be configured in all
the ETRs (even when the locator address is not for the local
ETR).
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.
The locator value <locator> can be from either the IPv4 or IPv6
address
families and can be mixed for the same <eid-prefix> in multiple
commands.
[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.
[no] {ip | ipv6} lisp itr map-cache <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. The
locator-set
can be up to size 4. Where is element in the locator-set is a 3-
tuple
of locator address, priority, and weight. This mapping is used
in the ITR. This command can be entered multiple times to
configure multiple locator 3-tuples 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 the 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 incomplete-cache-rate <pps>
This is the rate in packets-per-second the ITR should send
packets
while a mapping is waiting to arrive. An entry in this state is
known to be in "Incomplete State".
[no] {ip | ipv6} lisp itr send-map-request
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
the ITR is configured to use LISP-ALT (using the "ip lisp alt-
vrf"
command), the Map-Request is sent on the GRE tunnel based on a
EID
lookup in the URIB for the 'lisp' VRF (the VRF configured on
the "ip
lisp alt-vrf" command). The 'lisp' VRF can be populated by using
BGP via the LISP-ALT specification or by use of static routes.
In a
low-opex ITR configuration, when BGP is not used but a GRE
tunnel is
configured, a static route is used to point which way the Map-
Request
should be sent.
[no] {ip | ipv6} lisp itr map-request-source <source-address>
Configures an IP or IPv6 address used as a source address for
a LISP Map-Request message. Typically, this is one of the RLOC
addresses
configured from the "ip lisp etr database-mapping" command but
there
are cases if your xTR is behind a NAT, that you may want to
configure
a specific source address for a Map-Request message.
[no] {ip | ipv6} lisp alt-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 the default VRF. This command defaults to using the default
VRF
which results in LISP 1.0 operation, that is the Data Probe or
Map-Request is sent on the underlying topology. However, this
will not
work if EIDs are not in the underlying routing (the goal is to
remove
such routes from the underlying topology). When this command is
configure, the use of the LISP+ALT mapping database algorithm
will be
in use.
This command implements LISP+ALT according to Internet Draft
draft-fuller-lisp-interworking-xx.txt.
[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. This
feature
is documented in draft-lewis-lisp-interworking (and called LISP-
NAT)
where a site that upgrades to LISP can withdraw their site
addresses
from the DFZ Internet (because they are now used as EID-
prefixes) can
talk to non-LISP sites but providing them routable addresses
that are
out of the locator namespace (which are routable).
This command implements LISP-NAT according to Internet Draft
draft-lewis-lisp-interworking-xx.txt.
[no] {ip | ipv6} lisp etr map-cache-ttl <hours>
Configures the TTL value inserted in Map-Reply messages. The
granularity
cannot be less than 1 hour. The default value is 24 hours.
Debug Commands
--------------
[no] debug-filter {ip | ipv6} lisp vrf {<vrf-name> | all}
Configures which VRF the following debug commands will apply
to. When
you are using LISP-ALT and have a 'lisp' VRF configured, you do
not
need to use this command. Debug in the default VRF will tell
you when
"VRF crossover" happens.
[un]debug {ip | ipv6} lisp packet [<eid-prefix>] [encap | decap]
[translate] [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
keyword "translate" is specified, any LISP translation activity
based
on configuration of "ip lisp translate" commands will be
displayed.
When "all" is specified all the forwarding debugs available are
displayed.
[un]debug {ip | ipv6} lisp mapping {control | data}
Logs Map-Request, Map-Reply, and mapping entry activity. When
"control"
is specified you get messages from the DC-OS LISP process. When
"data"
is specified, you get messages from the DC-OS Netstack process.
Show Commands
-------------
show {ip | ipv6} lisp [vrf <vrf-name>]
Displays LISP ITR, ETR, and PTR 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.
-------------------------------------------------------------------------------