Hi Jon,
Some answers inline.
Thanks,
neale
-Original Message-
From: Jon Loeliger
Date: Thursday, 21 September 2017 at 16:42
To: "Neale Ranns (nranns)"
Cc: vpp-dev
Subject: Re: [vpp-dev] Static Route Data API Data Structures
On Tue, Aug 29, 2017 at 9:37 AM, Neale Ran
On Tue, Aug 29, 2017 at 9:37 AM, Neale Ranns (nranns) wrote:
>
> 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/
-Original Message-
From: Jon Loeliger
Date: Tuesday, 29 August 2017 at 21:23
To: "Neale Ranns (nranns)"
Cc: vpp-dev
Subject: Re: [vpp-dev] Static Route Data API Data Structures
>> As with all things VPP the allocation of the data-structure that
represents
>
Hi Jon,
Some answers inline.
Regards,
neale
-Original Message-
From: Jon Loeliger
Date: Tuesday, 29 August 2017 at 20:40
To: "Neale Ranns (nranns)"
Cc: vpp-dev
Subject: Re: [vpp-dev] Static Route Data API Data Structures
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ran
>> 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’
> A table doesn't know its Address Family, except by the inspection of
> the types of routes within it, right?
Ooo. My bad. Reading the ip_table_add_del API call, a Table
clearly knows what address family it holds:
autoreply define ip_table_add_del
{
u32 client_index;
u32 co
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) wrote:
> Hi Jon,
>
Neale,
> 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.
You say 4 h
changes
to make the verify jobs pass. This will take a few weeks (because vacations).
Regards,
neale
-Original Message-
From: Jon Loeliger
Date: Tuesday, 29 August 2017 at 14:49
To: "Neale Ranns (nranns)"
Cc: vpp-dev
Subject: Re: [vpp-dev] Static Route Data API Data Structur
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) 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.
Neale,
Also, for the benefit of other Wiki Doc Searchers, I have captured
y
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) 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 refe
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
-Original Message-
From: on behalf of Jon Loeliger
Date: Monday, 28 August 2017 at 01:36
To: vpp-dev
Subject: [vpp-dev] Static Route Data API Data Structures
VPP
VPP-ites,
I am delving into the world of static routes. I am clearly missing
some basic information and would like some help understanding
how static routes work.
For starters, I'm a little unclear on what exactly these items are,
or what they represent or hold, and their relationship to each ot
12 matches
Mail list logo
