load balance [OT?]

load balance [OT?]

[Martin]

Hello netfilter list!

I don't know if this is the right place to post this question, but looks
that I won't find people with more knowledge about networking anywhere
else :)

I've been browsing list archive and some people send a few examples on
how to do it with ip route, but it's not working for me...

Here is what I've configured based on those examples and this
http://lartc.org/lartc.html


I've two ISP, and internal lan.

#ISP 1
ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
ip route add default via $ISP1_GW dev $ISP1_IF

#ISP 2 
ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
ip route add default via $ISP2_GW dev $ISP2_IF

#Rules for ISPs
ip rule add $ISP1_IP table 1
ip rule add $ISP2_IP table 2

#Internal LAN and cross reference to the other ISP
ip route add $LAN_NET dev $LAN_IF table 1
ip route add $ISP2_NET dev $ISP2_IF table 1

ip route add $LAN_NET dev $LAN_IF table 2
ip route add $ISP1_NET dev $ISP1_IF table 2

#Add isp net in main
ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP
ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP

#This should do the trick of balancing

ip route add default scope global equalize nexthop via $ISP1_GW dev
ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2


What actually happens is that traffic is going out only by the first GW
declared in the first nexthop, and it doesn't care weight nor balance.
The only chance of making it to go throw the second GW declared is
shutting down or collapse that interface, so then it goes for the second
one.

I'm using a vanilla kernel 2.6.23.17 with Alexey Kuznetsov's route
patches and some others at http://www.ssi.bg/~ja/ (using the
combinations patch offered in the site)



What am I doing wrong? I'm missing something, but can't figure out
what...


Any clue will be investigated ;)


Thanks for your time


Martin

Re: load balance [OT?]

[Mark Perry]

Martin wrote:
> Hello netfilter list!
> 
> #ISP 1
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
> ip route add default via $ISP1_GW dev $ISP1_IF
> 
> #ISP 2 
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
> ip route add default via $ISP2_GW dev $ISP2_IF
> 
> #Rules for ISPs
> ip rule add $ISP1_IP table 1
> ip rule add $ISP2_IP table 2
> 
> #Internal LAN and cross reference to the other ISP
> ip route add $LAN_NET dev $LAN_IF table 1
> ip route add $ISP2_NET dev $ISP2_IF table 1
> 
> ip route add $LAN_NET dev $LAN_IF table 2
> ip route add $ISP1_NET dev $ISP1_IF table 2
> 
> #Add isp net in main
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP
> 
> #This should do the trick of balancing
> 
> ip route add default scope global equalize nexthop via $ISP1_GW dev
> ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2
> 
> 
> What actually happens is that traffic is going out only by the first GW
> declared in the first nexthop, and it doesn't care weight nor balance.
> The only chance of making it to go throw the second GW declared is
> shutting down or collapse that interface, so then it goes for the second
> one.
> 
You have requested different weights:

ip route add default scope global equalize nexthop via $ISP1_GW dev
ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2

If you want each to be equal then at least give them equal weights.


-- 
Mark Perry

Re: load balance [OT?]

[Martin]

On Tue, 2008-06-03 at 12:56 +0700, Mark Perry wrote:
[...]
> You have requested different weights:
> 
> ip route add default scope global equalize nexthop via $ISP1_GW dev
> ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2
> 
> If you want each to be equal then at least give them equal weights.
> 

Thanks for your response Mark.

That's right, I'm using different weights because they are differents
providers with different bandwidth.

Anyway, I tried it without "equalize", but still the same happens. Only
the first hop is used.


Can't figure out what am I doing wrong ¿something in kernel that I
should enable? Have "Advanced routing" build-in and some other things of
the "combination patch" at http://www.ssi.bg/~ja/ 


Thanks again for you feedback.


Cheers

Martin

Re: load balance [OT?]

[Martin]

On Mon, 2008-06-02 at 16:26 -0300, Martin wrote:
[...]
> #ISP 1
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
> ip route add default via $ISP1_GW dev $ISP1_IF
> 
> #ISP 2 
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
> ip route add default via $ISP2_GW dev $ISP2_IF
> 
> #Rules for ISPs
> ip rule add $ISP1_IP table 1
> ip rule add $ISP2_IP table 2
> 
> #Internal LAN and cross reference to the other ISP
> ip route add $LAN_NET dev $LAN_IF table 1
> ip route add $ISP2_NET dev $ISP2_IF table 1
> 
> ip route add $LAN_NET dev $LAN_IF table 2
> ip route add $ISP1_NET dev $ISP1_IF table 2
> 
> #Add isp net in main
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP
> 
> #This should do the trick of balancing
> 
> ip route add default scope global equalize nexthop via $ISP1_GW dev
> ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2
[...]


Well, here is some update.


I made some kind of load balance, but not as expected.

Doing some tests just to try to find out where con be the problem, I
found this:

ip route add default equalize nexthop dev $ISP_IF1 weight 1 nexthop dev
$ISP2_IF weight 1


It does load balance, sending some packets to one interface or another,
but using $ISP1_IP. That makes no sense, it's using second nexthop, but
using first nexthop's ip.

Anyway, if I add the complete sentence with corresponding IP and dev, it
keeps using only the first nexthop until it goes down.

Can't figure out why it only uses first IP at the "nexthop" rule....


Should I call Molder and Scully? :S


Thanks list for your support


Cheers


Martin

Re: load balance [OT?]

[Martin]

On Tue, 2008-06-03 at 23:51 +0700, Mark Perry wrote:
> Martin wrote:
> 
> >> #Rules for ISPs
> >> ip rule add $ISP1_IP table 1
> >> ip rule add $ISP2_IP table 2
> >>
> 
> Are these rules working?
> shouldn't they be:
> 
> ip rule add from $ISP1_IP table 1
> ip rule add from $ISP2_IP table 2
> 
> 
> mark


Thanks for the reply Mark.


Actually the do work. Why they shouldn't?


Cheers 

Martin

Re: load balance [OT?]

[Martin]

On Wed, 2008-06-04 at 00:09 +0700, Mark Perry wrote:
> Martin wrote:
> > On Tue, 2008-06-03 at 23:51 +0700, Mark Perry wrote:
> >> Martin wrote:
> >>
> >>>> #Rules for ISPs
> >>>> ip rule add $ISP1_IP table 1
> >>>> ip rule add $ISP2_IP table 2
> >>>>
> >> Are these rules working?
> >> shouldn't they be:
> >>
> >> ip rule add from $ISP1_IP table 1
> >> ip rule add from $ISP2_IP table 2
> >>
> >>
> >> mark

> > 
> > Actually the do work. Why they shouldn't?
> > 
> > 

> I tried then on a system at hand (OK 2.6.16 with iproute2 2.6.15) and I 
> got a parse error without the "from".
> 
> I'm no expert (an enthusiast maybe) - just another pair of eyes ;-)
> 
> mark


Mmmm...don't know...could it be a different iproute package?

I've installed a Debian "apt-get" one.

#dpkg -l | grep iproute

ii   iproute			20061002-3


May be I can try downloading source and compiling

Thanks for the extra eyes :)


Cheers


Martin

Re: load balance [OT?]

[Mark Perry]

Martin wrote:
> On Wed, 2008-06-04 at 00:09 +0700, Mark Perry wrote:
>> Martin wrote:
>>> On Tue, 2008-06-03 at 23:51 +0700, Mark Perry wrote:
>>>> Martin wrote:
>>>>
>>>>>> #Rules for ISPs
>>>>>> ip rule add $ISP1_IP table 1
>>>>>> ip rule add $ISP2_IP table 2
>>>>>>
>>>> Are these rules working?
>>>> shouldn't they be:
>>>>
>>>> ip rule add from $ISP1_IP table 1
>>>> ip rule add from $ISP2_IP table 2
>>>>
>>>>
>>>> mark
> 
>>> Actually the do work. Why they shouldn't?
>>>
>>>
> 
>> I tried then on a system at hand (OK 2.6.16 with iproute2 2.6.15) and I 
>> got a parse error without the "from".
>>
>> I'm no expert (an enthusiast maybe) - just another pair of eyes ;-)
>>
>> mark
> 
> 
> Mmmm...don't know...could it be a different iproute package?
> 
> I've installed a Debian "apt-get" one.
> 
> #dpkg -l | grep iproute
> 
> ii   iproute			20061002-3
> 
> 
> May be I can try downloading source and compiling
> 
> Thanks for the extra eyes :)

Well the important thing is do (after a reboot and rerun of your shell 
script):

ip route show
ip route show table 1
ip route show table 2
and
ip rule show

Produce the expected results?

mark

Re: load balance [OT?]

[Martin]

On Wed, 2008-06-04 at 00:40 +0700, Mark Perry wrote:
[...]
> 
> Well the important thing is do (after a reboot and rerun of your shell 
> script):
> 
> ip route show
> ip route show table 1
> ip route show table 2
> and
> ip rule show
> 
> Produce the expected results?
> 
> mark


Yes, it does.

Just in case I'm searching for a list of bugs at iproute package in
Debian distros.

By now I'm pretty confused about what can be wrong.

Thanks again for the help Mark.

Martin

Re: load balance [OT?]

[Martin]

On Wed, 2008-06-04 at 01:03 +0700, Mark Perry wrote:
> Martin wrote:
> >> #ISP 1
> >> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
> >> ip route add default via $ISP1_GW dev $ISP1_IF
> >>
> >> #ISP 2 
> >> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
> >> ip route add default via $ISP2_GW dev $ISP2_IF
> >>
> 
> Shouldn't the default routes here be for table 1 and table 2 respectively?
> 
> You are adding them to the default table?
> 
> I thought the idea was to have 2 new tables each with their own default 
> route?
> 
> mark
> 

Right, I figured out that after sending the first mail to the list.

By now it is:
#ISP 1
ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
ip route add default via $ISP1_GW dev $ISP1_IF table 1

#ISP 2 
ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
ip route add default via $ISP2_GW dev $ISP2_IF table 2


And then add the defualt with two nexthops at the default route.


Cheers


Martin

Re: load balance [OT?]

[Martin]

Well, it won't work, and probably is some kind of error with a kernel
patch.


My last test was using the method explained here
http://www.ssi.bg/~ja/nano.txt

As it didn't work out, I tried the same method using a fresh Debian
install, with a stock kernel without patches or anything else....it work
out just out the box.

The only difference between my try of linux router and a fresh installed
Debian box is the kernel it uses.

Kernel used in Linux-router: 2.6.23.17
Patches: IMQ www.linuximq.net
	 Combination routing patch www.ssi.bg/~ja/nano.txt
	 Layer 7 http://l7-filter.sourceforge.net

Load balance work: NO
-----------------------------------------------------------

Kernel in fresh Debian install: stock kernel 2.6.18-5-686
Patches: NONE
Load balance work: YES



If someone have similar kernel using those patches, or at least the
combination patch, with a working load balance, I'll be glad to ear
about how you did it (and invite you a beer if you ever come to where I
live). Until then.

I'll start trying one patch at time (and applying separated patches from
the combinations one) and see what can I do.


Thanks to all, specially to Mark Perry for his time and extra pair of
eyes 8)


Cheers


Martin

Re: load balance [OT?]

[ArcosCom Linux User]

I was using the patch you commented along this thread but it overloads the
routing tables.

Now I have this configuration:
=== REGLAS IPTABLES PARA EL ENRUTADO ===
Chain PREROUTING (policy ACCEPT 21M packets, 16G bytes)
num   pkts bytes target     prot opt in     out     source              
destination
1      14M   11G M_TRAF_IN  all  --  *      *       0.0.0.0/0           
0.0.0.0/0
2      13M   10G M_IFACE    all  --  *      *       0.0.0.0/0           
0.0.0.0/0
Chain M_IFACE (1 references)
num   pkts bytes target     prot opt in     out     source              
destination
1      12M 8196M CONNMARK   all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 CONNMARK restore
2    2581K 2331M RETURN     all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match !0x0/0xf000
3      11M 8158M M_IFACE_TRAF  all  --  *      *       0.0.0.0/0          
 0.0.0.0/0           MARK match 0x0/0xf000
4    40242 2284K MARK       all  --  eth2   *       0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x2000
5    40342 2381K MARK       all  --  eth3   *       0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x8000
6    80584 4665K CONNMARK   all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match !0x0/0xf000 CONNMARK save
7      11M 8158M RETURN     all  --  *      *       0.0.0.0/0           
0.0.0.0/0
Chain M_IFACE_TRAF (2 references)
num   pkts bytes target     prot opt in     out     source              
destination
Chain FORWARD (policy ACCEPT 3292K packets, 1985M bytes)
num   pkts bytes target     prot opt in     out     source              
destination
1    1618K 1046M M_IFACE_OUT  all  --  *      *       0.0.0.0/0           
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 20M packets, 15G bytes)
num   pkts bytes target     prot opt in     out     source              
destination
1      13M 9867M M_IFACE_OUT  all  --  *      *       0.0.0.0/0           
0.0.0.0/0
Chain M_IFACE_OUT (2 references)
num   pkts bytes target     prot opt in     out     source              
destination
1      13M 9885M CONNMARK   all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 CONNMARK restore
2    2342K 1180M RETURN     all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match !0x0/0xf000
3      12M 9733M M_IFACE_TRAF  all  --  *      *       0.0.0.0/0          
 0.0.0.0/0           MARK match 0x0/0xf000
4    58815 3592K MARK       all  --  *      eth2    0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x2000
5    59337 3615K MARK       all  --  *      eth3    0.0.0.0/0           
0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x8000
6     118K 7207K CONNMARK   all  --  *      *       0.0.0.0/0           
0.0.0.0/0           MARK match !0x0/0xf000 CONNMARK save
7      12M 9733M RETURN     all  --  *      *       0.0.0.0/0           
0.0.0.0/0
=== REGLAS DE ENRUTAMIENTO ===
0:      from all lookup local
50:     from all lookup main
100:    from all fwmark 0x2000/0x2000 lookup uno
101:    from all fwmark 0x8000/0x8000 lookup dos
150:    from 212.170.103.235 lookup uno
151:    from 212.59.210.142 lookup dos
200:    from all lookup defecto
32766:  from all lookup main
32767:  from all lookup default
=== TABLAS DE RUTAS ===
=== MAIN ===
212.170.103.192/26 dev eth2  proto kernel  scope link  src 212.170.103.235
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
212.59.210.0/24 dev eth3  proto kernel  scope link  src 212.59.210.142
10.1.1.0/24 dev zlan0  proto kernel  scope link  src 10.1.1.6
=== eth2 TABLA 150 ===
212.170.103.192/26 dev eth2  scope link  src 212.170.103.235
default via 212.170.103.193 dev eth2  src 212.170.103.235
prohibit default  proto static  metric 1
=== eth3 TABLA 151 ===
212.59.210.0/24 dev eth3  scope link  src 212.59.210.142
default via 212.59.210.1 dev eth3  src 212.59.210.142
prohibit default  proto static  metric 1
=== TABLA 200 (defecto) ===
default
        nexthop via 212.170.103.193  dev eth2 weight 1
        nexthop via 212.59.210.1  dev eth3 weight 1



Appears to work, but, for now, I'm having problems (last Centos 2.6.18
kernel).

I expect this can help you a bit. Be care, I have some problem as you,
with previous 2.6.18 centos kernel this configuration appeared to works
fine, but with last 2.6.28 centos kernel I'm having troubles.

Regards

El Lun, 2 de Junio de 2008, 21:26, Martin escribió:
> Hello netfilter list!
>
> I don't know if this is the right place to post this question, but looks
> that I won't find people with more knowledge about networking anywhere
> else :)
>
> I've been browsing list archive and some people send a few examples on
> how to do it with ip route, but it's not working for me...
>
> Here is what I've configured based on those examples and this
> http://lartc.org/lartc.html
>
>
> I've two ISP, and internal lan.
>
> #ISP 1
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP table 1
> ip route add default via $ISP1_GW dev $ISP1_IF
>
> #ISP 2
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP table 2
> ip route add default via $ISP2_GW dev $ISP2_IF
>
> #Rules for ISPs
> ip rule add $ISP1_IP table 1
> ip rule add $ISP2_IP table 2
>
> #Internal LAN and cross reference to the other ISP
> ip route add $LAN_NET dev $LAN_IF table 1
> ip route add $ISP2_NET dev $ISP2_IF table 1
>
> ip route add $LAN_NET dev $LAN_IF table 2
> ip route add $ISP1_NET dev $ISP1_IF table 2
>
> #Add isp net in main
> ip route add $ISP1_NET dev $ISP1_IF src $ISP1_IP
> ip route add $ISP2_NET dev $ISP2_IF src $ISP2_IP
>
> #This should do the trick of balancing
>
> ip route add default scope global equalize nexthop via $ISP1_GW dev
> ISP1_IF weight 1 nexthop via $ISP2_GW dev $ISP2_IF weight 2
>
>
> What actually happens is that traffic is going out only by the first GW
> declared in the first nexthop, and it doesn't care weight nor balance.
> The only chance of making it to go throw the second GW declared is
> shutting down or collapse that interface, so then it goes for the second
> one.
>
> I'm using a vanilla kernel 2.6.23.17 with Alexey Kuznetsov's route
> patches and some others at http://www.ssi.bg/~ja/ (using the
> combinations patch offered in the site)
>
>
>
> What am I doing wrong? I'm missing something, but can't figure out
> what...
>
>
> Any clue will be investigated ;)
>
>
> Thanks for your time
>
>
> Martin
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: load balance [OT?]

[Martin]

On Wed, 2008-06-04 at 00:27 +0200, ArcosCom Linux User wrote:
> I was using the patch you commented along this thread but it overloads the
> routing tables.
> 
> Now I have this configuration:
> === REGLAS IPTABLES PARA EL ENRUTADO ===
> Chain PREROUTING (policy ACCEPT 21M packets, 16G bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination
> 1      14M   11G M_TRAF_IN  all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> 2      13M   10G M_IFACE    all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> Chain M_IFACE (1 references)
> num   pkts bytes target     prot opt in     out     source              
> destination
> 1      12M 8196M CONNMARK   all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 CONNMARK restore
> 2    2581K 2331M RETURN     all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match !0x0/0xf000
> 3      11M 8158M M_IFACE_TRAF  all  --  *      *       0.0.0.0/0          
>  0.0.0.0/0           MARK match 0x0/0xf000
> 4    40242 2284K MARK       all  --  eth2   *       0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x2000
> 5    40342 2381K MARK       all  --  eth3   *       0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x8000
> 6    80584 4665K CONNMARK   all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match !0x0/0xf000 CONNMARK save
> 7      11M 8158M RETURN     all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> Chain M_IFACE_TRAF (2 references)
> num   pkts bytes target     prot opt in     out     source              
> destination
> Chain FORWARD (policy ACCEPT 3292K packets, 1985M bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination
> 1    1618K 1046M M_IFACE_OUT  all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20M packets, 15G bytes)
> num   pkts bytes target     prot opt in     out     source              
> destination
> 1      13M 9867M M_IFACE_OUT  all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> Chain M_IFACE_OUT (2 references)
> num   pkts bytes target     prot opt in     out     source              
> destination
> 1      13M 9885M CONNMARK   all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 CONNMARK restore
> 2    2342K 1180M RETURN     all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match !0x0/0xf000
> 3      12M 9733M M_IFACE_TRAF  all  --  *      *       0.0.0.0/0          
>  0.0.0.0/0           MARK match 0x0/0xf000
> 4    58815 3592K MARK       all  --  *      eth2    0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x2000
> 5    59337 3615K MARK       all  --  *      eth3    0.0.0.0/0           
> 0.0.0.0/0           MARK match 0x0/0xf000 state NEW MARK or 0x8000
> 6     118K 7207K CONNMARK   all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           MARK match !0x0/0xf000 CONNMARK save
> 7      12M 9733M RETURN     all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0
> === REGLAS DE ENRUTAMIENTO ===
> 0:      from all lookup local
> 50:     from all lookup main
> 100:    from all fwmark 0x2000/0x2000 lookup uno
> 101:    from all fwmark 0x8000/0x8000 lookup dos
> 150:    from 212.170.103.235 lookup uno
> 151:    from 212.59.210.142 lookup dos
> 200:    from all lookup defecto
> 32766:  from all lookup main
> 32767:  from all lookup default
> === TABLAS DE RUTAS ===
> === MAIN ===
> 212.170.103.192/26 dev eth2  proto kernel  scope link  src 212.170.103.235
> 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
> 212.59.210.0/24 dev eth3  proto kernel  scope link  src 212.59.210.142
> 10.1.1.0/24 dev zlan0  proto kernel  scope link  src 10.1.1.6
> === eth2 TABLA 150 ===
> 212.170.103.192/26 dev eth2  scope link  src 212.170.103.235
> default via 212.170.103.193 dev eth2  src 212.170.103.235
> prohibit default  proto static  metric 1
> === eth3 TABLA 151 ===
> 212.59.210.0/24 dev eth3  scope link  src 212.59.210.142
> default via 212.59.210.1 dev eth3  src 212.59.210.142
> prohibit default  proto static  metric 1
> === TABLA 200 (defecto) ===
> default
>         nexthop via 212.170.103.193  dev eth2 weight 1
>         nexthop via 212.59.210.1  dev eth3 weight 1
> 
> 
> 
> Appears to work, but, for now, I'm having problems (last Centos 2.6.18
> kernel).
> 
> I expect this can help you a bit. Be care, I have some problem as you,
> with previous 2.6.18 centos kernel this configuration appeared to works
> fine, but with last 2.6.28 centos kernel I'm having troubles.
> 
> Regards
> 
[..]

Thanks for the advice and details.

I'll be patching -> compiling -> testing all day, so I'll post any
update if I find that the problem is one of those patches.


Cheers and happy birthday to me! :)


Martin