Houston to China Connection

What do you think? I've got an office in Houston and an office in China. Going to be running 2003 with exchange. Need all employees to be part of the domain for file share and email. Am thinking about doing a couple PIX501's and setting up a site to site VPN with a server at each location, with the Houston box being primary.

5 Users in Houston with 23 in China. Am I barking up the right tree or is would you suggest a better alternative?
Reply to
Loading thread data ...

Might want to check the license exports to china. I do not think you would be able to use 3DES encryption. Not 100% sure of the license agreement.

Reply to
Chad Mahoney

I have no experience in links to China, so I don't know if it will work, but see the following thread:

formatting link

Reply to
Walter Roberson

formatting link
One thing to be aware of is the effect that the high latency (round Trip Time) has on the applications.

For example Microsoft File Shares are badly affected and I hear that Exchange can be too.

Clearly it depends on what you want to do but if your business depends on largish files or a large number of small files being sent across a high latnecy link you should understand the effect on performance. A good thing to do is to use a simulator such as nistnet to create a model of your proposed network.

There are fixes for these issues but they are not cheap.

Riverbed, Tacit, Cisco WAFS ... Others.

We happen to use Tacit and it is pretty effective for file sharing.

If you are doing your own apps you need to test with the appliances.

Reply to

formatting link

VPNs seem to work well most of the time, and high latency doesnt seem to be an issue - a customer has put these in scattered across a few continents on Cisco gear (they use routers, but the protocols are the same).

the issue about encryption is really separate - since the encryption is there to keep your data private if there is someone intercepting your packets as they cross the public network

i run a VPNclient link here over 3G , where the round trip is often more than 1 sec... despite having a thru put around 300 Kbps, outlook to exchange comms works, but is painfully unresponsive some of the time.

i use it where there isnt much choice, such as on a train - but i would never choose it if there was an alternative available - the same VPN link over a WLAN hotspot with comparable thruput but lower latency is a much better beast to use.

the underlying problem Walter is explaining is that exchange to client comms uses lots of "checkpoint" style interactions where the overall round trip time dictates how quickly things happen, so the responsiveness of the client and the throughput for mail delivery depends on the underlying latency.

so - spoofing the protocol to avoid some of the latency being in the critical path and / or prefetching can help. What may be a problem is that at least some of the checkpoints are there to preserve data integrity - so spoofing transactions has the potential to cause some serious problems if / when it goes wrong, and error occurs and so on.

if the main problem is exchange server to client comms then there are 2 other common "solutions":

  1. put an email server at each site. this keeps the exchange to client comms local, so avoiding the high latency between server and client. server to server mail flow happens in the background - this only needs to move mail going between China / US, but there isnt a human in the response loop, so it doesnt need to be realtime, and the latency is less of an issue.

set up and support is a bit more complex than 1 server - but at least all you have is 2 servers with similar configs......

you might still have long latency problems - eg with visitors at the "other" site.

  1. use Citrix or terminal server, so the mail client is really in the US, close to the server. this is a standard way to centralise client apps - usually pushed by server vendors :) the problem here is the user to client keystrokes etc now go between continents - the delay is probably too high for good user response.

never tried this "new" stuff - but spoofing to avoid latency has a long, painful history in data networking, storage etc.

I would do it if i really had to, (after a lot of testing to make sure it actually gave a useful improvement and didnt corrupt data), but i would try to design out such a requirement.

Reply to

Hi Rick,

Cisco PIX 501 Firewall

Approved by China

Information Security Product Certificate # XKC33203.

Issued by China Information Security Product Testing & Evaluation Center.


Brad Reese BradReese.Com - Cisco Salary and Compensation Rates

formatting link
Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant BradReese.Com - Cisco Job Databases
formatting link

Reply to


Latency to China *might* not be a major problem.

Our whole WAN, 90 sites, are linked via Satellite - min 540ms RTT with no traffic on the link. Most apps including VoIP operate reasonably well up to 1000ms. Citrix, VNC and Remte Desktop are also useable on these links.

Cisco have their own TCP spoofing algorythm, available in SP Services called RBSCP. Not tried it yet, otherwise Tacit is supposed to be good and is being used by several organizations that I work with. In the past I have used Expand Networks boxes, Junipers WX platform (Previously Peribit) and Riverbed boxes for Spoofing / Acceleration / Caching and Compression. All these boxes offer similar functionality my advice would be to get a line simulator and contact the manufacturers for a free evaluation of their products in your lab using your applications and data.

As mentioned above by someone else, a local mail server is always a good idea. We have local Exchange and DNS servers installed in all our sites. A Web Cache is also a good idea, we use ISA or Bluecoat Proxy SG's.


Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.