Hi Erez,
I'm not sure why you network acts like it's dead, but I can only
assume that the route command you have used did something bad to the
routing table (just a guess: maybe you need to execute: 'ip r del
default' before?).
Anyhow, what I do know (and from experience) is that the route command
you have used is not sufficient to achieve your goal. I would try
re-reading the NANO howto again (http://www.ssi.bg/~ja/nano.txt)

Noam

On 8/17/05, Erez D <[EMAIL PROTECTED]> wrote:
> noam,
>  
>  first, thanks for your reply.
>  
>  i wrote the original mail after reading the howto.
>  i removed the tables, for debug simplicity.
>  i used ping, so there is no need for all the packages be sent to the same
> interface as
>  ping is connectionless
>  
>  (anyway, linux cache the route and so will do send all packets from same
> source and dest via the same interface, but this does not matter for what i
> encountered with ping)
>  
>  anyway, when i did 'ping' - no packet went out of my interface. so this is
> a more basic problem.
>  
>  i saw that in the past (year 2002), linux would declare the first interface
> as dead. but this did not happen here. so it might be a variation on the od
> bug - does not say it is dead, but act as it is.
>  
>  the original problem was solved by cahnging version of GCC when compiling 
>  (i do not know if that refers to the kernel, or 'ip' command)
>  
>  10x,
>  erez.
> 
> On 8/17/05, Noam Meltzer <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > The command for itself is not enough. The problem is that you send one
> > packet from interface A and the other from interface B. Each interface
> > has a different IP and thus the target machine will not know how to 
> > handle it. (It's a bit more complicated, but n/m for now)
> > 
> > What you need to achieve is that your linux machine will have one of
> > the following mechanisms enabled:
> > 1. use a roundrobin virtual interface - one on your linux, and one on 
> > other router somewhere in the internet (like your ISP for example) and
> > will encapsulate your packets and send them on over the internet. - I
> > assume that this is not what you wish.
> > 
> > 2. Have your linux choose when to route from each interface & cache 
> > this route so that your TCP sessions (or other datagram protocols)
> > will not be broken. - this is what the howto and patches are dealing
> > with. (they route and cache according to the destination IP)
> > In the end what you shall achieve from this is that when you send a 
> > packet your routing table will decide to send it in the following
> > manner:
> > a- if it's the first time you send packet to that IP, it will choose
> > whether to use interface A or B and send the packet from there.
> > b- if you already have that destination IP in your routing table
> > cache, the packet will be routed from the same place it had been
> > routed before.
> > 
> > Uhm, this was a bad/good (choose what's true for you) attempt from me 
> > to explain what these howtos explain "on one foot". I suggest you'll
> > go on reading these howtos and the nano howto.
> > 
> > Noam
> > 
> > 
> > On 8/17/05, Erez D <[EMAIL PROTECTED] > wrote:
> > > hi
> > >
> > >  the command line i have used originated from
> > >  http://lartc.org/howto/lartc.rpdb.multiple-links.html
> > >
> > >  about: http://www.ssi.bg/~ja/#routes
> > >  are you aware of a specific bug/patch relevant the command i issued,
> > >  or is it just a pointer to the patches available in general. 
> > >
> > >  10x
> > >
> > >  erez.
> > >
> > > On 8/17/05, Noam Meltzer <[EMAIL PROTECTED]> wrote:
> > > > Hi Erez,
> > > > What you are requesting to do is not trivial, though not too
> complicated. 
> > > > Basically I would suggest you'll read the following documents (the
> > > > first has a link for the second, but it was worth mentioning here
> > > > too):
> > > > http://lartc.org/howto/lartc.rpdb.multiple-links.html
> > > > http://www.ssi.bg/~ja/#routes
> > > >
> > > > The first one is one the sections of "Linux Advanced Routing & Traffic
> > > > Control HOWTO"
> > > > The second is a page with some kernel patches that can help you
> > > > achieve your goal. (It also points for what he calls nano's howto,
> > > > which explains how to use these patches) 
> > > >
> > > > goodluck,
> > > > Noam
> > > >
> > > > On 8/16/05, Erez D <[EMAIL PROTECTED]> wrote:
> > > > > hi
> > > > >
> > > > >  i have 2 internet connetions: via eth3 and ppp0 
> > > > >
> > > > >  i wanted to do load balancing so i did:
> > > > >  ip route add default nexthop via <ip1> dev eth3 weight1 nexthop via
> > > <ip2> dev ppp0 weight 1
> > > > > 
> > > > >  i test by pinging the internet
> > > > >
> > > > >  i get funny results:
> > > > >  if the route was selected via ppp0 then it works
> > > > >  if the route was selected via eth3, then nothing is sent out
> (tcpdump 
> > > shows nothing)
> > > > >  ( i know which route was selected by doing 'ip route show cache')
> > > > >
> > > > >  if i swap the order of the interfaces in the above line, then ppp0
> does
> > > not work and eth3 does
> > > > >  so it seems that routes through the first interface specified does
> not
> > > work
> > > > >
> > > > >  however, if i only specify one of the interfaces (does not matter 
> > > which) then it works ok for it.
> > > > >
> > > > >  any idea ?
> > > > >
> > > > >  btw: my box is configured to do nat via ppp0, but not via eth3 (it
> is
> > > done further on the way at the isp) 
> > > > >
> > > > >  10x,
> > > > >  erez.
> > > > >
> > > >
> > >
> > >
> > 
> 
>

================================================================To unsubscribe, 
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to