IPFW2 versrcreach update

[James]

[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 at towardex.com                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net