[sisyphus] un-def и nat

[sisyphus] un-def и nat

[Anton Gorlov]

А никто не замечал что с un-def порой snat не работает?
Симптомы следующие - на локальном интерфейсе вижу приходящие пакеты с 
адресом из локальной сети,на исходящем вижу уже отначенные пакеты и 
ответные на них.а вот на локальном уже ответных пакетов не видно.
С 1 стороны pppoe до провайдера, с другой локалка по обычному эзернету.
Причём порой всё таки работает после перезагрузки

Re: [sisyphus] un-def и nat

[Anton Gorlov]

а вот кажется и ответ. в 3.6.2 типа пофиксили

commit 52fc5048534e9d4127622fa5a269a92f3bb5218b
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 4 01:25:26 2012 +0000

     ipv4: add a fib_type to fib_info

     [ Upstream commit f4ef85bbda96324785097356336bc79cdd37db0a ]

     commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.)
     introduced a regression for forwarding.

     This was hard to reproduce but the symptom was that packets were
     delivered to local host instead of being forwarded.

     David suggested to add fib_type to fib_info so that we dont
     inadvertently share same fib_info for different purposes.

     With help from Julian Anastasov who provided very helpful
     hints, reproduced here :

     <quote>
             Can it be a problem related to fib_info reuse
     from different routes. For example, when local IP address
     is created for subnet we have:

     broadcast 192.168.0.255 dev DEV  proto kernel  scope link  src
     192.168.0.1
     192.168.0.0/24 dev DEV  proto kernel  scope link  src 192.168.0.1
     local 192.168.0.1 dev DEV  proto kernel  scope host  src 192.168.0.1

             The "dev DEV  proto kernel  scope link  src 192.168.0.1" is
     a reused fib_info structure where we put cached routes.
     The result can be same fib_info for 192.168.0.255 and
     192.168.0.0/24. RTN_BROADCAST is cached only for input
     routes. Incoming broadcast to 192.168.0.255 can be cached
     and can cause problems for traffic forwarded to 192.168.0.0/24.
     So, this patch should solve the problem because it
     separates the broadcast from unicast traffic.

             And the ip_route_input_slow caching will work for
     local and broadcast input routes (above routes 1 and 3) just
     because they differ in scope and use different fib_info.

     </quote>

     Many thanks to Chris Clayton for his patience and help.

     Reported-by: Chris Clayton <chris2553@googlemail.com>
     Bisected-by: Chris Clayton <chris2553@googlemail.com>
     Reported-by: Dave Jones <davej@redhat.com>
     Signed-off-by: Eric Dumazet <edumazet@google.com>
     Cc: Julian Anastasov <ja@ssi.bg>
     Tested-by: Chris Clayton <chris2553@googlemail.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>
     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>



10.10.2012 14:42, Anton Gorlov пишет:
> А никто не замечал что с un-def порой snat не работает?
> Симптомы следующие - на локальном интерфейсе вижу приходящие пакеты с
> адресом из локальной сети,на исходящем вижу уже отначенные пакеты и
> ответные на них.а вот на локальном уже ответных пакетов не видно.
> С 1 стороны pppoe до провайдера, с другой локалка по обычному эзернету.
> Причём порой всё таки работает после перезагрузки
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus