I recompiled yet 2.6.19.1 kernel (using iptables with the same patches too).
The configuration for this test is:
1) linux box with 2.6.19.1 kernel (SMP machine) with these
patches/modules:
a) l7-filter
b) ipp2p
c) connlimit
d) set
2) 4 ethernet interfaces:
a) 2 external (eth1 and eth3) interfaces with balanced links (as
described in nato-howto) bridged as wan0 with static IPs assigned to
wan0 and wan0:1
b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP
enabled and configured.
IPTABLES relevant configuration:
# iptables -t nat -vn -L POSTROUTING
Chain POSTROUTING (policy ACCEPT 185 packets, 16649 bytes)
pkts bytes target prot opt in out source
destination
26 1529 MASQUERADE 0 -- * wan0 10.1.1.0/27
0.0.0.0/0
0 0 MASQUERADE 0 -- * wan0:1 10.1.1.0/27
0.0.0.0/0
ROUTES CONFIGURATION:
# service rt status
=== REGLAS DE ENRUTAMIENTO ==0: from all lookup local
50: from all lookup main
151: from NET_PUB1 lookup 151
152: from NET_PUB2 lookup 152
220: from all lookup 220
32766: from all lookup main
32767: from all lookup default
=== TABLAS DE RUTAS ===== MAIN ==NET_PUB1/26 dev wan0 proto kernel scope link
src IP_PUB1
NET_PUB2/24 dev wan0 proto kernel scope link src IP_PUB2
192.168.3.0/24 dev zlan0 proto kernel scope link src 192.168.3.247
192.168.2.0/24 dev zlan0 proto kernel scope link src 192.168.2.247
192.168.1.0/24 dev zlan0 proto kernel scope link src 192.168.1.247
10.1.1.0/24 dev zlan0 proto kernel scope link src 10.1.1.6
169.254.0.0/16 dev zlan0 scope link
239.0.0.0/8 dev zlan0 scope link
=== wan0 TABLA 151 ==default via GW_PUB1 dev wan0 proto static src IP_PUB1
prohibit default proto static metric 1
=== wan0 TABLA 152 ==default via GW_PUB2 dev wan0 proto static src IP_PUB2
prohibit default proto static metric 1
=== TABLA 220 (defecto) ==default proto static
nexthop via GW_PUB1 dev wan0 weight 1
nexthop via GW_PUB2 dev wan0 weight 1
ROUTING parameters configuration:
# grep . /proc/sys/net/ipv4/route/*
/proc/sys/net/ipv4/route/error_burst:5000
/proc/sys/net/ipv4/route/error_cost:1000
grep: /proc/sys/net/ipv4/route/flush: Operación no permitida
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:32768
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_delay:10
/proc/sys/net/ipv4/route/max_size:524288
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_delay:2
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:20
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:20480
/proc/sys/net/ipv4/route/secret_interval:600
When I test it along some weeks with intensive traffic I''ll put here
more
info about this test.
If somebody has any idea on how to solve the problem, please, tell us.
I''m
a bit desesperate with this issue.
Regards
ArcosCom Linux User
2007-Jan-12 01:13 UTC
Re: [LARTC] dst cache overflow (bridged wan interfaces)
The problem appears to be in the routes patch (after 1 day with 1 workstation with amule configured very agresively). I''m trying now the 2.6.19.2 kernel with the configuration exposed here, I''ll tell you if the problem were (or not) the patch for dead-gw-detection/multipath-routes from nano-howto. Perhaps this patch is for specific configuration and need more accurate routes config (don''t know). As I said: I''ll say if I the problem persist in some days. Thank you very much. Regards El Mie, 10 de Enero de 2007, 21:14, ArcosCom Linux User escribió:> I recompiled yet 2.6.19.1 kernel (using iptables with the same patches > too). > > The configuration for this test is: > 1) linux box with 2.6.19.1 kernel (SMP machine) with these > patches/modules: > a) l7-filter > b) ipp2p > c) connlimit > d) set > 2) 4 ethernet interfaces: > a) 2 external (eth1 and eth3) interfaces with balanced links (as > described in nato-howto) bridged as wan0 with static IPs assigned to > wan0 and wan0:1 > b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP > enabled and configured. > > IPTABLES relevant configuration: > # iptables -t nat -vn -L POSTROUTING > Chain POSTROUTING (policy ACCEPT 185 packets, 16649 bytes) > pkts bytes target prot opt in out source > destination > 26 1529 MASQUERADE 0 -- * wan0 10.1.1.0/27 > 0.0.0.0/0 > 0 0 MASQUERADE 0 -- * wan0:1 10.1.1.0/27 > 0.0.0.0/0 > > > ROUTES CONFIGURATION: > # service rt status > === REGLAS DE ENRUTAMIENTO ==> 0: from all lookup local > 50: from all lookup main > 151: from NET_PUB1 lookup 151 > 152: from NET_PUB2 lookup 152 > 220: from all lookup 220 > 32766: from all lookup main > 32767: from all lookup default > === TABLAS DE RUTAS ==> === MAIN ==> NET_PUB1/26 dev wan0 proto kernel scope link src IP_PUB1 > NET_PUB2/24 dev wan0 proto kernel scope link src IP_PUB2 > 192.168.3.0/24 dev zlan0 proto kernel scope link src 192.168.3.247 > 192.168.2.0/24 dev zlan0 proto kernel scope link src 192.168.2.247 > 192.168.1.0/24 dev zlan0 proto kernel scope link src 192.168.1.247 > 10.1.1.0/24 dev zlan0 proto kernel scope link src 10.1.1.6 > 169.254.0.0/16 dev zlan0 scope link > 239.0.0.0/8 dev zlan0 scope link > === wan0 TABLA 151 ==> default via GW_PUB1 dev wan0 proto static src IP_PUB1 > prohibit default proto static metric 1 > === wan0 TABLA 152 ==> default via GW_PUB2 dev wan0 proto static src IP_PUB2 > prohibit default proto static metric 1 > === TABLA 220 (defecto) ==> default proto static > nexthop via GW_PUB1 dev wan0 weight 1 > nexthop via GW_PUB2 dev wan0 weight 1 > > ROUTING parameters configuration: > # grep . /proc/sys/net/ipv4/route/* > /proc/sys/net/ipv4/route/error_burst:5000 > /proc/sys/net/ipv4/route/error_cost:1000 > grep: /proc/sys/net/ipv4/route/flush: Operación no permitida > /proc/sys/net/ipv4/route/gc_elasticity:8 > /proc/sys/net/ipv4/route/gc_interval:60 > /proc/sys/net/ipv4/route/gc_min_interval:0 > /proc/sys/net/ipv4/route/gc_min_interval_ms:500 > /proc/sys/net/ipv4/route/gc_thresh:32768 > /proc/sys/net/ipv4/route/gc_timeout:300 > /proc/sys/net/ipv4/route/max_delay:10 > /proc/sys/net/ipv4/route/max_size:524288 > /proc/sys/net/ipv4/route/min_adv_mss:256 > /proc/sys/net/ipv4/route/min_delay:2 > /proc/sys/net/ipv4/route/min_pmtu:552 > /proc/sys/net/ipv4/route/mtu_expires:600 > /proc/sys/net/ipv4/route/redirect_load:20 > /proc/sys/net/ipv4/route/redirect_number:9 > /proc/sys/net/ipv4/route/redirect_silence:20480 > /proc/sys/net/ipv4/route/secret_interval:600 > > When I test it along some weeks with intensive traffic I''ll put here more > info about this test. > > If somebody has any idea on how to solve the problem, please, tell us. I''m > a bit desesperate with this issue. > > Regards > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >
ArcosCom Linux User
2007-Jan-14 21:17 UTC
Re: [LARTC] dst cache overflow (bridged wan interfaces) [appears to be SOLVED]
Yes, the problem appears to be in the http://www.ssi.bg/~ja/#routes patch. Perhaps this patch is to any purposes and break the routes table or something about it. I tested for 2 days now with 4 pcs and amule/azureus configured very agressively to enable connections quickly and monitorized with "rtstat" util (as someone point to me) and I had seen how is working the routing in the linux box more numerically. I had take sense on all the comments about this problem and how to optimize the routing, ¡¡THANKS TO ALL!! Appears I can run fine with this configuration and use in production environment, but I''ll wait for 2 or 3 weeks before pass it into production. Thanks to all!! El Vie, 12 de Enero de 2007, 2:13, ArcosCom Linux User escribió:> The problem appears to be in the routes patch (after 1 day with 1 > workstation with amule configured very agresively). > > I''m trying now the 2.6.19.2 kernel with the configuration exposed here, > I''ll tell you if the problem were (or not) the patch for > dead-gw-detection/multipath-routes from nano-howto. Perhaps this patch is > for specific configuration and need more accurate routes config (don''t > know). > > As I said: I''ll say if I the problem persist in some days. > > Thank you very much. > > Regards > > El Mie, 10 de Enero de 2007, 21:14, ArcosCom Linux User escribió: >> I recompiled yet 2.6.19.1 kernel (using iptables with the same patches >> too). >> >> The configuration for this test is: >> 1) linux box with 2.6.19.1 kernel (SMP machine) with these >> patches/modules: >> a) l7-filter >> b) ipp2p >> c) connlimit >> d) set >> 2) 4 ethernet interfaces: >> a) 2 external (eth1 and eth3) interfaces with balanced links (as >> described in nato-howto) bridged as wan0 with static IPs assigned to >> wan0 and wan0:1 >> b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP >> enabled and configured. >> >> IPTABLES relevant configuration: >> # iptables -t nat -vn -L POSTROUTING >> Chain POSTROUTING (policy ACCEPT 185 packets, 16649 bytes) >> pkts bytes target prot opt in out source >> destination >> 26 1529 MASQUERADE 0 -- * wan0 10.1.1.0/27 >> 0.0.0.0/0 >> 0 0 MASQUERADE 0 -- * wan0:1 10.1.1.0/27 >> 0.0.0.0/0 >> >> >> ROUTES CONFIGURATION: >> # service rt status >> === REGLAS DE ENRUTAMIENTO ==>> 0: from all lookup local >> 50: from all lookup main >> 151: from NET_PUB1 lookup 151 >> 152: from NET_PUB2 lookup 152 >> 220: from all lookup 220 >> 32766: from all lookup main >> 32767: from all lookup default >> === TABLAS DE RUTAS ==>> === MAIN ==>> NET_PUB1/26 dev wan0 proto kernel scope link src IP_PUB1 >> NET_PUB2/24 dev wan0 proto kernel scope link src IP_PUB2 >> 192.168.3.0/24 dev zlan0 proto kernel scope link src 192.168.3.247 >> 192.168.2.0/24 dev zlan0 proto kernel scope link src 192.168.2.247 >> 192.168.1.0/24 dev zlan0 proto kernel scope link src 192.168.1.247 >> 10.1.1.0/24 dev zlan0 proto kernel scope link src 10.1.1.6 >> 169.254.0.0/16 dev zlan0 scope link >> 239.0.0.0/8 dev zlan0 scope link >> === wan0 TABLA 151 ==>> default via GW_PUB1 dev wan0 proto static src IP_PUB1 >> prohibit default proto static metric 1 >> === wan0 TABLA 152 ==>> default via GW_PUB2 dev wan0 proto static src IP_PUB2 >> prohibit default proto static metric 1 >> === TABLA 220 (defecto) ==>> default proto static >> nexthop via GW_PUB1 dev wan0 weight 1 >> nexthop via GW_PUB2 dev wan0 weight 1 >> >> ROUTING parameters configuration: >> # grep . /proc/sys/net/ipv4/route/* >> /proc/sys/net/ipv4/route/error_burst:5000 >> /proc/sys/net/ipv4/route/error_cost:1000 >> grep: /proc/sys/net/ipv4/route/flush: Operación no permitida >> /proc/sys/net/ipv4/route/gc_elasticity:8 >> /proc/sys/net/ipv4/route/gc_interval:60 >> /proc/sys/net/ipv4/route/gc_min_interval:0 >> /proc/sys/net/ipv4/route/gc_min_interval_ms:500 >> /proc/sys/net/ipv4/route/gc_thresh:32768 >> /proc/sys/net/ipv4/route/gc_timeout:300 >> /proc/sys/net/ipv4/route/max_delay:10 >> /proc/sys/net/ipv4/route/max_size:524288 >> /proc/sys/net/ipv4/route/min_adv_mss:256 >> /proc/sys/net/ipv4/route/min_delay:2 >> /proc/sys/net/ipv4/route/min_pmtu:552 >> /proc/sys/net/ipv4/route/mtu_expires:600 >> /proc/sys/net/ipv4/route/redirect_load:20 >> /proc/sys/net/ipv4/route/redirect_number:9 >> /proc/sys/net/ipv4/route/redirect_silence:20480 >> /proc/sys/net/ipv4/route/secret_interval:600 >> >> When I test it along some weeks with intensive traffic I''ll put here >> more >> info about this test. >> >> If somebody has any idea on how to solve the problem, please, tell us. >> I''m >> a bit desesperate with this issue. >> >> Regards >> >> _______________________________________________ >> LARTC mailing list >> LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> > > > >