FTP Head Ache (Multiple ADSL lines)

Unanswered Question
Oct 9th, 2008
User Badges:

Hi,

I'm hoping someone will be able to help me with a solution to my problem.


I have a CISCO 2811 running IOS 12.4 and 4 ADSL lines unfortunately not bonded so have seperate public IP addresses. NAT and CEF as been setup so that traffic is pretty much balanced over all 4 lines.


The problem is FTP, connecting to a server using standard ports is either very slow to connect or times out when trying to connnect for "data". I have tried shuttind down all but one interface and it works fine, as you bring up the interfaces the delay gets bigger. I suspect the problem is that sometimes the data channel traffic is getting sent down another line and therefore has a different IP address which means it gets blocked by the FTP service because it hasnt been authenticated. I may be wrong though.


I can't work out how to resolve the problem. I thought of an alternative way trying to force all FTP trafic down one line which isn't ideal but would do as a temporarly work around, but I cant get it to work.


Basically what I am doing is creating two ACL's like so


ip nat inside source route-rmd0 interface Dialer0 overload

ip nat inside source route-rmd1 interface Dialer1 overload

ip nat inside source route-rmd2 interface Dialer2 overload

ip nat inside source route-rmd3 interface Dialer3 overload

!

.....

.....

!

access-list 115 deny tcp any any eq ftp

access-list 115 deny tcp any any eq ftp-data

access-list 115 permit ip any any

access-list 6 permit 192.168.1.0 0.0.0.255



route-map rmd3 permit 10

match ip address 6

match interface Dialer3

!

route-map rmd2 permit 10

match ip address 115

match interface Dialer2


!

route-map rmd1 permit 10

match ip address 115

match interface Dialer1

!

route-map rmd0 permit 10

match ip address 115

match interface Dialer0

!


But this doesn't seem to resolve the problem either.


Anyone got any bright ideas?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
l33h3lluk Fri, 10/10/2008 - 01:08
User Badges:

I had looked at this and couldn't seem to work out how to make it work for my setup.


After some more surfing I have tried the following which still doesn't quite work. FTP was still doing the same and infact normal internet traffic was being killed.


interface FastEthernet0/0

..

ip policy route-map ftproute

..



route-map ftproute permit 10

match ip address 115

set interface Dialer3



route-map ftproute permit 20


..



I know what I need to do but can't seem to find an example how to do it.


I need to apply the route-map policy to "in" coming traffic on the FastEthernet so if its FTP then its set to use Dialer3 as the interface otherwise drop to the empty

route-map ftproute permit 20


Then use the route-maps assigned to the outgoing interfaces.

which are all now assigned


match ip address 6


I did try doing using "ip policy route-map ftproute in" on the FastEthernet0/0 interface but thats not valid. Am I getting warmer?


Thanks,


Lee

milan.kulik Fri, 10/10/2008 - 07:31
User Badges:
  • Red, 2250 points or more

Hi,


how excatly does your config look like?


IMHO, you just need to revert ACL 115 to

!

access-list 115 permit tcp any any eq ftp

access-list 115 permit tcp any any eq ftp-data


Then

interface FastEthernet0/0

..

ip policy route-map ftproute

..



route-map ftproute permit 10

match ip address 115

set interface Dialer3


route-map ftproute permit 20



And that's all for PBR.


If your NAT works correctly for NATing the outgoing packets to the address of outgoing interface by

ip nat inside source route-rmd0 interface Dialer0 overload

ip nat inside source route-rmd1 interface Dialer1 overload

ip nat inside source route-rmd2 interface Dialer2 overload

ip nat inside source route-rmd3 interface Dialer3 overload

!

.....

.....

!

route-map rmd3 permit 10

match interface Dialer3

!

route-map rmd2 permit 10

match interface Dialer2


!

route-map rmd1 permit 10

match interface Dialer1

!

route-map rmd0 permit 10

match interface Dialer0

!


it should work.


BR,

Milan

l33h3lluk Fri, 10/10/2008 - 07:45
User Badges:

Hi,

Yea my last change that I made to access-list 115 was as you have just mentioned.


access-list 115 permit tcp any any eq ftp

access-list 115 permit tcp any any eq ftp-data


I also tried


access-list 115 permit tcp any eq ftp any

access-list 115 permit tcp any eq ftp-data any


Doing either of these just kills the internet connection and makes no difference to the FTP problem.


Is this because traffic thats returning out of the FastEthernet back towards the lan is having to be tested against this policy?


Can you just only get the policy to be applied for traffic leaving the lan towards the internet which I assume would be FastEthernet In?


Any other ideas?


Also any ideas about the original problem allowing FTP to work down any line? Surely other people must have faced a similar problem?


Thanks,


Lee

milan.kulik Fri, 10/10/2008 - 08:02
User Badges:
  • Red, 2250 points or more

Hi,


my PBR understanding is it's always applied to IN traffic on the interface.


The problem might be cuased by a passive FTP or something like that.

I'd try to configure the ACL to permit all traffic from your device IP and see if FTP works.

If yes, you can tune the ACL to permit FTP traffic only.


BR,

Milan


l33h3lluk Fri, 10/10/2008 - 08:09
User Badges:

The problem with that ofcourse the condition will always be met and all traffic will be sent to Dialer3 won't it?


milan.kulik Sun, 10/12/2008 - 11:01
User Badges:
  • Red, 2250 points or more

Yes,


but if you configur it for one IP only and it works fine, you can investigate was was wrong with the previous ACL based on ports.


BR,

Milan

l33h3lluk Mon, 10/13/2008 - 00:04
User Badges:

Hi,

Sorry I don't quite follow,

Could you give an ACL example please.


Thanks,


Lee

milan.kulik Mon, 10/13/2008 - 00:39
User Badges:
  • Red, 2250 points or more

Hi,


my idea was following:

Let's say you are connecting from one PC in your LAN (192.168.1.10, e.g.) to an Internet FTP server.

If you configure

access-list 115 permit tcp host 192.168.1.10 any

and use it for your PBR, you could force traffic from that PC to use Dialer3 as the outgoing interface.

If you notice no problem with your FTP connection this way, you could modify the ACL to permit all FTP traffic outgoing from your LAN (this might be more than just access-list 115 permit tcp any eq ftp any

access-list 115 permit tcp any eq ftp-data any, if passive FTP transfer involved, e.g.).

Running Ethereal, e.g., on your PC would help you to identify what's necessary to permit by the ACL.


BR,

Milan

l33h3lluk Mon, 10/13/2008 - 00:51
User Badges:

I assume if I do this, no one else will be able to use the internet while I'm doing this as they would get a deny ACL wouldn't they?


Lee

l33h3lluk Mon, 10/13/2008 - 00:59
User Badges:

Ignore that last post, still early and need a few more cups of coffee.

milan.kulik Mon, 10/13/2008 - 01:02
User Badges:
  • Red, 2250 points or more

Hi,


if you use

route-map ftproute permit 10

match ip address 115

set interface Dialer3


route-map ftproute permit 20


the traffic which is denied by ACL 115 goes to the next route-map section whis is doing nothing with it, i.e, it should be sent by the standard routing procedure.


BR,

MIlan

l33h3lluk Mon, 10/13/2008 - 01:04
User Badges:

Yea thats what I released when the coffee started to kick in.


Forcing my connection to use Dialer3 using PBR like you said seemed to do the trick.


So I guess the question hows the best way to resolve the problem for everyone


I have just tried again using PBR for ftp and ftp-data and it just kills the internet performace. Just don't get it, it should work.


Lee


milan.kulik Mon, 10/13/2008 - 01:21
User Badges:
  • Red, 2250 points or more

Hi,


IMHO, you need to detect which ports are really used for your FTP traffic.

Trying capturing data on you PC by Ethereal is one way to create a proper ACL.


Another idea might be using NBAR to recognize the FTP traffic, see

http://www.cisco.com/en/US/docs/ios/12_4t/qos/configuration/guide/qsnbar1.html

I've never used NBAR for PBR, but maybe it could work?


BR,

Milan


l33h3lluk Mon, 10/13/2008 - 05:17
User Badges:

Yea I have been using Wireshark which replaces Ethereal although its not really told me alot that I don't already know.


I had a look at the NBAR stuff but couldn't see anyway to use it how I need to. You can't seem to (well not obviously) be able to specify a policy that matches FTP traffic to use a certain interface.

Can't believe it can be this difficult to get working.



Lee.

Giuseppe Larosa Mon, 10/13/2008 - 12:10
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Lee ,


>> I suspect the problem is that sometimes the data channel traffic is getting sent down another line and therefore has a different IP address which means it gets blocked by the FTP service because it hasnt been authenticated. I may be wrong though.


No, this cannot happen :

the FTP is sourced by using a single public address once that is chosen a NAT entry is created and also the data connection is constrained to use the same IP endpoints.


I hope you are not using any per packet load-balancing command in your router that could be a problem


Are you using also CBAC or other security measures that could affect the FTP sessions setup ?


Hope to help

Giuseppe


l33h3lluk Thu, 10/23/2008 - 07:14
User Badges:

Hi Azharmirza,

No success so far.

In the end we have got a some Cisco Partner looking into it, although that was end of last weekend and still no resolution.

I spent over week trying to get my head around IOS but never really got no where. In response to giuslar, apparently can happen the engineer from company was watching traffic and the return would come in on a different dialer. We are using CEF which apparently should do load balancing per stream. *Shrugs*

azharmirza Fri, 10/24/2008 - 04:52
User Badges:

Hello,

I solved this for my seup. I had exactly the same setup as mentioned in the 1st post. I used a dirty hack using EEM.

As the ftp session open multiple flows it always goes through the 1st & then 2nd dialer and connection is reset.

I created a policy route-map ftp1 to match ftp traffic & force out via dialer 1 but also tracked dialer 1 state and if dailer 1 goes down, EEM will automatically change the cli config to set interface to dialer 2 (when dialer 1 is down). For this i created another route-map to set interface via dialer 2. For me it works... I also changed "ip cef load-sharing algorithm original"


If you require any more info please let me know.


Regards,


[email protected]

l33h3lluk Fri, 10/24/2008 - 05:02
User Badges:

Hi azharmirza,

Could you post any examples of what changes are needed to get it working.


Thanks,


Lee.

l33h3lluk Mon, 11/10/2008 - 07:26
User Badges:

Just an quick update. Updating IOS to 12.4(18) resolved the issue.


Actions

This Discussion