Greetings,
I'm writing this to probe if there has been thoughts or efforts in
allowing sub-second TCP keep alive interval? One application is for TCP
connections between IP hosts connected by an internal backplane where a
faster detection is a necessity and the increased traffic can be
accommodate
eigh lookup.
Changes from v1:
- use __ipv4_neigh_lookup instead (per Eric Dumazet).
Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable
again.")
Signed-off-by: Stephen Suryaputra Lin
---
net/ipv4/route.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
I did the temporary clearing/restoring rt_gateway following the deleted
function check_peer_redir(). But, looking again at the function the
assigning of peer->redirect_learned.a4 to rt_gateway can be permanent
because restoring to the old_gw only happens on errors.
I have updated the patch to use
d
since the old_gw is the one that sends the ICMP redirect message. Then the
new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may
never gets resolved and the traffic is blackholed.
Changes from v1:
- use __ipv4_neigh_lookup instead (per Eric Dumazet).
Signed-off-by: S
d
since the old_gw is the one that sends the ICMP redirect message. Then the
new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may
never gets resolved and the traffic is blackholed.
Signed-off-by: Stephen Suryaputra Lin
---
net/ipv4/route.c | 2 ++
1 file changed, 2 insert
Hi, All,
I noticed through code inspection that ICMP redirects behavior is
different after commit 5943634fc5592037db0693b261f7f4bea6bb9457.
In v2.6 kernel, it used to be that ip_rt_redirect() calls
arp_bind_neighbour() which returns 0 and then the state of the neigh for
the new_gw is checked. If
