Aside:
 In the future, should I direct problems having to do with the
 networking portion of the kernel to tech-net or tech-kern?  Or is
 it appropriate to send such things to both?

Background:
 I'm using a NetBSD box as a router.  It happens to be running
 NetBSD 1.5, but after looking through the networking code, I
 believe that this is still a problem in NetBSD-current.

Problem:
 The ip stack, when forwarding a packet, in ip_forward(), makes use
 of a cached route from a global variable called "ipforward_rt".
 When the interface that route directs outbound packets toward goes
 down the cached route is not cleared, so the packets don't get
 re-routed.  When the interface comes back up, the packets still
 don't get delivered to it.

 Hmm. I just looked in the PR database.  This appears to be
 a longstanding problem.  der Mouse reported PR3508, which is
 the same problem, way back in 1997.  As he said then, I believe
 this is still a problem in NetBSD-current.

To Fix:
 I put in a call in if_down() and if_up() to free the cached route.
 The next time a packet is received, the route will be reallocated
 and everything will be happy.  This is just a hack to see if I'm
 on the right track.  However, PR3508 points out more ways that
 the cached route can be wrong.  I'm inclined to follow der Mouse's
 lead and get rid of the cached route entirely.

To Reproduce:

	Client1 <----> NetBSD Router <----> Client2
                    ifc0           ifc1

 1) Setup a NetBSD router with at least two interfaces (ifc0, ifc1)
    as above.

 2) Configure a default route on ifc0, and a route to Client2
    on ifc1.

 3) In the absence of any other traffic to be forwarded, ping
    Client2 from Client1. (The cached route is cleared whenever a
    packet for a different destination arrives)

 4) ifconfig ifc1 down

 5) notice the ping stops receiving the echo reply.

 6) ifconfig ifc1 up

 7) notice the ping still doesn't receive the echo reply.

 8) without stopping the first ping, ping another address which
    the router will also forward (doesn't have to respond)

 9) notice the first ping starts working again