From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 10:20:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B08116A4CE for ; Wed, 21 Jul 2004 10:20:22 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8248743D2F for ; Wed, 21 Jul 2004 10:20:21 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 29891 invoked from network); 21 Jul 2004 10:18:06 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jul 2004 10:18:06 -0000 Message-ID: <40FE4367.AA7B0A7F@freebsd.org> Date: Wed, 21 Jul 2004 12:20:23 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 10:20:22 -0000 James wrote: > > [Note: aggregate reply] > > Hi, > > > Tell me what the test results are. > > I just tested this out on the lab freebsd router using that exact line I > emailed earlier in ip_fw2.c. > > And it is working (test result is pasted bottom of this email) on both > -blackhole and -reject flags :) James, it just occured to me; but what is the purpose of versrcreach denying a packet that will be discarded a few cycles later anyway? When I mark a route with -reject I want the ICMPs go out and still use the versrcreach functionality in ipfw. So I don't think this is something that should be included into ipfw's versrcreach because it is redundant. -- Andre > [from Gleb] > > P.S. GNU zebra null-routes into lo0, always setting RTF_BLACKHOLE flag. What > > software uses RTF_REJECT flag? > > The "ip route a.b.c.d/cidr Null0" installs a blackhole route. However if you > "ip route a.b.c.d/32 reject" (at least on Quagga 0.96.5), it will install > -reject route with -iface pointing to lo0. > > It is worth noting that there is rather a buggy implementation on Quagga (havent > tested on zebra) where recursive routing does not work with Null0. If you have > a static route for example: ip route 192.0.2.0/24 Null0 on Quagga config, and > if you have BGP injecting a remote triggered null-route using next-hop of > 192.0.2.x, it will not install that onto kernel table. However, the good news is > it is simple enough issue to fix. Under zebra_rib.c, simply ensure that > NEXTHOP_TYPE_BLACKHOLE gets installed using nexthop_blackhole_add(rib) instead > of having it search for recursive nexthop on a blackhole/non-existant "Null0" > ifp. Quagga-dev is a better place for discussing this so I'll continue this > discussion there hopefully, or on offlist if anyone is interested. > > Furthermore, it is right that RTF_REJECT is almost not used. It is also good > to note that even on Juniper, almost every network operator uses discard, not > reject. Same deal with Cisco, most ensure ICMP unreachables are not generated > with a packet hitting Null0. However, from time to time, REJECT becomes a quite > a bit useful tool for debugging the network. REJECT becomes very valuable if > you want to temporarily use backscatter search technique to find the source > throughout your network, as routers with reject route will emit icmp signals at > you. > > [Test Outputs] > Test #1: Route 1.1.1.2/32 to a dummy interface and test uRPF. This should permit > the packet. > > lab-gw# route add -host 1.1.1.2/32 -iface ds0 > add host 1.1.1.2: gateway ds0 > lab-gw# ipfw zero > Accounting cleared. > > workstation# ifconfig lo0 inet 1.1.1.2/32 alias > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > Packets are permitted through as 1.1.1.2/32 is a valid host route, to a dummy > interface. > > -- > Test #2: Route 1.1.1.2/32 with RTF_BLACKHOLE. This should kill the packet. > > lab-gw# route delete -host 1.1.1.2 > delete host 1.1.1.2 > lab-gw# route add -host 1.1.1.2/32 -iface lo0 -blackhole > add host 1.1.1.2: gateway lo0 > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 2 168 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 3 252 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > > Loose-check uRPF is failing as expected and packets are being denied sourced > from 1.1.1.2/32 RTF_BLACKHOLE. > > -- > Test #3: Route 1.1.1.2/32 with RTF_REJECT. This should kill the packet as > well. > > lab-gw# route add -host 1.1.1.2/32 -iface lo0 -reject > add host 1.1.1.2: gateway lo0 > lab-gw# ipfw zero > Accounting cleared. > lab-gw# ipfw show 20001 | grep versrc > 20001 0 0 deny ip from any to any not versrcreach > > workstation# ping -S 1.1.1.2 3.3.3.3 > PING 3.3.3.3 (3.3.3.3) from 1.1.1.2: 56 data bytes > ^C > > lab-gw# ipfw show 20001 | grep versrc > 20001 3 252 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > lab-gw# ipfw show 20001 | grep versrc > 20001 4 336 deny ip from any to any not versrcreach > > uRPF is again failing. Packets are being dropped as exactly as expected. > > -J > -- > James Jun TowardEX Technologies, Inc. > Technical Lead Network Design, Consulting, IT Outsourcing > james@towardex.com Boston-based Colocation & Bandwidth Services > cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net