From: David Ahern <dsahern@gmail.com>
To: Jeff Barnhill <0xeffeff@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: v6/sit tunnels and VRFs
Date: Fri, 27 Oct 2017 10:25:08 -0600 [thread overview]
Message-ID: <aa76d6b7-dbb1-5275-09f6-a4450aeceeb2@gmail.com> (raw)
In-Reply-To: <CAL6e_pc=Z03obL1U_+EY1t2EQ3Q7pmmcfU72tuO-hPzqqgPgig@mail.gmail.com>
On 10/26/17 11:19 PM, Jeff Barnhill wrote:
> Thanks, David.
>
> I corrected the static route, applied the patch, and set the
> link/output dev on the tunnel and it works now. Is it required to set
> the link/output dev? I was thinking that this should not be required
> for cases where the outgoing device is not known, for instance on a
> router or device with multiple interfaces.
In a VRF environment, addresses have to be qualified with a VRF. Running
the command:
ip tunnel add jtun mode sit remote 192.168.200.1 local 192.168.210.2
You have a remote address with no qualification about which VRF to use
for the lookup.
Digging into the sit code and how the link parameter is used, the
existing code works just fine if you use:
sudo ip tunnel add jtun mode sit remote 192.168.200.1 local
192.168.210.2 dev myvrf
The tunnel link parameter is myvrf and it is used for tunnel lookups and
route lookups to forward the packet. So, really I should allow both
cases -- dev is a VRF and dev is a link that could be in a vrf.
>
> Also, what is the expected behavior of loopback addresses in a VRF
> context? For instance, if an application were being run under "ip vrf
> exec" and it tried to use these addresses.
The 127.0.0.1 address needs to exist in the VRF. The one on 'lo' is in
the default VRF only. VRF devices act as the VRF-local loopback, so you
can put the IPv4 loopback address on it.
>
> jeff@VM2:~$ ping -I myvrf 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
> ^C
> --- 127.0.0.1 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2033ms
If you add the loopback address to the
ip addr add dev myvrf 127.0.0.1/8
root@kenny-jessie3:~# ip addr add dev myvrf 127.0.0.1/8
root@kenny-jessie3:~# ping -I myvrf 127.0.0.1
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
^C
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms
>
> jeff@VM2:~$ ping -I myvrf ::1
> connect: Network is unreachable
I need to add support for ::1/128 on a VRF device.
next prev parent reply other threads:[~2017-10-27 16:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 20:45 v6/sit tunnels and VRFs Jeff Barnhill
2017-10-25 21:31 ` David Ahern
2017-10-26 3:28 ` Jeff Barnhill
2017-10-26 17:24 ` David Ahern
2017-10-27 5:19 ` Jeff Barnhill
2017-10-27 16:25 ` David Ahern [this message]
2017-10-27 20:59 ` Jeff Barnhill
2017-10-27 22:53 ` David Ahern
2017-10-28 2:43 ` Jeff Barnhill
2017-10-29 15:48 ` David Ahern
2017-10-31 22:20 ` Jeff Barnhill
2017-10-31 22:36 ` David Ahern
2017-10-31 22:42 ` David Ahern
2018-04-12 16:54 ` Jeff Barnhill
2018-04-13 2:25 ` David Ahern
2018-04-13 20:23 ` Jeff Barnhill
2018-04-13 20:31 ` David Ahern
2018-04-14 22:07 ` Jeff Barnhill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa76d6b7-dbb1-5275-09f6-a4450aeceeb2@gmail.com \
--to=dsahern@gmail.com \
--cc=0xeffeff@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).