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]"

Reply via email to