GRE tunnels bound to VRF

GRE tunnels bound to VRF

[Ben Greear]

Hello,

Is there any (sane) way to tell a GRE tunnel to use a VRF for its
underlying traffic?

For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
gre interfaces and have that go out whatever the ethernet VRFs route to...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[Alexandre Ferrieux]

On 17/11/2024 19:40, Ben Greear wrote:
> Hello,
> 
> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
> underlying traffic?
> 
> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
> gre interfaces and have that go out whatever the ethernet VRFs route to...

A netns is vastly more flexible than a VRF, with much cleaner operation. In your
case I'd just move each eth to a separate netns, and create its GRE there.

Re: GRE tunnels bound to VRF

[Ido Schimmel]

On Sun, Nov 17, 2024 at 10:40:18AM -0800, Ben Greear wrote:
> Hello,
> 
> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
> underlying traffic?
> 
> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
> gre interfaces and have that go out whatever the ethernet VRFs route to...

You can set eth{1,2} as the "physical device" of gre{0,1}

ip link add name gre0 up type gre [...] dev eth1
ip link add name gre1 up type gre [...] dev eth2

The "physical device" can be any interface in the VRF, not necessarily
eth{1,2}.

Re: GRE tunnels bound to VRF

[Ben Greear]

On 11/17/24 2:41 PM, Alexandre Ferrieux wrote:
> On 17/11/2024 19:40, Ben Greear wrote:
>> Hello,
>>
>> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
>> underlying traffic?
>>
>> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
>> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
>> gre interfaces and have that go out whatever the ethernet VRFs route to...
> 
> A netns is vastly more flexible than a VRF, with much cleaner operation. In your
> case I'd just move each eth to a separate netns, and create its GRE there.
> 

I vastly prefer VRF since it is cleaner for my use case.  But glad to know
netns works well for you.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[Ben Greear]

On 11/18/24 1:00 AM, Ido Schimmel wrote:
> On Sun, Nov 17, 2024 at 10:40:18AM -0800, Ben Greear wrote:
>> Hello,
>>
>> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
>> underlying traffic?
>>
>> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
>> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
>> gre interfaces and have that go out whatever the ethernet VRFs route to...
> 
> You can set eth{1,2} as the "physical device" of gre{0,1}
> 
> ip link add name gre0 up type gre [...] dev eth1
> ip link add name gre1 up type gre [...] dev eth2
> 
> The "physical device" can be any interface in the VRF, not necessarily
> eth{1,2}.

Hello,

Thanks for that suggestion.

I'm trying to implement this, but not having much luck.  My current approach
is trying to put gre0 in one VRF, attached to a VETH device in a different VRF.

Would you expect that to work?

And also, is there any way to delete a gre netdev?  ip link delete gre0 doesn't
complain, and doesn't work.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[Ben Greear]

On 11/18/24 11:48 AM, Ben Greear wrote:
> On 11/18/24 1:00 AM, Ido Schimmel wrote:
>> On Sun, Nov 17, 2024 at 10:40:18AM -0800, Ben Greear wrote:
>>> Hello,
>>>
>>> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
>>> underlying traffic?
>>>
>>> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
>>> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
>>> gre interfaces and have that go out whatever the ethernet VRFs route to...
>>
>> You can set eth{1,2} as the "physical device" of gre{0,1}
>>
>> ip link add name gre0 up type gre [...] dev eth1
>> ip link add name gre1 up type gre [...] dev eth2
>>
>> The "physical device" can be any interface in the VRF, not necessarily
>> eth{1,2}.
> 
> Hello,
> 
> Thanks for that suggestion.
> 
> I'm trying to implement this, but not having much luck.  My current approach
> is trying to put gre0 in one VRF, attached to a VETH device in a different VRF.
> 
> Would you expect that to work?

I found some other problems with my config, will try this again now that some other
problems are solved...

> 
> And also, is there any way to delete a gre netdev?  ip link delete gre0 doesn't
> complain, and doesn't work.

I found answer to this, for reference, it seems gre0 is default instance built by the
ip_gre module when it is loaded, and used for special purpose.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[Ben Greear]

On 11/18/24 5:47 PM, Ben Greear wrote:
> On 11/18/24 11:48 AM, Ben Greear wrote:
>> On 11/18/24 1:00 AM, Ido Schimmel wrote:
>>> On Sun, Nov 17, 2024 at 10:40:18AM -0800, Ben Greear wrote:
>>>> Hello,
>>>>
>>>> Is there any (sane) way to tell a GRE tunnel to use a VRF for its
>>>> underlying traffic?
>>>>
>>>> For instance, if I have eth1 in a VRF, and eth2 in another VRF, I'd like gre0 to be bound
>>>> to the eth1 VRF and gre1 to the eth2 VRF, with ability to send traffic between the two
>>>> gre interfaces and have that go out whatever the ethernet VRFs route to...
>>>
>>> You can set eth{1,2} as the "physical device" of gre{0,1}
>>>
>>> ip link add name gre0 up type gre [...] dev eth1
>>> ip link add name gre1 up type gre [...] dev eth2
>>>
>>> The "physical device" can be any interface in the VRF, not necessarily
>>> eth{1,2}.
>>
>> Hello,
>>
>> Thanks for that suggestion.
>>
>> I'm trying to implement this, but not having much luck.  My current approach
>> is trying to put gre0 in one VRF, attached to a VETH device in a different VRF.
>>
>> Would you expect that to work?
> 
> I found some other problems with my config, will try this again now that some other
> problems are solved...

Ok, I am happy to report that GRE with lower-dev bound to one VRF and greX in a different
VRF works fine.

Thanks,
Ben

> 
>>
>> And also, is there any way to delete a gre netdev?  ip link delete gre0 doesn't
>> complain, and doesn't work.
> 
> I found answer to this, for reference, it seems gre0 is default instance built by the
> ip_gre module when it is loaded, and used for special purpose.
> 
> Thanks,
> Ben
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[David Ahern]

On 11/19/24 7:59 AM, Ben Greear wrote:
> 
> Ok, I am happy to report that GRE with lower-dev bound to one VRF and
> greX in a different
> VRF works fine.
> 

mind sending a selftest that also documents this use case?

Re: GRE tunnels bound to VRF

[Ben Greear]

On 11/19/24 8:36 AM, David Ahern wrote:
> On 11/19/24 7:59 AM, Ben Greear wrote:
>>
>> Ok, I am happy to report that GRE with lower-dev bound to one VRF and
>> greX in a different
>> VRF works fine.
>>
> 
> mind sending a selftest that also documents this use case?
> 

I don't have an easy way to extract this into a shell script, but
at least as description:

Create VETH pair: rddVR0 rddVR1 in my case
rddVR0 has IP 2.2.2.1, in vrf0
rddVR1 has IP 2.2.2.2, in vrf1

# Create GRE device bound to rddVR1 (and indirectly bound to vrf1):
ip link add name gre1 up type gre remote 2.2.2.1 local 2.2.2.2 ttl 255 dev rddVR1

# Create GRE device bound to rddVR0 (and indirectly bound to vrf0)
ip link add name gre2 up type gre remote 2.2.2.2 local 2.2.2.1 ttl 255 dev rddVR0

Add gre1 to vrf11
Add gre2 to vrf00


gre1 IP address can be 10.1.1.2/32
gre2 IP address can be 10.1.1.1/32

And then you can generate TCP/UDP traffic between gre1 and gre2 if you bind to them in the normal
manner when using VRFs (SO_BINDTODEV or similar).

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: GRE tunnels bound to VRF

[Eyal Birger]

On Tue, Nov 19, 2024 at 8:58 AM Ben Greear <greearb@candelatech.com> wrote:
>
> On 11/19/24 8:36 AM, David Ahern wrote:
> > On 11/19/24 7:59 AM, Ben Greear wrote:
> >>
> >> Ok, I am happy to report that GRE with lower-dev bound to one VRF and
> >> greX in a different
> >> VRF works fine.
> >>
> >
> > mind sending a selftest that also documents this use case?
> >
>
> I don't have an easy way to extract this into a shell script, but
> at least as description:

FWIW I once created a tool for helping to jumpstart such scripts - see
https://www.netpen.io

If I use it to create something similar to what you've described, the
outcome is something like this (the link just encodes the relevant
diagram info in b64):

https:://netpen.io/shared/eyJzZXR0aW5ncyI6eyJ0aXRsZSI6IkdSRSBFeGFtcGxlIn0sIml0ZW1zIjpbeyJzdWJuZXQiOnsibmFtZSI6ImdyZWVuIiwiY2lkciI6IjE5OC41MS4xMDAuMC8yNCJ9fSx7InN1Ym5ldCI6eyJuYW1lIjoiYmx1ZSIsImNpZHIiOiIxMC4wLjAuMC8yNCJ9fSx7Im5ldG5zIjp7Im5hbWUiOiJuczEifX0seyJ2ZXRoIjp7Im5hbWUiOiJ2IiwiZGV2MSI6eyJuZXRucyI6Im5ldG5zLm5zMSIsInN1Ym5ldHMiOlsic3VibmV0LmdyZWVuIl0sImV0aHRvb2wiOnt9LCJ0YyI6e319LCJkZXYyIjp7Im5ldG5zIjoibmV0bnMubnMxIiwic3VibmV0cyI6WyJzdWJuZXQuZ3JlZW4iXX19fSx7InZyZiI6eyJuYW1lIjoidnJmZ3JlZW4iLCJuZXRucyI6Im5ldG5zLm5zMSIsIm1lbWJlcnMiOlsidmV0aC52LmRldjIiXX19LHsidnJmIjp7Im5hbWUiOiJ2cmZibHVlIiwibmV0bnMiOiJuZXRucy5uczEiLCJtZW1iZXJzIjpbInZldGgudi5kZXYxIl19fSx7InR1bm5lbCI6eyJuYW1lIjoiZ3JlMSIsIm1vZGUiOiJncmUiLCJzdWJuZXRzIjpbInN1Ym5ldC5ibHVlIl0sImxpbmsxIjoidmV0aC52LmRldjEiLCJsaW5rMiI6InZldGgudi5kZXYyIiwiZGV2MSI6eyJuZXRucyI6Im5ldG5zLm5zMyJ9LCJkZXYyIjp7Im5ldG5zIjoibmV0bnMubnMyIn19fSx7Im5ldG5zIjp7Im5hbWUiOiJuczIifX0seyJuZXRucyI6eyJuYW1lIjoibnMzIn19XX0=

Eyal.

Re: GRE tunnels bound to VRF

[David Ahern]

On 11/19/24 11:04 AM, Eyal Birger wrote:
> On Tue, Nov 19, 2024 at 8:58 AM Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 11/19/24 8:36 AM, David Ahern wrote:
>>> On 11/19/24 7:59 AM, Ben Greear wrote:
>>>>
>>>> Ok, I am happy to report that GRE with lower-dev bound to one VRF and
>>>> greX in a different
>>>> VRF works fine.
>>>>
>>>
>>> mind sending a selftest that also documents this use case?
>>>
>>
>> I don't have an easy way to extract this into a shell script, but
>> at least as description:
> 
> FWIW I once created a tool for helping to jumpstart such scripts - see
> https://www.netpen.io
> 
> If I use it to create something similar to what you've described, the
> outcome is something like this (the link just encodes the relevant
> diagram info in b64):
> 
> https:://netpen.io/shared/eyJzZXR0aW5ncyI6eyJ0aXRsZSI6IkdSRSBFeGFtcGxlIn0sIml0ZW1zIjpbeyJzdWJuZXQiOnsibmFtZSI6ImdyZWVuIiwiY2lkciI6IjE5OC41MS4xMDAuMC8yNCJ9fSx7InN1Ym5ldCI6eyJuYW1lIjoiYmx1ZSIsImNpZHIiOiIxMC4wLjAuMC8yNCJ9fSx7Im5ldG5zIjp7Im5hbWUiOiJuczEifX0seyJ2ZXRoIjp7Im5hbWUiOiJ2IiwiZGV2MSI6eyJuZXRucyI6Im5ldG5zLm5zMSIsInN1Ym5ldHMiOlsic3VibmV0LmdyZWVuIl0sImV0aHRvb2wiOnt9LCJ0YyI6e319LCJkZXYyIjp7Im5ldG5zIjoibmV0bnMubnMxIiwic3VibmV0cyI6WyJzdWJuZXQuZ3JlZW4iXX19fSx7InZyZiI6eyJuYW1lIjoidnJmZ3JlZW4iLCJuZXRucyI6Im5ldG5zLm5zMSIsIm1lbWJlcnMiOlsidmV0aC52LmRldjIiXX19LHsidnJmIjp7Im5hbWUiOiJ2cmZibHVlIiwibmV0bnMiOiJuZXRucy5uczEiLCJtZW1iZXJzIjpbInZldGgudi5kZXYxIl19fSx7InR1bm5lbCI6eyJuYW1lIjoiZ3JlMSIsIm1vZGUiOiJncmUiLCJzdWJuZXRzIjpbInN1Ym5ldC5ibHVlIl0sImxpbmsxIjoidmV0aC52LmRldjEiLCJsaW5rMiI6InZldGgudi5kZXYyIiwiZGV2MSI6eyJuZXRucyI6Im5ldG5zLm5zMyJ9LCJkZXYyIjp7Im5ldG5zIjoibmV0bnMubnMyIn19fSx7Im5ldG5zIjp7Im5hbWUiOiJuczIifX0seyJuZXRucyI6eyJuYW1lIjoibnMzIn19XX0=
> 
> Eyal.

pretty cool. FYI - extra ':' in that URL

Re: GRE tunnels bound to VRF

[Ido Schimmel]

On Tue, Nov 19, 2024 at 09:36:13AM -0700, David Ahern wrote:
> On 11/19/24 7:59 AM, Ben Greear wrote:
> > 
> > Ok, I am happy to report that GRE with lower-dev bound to one VRF and
> > greX in a different
> > VRF works fine.
> > 
> 
> mind sending a selftest that also documents this use case?

We already have that. See:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fed926d4f64ca1ba23c496747fc4209244c13d80