|
With this change, one lisp-gpe interface is created per vrf/overlay
tenant and its tx node is used as encapsulator (or tunnel ingress). For
all intents and purposes, the tx node inherits all functions previously
performed by the lisp-gpe-encap node and it maintains said node's
position in lisp-gpe's data-path graph. Chiefly, this opens the
possibility to chain interface features, like IPSec, transparently with
LISP. Furthermore, it brings basic data plane support for vrfs and LISP
instance-ids (or virtual network instances as per RFC7364).
Other changes include improvements to lisp-gpe enable and disable
sequences and corresponding API/VAT fixes.
Change-Id: I085500450660a976b587b1a720e282f6e728d580
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Control Plane
-------------
In essence, this introduces basic support for map-request/reply
processing, the logic to generate and consume such messages, including
SMRs, a control-plane backend, consisting of an eid-table, locator and
locator-set tables, and CLI to interact with it. Naturally, we can now
serialize/deserialize LISP specific types: addresses, locators,
mappings, messages. An important caveat is that IPv6 support is not
complete, both for EIDs and RLOCs.
Functionally, the DP forwards all packets it can't handle to the CP
(lisp_cp_lookup node) which takes care of obtaining a mapping for the
packet's destination from a pre-configured map-resolver using the LISP
protocol. The CP then caches this information and programs the DP such
that all new packets with the same destination (or within the covering
prefix) are encapsulated to one of the locators retrieved in the
mapping. Ingress traffic-engineering is not yet supported.
Data Plane
----------
First of all, to enable punting to the CP, when LISP GPE is turned on a
default route that points to lisp_cp_lookup is now inserted. The DP
also exposes an API the CP can use to program forwarding for a given
mapping. This mainly consists in allocating a tunnel and programming the
FIB such that all packets destined to the mapping's prefix are forwarded
to a lisp-gpe encapsulating node.
Another important change done for lisp forwarding is that both source
and destination IP addresses are considered when encapsulating a packet.
To this end, a new FIB/mtrie is introduced as a second stage, src
lookup, post dst lookup. The latter is still done in the IP FIB but for
source-dest entries, in the dest adjacency the lookup_next_index points
to a lisp lookup node and the rewrite_header.sw_if_index points to the
src FIB. This is read by the lisp lookup node which then walks the src
mtrie, finds the associated adjacency, marks the buffer with the index
and forwards the packet to the appropriate next node (typically,
lisp-gpe-encap).
Change-Id: Ibdf52fdc1f89311854621403ccdd66f90e2522fd
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
Damjan Marion
Florin Coras
Ed Warnicke