Odpovědět TMG Internal to Perimeter - Traffic is slow

  • 27. července 2012 5:05
     
     

    I am curious about TMG performance because I'm having some really major performance problems with my TMG array.

    If you do a typical copy (SMB) from internal to your perimeter, what kind of speeds do you guys expect to see? Do you use NLB?

    My problem is crazy. I tested in every direction -- TMG to perimeter, perimeter to perimeter, internal to tmg, and I get 90MB+/sec (gigabit speed basically). But the second I do internal to perimeter, which goes through TMG, the speeds drop to 500KB/sec. It stalls out a lot too.

    I'm not even sure where to begin to troubleshoot something like this sadly. I eliminated as many NLB factors as I could but it's still awful performance. I even powered off one member at a time to eliminate the possibility of a hardware problem. Both array members have the same problem :(

    I tried FTP and it's faster, running at about 7MB/sec but that still seems slow.

    TMG Version: 7.0.9193.540 (Hopefully the latest)
    Hardware: HP DL380G6, E5520 cpu, 8GB of RAM

Všechny reakce

  • 27. července 2012 5:36
     
     Odpovědět

    Hi,

    your performance problem may have many reasons. To start with performance optimization I recommend the following article:
    http://www.isaserver.org/tutorials/optimizing-performance-forefront-threat-management-gateway-part1.html
    In addition please check your network cards configuration (latest driver / Firmware)
    and have a look at Windows optimizatins like SNP (Scalable Networking Pack) settings, RSS settings TCP Offload and more


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de

  • 27. července 2012 19:25
     
     

    Hey thanks for the fast reply, Marc. That was very helpful.

    I actually tracked it down to the NLB on the internal side.

    I must not have the configuration quite right (hah!).

    For some reason this part of that article got me thinking:

    "NLB broadcasts heartbeat information which will be seen by all hosts on the segment. Having the TMG firewalls configured in an isolated segment limits those broadcasts to only the hosts that require it."

    So I checked the copy speed to the NLB address on the internal side and it's incredibly slow. Apparently our old Enterasys switches take some extra trickery to support NLB.

    http://www.mail-archive.com/enterasys@listserv.unc.edu/msg01135.html

  • 31. července 2012 3:17
    Moderátor
     
     

    Hi,

    Thank you for the post.

    For performance issue, you may also refer to this blog: http://blogs.technet.com/b/yuridiogenes/archive/2010/08/04/another-performance-caveat-when-troubleshooting-tmg-or-isa-slow-browsing-behavior.aspx.

    Regards,


    Nick Gu - MSFT

  • 1. srpna 2012 3:32
     
     Odpovědět

    So this all lead me to the answer:

    Enterasys has a special command to allow for good speeds on a Windows NLB in Multicast mode for Matrix N7 type equipment. They don't really document this command very well and it's stupid. I never experienced the ultra slow speeds (500KB/sec) on the HP switches in my environment, but they seem to suffer from the same "stall" in initial file copy speeds. I have yet to correct the stall on the HP switches - going to call tomorrow.

    For anyone experiencing this same situation, you probably need to know the magic commands.

    1) set mac unicast-as-multicast enable

    Resolves stall at the beginning of a file copy job. 

    2) set mac multicast macaddr vlanid ports_to_flood

    Example: set mac multicast 01-01-F4-56-78-90 1 ge.2.21;ge.2.22

    Resolves major thoughput problems on an Enterasys with with Multicast as NLB type.

    3) Add a static arp entry in your router with the mac address. This will enable multiple sites to reach TMG properly.

    I am still having issues with the C2G end user switches and my HP blade switches but that's for another day.

    • Označen jako odpověď Shaddie 1. srpna 2012 3:33
    •