[LARTC] multipath routing

[LARTC] multipath routing

[Lists @ Aptedtech]

I have a private lan that is connected to the world via 3 dsl lines.  I put
up a linux box that handles all the dsl lines, lan gateway and all is
working well...until...one of the dsl lines goes down.  My routing table is:

x.x.x.x dev ppp0  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp1  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp2  proto kernel  scope link  src x.x.x.x
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
255.255.255.0/24 dev eth0  scope link
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default equalize
        nexthop via x.x.x.x  dev ppp0 weight 1
        nexthop via x.x.x.x  dev ppp1 weight 1
        nexthop via x.x.x.x  dev ppp2 weight 1

When one of the dsl lines has trouble (temporarily looses sync, etc), the
kernel takes the entire default route out until the line comes back up.
When the line comes up, it puts a single default route back in instead of
the multipath route.  If I can make it so the multipath route is maintained
even when one of the dsl lines goes down, that would be great.  Is there a
way to have just one of the hops removed from the default multipath while
the line is down and then reinserted back in as a hop in the multipath
route?  Thanks for any input.

-Chris

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] multipath routing

[RonSenykoff]

This is a multipart message in MIME format.
--=_alternative 002179AF86256E61_Content-Type: text/plain; charset="US-ASCII"

<snip>
I have a private lan that is connected to the world via 3 dsl lines.  I 
put
up a linux box that handles all the dsl lines, lan gateway and all is
working well...until...one of the dsl lines goes down.  My routing table 
is:

x.x.x.x dev ppp0  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp1  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp2  proto kernel  scope link  src x.x.x.x
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
255.255.255.0/24 dev eth0  scope link
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default equalize
        nexthop via x.x.x.x  dev ppp0 weight 1
        nexthop via x.x.x.x  dev ppp1 weight 1
        nexthop via x.x.x.x  dev ppp2 weight 1

When one of the dsl lines has trouble (temporarily looses sync, etc), the
kernel takes the entire default route out until the line comes back up.
When the line comes up, it puts a single default route back in instead of
the multipath route.  If I can make it so the multipath route is 
maintained
even when one of the dsl lines goes down, that would be great.  Is there a
way to have just one of the hops removed from the default multipath while
the line is down and then reinserted back in as a hop in the multipath
route?  Thanks for any input.

-Chris
</snip>

Do you have the stateful firewall settings in your script?

According to nano.txt
http://www.ssi.bg/~ja/nano.txt

"At least for netfilter (not sure for ipfwadm/ipchains), the firewall
must be stateful. This can be done by:

                 iptables -t filter -N keep_state
                 iptables -t filter -A keep_state -m state --state 
RELATED,ESTABLISHED \
                                 -j ACCEPT
                 iptables -t filter -A keep_state -j RETURN

                 iptables -t nat -N keep_state
                 iptables -t nat -A keep_state -m state --state 
RELATED,ESTABLISHED \
                                 -j ACCEPT
                 iptables -t nat -A keep_state -j RETURN

and calling this at the beginning of the script:

                 iptables -t nat -A PREROUTING -j keep_state
                 iptables -t nat -A POSTROUTING -j keep_state
                 iptables -t nat -A OUTPUT -j keep_state
                 iptables -t filter -A INPUT -j keep_state
                 iptables -t filter -A FORWARD -j keep_state
                 iptables -t filter -A OUTPUT -j keep_state
"
--=_alternative 002179AF86256E61_Content-Type: text/html; charset="US-ASCII"


<br><font size=1 face="Verdana"><i>&lt;snip&gt;</i></font>
<br><font size=1 face="Verdana"><i>I have a private lan that is connected
to the world via 3 dsl lines. &nbsp;I put<br>
up a linux box that handles all the dsl lines, lan gateway and all is<br>
working well...until...one of the dsl lines goes down. &nbsp;My routing
table is:<br>
<br>
x.x.x.x dev ppp0 &nbsp;proto kernel &nbsp;scope link &nbsp;src x.x.x.x<br>
x.x.x.x dev ppp1 &nbsp;proto kernel &nbsp;scope link &nbsp;src x.x.x.x<br>
x.x.x.x dev ppp2 &nbsp;proto kernel &nbsp;scope link &nbsp;src x.x.x.x<br>
192.168.1.0/24 dev eth0 &nbsp;proto kernel &nbsp;scope link &nbsp;src 192.168.1.1<br>
255.255.255.0/24 dev eth0 &nbsp;scope link<br>
169.254.0.0/16 dev eth0 &nbsp;scope link<br>
127.0.0.0/8 dev lo &nbsp;scope link<br>
default equalize<br>
 &nbsp; &nbsp; &nbsp; &nbsp;nexthop via x.x.x.x &nbsp;dev ppp0 weight 1<br>
 &nbsp; &nbsp; &nbsp; &nbsp;nexthop via x.x.x.x &nbsp;dev ppp1 weight 1<br>
 &nbsp; &nbsp; &nbsp; &nbsp;nexthop via x.x.x.x &nbsp;dev ppp2 weight 1<br>
<br>
When one of the dsl lines has trouble (temporarily looses sync, etc), the<br>
kernel takes the entire default route out until the line comes back up.<br>
When the line comes up, it puts a single default route back in instead
of<br>
the multipath route. &nbsp;If I can make it so the multipath route is maintained<br>
even when one of the dsl lines goes down, that would be great. &nbsp;Is
there a<br>
way to have just one of the hops removed from the default multipath while<br>
the line is down and then reinserted back in as a hop in the multipath<br>
route? &nbsp;Thanks for any input.<br>
<br>
-Chris<br>
&lt;/snip&gt;</i></font>
<br>
<br><font size=1 face="Verdana">Do you have the stateful firewall settings
in your script?</font>
<br>
<br><font size=1 face="Verdana">According to nano.txt</font>
<br><font size=1 face="Verdana">http://www.ssi.bg/~ja/nano.txt</font>
<br>
<br><font size=1 face="Verdana">&quot;At least for netfilter (not sure
for ipfwadm/ipchains), the firewall<br>
must be stateful. This can be done by:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -N keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -A keep_state -m state --state RELATED,ESTABLISHED \<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-j
ACCEPT<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -A keep_state -j RETURN<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -N keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -A keep_state -m state --state RELATED,ESTABLISHED \<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;-j
ACCEPT<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -A keep_state -j RETURN<br>
<br>
and calling this at the beginning of the script:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -A PREROUTING -j keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -A POSTROUTING -j keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t nat -A OUTPUT -j keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -A INPUT -j keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -A FORWARD -j keep_state<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
iptables -t filter -A OUTPUT -j keep_state<br>
&quot;</font>
--=_alternative 002179AF86256E61_=--
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

RE: [LARTC] multipath routing

[Lists @ Aptedtech]

[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]

<snip>
I have a private lan that is connected to the world via 3 dsl lines.  I put
up a linux box that handles all the dsl lines, lan gateway and all is
working well...until...one of the dsl lines goes down.  My routing table is:

x.x.x.x dev ppp0  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp1  proto kernel  scope link  src x.x.x.x
x.x.x.x dev ppp2  proto kernel  scope link  src x.x.x.x
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
255.255.255.0/24 dev eth0  scope link
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default equalize
       nexthop via x.x.x.x  dev ppp0 weight 1
       nexthop via x.x.x.x  dev ppp1 weight 1
       nexthop via x.x.x.x  dev ppp2 weight 1

When one of the dsl lines has trouble (temporarily looses sync, etc), the
kernel takes the entire default route out until the line comes back up.
When the line comes up, it puts a single default route back in instead of
the multipath route.  If I can make it so the multipath route is maintained
even when one of the dsl lines goes down, that would be great.  Is there a
way to have just one of the hops removed from the default multipath while
the line is down and then reinserted back in as a hop in the multipath
route?  Thanks for any input.

-Chris
</snip>

Do you have the stateful firewall settings in your script?

According to nano.txt
http://www.ssi.bg/~ja/nano.txt

"At least for netfilter (not sure for ipfwadm/ipchains), the firewall
must be stateful. This can be done by:

                iptables -t filter -N keep_state
                iptables -t filter -A keep_state -m state --state
RELATED,ESTABLISHED \
                                 -j ACCEPT
                iptables -t filter -A keep_state -j RETURN

                iptables -t nat -N keep_state
                iptables -t nat -A keep_state -m state --state
RELATED,ESTABLISHED \
                                 -j ACCEPT
                iptables -t nat -A keep_state -j RETURN

and calling this at the beginning of the script:

                iptables -t nat -A PREROUTING -j keep_state
                iptables -t nat -A POSTROUTING -j keep_state
                iptables -t nat -A OUTPUT -j keep_state
                iptables -t filter -A INPUT -j keep_state
                iptables -t filter -A FORWARD -j keep_state
                iptables -t filter -A OUTPUT -j keep_state
"


/sbin/iptables-save

# Generated by iptables-save v1.2.7a on Wed Mar 24 15:54:00 2004
*nat
:PREROUTING ACCEPT [9983:812849]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [3:174]
:keep_state - [0:0]
-A PREROUTING -j keep_state
-A POSTROUTING -o ppp+ -j MASQUERADE
-A POSTROUTING -j keep_state
-A OUTPUT -j keep_state
-A keep_state -m state --state RELATED,ESTABLISHED -j ACCEPT
-A keep_state -j RETURN
COMMIT
# Completed on Wed Mar 24 15:54:00 2004
# Generated by iptables-save v1.2.7a on Wed Mar 24 15:54:00 2004
*filter
:INPUT ACCEPT [1020:161876]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [425:33288]
:keep_state - [0:0]
-A INPUT -i lo -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i ppp+ -m state --state INVALID -j DROP
-A INPUT -i ppp+ -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i ppp+ -p tcp -j DROP
-A INPUT -i ppp+ -p udp -j DROP
-A INPUT -i ppp+ -p icmp -j DROP
-A INPUT -j keep_state
-A FORWARD -i ppp+ -o eth+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth+ -o ppp+ -j ACCEPT
-A FORWARD -j keep_state
-A OUTPUT -o lo -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o ppp+ -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -j keep_state
-A keep_state -m state --state RELATED,ESTABLISHED -j ACCEPT
-A keep_state -j RETURN
COMMIT
# Completed on Wed Mar 24 15:54:00 2004

The link you reference (http://www.ssi.bg/~ja/nano.txt) suggests several
patches to be applied to the kernel for the routing described to be
possible.  I would like to do this, but it is a company box and they want a
"standard" installation which basically means no patching for me.  The box
is running the most up to date kernel for a RedHat 9.0 install.  Thanks for
any input.

-Chris

[-- Attachment #2: Type: text/html, Size: 6914 bytes --]

[LARTC] Multipath Routing..

[Daniel Frederiksen]

Ok folks, here goes..

I have been boggling with a problem for the past week, and still haven't 
found a solution..

I'm trying to route traffic from two providers through a Linux machine.
But that is not the problem. The ISP's have provided me with a WAN IP 
class for both of the lines, to be routed into a DMZ where the machines 
a to respond to their respective designated WAN IP on both lines.
Every machine on the DMZ has two IP's one on each ISP WAN Class.

I think I'll better draw a map:


       WAN1(eth2), WAN2(eth3)
            ---------                             (eth0)
            |       |-----\                     ----------
            |  DMZ  |---\  \                /---|  ISP1  |-----
            ---------    \  \              /    ----------     \
                          \  \            /                     \
                          -----------------
                          |  Linux GW/FW  |                     WWW
                          -----------------
                          /               \       (eth1)        /
            ---------    /                 \    ----------     /
            |  LAN  |---/                   \---|  ISP2  |-----
            ---------                           ----------
               NAT(eth4)


The DMZ has two WAN IP classes routed from the ISP.

The thing I just can not figure out is how to make the respective WAN IP 
from the DMZ route out the right ISP link, and the right request from 
the ISP route into the DMZ.

.. and finally how can I make the LAN able to access it all..

Thanks for your time..

/Daniel Frederiksen

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Multipath Routing..

[Alexander Samad]

[-- Attachment #1.1: Type: text/plain, Size: 2596 bytes --]

On Tue, Aug 16, 2005 at 06:11:26AM +0200, Daniel Frederiksen wrote:
> Ok folks, here goes..
> 
> I have been boggling with a problem for the past week, and still haven't 
> found a solution..
> 
> I'm trying to route traffic from two providers through a Linux machine.
> But that is not the problem. The ISP's have provided me with a WAN IP 
> class for both of the lines, to be routed into a DMZ where the machines 
> a to respond to their respective designated WAN IP on both lines.
> Every machine on the DMZ has two IP's one on each ISP WAN Class.
> 
> I think I'll better draw a map:
> 
> 
>       WAN1(eth2), WAN2(eth3)
>            ---------                             (eth0)
>            |       |-----\                     ----------
>            |  DMZ  |---\  \                /---|  ISP1  |-----
>            ---------    \  \              /    ----------     \
>                          \  \            /                     \
>                          -----------------
>                          |  Linux GW/FW  |                     WWW
>                          -----------------
>                          /               \       (eth1)        /
>            ---------    /                 \    ----------     /
>            |  LAN  |---/                   \---|  ISP2  |-----
>            ---------                           ----------
>               NAT(eth4)
> 
> 
> The DMZ has two WAN IP classes routed from the ISP.
> 
> The thing I just can not figure out is how to make the respective WAN IP 
> from the DMZ route out the right ISP link, and the right request from 
> the ISP route into the DMZ.
> 
> .. and finally how can I make the LAN able to access it all..

you need to use ip ru

my ip ru looks like 
0:      from all lookup local 
200:    from 141.168.16.16 lookup cable 
201:    from 220.233.15.63 lookup adsl 
32766:  from all lookup main 
32767:  from all lookup default 

I created 200 and 201 which means that all traffic that came in on the
cable 141.168.16.16 will go out the cable

ip ro sh tab cable
192.168.11.0/24 dev br0  scope link 
192.168.10.0/24 dev eth3  scope link 
192.168.9.0/24 dev eth4  scope link 
default via 141.168.16.1 dev eth0  src 141.168.16.16  metric 30 


and the routing tab for the adsl uses the adsl as its default gw.

does that help ?


> 
> Thanks for your time..
> 
> /Daniel Frederiksen
> 
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] multipath routing

[comp.techs]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============1372392955==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5DA76.EA68DB86"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 366 bytes --]

Hi, I am tring to us ip route to load balance  between two interfaces.
 
ip route add equalize 10.200.1.0/24 nexthop via 10.200.0.2 dev neta nexthop via 10.200.0.2 dev neta2
 
Where neta and neta2 are gre tunnels.   Testing show that packets travel  in a single sided manner.
 
Do I need to use the multipath (IP_ROUTE_MULTIPATH_CACHED) module?
 
thx jason

[-- Attachment #3: Type: text/html, Size: 830 bytes --]

Re: [LARTC] multipath routing

[Edmundo Carmona]

Multipath takes a little more that just setting the default route. You
have to set separate routing tables for each interface involved in the
multipath routing (though I haven't understood yet why they are
needed.. the fact is that if you don't set them, multipath won't
route).

Also, even if you set it all right, it doesn't mean that if you send
two packets to a location X, one will go through one interface and the
second will go through the other. Routes are cached, and after a
routing decision has been made for the first packet, packets going to
that same host will go through the same interface till the caching
time has gone by.

On 10/26/05, comp.techs <comp.techs@aspenview.org> wrote:
> Hi, I am tring to us ip route to load balance  between two interfaces.
>
>
>
> ip route add equalize 10.200.1.0/24 nexthop via 10.200.0.2 dev neta nexthop
> via 10.200.0.2 dev neta2
>
> Where neta and neta2 are gre tunnels.   Testing show that packets travel  in
> a single sided manner.
>
> Do I need to use the multipath (IP_ROUTE_MULTIPATH_CACHED) module?
>
> thx jason
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] multipath routing

[comp.techs]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============1656897621==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5DB10.04489052"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 1701 bytes --]

Hi, I also used TEQL this worked very well, but I require the (weight) option.
 
thx jason

________________________________

From: lartc-bounces@mailman.ds9a.nl on behalf of Edmundo Carmona
Sent: Thu 10/27/2005 8:20 AM
To: lartc
Subject: Re: [LARTC] multipath routing



Multipath takes a little more that just setting the default route. You
have to set separate routing tables for each interface involved in the
multipath routing (though I haven't understood yet why they are
needed.. the fact is that if you don't set them, multipath won't
route).

Also, even if you set it all right, it doesn't mean that if you send
two packets to a location X, one will go through one interface and the
second will go through the other. Routes are cached, and after a
routing decision has been made for the first packet, packets going to
that same host will go through the same interface till the caching
time has gone by.

On 10/26/05, comp.techs <comp.techs@aspenview.org> wrote:
> Hi, I am tring to us ip route to load balance  between two interfaces.
>
>
>
> ip route add equalize 10.200.1.0/24 nexthop via 10.200.0.2 dev neta nexthop
> via 10.200.0.2 dev neta2
>
> Where neta and neta2 are gre tunnels.   Testing show that packets travel  in
> a single sided manner.
>
> Do I need to use the multipath (IP_ROUTE_MULTIPATH_CACHED) module?
>
> thx jason
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc



[-- Attachment #3: Type: text/html, Size: 2668 bytes --]

RE: [LARTC] multipath routing

[comp.techs]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============0631013531==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5DB21.458BE26A"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 2188 bytes --]

Hi, using the following:
 
ip route add equalize 10.200.1.0/24 nexthop via 10.200.0.2 dev neta nexthop
> via 10.200.0.2 dev neta2

while doing a  ->
 
while [ 1 ]
do 
   ip route flush cache
done
 
the transfer of packets almost seems equal?
 
thx jason

________________________________

From: lartc-bounces@mailman.ds9a.nl on behalf of comp.techs
Sent: Thu 10/27/2005 10:02 AM
To: Edmundo Carmona; lartc@mailman.ds9a.nl
Subject: RE: [LARTC] multipath routing


Hi, I also used TEQL this worked very well, but I require the (weight) option.
 
thx jason

________________________________

From: lartc-bounces@mailman.ds9a.nl on behalf of Edmundo Carmona
Sent: Thu 10/27/2005 8:20 AM
To: lartc
Subject: Re: [LARTC] multipath routing



Multipath takes a little more that just setting the default route. You
have to set separate routing tables for each interface involved in the
multipath routing (though I haven't understood yet why they are
needed.. the fact is that if you don't set them, multipath won't
route).

Also, even if you set it all right, it doesn't mean that if you send
two packets to a location X, one will go through one interface and the
second will go through the other. Routes are cached, and after a
routing decision has been made for the first packet, packets going to
that same host will go through the same interface till the caching
time has gone by.

On 10/26/05, comp.techs <comp.techs@aspenview.org> wrote:
> Hi, I am tring to us ip route to load balance  between two interfaces.
>
>
>
> ip route add equalize 10.200.1.0/24 nexthop via 10.200.0.2 dev neta nexthop
> via 10.200.0.2 dev neta2
>
> Where neta and neta2 are gre tunnels.   Testing show that packets travel  in
> a single sided manner.
>
> Do I need to use the multipath (IP_ROUTE_MULTIPATH_CACHED) module?
>
> thx jason
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc



[-- Attachment #3: Type: text/html, Size: 3687 bytes --]

[LARTC] multipath routing

[comp.techs]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============0514444131==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5EBB8.2616F238"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

Hi, I have set up multipath routing using two gre tunnels. The multipath routes are setup via (zebra/ospf).
I managed to modify zebra not to include the 'equalize' in the multpath route, and set the weights 1:2.
 My question is that after doing 4+ ftp transfers I still do not see much traffic on the interface with a weight of 1 even thought the first tunnel is near maximum capacity. If this is due to the route cache, is there a way to reduce
the TTL on the cache ?
 
thx jason

[-- Attachment #3: Type: text/html, Size: 992 bytes --]

[LARTC] Multipath routing

[Michał Margula]

Hello!

	I have trouble with multipath routing. Those options are enabled in kernel:

[*]   IP: policy routing
[*]   IP: equal cost multipath
[*]     IP: equal cost multipath with caching support (EXPERIMENTAL)
<*>       MULTIPATH: round robin algorithm

But issuing:

ip r a 1.2.3.0/23 scope global equalize nexthop via 80.245.176.11 \
    dev eth0 weight 1 nexthop via 80.245.176.13 dev eth0 weight 1

and then

# ip r s
[...]
1.2.3.0/24
         nexthop via 80.245.176.11  dev eth0 weight 1
         nexthop via 80.245.176.13  dev eth0 weight 1

As you can see there is no equalize keyword in here.

Also I have trouble using multipath quagga, it simply doesn't put 
multipath route in routing table.

For example:

faramir# sh ip bgp 10.100.0.1
BGP routing table entry for 10.101.0.0/22
Paths: (2 available, best #1, table Default-IP-Routing-Table)
   Not advertised to any peer
   Local
     80.245.176.13 (metric 1) from 80.245.176.13 (80.245.177.4)
       Origin IGP, metric 0, localpref 100, weight 150, valid, internal, 
best
       Last update: Tue Jun  5 01:59:29 2007

   Local
     80.245.176.10 (metric 1) from 80.245.176.10 (80.245.176.10)
       Origin IGP, metric 0, localpref 100, weight 100, valid, internal
       Last update: Tue Jun  5 01:28:02 2007

# ip r s
[...]
10.100.0.0/22 via 80.245.176.11 dev eth0  proto zebra

But if I manually put something like that in quagga:

faramir(config)# ip route 1.2.3.0/24 80.245.176.13
faramir(config)# ip route 1.2.3.0/24 80.245.176.11

Then:

# ip r s
[...]
1.2.3.0/24
         nexthop via 80.245.176.11  dev eth0 weight 1
         nexthop via 80.245.176.13  dev eth0 weight 1


Please help, I am out of ideas.

-- 
Micha³ Margula, alchemyx@uznam.net.pl, http://alchemyx.uznam.net.pl/
"W ¿yciu piêkne s± tylko chwile" [Ryszard Riedel]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Multipath routing

[Piotr Chytla]

On Tue, Jun 05, 2007 at 11:13:52AM +0200, Micha³ Margula wrote:
> Hello!
>
Hi
 
> 	I have trouble with multipath routing. Those options are enabled in 
> 	kernel:
> 
> [*]   IP: policy routing
> [*]   IP: equal cost multipath
> [*]     IP: equal cost multipath with caching support (EXPERIMENTAL)
> <*>       MULTIPATH: round robin algorithm
>
First of all equal cost multipathing is evil ;>, It simply doesn't work for packets in
forwarding path besides support in kernel is not maintained

Realy if you want load balance both uplinks disable
CONFIG_IP_ROUTE_MULTIPATH_CACHED and you will have random traffic 
distribiution between both links.

More details : 
          http://lists.openwall.net/netdev/2007/03/14/50
          http://lists.openwall.net/netdev/2007/03/12/76
          http://lists.quagga.net/pipermail/quagga-users/2007-May/008469.html

 
> Also I have trouble using multipath quagga, it simply doesn't put 
> multipath route in routing table.
> 
> For example:
> 
> faramir# sh ip bgp 10.100.0.1
> BGP routing table entry for 10.101.0.0/22
> Paths: (2 available, best #1, table Default-IP-Routing-Table)
>   Not advertised to any peer
>   Local
>     80.245.176.13 (metric 1) from 80.245.176.13 (80.245.177.4)
>       Origin IGP, metric 0, localpref 100, weight 150, valid, internal, 
> best
>       Last update: Tue Jun  5 01:59:29 2007
> 
>   Local
>     80.245.176.10 (metric 1) from 80.245.176.10 (80.245.176.10)
>       Origin IGP, metric 0, localpref 100, weight 100, valid, internal
>       Last update: Tue Jun  5 01:28:02 2007
>
BGP always have alternative paths in BGP RIB and mostly don't insert them
as multipath route to FIB.

Of course there is path : http://lebon.org.ua/quagga.html that force 
route to be inserted to kernel with multiple gateways - but realy this
is some kind of dirty-hack.

Check thread 'Linux and BGP multipath' on quagga-dev, and especially this mail:

           http://lists.quagga.net/pipermail/quagga-dev/2007-April/004700.html


> # ip r s
> [...]
> 10.100.0.0/22 via 80.245.176.11 dev eth0  proto zebra
> 
> But if I manually put something like that in quagga:
> 
> faramir(config)# ip route 1.2.3.0/24 80.245.176.13
> faramir(config)# ip route 1.2.3.0/24 80.245.176.11
> 
yeah this is static route.


/pch

-- 
Dyslexia bug unpatched since 1977 ...
exploit has been leaked to the underground.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Multipath routing

[Michał Margula]

Piotr Chytla pisze:
> First of all equal cost multipathing is evil ;>, It simply doesn't work for packets in
> forwarding path besides support in kernel is not maintained
> 
> Realy if you want load balance both uplinks disable
> CONFIG_IP_ROUTE_MULTIPATH_CACHED and you will have random traffic 
> distribiution between both links.
> 
> More details : 
>           http://lists.openwall.net/netdev/2007/03/14/50
>           http://lists.openwall.net/netdev/2007/03/12/76
>           http://lists.quagga.net/pipermail/quagga-users/2007-May/008469.html
>

Oh. I see. Thanks. BTW: google doesn't show that links when looking for 
multipath on linux :-)

Random load sharing over multiple routes is not a good idea, or maybe is 
it? Am I guessing right that with enough amount of traffic and having 
two nexthops it will split 50%/50% ?


> BGP always have alternative paths in BGP RIB and mostly don't insert them
> as multipath route to FIB.
> 
> Of course there is path : http://lebon.org.ua/quagga.html that force 
> route to be inserted to kernel with multiple gateways - but realy this
> is some kind of dirty-hack.

I know that site, but I thought that those patches were obsoleted, 
because of --multipath option when compiling quagga.

> Check thread 'Linux and BGP multipath' on quagga-dev, and especially this mail:
> 
>            http://lists.quagga.net/pipermail/quagga-dev/2007-April/004700.html


I know that also :). BTW: until now I was quite pleased with linux 
networking which quality is amazing. But now, when I need loadbalancing 
I am disapointed, because it doesn't support things that with cisco 
hardware you take for granted. I miss mostly recursive routes.

Something like that

	ip route add 80.245.177.4/32 via 80.245.176.11
	ip route add 10.0.0.0/24 via 80.245.177.4

It would solve problems with multipath bgp and loadbalancing because I 
could add remove additional routes to 80.245.177.4 (or some other 
imaginary loopback) and it would work as expected.

I hope it will be added some day :)

Thank you for your help!


-- 
Micha³ Margula, alchemyx@uznam.net.pl, http://alchemyx.uznam.net.pl/
"W ¿yciu piêkne s± tylko chwile" [Ryszard Riedel]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Multipath routing

[Michał Margula]

Piotr Chytla pisze:
> First of all equal cost multipathing is evil ;>, It simply doesn't work for packets in
> forwarding path besides support in kernel is not maintained
> 
> Realy if you want load balance both uplinks disable
> CONFIG_IP_ROUTE_MULTIPATH_CACHED and you will have random traffic 
> distribiution between both links.
> 

Unfortunately it still doesn't work as expected. When i ping some host
it always go trough one nexthop. It does per-destination loadbalancing,
I am afraid.

-- 
Micha³ Margula, alchemyx@uznam.net.pl, http://alchemyx.uznam.net.pl/
"W ¿yciu piêkne s± tylko chwile" [Ryszard Riedel]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc