On 9/30/20 7:23 PM, Stephen Suryaputra wrote:
> On Thu, Sep 24, 2020 at 08:41:54AM -0600, David Ahern wrote:
>>> We have multiple options on the table right now. One that can be done
>>> without writing any code is to use an nft prerouting rule to mark
>>> the packet with iif equals the tunnel and
On Thu, Sep 24, 2020 at 08:41:54AM -0600, David Ahern wrote:
> > We have multiple options on the table right now. One that can be done
> > without writing any code is to use an nft prerouting rule to mark
> > the packet with iif equals the tunnel and use ip rule fwmark to lookup
> > the right table
On 9/24/20 7:48 AM, Stephen Suryaputra wrote:
> On Wed, Sep 23, 2020 at 07:47:16PM -0600, David Ahern wrote:
>> If I remove the fib rules and add VRF route leaking from core to tenant
>> it works. Why is that not an option? Overlapping tenant addresses?
>
> Exactly.
>
>> One thought to get around
On Wed, Sep 23, 2020 at 07:47:16PM -0600, David Ahern wrote:
> If I remove the fib rules and add VRF route leaking from core to tenant
> it works. Why is that not an option? Overlapping tenant addresses?
Exactly.
> One thought to get around it is adding support for a new FIB rule type
> -- say l3
On 9/23/20 5:50 PM, Stephen Suryaputra wrote:
>
> I have a reproducer using namespaces attached in this email (gre_setup.sh).
Thanks for the script. Very helpful.
Interesting setup.
# +---+ +--+ +--+ +---+
# | h0| |r0| |r1| |h1 |
On Tue, Sep 22, 2020 at 09:39:36AM -0600, David Ahern wrote:
> >
> > We have a use case where there are multiple user VRFs being leak routed
> > to and from tunnels that are on the core VRF. Traffic from user VRF to a
> > tunnel can be done the normal way by specifying the netdev directly on
> > t
On 9/22/20 7:11 AM, Stephen Suryaputra wrote:
> Hi,
>
> We have a use case where there are multiple user VRFs being leak routed
> to and from tunnels that are on the core VRF. Traffic from user VRF to a
> tunnel can be done the normal way by specifying the netdev directly on
> the route entry on t
Hi,
We have a use case where there are multiple user VRFs being leak routed
to and from tunnels that are on the core VRF. Traffic from user VRF to a
tunnel can be done the normal way by specifying the netdev directly on
the route entry on the user VRF route table:
ip route add via dev
But tra
