Re: IPFW2 versrcreach update

From: Andre Oppermann (andre_at_freebsd.org)
Date: 07/21/04

  • Next message: Anil Madhavapeddy: "Set device BD_ADDR via ng_bluetooth" 
    Date: Wed, 21 Jul 2004 12:20:23 +0200
To: James <james@towardex.com>

    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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Anil Madhavapeddy: "Set device BD_ADDR via ng_bluetooth"