Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[vGW] Performance Optimization

0

0

Article ID: KB22047 KB Last Updated: 05 Mar 2017Version: 6.0
Summary:
In as virtual deployments grow larger (10+ ESX/ESXi hosts), certain optimizations can be done to vGW Series to reach the best possible administrative experience and achieve the best possible stability. This article outlines those items.
Solution:
The following key items should be configured to achieve the best possible performance and stability in larger vGW Series deployments.

1. Utilize external NetFlow collection devices (for example Juniper STRM) or disable Network Monitoring completely.
The most resource intensive process for vGW Series is to track all the network connections. By default this feature is activated and for every single connection an entry is made to the SD vGW management systems internal database. It's possible to completely disable this Network monitoring feature or to offload the writing of these connections to the SD vGW VM by using Netflow.  Most larger deployments will want to have a NetFlow device (like STRM) to monitor both physical and virtual connections anyway so this procedure is optimal.

Some Key Points

A.) NetFlow is always sent from the SVMs.
B.) By default when NetFlow is activated all SVM's send to the Collector defined in Settings -> Global -> NetFlow Configuration
C.) It's possible to have an SVM send to a different collector by changing Settings -> Security VM Settings -> Relevant SVM -> Network Monitoring -> Override global net flow collector
D.) By default network monitoring data will be sent to the SD vGW VM (and network stats will be displayed in the Network module). To stop this collection activity (which is recommended for performance purposes) disable Settings -> Security VM Settings -> Relevant SVM -> Network Monitoring -> Network Traffic Monitoring -> Enable traffic monitoring. (this settings is independent of NetFlow configuration).

Note: vGW default when NetFlow is activated isn't currently to de-activate Network Traffic Monitoring to the SD vGW VM (you will need to go through each Security VM (SVM) and disable this individually).

2. Offload Firewall and other logs to a SIEM (for example Juniper STRM)As is the case with the above, there is generally a desire to aggregate  log and alert information from the physical network and the virtual network in a central location (SIEM).  The performance hit of logging events (ie firewall rules with log action on them) using SYSLOG is significantly smaller than NetFlow but, it's generally good to use a SIEM in larger deployments.

Settings -> Global -> External Logging can be use to control this behavior.  With this setting it's possible to have logs come from SD vGW VM or from the SVMs directly (SVMs can send to different SIEM systems as well).  
Settings -> Security VM Settings -> SYSLOG

3. Juniper IDS and External Device Inspcetion (GRE Mirroring)
It's good practice to only send the exact packets you want to the internal Juniper IDS engine or to an external inspection device via the Juniper GRE Mirroring process (Settings -> Global -> External Inspection Devices).  There can be a performance penalty for over sending packets to the insecption engines (even though the IDS mechanisms aren't 'inline' you don't want to overload the system by unnecessarily examining connections/packets.)

A.) Make sure your rule redirecting to Juniper IDS or a user defined External Insepection Device is as narrow as possible (restrict the source, destination and protocol to only that which is of interest).
B.) Utilize a Signature Set (Settings -> IDS Signatures) which is relevant for your environment (for example don't use web-php rules if you aren't protecting web servers)

4. Use Multi-Center and Split-Center
There should be a vGW SD VM for every vCenter in a deployment and you should link these via Multi-Center feature in vGW Series 5.0 and later.  You can also use the Split-Center feature to divide a large vCenter into more manageable segments for multiple vGW SD management VMs (i.e. one large vCenter with multiple datacenters can be managed by two or more SD vGW VMs (which can be linked together with Multi-Center)).

** If you are managing more than 100 ESX/ESXi hosts you should leverage Split-Center to build out a SD vGW VM for each datacenter object in vCenter.  This will allow you to scale more effectively and avoid the SD vGW VM from being over utilized.


5. Always apply the very latest version of the vGW Series Product
The vGW Series team is constantly analyzing performance and making architecture improvements to get the very best performance from the system we will roll changes to both the management center code and the enforcement code on a regular basis and often these changes result in significant improvements so it's important customers apply the latest version (not just bug fixes but performance improvements as well!)

6. vCenter and Infrastructure Optimization
vGW Series is reliant on the performance of the underlying virtualization infrastructure so the following elements should be analyzed closely

A.) Make sure the vGW Components are on fast storage locations.  This is especially important for SD management VM because of the database operations.  However,  delays in the SAN will impact policy distribution and log writing activity on the SVMs.  Monitor the SAN closely to make sure there are no unexpected latencies in disk access.
B.) Use vCenter to reserve resources for the center especially memory but CPU is also recommended (especially if it's running at high rates).  Don't add more resources than highlighted in the documentation for the version you are running
C.) By default the vGW SD system (management server) only has 2GB of memory allocated to it.  This should be changed in larger deployments to 3.5 GB (don't allocate more than 4GB as the OS isn't 64Bit).


Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search