netdev - Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5A5CBE09-D249-482B-AB8A-E62E8382F43F@ciena.com>
Date:   Tue, 24 Jul 2018 16:08:51 +0000
From:   "D'Souza, Nelson" <ndsouza@...na.com>
To:     David Ahern <dsa@...ulusnetworks.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge

It's strange that enslaving eth1 -> br0 -> test-vrf does not work, but enslaving eth1->test-vrf works fine.

Nelson

On 7/24/18, 8:58 AM, "D'Souza, Nelson" <ndsouza@...na.com> wrote:

    Thank you David, really appreciate the help. Most likely something specific to my environment.
    
    ip vrf id, does not report anything on my system. Here's the result after running the command.
    
    # ip vrf id
    #
    
    I'll follow up with a VM.
    
    Nelson
    
    On 7/24/18, 5:55 AM, "David Ahern" <dsa@...ulusnetworks.com> wrote:
    
        On 7/23/18 7:43 PM, D'Souza, Nelson wrote:
        > I copy and pasted the configs onto my device, but pings on test-vrf do not work in my setup. 
        > I'm essentially seeing the same issue as I reported before.
        > 
        > In this case, pings sent out on test-vrf (host ns) are received and replied to by the loopback interface (foo ns). Although the replies are seen at the test-vrf level, they are not locally delivered to the ping application.
        > 
        
        I just built v4.14.52 kernel and ran those commands - worked fine. It is
        something specific to your environment. Is your shell tied to a VRF --
        (ip vrf id)?
        
        After that, I suggest you create a VM running a newer distribution of
        your choice (Ubuntu 17.10 or newer, debian stretch with 4.14 kernel, or
        Fedora 26 or newer) and run the commands there.