On Wed, 21 Jul 1999 [EMAIL PROTECTED] wrote: > > I first thought, that there might be some kind of minimal update delay on > > It seems natural to try: > > /proc/sys/net/ipv4/route/min_delay > > to change minimal delay, is not it? 8) Yes and indeed, I did try it, but it didn't work. Now that you confirmed that it should work, I tried to find the reason from somewhere else. I'm trying to measure TCP and UDP throughput with netperf and so I used it to generate the UDP flood that I wanted to switch between two tunnels. I now tried to do the same test with ping flood and my own UDP flooder. This time the routing change happened immediately (after setting min_delay and max_delay to zero). Digging into the netperf's sources revealed that it uses connect() and send() also with UDP sockets. So, I added this option to my UDP sender and after that all the packets went to one tunnel even if I changed the default route multiple times. It seems that when the socket (at least SOCK_DGRAM) is in connected mode, the routing table change does not change (at least in less than 10 seconds) the effective destination of the packets. Is this the correct action? If yes, my question changes a bit.. Is there some other parameter that could be used to force even the connected sockets to change routing information immediately? -- Jouni Malinen - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to [EMAIL PROTECTED]
