Offloading FTP traffic via low cost bandwidth

[Alain Desnoyers]

I have a scenario where we need to offload FTP traffic between site A and our Hub site where the FTP servers are located. Presently this ftp traffic along with all other traffic uses the primary MPLS link at our site A. The problem with this is the MPLS link is relatively small and this ends up "chewing up all the bandwidth. At site A is also a backup link to our HUB site via a GRE/IPSEC tunnel using the site A's 100Mb Internet link. We want to leverage this Internet link to offload FTP traffic. I have taken care of the PBR to have that FTP traffic use the GRE/IPSEC tunnel but need advice on how to insure that the return FTP traffic from the HUB site utilizes the same GRE/IPSEC tunnel instead of the MPLS link between Site A and our HUB site. We want to avoid any configuration at the HUB site so that this model can be applied to multiple Spoke sites without having to reconfigure the HUB site everytime. We run BGP at the WAN routers at each site as well as BGP between routers at the GRE/IPSEC tunnel endpoints.So we basically have a router for the WAN link and a router for the GRE/IPSEC link.

My thought was in order to have the return traffic use the tunnel, we would NAT the ftp source addresses from site A in order to provide a destination network at the HUB site that is unique to the GRE/IPSEC tunnel. Then I could adverstise this NAT'ed network into BGP at the site A GRE/IPSEC router2,  and the BGP peer at the HUB site router2 would simply learn about this network and advertise it into the LAN. Does this make sense?

Thanks

[meperuma]

Hi,

Looks ok to me. but you need to take care of the operational complexities involved.

Did you consider QOS ? Will that help to contain the BW eatup? I.e policing or shaping ?

How about using same type of pbr using at the hub?

Sent from Cisco Technical Support iPhone App

[Alain Desnoyers]

Thanks for your input... I was thinking of doing PBR at the HUB but don't want to have to reconfigure the HUb everytime I include a new spoke site for this setup. QOS can only help to a certain extent, the FTP traffic alone is beyond what QOS can do and I don't want to police the FTP traffic with the primary bandwidth so low, it would cause performance problems. We just want to use the enormous amount Internet bandwidth for the FTP traffic, since we're underutilizing it in a big way.

Thanks again for your comment