netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsa@cumulusnetworks.com>
To: "D'Souza, Nelson" <ndsouza@ciena.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: VRF with enslaved L3 enabled bridge
Date: Thu, 19 Jul 2018 21:37:04 -0600	[thread overview]
Message-ID: <03a5d61d-32eb-e329-a12c-59e3594e1b51@cumulusnetworks.com> (raw)
In-Reply-To: <9E3A1F70-E009-49DC-B639-B48B28F99C52@ciena.com>

On 7/19/18 8:19 PM, D'Souza, Nelson wrote:
> Hi,
> 
>  
> 
> I'm seeing the following issue on a system running a 4.14.52 Linux kernel.
> 
>  
> 
> With an eth interface enslaved to a VRF device, pings sent out on the
> VRF to an neighboring host are successful. But, with an eth interface
> enslaved to a L3 enabled bridge (mgmtbr0), and the bridge enslaved to a
> l3mdev VRF (mgmtvrf), the pings sent out on the VRF are not received
> back at the application level.

you mean this setup:
    eth1 (ingress port) -> br0 (bridge) -> red (vrf)

IP address on br0:

9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master
red state UP group default qlen 1000
    link/ether 02:e0:f9:1c:00:37 brd ff:ff:ff:ff:ff:ff
    inet 10.100.1.4/24 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::e0:f9ff:fe1c:37/64 scope link
       valid_lft forever preferred_lft forever

And then ping a neighbor:

# ping -I red -c1 -w1 10.100.1.254
ping: Warning: source address might be selected on device other than red.
PING 10.100.1.254 (10.100.1.254) from 10.100.1.4 red: 56(84) bytes of data.
64 bytes from 10.100.1.254: icmp_seq=1 ttl=64 time=0.810 ms

--- 10.100.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.810/0.810/0.810/0.000 ms

> 
>  
> 
> ICMP Echo requests are successfully sent out on the mgmtvrf device to a
> neighboring host. However, ICMP echo replies that are received back from
> the neighboring host via the eth and mgmtbr0 interfaces are not seen at
> the vrf device level and therefore fail to be delivered locally to the
> ping application.

Does tcpdump on each level show the response? tcpdump on eth, tcpdump on
bridge and tcpdump on the vrf device?

> 
>  
> 
> The following LOG rules were added to the raw table, prerouting chain
> and the filter table, OUTPUT chains:
> 
>  
> 
> root@x10sdv-4c-tln4f:~# iptables -t raw -S PREROUTING
> 
> -P PREROUTING ACCEPT
> 
> -A PREROUTING -s 10.32.8.135/32 -i mgmtbr0 -j LOG
> 
> -A PREROUTING -s 10.32.8.135/32 -i mgmtvrf -j LOG
> 
>  
> 
> root@x10sdv-4c-tln4f:~# iptables -S OUTPUT
> 
> -P OUTPUT ACCEPT
> 
> -A OUTPUT -o mgmtvrf -j LOG
> 
> -A OUTPUT -o mgmtbr0 -j LOG
> 
>  
> 
> Pings are sent on the management VRF to a neighboring host (10.32.8.135)
> and the netfilter logs included below:
> 
> Note, that in the logs, ICMP echo requests are sent out on the mgmtvrf
> and match the output rules for mgmvrf and mgmtbr0, but the ICMP echo
> replies are only seen on mgmtbr0, not on mgmtvrf
> 
>  
> 
> root@x10sdv-4c-tln4f:~# ping 10.32.8.135 -I mgmtvrf -c 1
> 
> PING 10.32.8.135  (10.32.8.135):
> 
> 56 data bytes
> 
> [ 2679.683027] IN= OUT=mgmtvrf SRC=10.33.96.131 DST=10.32.8.135 LEN=84
> TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
> SEQ=0   <<< ICMP echo sent on mgmtvrf
> 
> [ 2679.697560] IN= OUT=mgmtbr0 SRC=10.33.96.131 DST=10.32.8.135 LEN=84
> TOS=0x00 PREC=0x00 TTL=64 ID=23921 DF PROTO=ICMP TYPE=8 CODE=0 ID=32610
> SEQ=0   <<< ICMP echo sent on mgmtbr0
> 
> [ 2679.713312] IN=mgmtbr0 OUT= PHYSIN=ethUSB
> MAC=c0:56:27:90:4f:75:c4:7d:4f:bb:02:e7:08:00 SRC=10.32.8.135
> DST=10.33.96.131 LEN=84 TOS=0x00 PREC=0x00 TTL=62 ID=64949 PROTO=ICMP
> TYPE=0 CODE=0 ID=32610 SEQ=0     <<< ICMP echo reply rcvd on mgmtbr0,
> but not on mgmtvrf
> 
>  
> 
> --- 10.32.8.135 ping statistics ---
> 
> 1 packets transmitted, 0 packets received, 100% packet loss     <<<<
> ping failed
> 
>  
> 
> I’d like to know if this is an outstanding/resolved issue.
> 

This one works (see above), so I suspect it is something with your setup.

       reply	other threads:[~2018-07-20  4:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9E3A1F70-E009-49DC-B639-B48B28F99C52@ciena.com>
2018-07-20  3:37 ` David Ahern [this message]
2018-07-20 19:03   ` [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge D'Souza, Nelson
2018-07-20 19:11     ` David Ahern
2018-07-20 21:59       ` [**EXTERNAL**] " D'Souza, Nelson
2018-07-23 22:00     ` David Ahern
2018-07-24  1:43       ` D'Souza, Nelson
2018-07-24 12:54         ` David Ahern
2018-07-24 15:58           ` D'Souza, Nelson
2018-07-24 16:08             ` D'Souza, Nelson
2018-07-26  0:35               ` D'Souza, Nelson
2018-07-26  0:44                 ` D'Souza, Nelson
2018-07-27 23:29                 ` D'Souza, Nelson
2018-08-02 23:12                   ` D'Souza, Nelson
2018-09-05 18:00                     ` D'Souza, Nelson
2018-09-07  0:26                       ` David Ahern
     [not found]                         ` <BYAPR04MB3797F5219C2164F3C0B6DE57AD000@BYAPR04MB3797.namprd04.prod.outlook.com>
2018-09-07 16:09                           ` David Ahern
2018-09-07 23:42                             ` D'Souza, Nelson

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=03a5d61d-32eb-e329-a12c-59e3594e1b51@cumulusnetworks.com \
    --to=dsa@cumulusnetworks.com \
    --cc=ndsouza@ciena.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).