Hi Jon,
The new API does not function correctly in master at this time. If you want to
ride on the bleeding edge with the new API, the code I intend to commit is
(complete AFAICT) here:
https://gerrit.fd.io/r/#/c/7819/
it’s not committed yet because I need to do an n-step dance with CSIT changes
to make the verify jobs pass. This will take a few weeks (because vacations).
Regards,
neale
-----Original Message-----
From: Jon Loeliger <j...@netgate.com>
Date: Tuesday, 29 August 2017 at 14:49
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) <nra...@cisco.com>
wrote:
> Hi Jon,
>
> (apologies for repeating some of what you already know, but from the top…)
>
> A VRF is virtualisation of a router’s *IP* routing and forwarding. VRFs
are typically identified by a name (and again typically named to refer to the
VPN customer they represent). IP packets in VRF RED must be separate from IP
packets in VRF BLUE. By ‘IP’ in this context we mean IPv4 and IPv6 and unicast
and multicast (known as sub-address families or SAFIs). To provide this
separation we therefore need 4 ‘tables’ per-VRF, one for each SAFI. A ‘table’
in this context is the well known longest-prefix matching DB. Tables are known
by a unique per-AFI ID (note per-AFI not per-SAFI, so IPv4 unicast and
multicast share the same table-id). It is the client’s responsibility to
associate unique table IDs to tables within all of its VRFs. The client is free
to choose the table-ID from the full u32 range. So, bottom line, in the context
of IP forwarding a table (and its associated ID) refer to an instance of a LPM
DB.
>
> Despite code comments and variable naming, VPP does not maintain the
concept of a VRF, i.e. it does not maintain a grouping of ‘tables’. At the
client interface VPP deals only with table IDs – i.e. an identifier that the
client provided for a given LPM DB. All APIs that claim to accept a VRF index
should be renamed to accept an IP table ID.
> As with all things VPP the allocation of the data-structure that
represents the LPM-DB comes from a memory pool. This data-structure thus has an
associated pool index – this is the FIB index. So, there is a one to one
mapping between the externally visible and client assigned ‘table ID’ and the
internal use only ‘FIB index’. Both are a u32, neither are strictly typed…
>
> With regards to the creation of tables, I’m currently working on the API
you discovered – ip_table_add_del. With this API the client instructs VPP to
add/delete a ‘table ID’ (as discussed above). The VPP FIB has the concept of
ownership or ‘sourcing’ of its resources. Sources can be external (i.e. the CLI
or the API) or internal (e.g. LISP and DHCP). FIB resources are only completely
free’d was there are no more sources that are referencing it.
> My intention with the table add/delete API is that the client can add the
table then insert routes and bind interfaces. If the client then deletes the
table its routes will be purged. The table will then be deleted iff it held the
last reference. With the introduction of this API VPP will insist that it has
been called to create the table before any routes or interfaces refer to it.
> The current behaviour is that tables can be created either by setting an
interface into that table, or by setting the ‘create_vrf_if_needed’ flag in a
route add. There is no means to delete it, hence my new API work.
>
> Hth,
> neale
Neale,
That helps tremendously!
I am poised to add a bunch of route-related API calls to our project.
Are the "new" IP Route APIs in place at this time? Or shall I wait a bit
and watch for a bit still?
Thank you!
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
