Npte that all ipv4 addresses on the system when leaving the system asQuote:> $ ip addr show tr0
> 5: tr0: <BROADCAST,MULTICAST,UP> mtu 2000 qdisc pfifo_fast qlen 100
> link/ 40:00:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
> inet 188.8.131.52/21 brd 184.108.40.206 scope link tr0
> inet6 fe80::4000:dead:beef/10 scope link
> inet6 fe80::4200:deff:fead:beef/10 scope link
> $ ip addr show tr1
> 6: tr1: <BROADCAST,MULTICAST,UP> mtu 2000 qdisc pfifo_fast qlen 100
> link/ 00:06:29:b0:59:63 brd ff:ff:ff:ff:ff:ff
> inet 220.127.116.11/21 brd 18.104.22.168 scope link tr1
> inet6 fe80::206:29ff:feb0:5963/10 scope link
> inet6 fe80::6:29b0:5963/10 scope link
locally originated will appear to leave lo first. So to control them
with rules use the following type of structure:
ip rule add from 22.214.171.124 dev lo table 1 prio 10000
ip rule add from 126.96.36.199 dev lo table 2 prio 20000
This will capture all originated traffic (such as host responses to pings
etc...) from each address and send it to a different table. Then you can
populate the tables as needed.
"appears" as in 'ip link sh dev tr1' never increases... or as in a tcpdumpQuote:> If I change the default route thusly:
> $ ip route add default metric 1 src 188.8.131.52 \
> nexthop via 184.108.40.206 dev tr0 nexthop via 220.127.116.11 dev tr1
> Then things work fine, incomming requests are processed as normal, but
> it appears that outgoing requests are always sent via dev tr0
on the ring only shows ip src 18.104.22.168 ? Please supply the info if
possible as I suspect that that both tr interfaces are being used but the
src command is honored thus the src addresses will always look to be tr0.
IE: look at 'ip -s link show' and see if both tr0 and tr1 are increasing
the packets sent...
Yes. In this case you could try variations on the rules above with bothQuote:> If I leave off the src argument, then incomming smtp sessions to dev tr0
> (22.214.171.124) are not properly handled - I'm guessing because the src address
> could be that dev tr1 (126.96.36.199).
> of tr1
route tables having the same default route with different src statements
but I suspect that is not exactly what you want.
Your confusion stems from the fact that the ipv4 addresses are _not_Quote:> What am I misunderstanding... What I was trying to achieve was:
> *) Incomming requests are handled on whatever interface the're received on
> *) Outgoing requests are handled on either interface
assigned to the interfaces per se but actually 'exist' as a definition of
a service (ipv4 transport) to the machine itself. Consider DECnetIV type
addressing with multiply connected hosts...
No - but it is usually not seen for two cards connected to the sameQuote:> Is this more than can be done via ip route ?
physical network ;-}
> Rick Nelson
> Life'll kill ya -- Warren Zevon
> Then you'll be dead -- Life'll kill ya
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/