On 09/27/2012 06:36 AM, Steve Clark wrote:
I was trying to figure out what criteria to use to mark the connection. FTP is such a braindead application, using to channels and active and passive mode. What really needs to happen is someway to tell the kernel to recheck the routing after SNAT.
I'm mostly sure that if you mark the *connection* to the FTP server, the related data will follow its path.
Again, multipath routing is complex, and Shorewall will do it properly. At the very least, I recommend building a working configuration with Shorewall and then reading the rules that it compiles to understand why it handles routing the way that it does.
On 09/27/2012 05:24 PM, Gordon Messmer wrote:
On 09/27/2012 06:36 AM, Steve Clark wrote:
I was trying to figure out what criteria to use to mark the connection. FTP is such a braindead application, using to channels and active and passive mode. What really needs to happen is someway to tell the kernel to recheck the routing after SNAT.
I'm mostly sure that if you mark the *connection* to the FTP server, the related data will follow its path.
Again, multipath routing is complex, and Shorewall will do it properly. At the very least, I recommend building a working configuration with Shorewall and then reading the rules that it compiles to understand why it handles routing the way that it does.
Steve, what you need is to send packages of particular stream via particular ISP in situation where stupid load balancing will brake a connection, send it via different ISP and thus change the clients IP.
Shorewall and it's Multi-ISP config is only thing you need for this to work.
On 10/09/2012 05:36 PM, Ljubomir Ljubojevic wrote:
On 09/27/2012 05:24 PM, Gordon Messmer wrote:
On 09/27/2012 06:36 AM, Steve Clark wrote:
I was trying to figure out what criteria to use to mark the connection. FTP is such a braindead application, using to channels and active and passive mode. What really needs to happen is someway to tell the kernel to recheck the routing after SNAT.
I'm mostly sure that if you mark the *connection* to the FTP server, the related data will follow its path.
Again, multipath routing is complex, and Shorewall will do it properly. At the very least, I recommend building a working configuration with Shorewall and then reading the rules that it compiles to understand why it handles routing the way that it does.
Steve, what you need is to send packages of particular stream via particular ISP in situation where stupid load balancing will brake a connection, send it via different ISP and thus change the clients IP.
Shorewall and it's Multi-ISP config is only thing you need for this to work.
Hi Ljubomir,
Thanks for the response. We have 450 units in the field and have only needed to do this at one site. I am using a userspace script to monitor the viability of each isp and changing the routing accordingly as described in the LARTC document. Our units in the field use CentOS so we don't want to use a custom kernel outside of what CentOS provides. That's why I am reluctant to use the patches at
Regards,
On Wed, Oct 10, 2012 at 6:32 AM, Steve Clark sclark@netwolves.com wrote:
I was trying to figure out what criteria to use to mark the connection. FTP is such a braindead application, using to channels and active and passive mode. What really needs to happen is someway to tell the kernel to recheck the routing after SNAT.
I'm mostly sure that if you mark the *connection* to the FTP server, the related data will follow its path.
Again, multipath routing is complex, and Shorewall will do it properly. At the very least, I recommend building a working configuration with Shorewall and then reading the rules that it compiles to understand why it handles routing the way that it does.
Steve, what you need is to send packages of particular stream via particular ISP in situation where stupid load balancing will brake a connection, send it via different ISP and thus change the clients IP.
Shorewall and it's Multi-ISP config is only thing you need for this to work.
Hi Ljubomir,
Thanks for the response. We have 450 units in the field and have only needed to do this at one site. I am using a userspace script to monitor the viability of each isp and changing the routing accordingly as described in the LARTC document. Our units in the field use CentOS so we don't want to use a custom kernel outside of what CentOS provides. That's why I am reluctant to use the patches at
If you have a squid parked somewhere with working internet routing, a quick-fix would be to export ftp_proxy=http://squid_ip:port before running yum (or whatever is using ftp). You can even port-forward this over an ssh connection if your squid proxy can't be reached directly.
On 10/10/2012 04:32 AM, Steve Clark wrote:
Thanks for the response. We have 450 units in the field and have only needed to do this at one site. I am using a userspace script to monitor the viability of each isp and changing the routing accordingly as described in the LARTC document. Our units in the field use CentOS so we don't want to use a custom kernel outside of what CentOS provides. That's why I am reluctant to use the patches at
No patches are required to use the configuration that is generated by Shorewall. If you're not extremely experienced with iptables and 'ip rule', you're a lot better off using something like Shorewall to generate your configurations. As I previously suggested, you should at least generate working configurations with shorewall and then reviewing them to learn *why* they work before attempting to do multi-isp setups by hand. You will save yourself a lot of trouble that way.
-
Gordon Messmer -
Les Mikesell -
Ljubomir Ljubojevic -
Steve Clark