cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
843
Views
0
Helpful
21
Replies

FTP Head Ache (Multiple ADSL lines)

l33h3lluk
Level 1
Level 1

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?

21 Replies 21

milan.kulik
Level 10
Level 10

Hi,

IMHO, you should use PBR to force your FTP traffic using only one interface.

See http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481d.shtml

BR,

Milan

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

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

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

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

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

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

Hi,

Sorry I don't quite follow,

Could you give an ACL example please.

Thanks,

Lee

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

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

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

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

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco