>>> at the very least, all the reject routes that get installed could be
>>> changed to dump traffic out a nul interface instead, which might make
>>> visual inspection of the routing table easier.
>>But would have different semantics.  Traffic that hits a reject route
>>generates an ICMP unreachable, as I recall; traffic routed out a nul
>>interface wouldn't.
>
>	i'm not really objecting, but anyway i'd like to comment.
>
>	actually, there's RTF_BLACKHOLE so you don't really need nul0 for the
>	behavior.
>	RTF_BLACKHOLE - no icmp
>	RTF_REJECT - with icmp

i remember reading this

	if (rt && rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE)) {
		m_freem(m);
		return (rt->rt_flags & RTF_BLACKHOLE ? 0 :
			rt->rt_flags & RTF_HOST ? EHOSTUNREACH : ENETUNREACH);
	}

as i was chopping my way through if_loop.c last night, and thinking
that at least the traffic doesn't generate an EPERM error.

the only thing it would do it segregate traffic that was looped back
from traffic that was tossed away.  you could also use ipf's
fast-routing to throw packets out the nul interface for logging via
bpf.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."