Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I56461c5d892ce223d1160fb57313ca1c51db9a23
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
* Map-register
* Map-notify
* RLOC probing
Change-Id: I7f6295376b21cd67805446dfd1c1033acead2d4b
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change the adjacency completion model to pull not push.
A complete adjacency has a rewirte string, an incomplete one does not. the re-write string for a peer comes either from a discovery protocol (i.e. ARP/ND) or can be directly derived from the link type (i.e. GRE tunnels). Which method it is, is interface type specific.
For each packet type sent on a link to a peer there is a corresponding adjacency. For example, if there is a peer 10.0.0.1 on Eth0 and we need to send to it IPv4 and MPLS packets, there will be two adjacencies; one for the IPv4 and one for the MPLS packets. The adjacencies are thus distinguished by the packets the carry, this is known as the adjacency's 'link-type'. It is not an L3 packet type, since the adjacency can have a link type of Ethernet (for L2 over GRE).
The discovery protocols are not aware of all the link types required - only the FIB is. the FIB will create adjacencies as and when they are required, and it is thus then desirable to 'pull' from the discovery protocol the re-write required. The alternative (that we have now) is that the discovery protocol pushes (i.e. creates) adjacencies for each link type - this creates more adjacencies than we need.
To pull, FIB now requests from the interface-type to 'complete' the adjacency. The interface can then delegate to the discovery protocol (on ethernet links) or directly build the re-write (i.e on GRE).
Change-Id: I61451789ae03f26b1012d8d6524007b769b6c6ee
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: If88e4161e0944b657e6183b7b44348f7f46ba0a8
Signed-off-by: Florin Coras <fcoras@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
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>
|
|
- refactor VAT so it won't cache data
- remove unused filter flag from locator dump API call
- json structure changed for locator and EID table dump calls
- remote mapping VAT cli now accepts string for negative mapping action
Change-Id: I776fb50659aaa7e98ad93715d282a83f78287344
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: I29b84c44c12ab746e9e61c30efa0ac3418d1a09a
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I0db53af96b925ec0d975dd77f471804b61351aec
Signed-off-by: Filip Tehlar <ftehlar@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>
|
|
Change-Id: I60ef5218110e596f77d11e3949284a7a7af7dedb
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>
|
|
- fix bug
- refactoring code
Change-Id: I2c330f3fbdead567b65c889cfffc2562d99b61db
Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
|
|
Fix bug, can`t remove static remote mapping,
small update in LISP remote mapping API.
Change-Id: Ide32485a1a0d2cf08829d544500fa2755214b8cc
Signed-off-by: Andrej Kozemcak <akozemca@cisco.com>
|
|
Change-Id: Ib707d252e624e3c1c4ac261fd3cef17b097633e5
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: Ie5e6751fd791e7ca728522632332abe442a1a75b
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
- avoid code duplication by using only one function for
insertion/updating of remote mappings into map-cache. Static remote
mappings are now inserted using this function as well and therefore
the code does not try to build forwarding entries out of them now.
- bring up lisp dp interfaces when a vni is bound to a vrf.
- ensure eids are cleaned-up before parsing control plane messages
- ensure map-requests are always sent to default fib
- new API to insert lisp adjacencies as opposed to remote mappings which
should be replaced post merged in CSIT
- reorganize and group functions according to their purpose and use. No
need to pre-declare internal functions now.
- this does not touch locator-set logic
Change-Id: Ibcfc0f2d9c1bc1c9eab6e83c1af1b4cf9302ac10
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I80f05a222cb0f728ad2460efe33955e781b6849f
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Example output:
DBGvpp# sh lisp eid
EID type locators
[100] 6.0.2.0/24 local(ls1) host-intervpp1
[200] 6.0.2.0/24 local(ls2) host-intervpp1
[100] 6.0.4.0/24 remote 6.0.3.2
[200] 6.0.99.0/24 local(ls3) local0
host-intervpp1
[0] 6.0.0.0/16 remote
Change-Id: I69200bf7636167bce931def88828503a75496f4b
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: I892c001cfdff9d8d93e646641d96520beb3c6265
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Change-Id: I79e3915fa61b497e6b586babcdf093937af07b2b
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Make sure when selecting the local and remote locator pair for a
data-plane tunnel that the local locator has a route, in the FIB,
to the remote one.
Change-Id: Idbc8a28a8ede786c11ef98cb18eba4a78c4a228e
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: Icbf3e269471ee0fc1d21f842b2ea220328a0f891
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: Ifce3f2bdcba099157a42d0b694f3161b9f700ed2
Signed-off-by: Filip Tehlar <ftehlar@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>
|
|
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I802700ad832de1dc6f4a1981e8985aa6e926c8ad
Signed-off-by: Filip Tehlar <ftehlar@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>
|