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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Jan 2020 13:33:41 -0700 From: David Ahern <dsahern@...il.com> To: Ido Schimmel <idosch@...sch.org>, Ben Greear <greearb@...delatech.com> Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: vrf and multicast is broken in some cases On 1/15/20 1:23 PM, Ido Schimmel wrote: > > I'm not sure this is the correct way (David?). Can you try to delete > this default route and instead add a default unreachable route with an > high metric according to step 3 in Documentation/networking/vrf.txt: > > " > 3. Set the default route for the table (and hence default route for the VRF). > ip route add table 10 unreachable default metric 4278198272 > > This high metric value ensures that the default unreachable route can > be overridden by a routing protocol suite. FRRouting interprets > kernel metrics as a combined admin distance (upper byte) and priority > (lower 3 bytes). Thus the above metric translates to [255/8192]. > " > > If I'm reading ip_route_output_key_hash_rcu() correctly, then the error > returned from fib_lookup() because of the unreachable route should allow > you to route the packet via the requested interface. > yes, IPv4 is a bit goofy with multicast (at least to me, but then I have not done much with mcast).
Powered by blists - more mailing lists