Hello, this is just for my own curiosity.
On the weekend at work, the comms guys rebuilt a router and our freebsd boxes could not talk to database server in a different subnet for a few hours. The router upgrade failed so upgrade was backed out and routes eventually re-established. All seemed well, could ssh into the freebsd boxes from different subnets but the freebsd boxes could not talk to the database server in one particular subnet (or indeed contact the box on that subnet vi any protocol except ping [icmp]). Other subnet could be reached. sockstat showed there were existing connections to database. The router changed its mac address back and forth during upgrade so did 'arp -ad' but this did not help. Flushing all routes and re-establishing default route and everything immediately worked. The routing table before and after the flushing were identical (and of course default route worked to other subnets before flushing). I assume it was because of the existing database connections there was some bad routing 'info' held in the sytem somewhere. Anyone have any further insight into this. just curious -- tonym _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"