Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 649 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

Network Performance Results on Via EPIA PD-10000

Jhaislet
I finally got around to setting up a DMZ subnet on the EPIA PD-10000 1.0Ghz C3 board w/1GB ram and ran some network performance tests through the ASG.

Setup:
Eth0: 192.168.0.xx Port 1 on Intel Dual Port Pro/1000MT card (internal network)
Eth1: 192.168.1.xx Port 2 on Intel Dual Port Pro/1000MT card (DMZ w/web servers).

Each subnet above is connected to it's own Netgear gigabit switch (the 0.x internal subnet is on a 8-port GS108 gigabit switch and the 1.x DMZ subnet is on a 5-port GS105 gigabit switch).

Eth2: External interface to cable modem 100BaseT connection using the on-board VIA VT6105 [Rhine-III] NIC.

Feature usage: ASG 6.303, 370MB of ram in use (of 1024MB)
- 8 packet filters
- DNS (on Internal & DMZ)
- DHCP (on Internal & DMZ)
- NO other proxy services
- 2 constant IPSec VPN tunnels to other locations
- Intrusion Protection enabled.

Here's where things get interesting:
From the external interface inward, everything is gigabit ethernet.  
I have two systems on my "Internal" network that can transfer large ISO files at about 18MB/s back & forth.  
These speeds & connections, while not that great for gigabit, do NOT go through the ASG.   

However, when moving one of the systems onto the DMZ, which forces ALL traffic between the two machines to go through the Intel Dual Port gigabit NIC's in ASG, my transfers dropped to only 2MB/s as configured above.  
This was a lot slower than I expected.

Disabling Intrusion Protection bumped the speeds up to a respectable 12MB/s through the ASG gateway.

I assume the Intrusion Protection service requires quit a bit of CPU horsepower to keep the throughput through ASG at a respectable level.

My current ASG setup seems more than adequate with IPS enabled for most decent sized operations and networks.  

2MB/s sustained equates to about a 16mbps pipeline.  

My cable modem service provides an 8mbps connection, which even at full saturation, would still leave about 50% capacity available on ASG for growth and bandwidth expansion.  

However, I'm not sure how resource utilization and efficiency will change with the upcoming ASG v7.  

It would be interesting to see how the Via C7 1.5ghz CPU performs in testing similar to what I did above.  Hindsight 20/20, I wish I would have done this test before I deployed the Via EN-15000 on my relative's network.


This thread was automatically locked due to age.
Parents
  • 0
    Great info. To see what exactly uses up CPU during your tests, log into the machine either on the console or via ssh and run top to figure out what the big offenders are.

    Without IPS, the machine appears to be more than fast enough!
  • 0 in reply to drees
    I forgot to mention that I used the 'top' command in SSH to see what was eating up the CPU cycles when I first looked into the network performance.  

    The "snort_inline" process, which I assume is the main process that runs the IPS rules, was using 90-93% of the CPU when transferring ISO's as described above (and a couple other misc services were using the remaining 6-10% at any given time).  Essentially, IPS (Snort) was running as fast as the CPU would allow.
    Turning off "Anomaly Detection" on the IPS page bumped up throughput to about 2.2MB/s.

    I just ran 'top' again and with IPS DISABLED.  The CPU usage was practically nothing (less than 1%) with 12MB/s of data flowing through ASG!  About every 10 seconds or so, "confd" uses about 10-15% CPU utilization for a second or two, but that's it.  I assume that is the configuration database; the back-end that runs everything behind the scene.



    top - 03:17:39 up 1 day,  2:41,  1 user,  load average: 1.11, 1.09, 0.92
    Tasks:  71 total,   2 running,  68 sleeping,   0 stopped,   1 zombie
    Cpu(s): 78.4% us,  4.7% sy,  0.0% ni,  2.3% id,  0.0% wa,  2.3% hi, 12.3% si
    Mem:   1019884k total,   668920k used,   350964k free,    47432k buffers
    Swap:  1048816k total,        0k used,  1048816k free,   278544k cached

      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    24932 root      25   0  186m 183m 1120 R 96.0 18.4   8:33.82 snort_inline
     3576 root      17   0 16324  11m 2692 S  1.0  1.1   7:54.00 selfmonng.pl
    25067 loginuse  17   0  1948 1036  816 R  0.7  0.1   0:00.30 top
        1 root      16   0   588  244  208 S  0.0  0.0   0:02.64 init
        2 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
        3 root       5 -10     0    0    0 S  0.0  0.0   0:00.01 events/0
        4 root       5 -10     0    0    0 S  0.0  0.0   0:00.01 khelper
       16 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 kacpid
       76 root       5 -10     0    0    0 S  0.0  0.0   0:00.02 kblockd/0
       84 root      15   0     0    0    0 S  0.0  0.0   0:00.23 khubd
  • 0 in reply to Jhaislet
    Out of curiosity, what would be the security ramifications of adding the DMZ to the list of "Local Networks" on the IPS configuration page?  

    This would still leave IPS working on my External interface (which feeds the DMZ).

    I wonder how much protection (if any), IPS would provide if a server on the DMZ network was compromised and attempts were made to get into my "Internal" network?

    Adding the DMZ network to the "Local Network" group in IPS should by-pass Snort and would make internal access, backups, and management of the servers much quicker, but I wonder what it would do to network security?
  • 0 in reply to Jhaislet
    The "snort_inline" process, which I assume is the main process that runs the IPS rules, was using 90-93% of the CPU when transferring ISO's as described above (and a couple other misc services were using the remaining 6-10% at any given time).  Essentially, IPS (Snort) was running as fast as the CPU would allow. 
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

    24932 root      25   0  186m 183m 1120 R 96.0 18.4   8:33.82 snort_inline
    Yep, that's exactly what I expected to see, snort is a huge CPU and memory hog.

    I'm surprised you can only get 22MB/s through Astaro, though, I would have expected to see around 50MB/s which is typical, perhaps disk speed is limiting your throughput during your tests?
  • 0 in reply to drees
    The fastest I saw with IPS Enabled was 2 MB/s (2.2MB/s with Anomaly Detection turned off).

    With IPS Disabled, true throughput through ASG was about 12 MB/s. 

    After moving both machines back to the same switch & trying the file transfer again between the two machines, the speed didn't change (remained ~12 MB/s).  So this IS a hardware limitation with the two machines doing the transfer (and not ASG).  

    I think you're right, without IPS turned on, my ASG machine seems like it could theoretically max out the 33mhz PCI bus the Intel Dual-Port gigabit NIC is plugged into.  Unfortunately, only one of my servers has U320 SCSI equipment (3x Seagate 15K.3 drives), so the other drives (slower IDE/SATA) are probably holding me back as far as testing is concerned.

    NOTE:
    The above throughput measurements were taken in XP's "Task Manager" under the "Network" tab.
    It reports the speed as "Bytes Sent per Interval" (~12,000,000 per second = ~12 MB/s)
Reply
  • 0 in reply to drees
    The fastest I saw with IPS Enabled was 2 MB/s (2.2MB/s with Anomaly Detection turned off).

    With IPS Disabled, true throughput through ASG was about 12 MB/s. 

    After moving both machines back to the same switch & trying the file transfer again between the two machines, the speed didn't change (remained ~12 MB/s).  So this IS a hardware limitation with the two machines doing the transfer (and not ASG).  

    I think you're right, without IPS turned on, my ASG machine seems like it could theoretically max out the 33mhz PCI bus the Intel Dual-Port gigabit NIC is plugged into.  Unfortunately, only one of my servers has U320 SCSI equipment (3x Seagate 15K.3 drives), so the other drives (slower IDE/SATA) are probably holding me back as far as testing is concerned.

    NOTE:
    The above throughput measurements were taken in XP's "Task Manager" under the "Network" tab.
    It reports the speed as "Bytes Sent per Interval" (~12,000,000 per second = ~12 MB/s)
Children
Cookie Information Banner