Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

[Carmine Scarpitta]

Hi David,

Regarding your question. 

Our use-case is more than doing lookup into a VRF. 

What we are working on a multi-tenant automated DC fabric that supports 
overlay, traffic engineering (TE) and service function chaining (SFC). 
We are leveraging the SRv6 implementation in Linux. 
 
For the overlay we leverage: 
- SRv6 T.Encaps to encapsulate both IPv4 and IPv6 traffic of the tenant 
   (T.Encaps is supported since kernel 4.10) 
- SRv6 End.DT4 to decapsulate the overlay encapsulation and does the 
lookup inside the tenants VRF (this is the only missing piece)

For TE we leverage: 
- SRv6 End and End.X functions to steer traffic through one or more midpoints
to avoid congested links, etc. (End and End.X are supported since kernel 4.14)

For SFC we leverage some network functions that supports SRv6: 
- iptables already supports matching SRv6 header since kernel 4.16. 
- There is some work in progress of adding support to nftables as well. 

On top of that we are using BGP as a control plane to advertise the VPN/Egress 
tunnel endpoints. 

Part of this is already running in production at LINE corporation [1]. 

As you can see, what is missing is having SRv6 End.DT4 supported to do 
decapsulation and VRF lookup.  

We introduced this flag to avoid duplicating the IPv4 FIB lookup code. 

For the "tbl_known" flag, we can wrap the check of the flag inside 
a "#ifdef CONFIG_IP_MULTIPLE_TABLES" directive. 
If CONFIG_IP_MULTIPLE_TABLES is not set, we won't do any check.  

Thanks, 
Carmine 


[1] https://speakerdeck.com/line_developers/line-data-center-networking-with-srv6


On Tue, 18 Feb 2020 21:29:31 -0700
David Ahern <dsahern@xxxxxxxxx> wrote:

> On 2/18/20 7:49 PM, Carmine Scarpitta wrote:
> > Hi David,
> > Thanks for the reply.
> > 
> > The problem is not related to the table lookup. Calling fib_table_lookup and then rt_dst_alloc from seg6_local.c is good.
> > 
> 
> you did not answer my question. Why do all of the existing policy
> options (mark, L3 domains, uid) to direct the lookup to the table of
> interest not work for this use case?
> 
> What you want is not unique. There are many ways to make it happen.
> Bleeding policy details to route.c and adding a flag that is always
> present and checked even when not needed (e.g.,
> CONFIG_IP_MULTIPLE_TABLES is disabled) is not the right way to do it.


-- 
Carmine Scarpitta <carmine.scarpitta@xxxxxxxxxxx>