10-09-2008 04:21 AM - edited 03-03-2019 11:51 PM
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?
10-09-2008 11:53 PM
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
10-10-2008 01:08 AM
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
10-10-2008 07:31 AM
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
10-10-2008 07:45 AM
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
10-10-2008 08:02 AM
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
10-10-2008 08:09 AM
The problem with that ofcourse the condition will always be met and all traffic will be sent to Dialer3 won't it?
10-12-2008 11:01 AM
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
10-13-2008 12:04 AM
Hi,
Sorry I don't quite follow,
Could you give an ACL example please.
Thanks,
Lee
10-13-2008 12:39 AM
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
10-13-2008 12:51 AM
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
10-13-2008 12:59 AM
Ignore that last post, still early and need a few more cups of coffee.
10-13-2008 01:02 AM
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
10-13-2008 01:04 AM
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
10-13-2008 01:21 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide