* GRE tunnels bound to VRF @ 2024-11-17 18:40 Ben Greear 2024-11-17 22:41 ` Alexandre Ferrieux 2024-11-18 9:00 ` Ido Schimmel 0 siblings, 2 replies; 12+ messages in thread From: Ben Greear @ 2024-11-17 18:40 UTC (permalink / raw) To: netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-17 18:40 GRE tunnels bound to VRF Ben Greear @ 2024-11-17 22:41 ` Alexandre Ferrieux 2024-11-18 16:38 ` Ben Greear 2024-11-18 9:00 ` Ido Schimmel 1 sibling, 1 reply; 12+ messages in thread From: Alexandre Ferrieux @ 2024-11-17 22:41 UTC (permalink / raw) To: Ben Greear, netdev 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-17 22:41 ` Alexandre Ferrieux @ 2024-11-18 16:38 ` Ben Greear 0 siblings, 0 replies; 12+ messages in thread From: Ben Greear @ 2024-11-18 16:38 UTC (permalink / raw) To: Alexandre Ferrieux, netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-17 18:40 GRE tunnels bound to VRF Ben Greear 2024-11-17 22:41 ` Alexandre Ferrieux @ 2024-11-18 9:00 ` Ido Schimmel 2024-11-18 19:48 ` Ben Greear 1 sibling, 1 reply; 12+ messages in thread From: Ido Schimmel @ 2024-11-18 9:00 UTC (permalink / raw) To: Ben Greear; +Cc: netdev 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}. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-18 9:00 ` Ido Schimmel @ 2024-11-18 19:48 ` Ben Greear 2024-11-19 1:47 ` Ben Greear 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2024-11-18 19:48 UTC (permalink / raw) To: Ido Schimmel; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-18 19:48 ` Ben Greear @ 2024-11-19 1:47 ` Ben Greear 2024-11-19 14:59 ` Ben Greear 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2024-11-19 1:47 UTC (permalink / raw) To: Ido Schimmel; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 1:47 ` Ben Greear @ 2024-11-19 14:59 ` Ben Greear 2024-11-19 16:36 ` David Ahern 0 siblings, 1 reply; 12+ messages in thread From: Ben Greear @ 2024-11-19 14:59 UTC (permalink / raw) To: Ido Schimmel; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 14:59 ` Ben Greear @ 2024-11-19 16:36 ` David Ahern 2024-11-19 16:53 ` Ben Greear 2024-11-20 7:40 ` Ido Schimmel 0 siblings, 2 replies; 12+ messages in thread From: David Ahern @ 2024-11-19 16:36 UTC (permalink / raw) To: Ben Greear, Ido Schimmel; +Cc: netdev 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 16:36 ` David Ahern @ 2024-11-19 16:53 ` Ben Greear 2024-11-19 18:04 ` Eyal Birger 2024-11-20 7:40 ` Ido Schimmel 1 sibling, 1 reply; 12+ messages in thread From: Ben Greear @ 2024-11-19 16:53 UTC (permalink / raw) To: David Ahern, Ido Schimmel; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 16:53 ` Ben Greear @ 2024-11-19 18:04 ` Eyal Birger 2024-11-19 18:08 ` David Ahern 0 siblings, 1 reply; 12+ messages in thread From: Eyal Birger @ 2024-11-19 18:04 UTC (permalink / raw) To: Ben Greear; +Cc: David Ahern, Ido Schimmel, netdev 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 18:04 ` Eyal Birger @ 2024-11-19 18:08 ` David Ahern 0 siblings, 0 replies; 12+ messages in thread From: David Ahern @ 2024-11-19 18:08 UTC (permalink / raw) To: Eyal Birger, Ben Greear; +Cc: Ido Schimmel, netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GRE tunnels bound to VRF 2024-11-19 16:36 ` David Ahern 2024-11-19 16:53 ` Ben Greear @ 2024-11-20 7:40 ` Ido Schimmel 1 sibling, 0 replies; 12+ messages in thread From: Ido Schimmel @ 2024-11-20 7:40 UTC (permalink / raw) To: David Ahern; +Cc: Ben Greear, netdev 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2024-11-20 7:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-17 18:40 GRE tunnels bound to VRF Ben Greear 2024-11-17 22:41 ` Alexandre Ferrieux 2024-11-18 16:38 ` Ben Greear 2024-11-18 9:00 ` Ido Schimmel 2024-11-18 19:48 ` Ben Greear 2024-11-19 1:47 ` Ben Greear 2024-11-19 14:59 ` Ben Greear 2024-11-19 16:36 ` David Ahern 2024-11-19 16:53 ` Ben Greear 2024-11-19 18:04 ` Eyal Birger 2024-11-19 18:08 ` David Ahern 2024-11-20 7:40 ` Ido Schimmel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).