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
