Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I12892fa571cc50e0541d6463a8b68e1b618edd9f
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
This is a work-in-progress basic BFD session handling. Only
asynchronous mode is supported at the moment. Setting the session flags
doesn't work.
Change-Id: Idba27f721b5c35be5a66a6d202a63d23ff7ecf6f
Signed-off-by: Klement Sekera <ksekera@cisco.com>
|
|
By default, VPP replies with ICMP error: port unreachable when receives
an ‘unknown’ UDP (destination port with no registered listener) packet.
An existing punt() API is extended to accept ALL (~0) as a L4 port
number and if used redirects all ‘unknown’ UDP packets to the host.
New ‘all’ option is added to the “set punt udp” CLI as well.
Change-Id: I444fc5e32ffa3f0f085bb17708bf32b883ba09df
Signed-off-by: Alexander Popovsky (apopovsk) <apopovsk@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>
|
|
PatchSet4: consolidate code as per comments.
PatchSet3: simplify the code using ip_udp_encap_one/two
PatchSet2: consolidate comments and indent style
Change-Id: Ia8b43f854a46d77e838e198566200ad28fd72472
Signed-off-by: Hongjun Ni <hongjun.ni@intel.com>
|
|
Thanks to Chris Luke for reporting.
Change-Id: I4f2ac5bb0eb565738755ddb00e8c918134ff67b6
Signed-off-by: Florin Coras <fcoras@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>
|
|
Refactors the VXLAN node to work with both IPv4 and IPv6 transports.
There is a discussion thread for this change at
https://lists.fd.io/pipermail/vpp-dev/2016-March/000279.html
Note that this changes the binary configuration API to support both
address families; each address uses the same memory for either address
type and a flag to indicate which is in use. This also includes changes
to the Java API to support both address families.
The CLI and VAT syntax remains unchanged; the code detects whether an
IPv4 or an IPv6 address was given.
Configuration examples:
IPv4 CLI: create vxlan tunnel src 192.168.1.1 dst 192.168.1.2
vni 10 encap-vrf-id 0 decap-next l2
IPv6 CLI: create vxlan tunnel src 2620:124:9000::1 dst 2620:124:9000::2
vni 16 encap-vrf-id 0 decap-next l2
IPv4 VAT: vxlan_add_del_tunnel src 192.168.1.1 dst 192.168.1.2
vni 10 encap-vrf-id 0 decap-next l2
IPv6 VAT: vxlan_add_del_tunnel src 2620:124:9000::1 dst 2620:124:9000::2
vni 16 encap-vrf-id 0 decap-next l2
TODO: The encap path is not as optimal as it could be.
Change-Id: I87be8bf0501e0c9cd7e401be4542bb599f1b6e47
Signed-off-by: Chris Luke <chrisy@flirble.org>
|
|
Change-Id: I22cb443c4bd0bf298abb6f06e8e4ca65a44a2854
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: If666cda99a5fd92e904898ced40bcf2b5ac2d3a5
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I4734b248f512e223703d234d28542257af1a8074
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>
|
|
Change-Id: Ib246f1fbfce93274020ee93ce461e3d8bd8b9f17
Signed-off-by: Ed Warnicke <eaw@cisco.com>
|