Imperva Cyber Community

communities_1.jpg
 View Only
  • 1.  Gateway Throughput

    Posted 01-20-2020 06:54
    Hi Team,

    Please help to understand :- What will be the impact on both applicative and non applicative traffic in X8510 Series Gateway if throughput is > 5Gbps ?


    I have observed some latency in both traffic when throughput is > 5Gbps.
    #On-PremisesWAF(formerlySecuresphere)

    ------------------------------
    Pankaj Chouhan
    Inspira Enterprise India Pvt. Ltd.
    Mumbai
    ------------------------------


  • 2.  RE: Gateway Throughput

    Posted 01-20-2020 07:54

    Fiber channel or copper interfaces?

    The throughput for a x8510 machine, is 5Gbps of inspected traffic. So if you have any other traffic passing by, there will no be problem (just the network interfaces and the switch).

    So, it's just depends on what kind of interfaces do you have.

    If you have cooper, that's default 4x1G or the optional 2x10Gb.



    ------------------------------
    Andres Moore
    Globant
    Santiago
    ------------------------------



  • 3.  RE: Gateway Throughput

    Posted 01-21-2020 01:24
    Hi,

     We have 10G fibre interfaces.
    Just want to know the impact on traffic when gateway throughput goes over 5Gbps ?

    ------------------------------
    Pankaj Chouhan
    Inspira Enterprise India Pvt. Ltd.
    Mumbai
    ------------------------------



  • 4.  RE: Gateway Throughput

    Posted 01-21-2020 11:42
    Pankaj,

    So the default behavior is that if a gateway exceeds the expected inspection throughput or processing power (note that it is not always exactly 5GBPS for the x8510 model, and could be more or less depending on the configuration), you will get unfiltered traffic up to the limitation of the interface bandwidth. If the interface bandwidth is exceeded, then you can run into issues with packet loss that will not always be obvious without some traffic captures, so monitoring would be your friend in those situations (think SNMP going to another network tool such as PRTG, Nagios, etc.).

    ------------------------------
    Jason Park
    ISD LA County
    ------------------------------



  • 5.  RE: Gateway Throughput

    Posted 01-22-2020 12:31
    Sorry for the delay. Jason gives you the most accurate response. If you have non inspected traffic over the 5Gbps limit, its not a problem. 
    The 5Gbps are for inspected traffic coming to you GW.


    ------------------------------
    Andres Moore
    Globant
    Santiago
    ------------------------------



  • 6.  RE: Gateway Throughput

    Posted 01-23-2020 00:10
    Hi,

    Thanks for the revert.
    But, i have observed that when the throughput goes over 5Gbps (lets say throughput is 7-8 Gbps) , we can see ping drops and latency for both applicative and non-applicative traffic.


    ------------------------------
    Pankaj Chouhan
    Inspira Enterprise India Pvt. Ltd.
    Mumbai
    ------------------------------



  • 7.  RE: Gateway Throughput

    Posted 01-23-2020 09:46
    Good discussion guys 
    just wanted to summarize - some of this you may already know - so please read this as a review 

    - All quoted throughput numbers are for applicative traffic - and the max throughput is the max applicative traffic that can be inspected 
    - max throughput has no relationship to the speed of the NIC - these are two distinct values and are not related 
    - The impact of non-applicative traffic 
    First - it is important to understand the messaging in this regard 
    - it used to be communicated that non-applicative  traffic had either no or minimal impact 
    - that may have been fair to say for our very early releases 
    - but that is not the situation in todays deployments - non-applicative traffic has an impact 

    What has changed 
    - the primary thing that has changed is a combination of new features and better/advanced inspection which both require more resources 
    - with the current resource requirements non-applicative traffic becomes more of a factor 

    If non-applicative traffic is not inspected how can it be a factor 
    - this is a very common question 
    - the answer begins with another question - how do we know if its applicative or not 
    - answer - you have to look at all the traffic to see if it needs inspected
    - This means every connection must at least be examined to determine if its applicative or not 
    - this takes resources

    Are their guidelines on how much non-applicative traffic can be sent through 
    - There is no accurate guideline that can be applied to all deployments 
    - the reason, as Jason mentioned, - has to do with the type of traffic 
    - if we have a really chatty application going through and it does NOT need to be inspected - that will consume more resources simply because there are more connections that need to be classified as being  applicative or non-applicative 

    Simply based on experience I personally would say 25% non-applicative should be - emphasis on should - within the limits we can manage 
    The closer you get to 50% the more you could expect to see unexpected behavior 

    So, to answer the base question - if we exceed the max throughput should we see latency IF we are exceeding that max limit due to non-applicative traffic?
    - Yes - the more exceed max throughput - even if its non-applicative - the more likely it is you see some degradation 




  • 8.  RE: Gateway Throughput
    Best Answer

    Posted 01-23-2020 11:37
    This is a very useful discussion, because as Phil points out, there are a lot of issues to address when it comes to making sure the appliances behave as expected. So I'd like to throw in a suggestion which Phil could say yay, nay, or add some color to...

    To optimize the inspection and limitations of the WAFs, in our environment we have a packet filter taking the full load of our traffic, and then parsing out only the HTTP/HTTPS (and you could also do this for DB or other types of traffic depending on your Imperva deployment), then we route only the pre-filtered traffic over to our inline WAF appliances (additive approach). That relieves some of the inspection load that Phil brings up for non-applicative traffic (you really don't need to inspect SMTP, DNS, etc. with your WAF), and gives you the best chance of inspecting all your HTTP/HTTPS traffic without the overhead of chatty (or sometimes mis-configured architecture) application traffic and reducing the load on the environment substantially in some cases (which could affect latency).

    One primary example of this, is before we had this type of pre-filtering going on, we had an agent deployed to all of our servers protected by our WAFs, and a firewall rule that did not allow that traffic... we did not know of the agent deployment or the lack of a firewall port opening to allow this to work, so the agents kept reaching out to a server that would not respond, and generated open TCP connections that were waiting for a response or a timeout. The team who were installing the agents knew there was a problem... the firewall team saw a large load as well... but the WAF team never knew any of this was occurring since it is generally unrelated. This generated open TCP requests across the WAFs and ate up resources waiting for the TCP connections to close. Tracking this down was extremely hard, but when we finally found it there was perfect sense to the issue. The problem is, we didn't need to inspect traffic for client configurations or backups, and this affected traffic to all HTTP services and caused both latency and packet inspection loss. When designing your solution/environment, take things like this into consideration, and at very least you could take a subtractive approach... if you have backup traffic going through your primary interface (for single interface host deployments), with the proper architecture you could exclude that from traversing your WAF and severely reduce the WAF load during backups (very possibly keeping your sites running optimally from a WAF perspective)... same goes for SMTP traffic if it traverses this segment of your network, etc. In most simple DMZ deployments this could and does happen, so take a step back, look at the design of the network, and see if there is anything you can do to optimize the design without giving the environment a full lobotomy :)

    ------------------------------
    Jason Park
    County of Los Angeles
    CA
    ------------------------------



  • 9.  RE: Gateway Throughput

    Posted 01-23-2020 12:02
    Create a vlan, and just point the traffic that you want to inspect on that vlan, and point that traffic only to Securesphere. That was our solution to a client with the same problem, a lot of mixed traffic coming.

    ------------------------------
    Andres Moore
    Globant
    Santiago
    ------------------------------



  • 10.  RE: Gateway Throughput

    Posted 01-24-2020 01:12
    Thanks everyone :)
    You have provided very valuable information.


      Thanks & Regards,

      Pankaj Chouhan | Network Engineer

      Mobile:  +91 9829179705

      Email: pankaj.chouhan@inspiraenterprise.com

      Inspira Enterprise India Pvt. Ltd.