Re: IPFW2 versrcreach update

From: James (james_at_towardex.com)
Date: 07/21/04

  • Next message: Andre Oppermann: "Re: IPFW2 versrcreach update"
    Date: Tue, 20 Jul 2004 22:04:19 -0400
    To: Andre Oppermann <andre@freebsd.org>
    
    

    [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 :)

    [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: Andre Oppermann: "Re: IPFW2 versrcreach update"