while this multipath patch does round robin the packets (according to pathmetric) across the two gateways, it does not change the source ip address of the packet to correspond with the interface it went out on.
as such, the round robin works this way. the first 10 packets are sent with a src ip of 192.168.0.5 (fxp0's address) out via fxp0. the next 10 are sent still with a src ip of 192.168.0.5 out via aue0. then the cycle repeats with 10 more being sent out via fxp0. this magic number 10 is equivalent to the -pathmetric argument given when creating the route. the default, obviously, is 10. but i digress.
this obviously doesn't work for me, since higher upstream from aue0 (ip address 10.1.105.26), the src address of 192.168.0.5 is address translated to a public IP address. the router/natd which does that will obviously not have any address translation maps for 192.168.0.5, and thus silently drop the packet. packets going out fxp0 work the way they should. after all, why shouldn't they ? :)
it would however work if both the interfaces were assigned a public ip address, though all this still would do is to round robin outgoing packets, but incoming packets will still come down the same interface (due to the src address not changing). i'm guessing the the picked source ip address depends on the current active gateway for that route, as i've seen the same happen in reverse with a source ip address of 10.1.105.26, the address on aue0. which leads me to deduce that the src address is picked on a per connection basis, depending on the current active gateway, and held for the duration of the connection. thus this does not ensure proper load balancing over both links, even if public ip addresses were used.
this does not do what i want to do, i.e. multipath routing in a round robin fashion over x number of interfaces with src ip address changed to the address of the interface the packet goes out on. this would ensure that the reply packets from the destination are routed back in correctly.
Hmm, have you accounted for the fact, that if packets of same connection will be distributed in round-robin fashion between several outgoing interfaces and get their src IP "fixed", destination host won't see that as single connection and drop them?
If you want to round-robin with two different src IPs on the gateway (host), you have to implement this as functionality of NAT service, which will keep track of connections and send each connection's traffic via _exactly_ one(same) interface.
On routing level, IMHO, patch operation, you've described, is exactly following multipath functionality. Issue with return traffic could be resolved with both ISPs announcing route to your IP to the Internet. In this way, return packets will be routed from the destination according to routing decisions take by routers on the path.
Regards, -- Adrian Pavlykevych
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
