| 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
| ||
|
Message-ID: <b81747f9-441e-b69a-02f1-5b9554e02d52@iogearbox.net> Date: Fri, 27 Apr 2018 11:10:10 +0200 From: Daniel Borkmann <daniel@...earbox.net> To: William Tu <u9012063@...il.com>, netdev@...r.kernel.org Subject: Re: [PATCHv2 bpf-next 0/2] BPF tunnel testsuite On 04/26/2018 11:01 PM, William Tu wrote: > The patch series provide end-to-end eBPF tunnel testsute. A common topology > is created below for all types of tunnels: > > Topology: > --------- > root namespace | at_ns0 namespace > | > ----------- | ----------- > | tnl dev | | | tnl dev | (overlay network) > ----------- | ----------- > metadata-mode | native-mode > with bpf | > | > ---------- | ---------- > | veth1 | --------- | veth0 | (underlay network) > ---------- peer ---------- > > > Device Configuration > -------------------- > Root namespace with metadata-mode tunnel + BPF > Device names and addresses: > veth1 IP: 172.16.1.200, IPv6: 00::22 (underlay) > tunnel dev <type>11, ex: gre11, IPv4: 10.1.1.200 (overlay) > > Namespace at_ns0 with native tunnel > Device names and addresses: > veth0 IPv4: 172.16.1.100, IPv6: 00::11 (underlay) > tunnel dev <type>00, ex: gre00, IPv4: 10.1.1.100 (overlay) > > > End-to-end ping packet flow > --------------------------- > Most of the tests start by namespace creation, device configuration, > then ping the underlay and overlay network. When doing 'ping 10.1.1.100' > from root namespace, the following operations happen: > 1) Route lookup shows 10.1.1.100/24 belongs to tnl dev, fwd to tnl dev. > 2) Tnl device's egress BPF program is triggered and set the tunnel metadata, > with remote_ip=172.16.1.200 and others. > 3) Outer tunnel header is prepended and route the packet to veth1's egress > 4) veth0's ingress queue receive the tunneled packet at namespace at_ns0 > 5) Tunnel protocol handler, ex: vxlan_rcv, decap the packet > 6) Forward the packet to the overlay tnl dev > > Test Cases > ----------------------------- > Tunnel Type | BPF Programs > ----------------------------- > GRE: gre_set_tunnel, gre_get_tunnel > IP6GRE: ip6gretap_set_tunnel, ip6gretap_get_tunnel > ERSPAN: erspan_set_tunnel, erspan_get_tunnel > IP6ERSPAN: ip4ip6erspan_set_tunnel, ip4ip6erspan_get_tunnel > VXLAN: vxlan_set_tunnel, vxlan_get_tunnel > IP6VXLAN: ip6vxlan_set_tunnel, ip6vxlan_get_tunnel > GENEVE: geneve_set_tunnel, geneve_get_tunnel > IP6GENEVE: ip6geneve_set_tunnel, ip6geneve_get_tunnel > IPIP: ipip_set_tunnel, ipip_get_tunnel > IP6IP: ipip6_set_tunnel, ipip6_get_tunnel, > ip6ip6_set_tunnel, ip6ip6_get_tunnel > XFRM: xfrm_get_state Applied yesterday night to bpf-next (and now in net-next), thanks William!
Powered by blists - more mailing lists