Re: Re: [LARTC] Application routing

Re: Re: [LARTC] Application routing

[paul.walling]

As requested I am attaching my network topology and routing
tables. I can see that my request was a little ambiquous so
heres a little more info

NETWORK TOPOLOGY
========
On my linux PC (redhat 7.3) I have two interfaces IF1 & F2.
Each is connected to an ADSL router IF1 to R1 and IF2 to R2.
The ADSL routers are configured with static NAT active.
My networks are private with the addressing scheme.
 IF1 address 172.21.1.12 
  R1 address 172.21.1.11
NET1 address 172.21.0.0/16

 IF2 address 172.22.1.12 
  R2 address 172.22.1.11
NET2 address 172.22.0.0/16

ASSUMPTIONS
=====The network topology as above means that I can guarantee
that all incoming frames at IF1 and IF2 will have the 
destination address as the appropriate IF address.
There are no other devices on these networks.

ROUTING TABLES
=======
Add routing tables T1 and T2 
ip route add default via 172.21.1.11 dev eth1 table T1
ip route add default via 172.22.1.11 dev eth2 table T2

Add policy rules 
ip rule add from 172.21.1.12 table T1
ip rule add from 172.22.1.12 table T2

Show Routing table main:
172.21.0.0/16 dev eth1 scope link
172.22.0.0/16 dev eth2 scope link
127.0.0.0/8 dev lo scope link

Show Routing table T1:
default via 172.21.1.11 dev eth1

Show Routing table T2:
default via 172.22.1.11 dev eth2

Show Rule table:
0: from all lookup local
32764:  from 172.21.1.12 lookup T1
32765:  from 172.22.1.12 lookup T2
32766:  from all lookup main
32767:  from all lookup 253

TESTING
===
INCOMING PACKETS
----------------
With the above configuration I have been able to receive 
incoming packets and route them back out the interface they 
have been received on. This works because when the
applications respond to a request they swap the IP dest
address and IP source address hence I know that the source
address has been set correctly, hence my rule applies
and hence traffic is sent via the correct interface.

OUTGOING PACKETS
----------------
Here in lies the problem.
I use ping as an application first. If I just ping an 
address which happens to be accessible via both networks 
e.g. ping 194.159.243.228 (www.sip.com) then frames 
will not actually route out of my system. This is because 
there is no rule or route to return a source address.
Now if I include the interface ping -i IF1 194.159.243.228
then frames are sent out on IF1. This works because the 
ping application binds to the source address of the 
interface.

MY APPLICATION
=======
I want to be able to simultaneously get the same web page
via both routers. Hence in this application the destination 
address will always be the same. This discounts routing by 
destination address. As my application resides well above 
the socket layer, there is no access to the bind facility.

Now this is why I'm thinking of Marking frames with the 
target interface ID based on the PID of the application. 
Hence each frame that the application sends will then be 
marked with either a 1 or a 2. I can then add two further 
rules which would then route based on the Mark to either T1 
or T2 which will. However a response I have received 
indicates that this is not reliable.

So back to my original question which I suppose is how do 
you get an application to be able to select the source 
address if you don't have access to bind ?

Sorry this has been a bit long winded but at least you have 
the entire picture now

Many thanks

Paul


-----------------------------------------
Email provided by http://www.ntlhome.com/


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

Re: Re: [LARTC] Application routing

[Martin A. Brown]

Paul,

[ Sorry for the slow reply. ]

 : As requested I am attaching my network topology and routing tables. I
 : can see that my request was a little ambiquous so heres a little more
 : info

[ good and accurate description, based on LARTC HOWTO, snipped ]

 : Here in lies the problem. I use ping as an application first. If I just
 : ping an address which happens to be accessible via both networks e.g.
 : ping 194.159.243.228 (www.sip.com) then frames will not actually route
 : out of my system. This is because there is no rule or route to return a
 : source address. Now if I include the interface ping -i IF1
 : 194.159.243.228 then frames are sent out on IF1. This works because the
 : ping application binds to the source address of the interface.

You could add a multipath route into your main routing table.  Then at
any given time, a new route lookup in the main routing table would return
something at least.

 : I want to be able to simultaneously get the same web page via both
 : routers. Hence in this application the destination address will always
 : be the same. This discounts routing by destination address.

As an example, I would recommend using "wget --bind-address\x172.21.1.12"

       --bind-address­DRESS
           When making client TCP/IP connections, "bind()" to
           ADDRESS on the local machine.  ADDRESS may be speci­
           fied as a hostname or IP address.  This option can be
           useful if your machine is bound to multiple IPs.

 : As my application resides well above the socket layer, there is no
 : access to the bind facility.

Ah!  Now that's a problem for which I have no solution!

 : Now this is why I'm thinking of Marking frames with the target
 : interface ID based on the PID of the application.  Hence each frame
 : that the application sends will then be marked with either a 1 or a 2.
 : I can then add two further rules which would then route based on the
 : Mark to either T1 or T2 which will. However a response I have received
 : indicates that this is not reliable.

Indeed, it is not.  This reply was accurate (to my knowledge).

 : So back to my original question which I suppose is how do you get an
 : application to be able to select the source address if you don't have
 : access to bind ?

Indeed--unfortunately, this is a problem for which I have no answer.  I
believe I have seen subsequent postings from you where you are
experimenting with using netfilter to route packets out particular
interfaces, and I saw somebody else mention a desired netfilter
<software type="imagined">-j RT_LOOKUP</software> target.

Best of luck,

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

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