Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 2 subscribers
  • Views 12679 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NAT Latency?

Coldfusioneer
I'm trying to determine what is normal as far as latency and throughput goes for ASL with NAT enabled.  We have a cable modem in our office which shows 16Mbps downstream when a PC is connected directly to the cable modem.  However, when we have our Astaro appliance between the gateway and the PC with NAT enabled, we're seeing significantly slower speeds.  On a more basic level, from the outside if I ping the various devices at work it appears that the Astaro box is slowing things down:

Ping Cable Modem, average 56ms
Ping Astaro WAN IP, average 58ms
Ping Server on LAN, average 70ms

From this it appears that the cable modem itself is adding about 2ms of latency as traffic passes over its bridge, and the WAN interface on the Astaro box is responding quickly.  However, once the packets pass through the Astaro box into the local network there is quite a bit more time added to the response.  Internal pings from that server to the Astaro box show 


This thread was automatically locked due to age.
Parents
  • 0
    Thank you for the response, though I believe the information you are asking for was contained in my original post...

    We're running ASL v7.201 on ASG220 appliances with 512MB of RAM each.  The one with the added latency is only running firewall with NAT.  We don't use any of the spam/virus functions, or any other special options except the NAT FTP application helper.


    With these being appliance units that we purchased from an Astaro reseller (ASG220) we do not know what CPU they have in there, but as mentioned it has 512MB of RAM.  Thanks again!
  • 0 in reply to Coldfusioneer
    It could be the IPS that is adding the latency. You can tune it or turn it off and see if it makes a difference.
    You are supposed to tune it by defining servers (http, db, smtp, ...) to protect.

    Is 12MS really a big deal?

    A faster CPU would make the IPS faster.

    Barry
  • 0 in reply to Coldfusioneer
    I have personally seen, and fixed, about 10 times in my career, connectivity issues that boiled down to a switch port and client NIC not autonegotiating properly, or for some reason, not working together even when forced to certain speeds... most of the time it was a Cisco / 3COM thing, but also had an issue with certain 3COM NICs and 3COM switches.  Try forcing the speed to 100MB / half duplex on both ends.  Sounds dumb, I know... but a look at the switch or nic statistics should reveal the issue... look for a lot of CRC errors, etc...
  • 0 in reply to BrucekConvergent
    it could be astaro and the particular mobo just don't get along..no two mobos even from the same maker with the same model are exactly the same due to the complexities of modern electronics.
  • 0 in reply to BrucekConvergent
    I've had autoneg problems between Cisco switches and BroadCom NICs, esp. when a ethernet TAP was added.

    William, he's running a 220, so it can't be a motherboard incompatibility.

    Barry
  • 0 in reply to BarryG
    oh yes it can...no two pieces of equipment are exactly the same.  I've had astaro balk at one sc440 only to work perfectly on another.  An incompatibility is most certainly in the cards..either that or he has a nic/cable/port issue.
  • 0 in reply to William Warren
    oh yes it can...no two pieces of equipment are exactly the same.  I've had astaro balk at one sc440 only to work perfectly on another.


    Dunno, that sounds like a bad piece of hardware, not an incompatibility.

    Barry
  • 0 in reply to BarryG
    I appreciate everyone's responses on this thread.  I still haven't been able to pin down the cause, though I suspect it's just the NAT engine being sluggish.  It could be a hardware issue but I'm not sure I want to try and convince support to loan me another unit for comparison right now.  The network is working, just not as fast as we'd like it to.  Thanks again!
  • 0 in reply to Coldfusioneer
    FWIW, NAT isn't sluggish.

    There may be another network problem which is being brought out by adding a device.
    Try bridging the firewall and seeing if the latencies change.

    Run 
    ps aux|grep snort

    and make sure that snort isn't still running (I had a problem in ASL long ago where it was still running even though IPS was "turned off").

    Barry
  • 0 in reply to BarryG
    Run
    ifconfig
    and look for any errors.
    Everything except the RX/TX counters should be ZERO. 

    e.g.

    eth0      Link encap:Ethernet  HWaddr 00:A0:C9:B8:8B:48  

              inet addr:1.2.3.4  Bcast:255.255.255.255  Mask:255.255.248.0

              UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:115248210 errors:0 dropped:0 overruns:0 frame:0

              TX packets:49389338 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0     txqueuelen:1000 

              RX bytes:1277667633 (1218.4 Mb)  TX bytes:3387226476 (3230.3 Mb)

    

    eth1      Link encap:Ethernet  HWaddr 00:90:27:2A:75[:D]5  

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:46054475 errors:0 dropped:0 overruns:0 frame:0

              TX packets:47554998 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0     txqueuelen:1000 

              RX bytes:2993638980 (2854.9 Mb)  TX bytes:2149527211 (2049.9 Mb)


    Barry
  • 0 in reply to BarryG
    Try bridging the firewall and seeing if the latencies change.


    If I had enough external IP addresses to not need NAT I'd give it a shot.  Maybe over the weekend when nobody is here I'll do a backup and reconfigure it to see what happens and restore the current config when I'm done.  Couldn't hurt.

    ps aux|grep snort


    Took a peek and snort isn't showing up on the list.
  • 0 in reply to BarryG
    Run ifconfig and look for any errors.


    Looks good, here's the output... 


    fw1:/home/login # ifconfig

    eth0      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:A9

              inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:8863122 errors:0 dropped:0 overruns:0 frame:0

              TX packets:10213530 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:3927621303 (3745.6 Mb)  TX bytes:693476415 (661.3 Mb)

    

    eth1      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:AB

              inet addr:75.145.194.1  Bcast:75.145.194.1  Mask:255.255.255.255

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:10274188 errors:0 dropped:0 overruns:0 frame:0

              TX packets:8656286 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:720766278 (687.3 Mb)  TX bytes:3895204293 (3714.7 Mb)
Reply
  • 0 in reply to BarryG
    Run ifconfig and look for any errors.


    Looks good, here's the output... 


    fw1:/home/login # ifconfig

    eth0      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:A9

              inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:8863122 errors:0 dropped:0 overruns:0 frame:0

              TX packets:10213530 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:3927621303 (3745.6 Mb)  TX bytes:693476415 (661.3 Mb)

    

    eth1      Link encap:Ethernet  HWaddr 00:10:F3:0E:5E:AB

              inet addr:75.145.194.1  Bcast:75.145.194.1  Mask:255.255.255.255

              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

              RX packets:10274188 errors:0 dropped:0 overruns:0 frame:0

              TX packets:8656286 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:1000

              RX bytes:720766278 (687.3 Mb)  TX bytes:3895204293 (3714.7 Mb)
Children
  • 0 in reply to Coldfusioneer
    Well, the good news is that I decided to run some speed tests and traces this evening now that the office is cleared out, and the network looks like it should.  We're testing 17+ Mbps through our Astaro now.  Frankly, I don't know what changed from a few days ago, but it's dramatically faster now.  Perhaps one of the earlier changes took a while to kick in for some reason?

    Thank you to everyone who made suggestions and offered assistance.
  • 0 in reply to Coldfusioneer
    My guess is one or more of the following was the problem:

    1. ISP slow
    2. Something on your net consuming lots of traffic, or a misconfiguration allowing internet traffic.
    Keep in mind that although Astaro is secure by default, it is possible to mis-configure it and allow outside traffic to use the proxies, etc.

    Barry
  • 0 in reply to BarryG
    1. ISP slow


    I'm starting to think it may have been their gateway device.  I logged in to the web admin on the gateway and some of the options have changed since I was in there a couple of weeks ago.  They may have done a firmware update that corrected some unknown problem.  I'm also seeing that our traceroutes out to common destinations are showing fewer hops and lower values all around.  Here's to hoping it stays "fixed" for a while.
  • 0 in reply to Coldfusioneer
    I was having the same issue. While I don't believe the issues were necessairly he same, I thought I would post my findings.
    DSL modem in one office and ASG120 in the network rack. The two are separated by a 30 foot network cable.
     I have a 2m down and 512 up dsl modem but was only getting 400k down and 300k up. I put a layer three network switch at the DSL modem, between the ASG120 and modem. After a few minutes, the collisions began showing up. 
    Moved the ASG120 from the rack to the cabinet where the modem is and problems went away. The 120 couldn't handle the connection over the 30 feet without complaining. The network switch didn't have an issue with it at all.
    Replacing the network cable from the modem to the main switch and moving the asg120 back to the switch resolved the issues.
     I played with flow control and speed settings but nothing would resolve the collisions.
     To often, we assume since there is some communication, the cable between two devices should be fine. My issues were just another example of "Suspect EVERYTHING"!
     I only resolved my issue after applying the "divide and concur" approach.
  • 0 in reply to kwyrick
    For us, we always start at the physical layer and work up from there.  Our gateway and ASG220 were in the same closet with a brand new custom made cable about two feet long.  We tried a couple of cables with the same results.  We ended up forcing all interfaces to 100/full all around and had the cable company replace their gateway device.  Once that was done we were able to pull our full bandwidth all the way through the network to our workstations.