File: api.rst

package info (click to toggle)
networking-bgpvpn 23.0.0-2
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 1,500 kB
  • sloc: python: 8,655; sh: 94; makefile: 43
file content (69 lines) | stat: -rw-r--r-- 2,433 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
..
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.

 http://creativecommons.org/licenses/by/3.0/legalcode

===
API
===

This API is documented in the `Neutron API Reference <https://docs.openstack.org/api-ref/network/v2/#bgp-mpls-vpn-interconnection>`_.

ADMIN
=====

Configuration
=============

On VXLAN VNI
------------

.. note:: This feature is under development in the Queens release

VXLAN is one option among others that could be used for BGP E-VPNs.
When VXLAN is used on a hardware platform the use of a locally-assigned id
may not be always possible which introduces the need to configure a
globally-assigned VXLAN VNI.

The optional ``vni`` attribute is an admin-only parameter and allows the
admin to enforce the use of a chosen globally-assigned VXLAN VNI for the
said BGPVPN.

The default when no VNI is specified and the VXLAN encapsulation is used, is
to let the backend choose the VNI in advertised routes, and use the VNI in
received routes for transmitted traffic. The backend will conform to
E-VPN overlay specs.

If the ``vni`` attribute is set for a BGPVPN, the following is enforced:

* the routes announced by the backend will advertise the specified VNI (this
  relates to traffic sent from this BGP VPN to a Network or Router)

* for the routes received by the backend for this BGPVPN, and that carry a
  different VNI that the VNI specified for the BGPVPN the behavior may
  depend on the backend, with the recommended behavior being to
  liberally accept such routes.

If a backend does not support the approach recommended above of liberally
accepting routes with a different VNI, the check can be implemented as follows:

* when a route is imported, for each BGPVPN associated to the Network or
  Router and having a VNI defined:

  * the set of Route Targets of the route is intersected with the import_rts of
    the BGPVPN

  * if this intersection is non-empty the ``vni`` of the BGPVPN is retained

* the route is used to establish connectivity to the destination in the
  forwarding plane only if the advertised VNI is equal to all retained
  VNIs in the previous step

The above check is applied similarly for a Router associated to multiple BGP
VPN.

The backend is expected to provide troubleshooting information for the cases
when a route ends up not being used because the VNI check failed.

Valid range for the ``vni`` attribute is [1, 2\ :sup:`24`\ -1].