cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2276
Views
0
Helpful
16
Replies

VRF and FTP Server

I have a weird problem with VRF and FTP Server. I have a lab setup whereby two VRFs Client1 and Client2 are created. Both the VRFs are in the same subnet. I have configured FTP-Server and TFTP-Server on this router. TFTP-Server works perfectly fine from both the networks. But for FTP-Server, I can login in to the FTP Server and authenticate positively. But when I try to do listing of directory, it gives a error "can't bind data".

The web access to this router also works perfectly fine.

Any idea why FTP fails.

Before configuring vrf, the FTP server did work fine.

Any idea why. here's the config :

interface FastEthernet0/0.371

description Client1

encapsulation dot1Q 371

ip vrf forwarding client1

ip address 10.0.1.1 255.255.255.0

!

interface FastEthernet0/0.372

description Client2

encapsulation dot1Q 372

ip vrf forwarding client2

ip address 10.0.1.1 255.255.255.0

!

16 Replies 16

Harold Ritter
Cisco Employee
Cisco Employee

Try initiating the FTP transfer using passive (PASV) mode.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

I have tried it out with PASV mode but no luck.

jeff.bankston
Level 1
Level 1

You're using the same ip address schema on two different vrf's with distinct vlans. Try using unique IP addresses like you'd do for standard IP subnetting, and put the ftp server on the proper IP subnet with the appropriate routing.

-Jeff

My requirement is to have the same IP Address schema and that's the reason I am using VRFs. Previously when I didnt have VRFs and both the networks were in different IP subnets with distinct vlans, the FTP server was working fine. But when I changed the setup with VRFs, that's when FTP service running on the IOS router refuses to list the directory, but allows to log in.

I'm willing to bet that if you turned on debugs for the ftp process, you'll see a problem with ftp non-matching addresses in the port command. Even though you're in two different vrfs, you're traversing duplicate IP addresses which ftp doesn't care for without doing NAT.

Can you just try the change to a different IP address schema, say the next numbered subnet? Get it working first, then fight the IP address needs afterwards.

-Jeff

Here's the update on the FTP process through VRF in steps.

First I tried without VRF with the next IP subnet for 2nd network. FTP process worked. I could log in and see the directory listing. Then I enabled VRF on these interfaces and then tried FTP. The IP subnets are different as you suggested. When I tried to do FTP, I can login but cannot list the directory.

From this I can conclude that it has nothing to do with duplicate IP Addresses, but only when you enable VRF

What do the debugs and ftp server log files look like? Can you post them here? What are the IOS versions and router platforms serving the clients?

This is indeed wierd, has to be something relating to the IP addresses assigned in the vrf from the gist of your discussion.

If nothing else, this will give you enough information to open a tac case if you need to. Quite honestly, I've never had this problem in MPLS on Cisco platforms, just completed a new set of testing in fact that uses multiple vendor platforms with smtp, pop3, ftp, web, and dns, all worked fine.

-Jeff

Again, the TFTP transfers from both VRF work fine. Try using passive FTP and that should take care of it.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

The important thing to be remembered here is that I am using ftp-server process of IOS router itself not a Windows/Linux FTP server.

Anyway I will open a TAC case with Cisco.

Have you tried to ftp in to the router through an interface that is not part of a vrf?. Just wondering what will happen in this case.

Ohhhhhhhh!!!

I'm even more convinced its a passive/active problem with the ftp control channel. Did you try the gentleman's suggestion of passive ftp?? What's happening is that from a client on one vrf, you're attempting to terminate the ftp session in a router whom is in the second vrf. The ftp data session isn't vrf-aware from the sound of it, hence my question about what device models and IOS you're using.

But I agree, it's getting complicated enough that sounds like TAC-time. My bet is something isn't vrf-aware to the point that the data is lost. For instance, to ping from one device to another from _within_ a vrf router instance, you have to use the keyword "vrf" like "ping vrf VRF_Name src dest".

In your situation, your source is on one vrf while the destination is _within_ the second vrf, not just simply the IP packet being routed from vrf1-client (like a Windows PC) to vrf2-server (like a Unix ftp server).

I'd be interested in hearing their solution.

-Jeff

When I said passive ftp, I was referring to the client side. Is the client side Cisco IOS as well?

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Just found this doc on CCO, looks like ftp over vrf is something just coming about.

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5413/prod_release_note09186a00801b3ad1.html

Granted, this may not be your situation, but might be worth a try. The key is that the source and destination be contained within the _same_ vrf. Try moving things around so that IP address withstanding, the router ftp is on the _same_ vrf as the client.

-Jeff

This is not required if the FTP session is initiated from the clients in the VRF.

BTW: I just ran a quick test and this scenario works like a charm if the workstations in the VRF iniate the FTP session in passive (PASV) mode. If the client is and IOS based box, this will be done by default.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México