Age | Commit message (Collapse) | Author | Files | Lines |
|
Main Enhancements:
- Protocol Independent FIB API
- Hierarchical FIB entries. Dynamic recursive route resolution.
- Extranet Support.
- Integration of IP and MPLS forwarding.
- Separation of FIB and Adjacency databases.
- Data-Plane Object forwarding model.
Change-Id: I52dc815c0d0aa8b493e3cf6b978568f3cc82296c
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I5b282964330f4c14f7991453ee02c455a8d367ea
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I1bc2098e79ce753f3d72f05f2fcac9ab00d0d052
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: If96d9ff23a7aacdb684494f854d4029f55837065
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I106352a6da0fad2b91dc8593f8d6d664af3113a8
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
- cleaned up some of the LISP APIs
- added support for mac in dp APIs
Change-Id: I11d419a30d73ddbf6554768d6dc2a09cc5a6e072
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
This introduces support for layer 2 overlays with LISP. Similarly to L3,
all tenant packets to be encapsulated are captured by an interface, but
the mapping (layer binding) instead of being between an L3 VRF and a
LISP VNI, it is between and an L2 bridge domain and a VNI. At a high
level, this results in two important properties:
1) the source and destinations of all packets flooded in the
bridge-domain are mapped via the LISP control plane and the replies are
converted into data-plane tunnels tracked via a LISP specific
source/dest L2 FIB
2) All packets reaching the interface and matching a source/dest L2 LISP
FIB entry are L3 (IP4/6) encapsulated.
This is solely a unicast feature, therefore at this time ARPs are not
handled in any special way.
Change-Id: I0b7badcd7c6d5166db07d4acd2cc4ae7fba3e18e
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Lisp enable flag is enforced. DP API should not be call if the dp is disable.
Change-Id: I265cf3ea0460987f3fd5fd84b43127dd3b1c43c3
Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
|
|
This patch adds an enable/disable API/CLI for control plane
which calls similar functions for data plane. When re-enabling
it also re-populates dataplane with tunnels and interfaces.
Change-Id: Id8c3d6af90ecc0be331d502756914b1f62824046
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: Ib22ec807d2b74b7c3cb37f66052cd07bc4d896db
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
API:
lisp_gpe_enable_disable_dump
Change-Id: I1c8e78f00f9a3f99c1f2f54884af565292e4ccf8
Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
|
|
The implementation mimics that of the ip4 data-plane. Therefore, a new
lgpe-ip6-lookup lookup node is introduced for ip6 source lookups, a
lisp-gpe-ip6-input node for decapsulating ip6 encapsulated packets and
the tx function of the lisp-gpe interface is updated to support any mix
of v4 and v6 in underlay and overlay.
Change-Id: Ib3a6e339b8cd7618a940acf0dd8e61c042fd83dd
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
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>
|
|
I got many warnings at the link step with gcc version 5.3.1 20160225 (Ubuntu 5.3.1-10ubuntu2):
/usr/bin/ld: Warning: size of symbol `cop_input_node' changed from 112 in vnet/cop/.libs/cop.o to 168 in vnet/cop/.libs/node1.o
/usr/bin/ld: Warning: size of symbol `ethernet_input_node' changed from 112 in vnet/.libs/interface.o to 136 in vnet/ethernet/.libs/node.o
/usr/bin/ld: Warning: size of symbol `l2output_node' changed from 112 in vnet/l2/.libs/l2_efp_filter.o to 120 in vnet/l2/.libs/l2_output.o
/usr/bin/ld: Warning: size of symbol `srp_input_node' changed from 112 in vnet/srp/.libs/format.o to 136 in vnet/srp/.libs/node.o
/usr/bin/ld: Warning: size of symbol `vxlan_encap_node' changed from 112 in vnet/vxlan/.libs/vxlan.o to 128 in vnet/vxlan/.libs/encap.o
/usr/bin/ld: Warning: size of symbol `vxlan_input_node' changed from 112 in vnet/vxlan/.libs/vxlan.o to 144 in vnet/vxlan/.libs/decap.o
...
Looking at vlib_node_registration_t, I think the reason is that
the char * next_nodes[] could be bigger where the variable is defined
in .c file.
We should mark global variables as external in header files.
Some of them can be made static.
Change-Id: Ieb6961fd08180c9a69e1d884852703f3eb23f23f
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
|
|
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|