Introduction

This guide aims to assist Cisco Secure Firewall customers transitioning from Snort 2 to Snort 3. Snort 3 represents a significant update in both detection engine capabilities as well as the Firewall Management Center (FMC) intrusion policy user interface. While support for Snort 2 continues, Snort 3 will become the primary focus of new and improved threat detection features as the Secure Firewall product line advances. At the same time, some legacy Snort 2 features may not be supported in early Snort 3 versions. Because of this, customers must understand what to expect before deciding to move to Snort 3.

We will start with a high-level comparison of the two Snort versions. Later, this document outlines the various Secure Firewall releases and the new Snort 3 features available in each. This is followed by a detailed discussion of what to expect when moving to Snort 3. The goal is to allow customers to determine when moving to Snort 3 becomes a viable option.

A Snort 2 and 3 Comparison

Early Snort

Snort was originally written by Martin Roesch and began life as a network sniffer in 1998. In 1999, intrusion detection capability was added, making it one of the world's first Intrusion Detection Systems (IDS). Snort was very successful as an open-source project and became the core component of the new Sourcefire Intrusion Detection System when the company was formed in 2001. Inline capabilities were added in 2004 to provide Snort Intrusion Prevention System (IPS) capabilities. Now, Snort could detect and stop malicious network traffic.

Historically network traffic speeds have grown faster than that of the computing systems running applications such as Snort. As a result, significant, ongoing development has improved the efficiency of Snort's deep packet inspection capability. These improvements and special high-speed device hardware have empowered Snort devices to perform intelligent deep packet inspection even at multi-gigabit network speeds.

At the same time, Snort's abilities to detect and thwart evasion attempts have also grown. Network traffic consists of numerous encoding types, packet fragmentation, and reassembly. These, along with complex application and network protocols, offer attackers almost limitless opportunities to hide attacks. But as these opportunities have grown, so have Snort's capabilities. Purpose-built preprocessors normalize the various traffic types and protocols, removing obfuscations so Snort rules get an accurate picture of what the traffic really contains.

Even with the many improvements, Snort developers realized they needed a better way to deal with network traffic flows. Snort 2 is packet-based, and many obfuscation techniques attempt to spread an attack across multiple packets. A better, flow-based detection engine was needed to overcome the inherent limits of packet-based inspection technology.

Snort 3 Arrives

After over a decade of development, Cisco released the Open Source version of Snort 3 in January 2021. The new Snort uses a flow-based detection engine. This new engine makes it much easier to normalize network traffic flows without overcoming Snort 2's packet-based limitations. Snort 3 preprocessors, now called inspectors, still serve a similar function, normalizing traffic for the rules engine.

As part of the new Snort 3 flow-based detection, changes were also made to the interaction between the various data acquisition components on the Cisco Secure Firewall. These improvements have increased the overall inspection performance on Cisco devices without upgrading the hardware. This means that customers can increase existing device throughput capabilities simply by upgrading to the Snort 3 engine.

One of the most anticipated features of Snort 3 addresses one of the most common complaints about Snort 2, its single-threaded nature. Snort 3 is now a multi-threaded process that consists of a single control thread and multiple detection processing threads.

Snort 2, with its single-threaded design, required loading the configuration and network map separately for each process. Since Snort 3 does this once, it uses less memory, leaving the extra available for more IPS rules and/or a larger network map.

There are several other changes and enhancements in Snort 3. Each is designed to address some of the weaknesses in Snort 2 and continue to improve on its already strong protection legacy. Figure 2 shows a quick
summary, for more information visit www.snort.org.

Software Lifecycle

Before deciding if you are ready to move to Snort 3, we need to understand the Secure Firewall software release strategy. Cisco follows a similar software release strategy as we have over the years with the Adaptive Security Appliance (ASA), consisting of short-lived and long-lived software releases.

Releases come about every six months with alternating shorter and longer lifetimes. Most customers opt for long-term releases – denoted by even release numbers like 6.4, 6.6, 7.0, etc. Intermediate releases such as 6.5, 6.7, and 7.1 provide early access to new features for customers who need the most up-to-date software.

Short-term releases typically include 18 months of software maintenance, while long-term and extra-long-term releases may be supported for 36 to 51 months after their initial release. All releases include 24 months of TAC support after software maintenance expires. See Figure 3 for an example of the software maintenance lifecycle.

For more information on Cisco’s firewall software lifecycle, see the Firewall Product Line Software Release and Sustaining Bulletin.

Snort 3 Features by Release

Cisco first introduced Snort 3 in the Cisco Firepower 6.7 release. This initial release was only available on devices managed locally using the Firepower Device Manager (FDM). Starting with release 7.0, Snort 3 was
available on both FDM and FMC-managed devices. At its introduction, Snort 3 did not include all the features available in Snort 2. However, we are adding many of these features and more in subsequent 7.x software
releases. The rest of this document applies only to FMC-managed devices. Information on the
Firepower Device Manager.

The following table outlines the features available in each release. The focus is on comparing functionality already available in Snort 2 to what this looks like in Snort 3.

Feature Comparison

📘

Note

An empty cell indicates the feature is unchanged from the previous release.

Table 1: Snort 2 & 3 Feature Comparison

Policy/Rule Management

Because of the Snort 3 Intrusion Policy user interface changes, it’s essential to understand how your current policy management processes and procedures might translate from what you do today with Snort 2 to what this looks like for Snort 3.

Rule Updates

One of the most common administrative tasks is updating the Snort rule set. Talos rules are released twice a week as part of the normal release cycle and can also be released out of cycle for critical rule updates. The most common method for updating these is configuring the FMC to check for and download updates daily.

This process is unchanged regardless of the Snort version on your managed devices. The rule update package for Snort 2 is the SRU or Security Rule Update. For Snort 3, this package is an LSP or Lightweight Security Package. The new package is more flexible and smaller in size. However, the method of downloading and deploying to devices is unchanged. You will see both the SRU and LSP versions displayed on the FMC on the System > Updates > Rule Updates tab.

Until Snort 2 is entirely deprecated, the FMC will continue to download both the SRU and LSP rule update packages at the scheduled interval.

Key takeaways:

1. LSP replaces SRU
2. Rule updates follow the same schedule and process from Snort 2 to Snort 3

Access Control Policy

Allow rules in the Access Control Policy are the primary method to enable Snort deep packet inspection on network traffic. This is done by specifying an Intrusion policy on the Inspection tab for an Allow rule. This behavior is unchanged for Snort 2 and Snort 3 devices. Each Intrusion policy consists of both Snort 2 and Snort 3 versions. When a policy is specified on the Inspection tab, the deployed version of the policy will correspond with the Snort engine on the target device.

When you first upgrade your FMC to a Secure Firewall 7.x release, the existing Snort 2 Intrusion policies is used to create equivalent Snort 3 versions. Therefore, immediately following your FMC upgrade, the Snort 2 and Snort 3 versions of your policies are the same. However, if time has passed since this upgrade, and you have made modifications to your Snort 2 policies, you should synchronize these changes to your Snort 3 policies. You can do this manually or by using the policy synchronization feature.

What does this mean to you? When migrating a device from Snort 2 to Snort 3, you should ensure that your Snort 3 Intrusion policy mirrors your Snort 2 policy. While there will not be an exact one-to-one match for Snort 2 and Snort 3 rules, you can use the policy synchronization feature to ensure the policies provide equal protection/detection.

📘

Note

On FMC 7.x the information note shown above indicates you have Allow rules that specify a customized Intrusion policy. This note appears regardless of the policy synchronization status.

Another important consideration is using URL or Application Identification rules within your Access Control policy. Normal rule processing is from top to bottom. As soon as a rule matches a given connection, the rule action is applied to the traffic (Trust, Allow, Block, etc.) and no further rules are evaluated. The exception is the Monitor action which allows the traffic to continue to be evaluated by subsequent rules.

However, this is different if the Access Control rule contains an application or URL criteria. The system can make a rule matching decision based on the first packet for the other criteria such as zone, port, IP address, etc. However, identifying the application or URL in a connection requires one or more data packets to pass through the firewall as the application or URL is determined. Because of how Snort inspects traffic, these packets that pass before the application or URL are identified do not get evaluated by other rules in the policy. This means that if you have an Allow rule later in your rule set with an associated Intrusion policy, this rule will not evaluate the full packet stream.

To address this behavior, the Access Control policy contains an Advanced setting called "Intrusion Policy used before Access Control rule is determined." This setting allows the user to select an Intrusion policy that will evaluate the traffic while an application or URL is being identified.

Because of the way Snort 3 performs inspection, this setting is more critical than it is for Snort 2. The use of application identification or URL rules in your Access Control policy has a greater potential to allow traffic to pass uninspected unless you specify an Intrusion policy in the Advanced setting mentioned above. As a result, you should ensure that any time you use an application or URL criteria in an Access Control rule, you select an Intrusion policy in the "Intrusion Policy used before Access Control rule is determined" under Network Analysis and Intrusion Policies on the Advanced tab.

Key takeaways:

1. Access Control rules do not need to be updated when upgrading to Snort 3.

2. Ensure Snort 2 and Snort 3 policy versions provide the same level of protection/detection.

3. If using application or URL rules, ensure you select an intrusion policy under the "Intrusion Policy used before Access Control rule is determined" setting.

Intrusion Policy

Intrusion policy configuration is where you will find the most significant changes between Snort 2 and Snort 3. This section covers the significant changes between the two versions.

Rule Management

Rule States

Snort 2 rule management mainly consists of setting the rule state. Snort 3 calls this rule action.

Snort 2 rule states:

• Generate Events
• Drop and Generate Events
• Disable

Snort 2 custom rules can also be created using the Pass action. To enable these rules in a policy, you would set the state to Generate Events.

Available Snort 3 rule actions depend on the software release. Release 7.1 introduced additional rule actions. Snort 3 rule actions:

• Alert
• Block
• Drop*
• Rewrite*
• Pass*
• Reject*

* Added in the 7.1 release

📘

Note

Disable is not technically a rule action as it simply means the rule is not deployed in the policy.

Searching

Another change users may find involves rule searching. Snort 2 policy provides numerous ways to search rules. The filter panel to the left of the rule list contains categories such as:

• Rule Configuration
• Rule Content
• Category
• Classifications
• Microsoft Vulnerabilities
• Microsoft Worms
• Platform Specific
• Preprocessors
• Priority
• Rule Update

Each category can be expanded to several sub options. Selecting items here populates the filter bar and filters the rule list based on the selected criteria.

The Snort 3 policy interface does not include all of these rule search options. For example, Microsoft Worms, Platform Specific, Preprocessors, Priority and several other options are no longer available. However, the Snort 3 rule search bar conducts a more thorough Snort rule search that provides the ability to search for specific rule keywords, a feature not available for Snort 2 rule searches.

The key here is that rule searches operate differently between the two policy versions. It’s possible that your favorite Snort 2 rule search may not work the same for Snort 3 rules. However, as you become familiar with the Snort 3 rule search feature, you will be able to locate the rules you are looking for - it just may take a little practice.

Other Rule Settings

There are a few other rule settings that have changed. Dynamic State, a seldom-used Snort 2 feature, is unavailable in Snort 3. Intrusion rules with dynamic states set will not be migrated to Snort 3 policies.

Another deprecated feature is per rule SNMP alerting. While this is no longer available in the Intrusion policy, you can still create FMC Correlation rules to send SNMP traps for intrusion events generated by specific Snort rules.

While supported on Snort 3, rule comments are not migrated from Snort 2 to Snort 3 rules. In addition, in Snort 3, comments are saved with the policy instead of the rule. Comments added to a rule in one policy will not be visible in other policies. When a policy is deleted, the associated rule comments are also removed.

Custom Rules

Snort 3 has a new rule syntax similar to Snort 2. The Snort 3 syntax has a few new keyword options and has removed many Snort 2 syntax inconsistencies. Because of this, the two rule languages are not compatible.

Snort 3 also provides more flexibility for organizing custom rules. You can now create multiple custom rule groups that can be added to policies the same way as the system-created groups. A custom rule can be a member of one or more custom groups.

The system provides a rule conversion utility to convert the syntax of your Snort 2 custom rules to Snort 3. For most Snort 2 rules, this works fine. However, you should be aware that while the Snort 3 rules will be syntactically correct, detection may not be identical between the two rule versions. You should evaluate your converted rules to ensure they have the same detection level as the originals. In fact, Talos recommends manually converting Snort 2 rules unless you have a large custom rule set, making manual conversion impractical. Also, manual rule conversion allows you to take advantage of the new keyword options if desired.

One issue that can occur with Snort 2 to 3 conversion is failing to specify inspection buffers. In Snort 2, if the rule does not contain buffer information, Snort will still inspect the raw packet data. However, in Snort 3, if a buffer exists for the normalized flow data, then that data will not be available in the raw packet.

alert tcp $EXTERNAL_NET any -\> $HOME_NET $HTTP_PORTS (msg:"HTTP rule
without proper URI buffer"; flow:to_server,established;
content:"/myurl"; classtype:misc-activity; sid:1000000; )

The converted Snort 3 rule is exactly the same as above. No syntax changes are required in this case. However, because we have a buffer available for the HTTP URI, the Snort 3 rule will not inspect this in the raw packet data, and the rule will not trigger.

alert tcp $EXTERNAL_NET any -\> $HOME_NET $HTTP_PORTS (msg:"HTTP rule
with proper URI buffer"; flow:to_server,established; http_uri;
content:"/myurl"; service:http; classtype:misc-activity; sid:1000000; )

Note the addition of the http_uri and service:http keywords. If the original rule had followed proper rule-writing practices, both of these (in their Snort 2 equivalents) would have been in the Snort 2 version of this rule. If that were the case, the rule conversion – and Snort 3 detection - would have worked seamlessly.

You can now use new Snort 3 features like the rem keyword to add a remark to a rule. You can also add C-style inline comments using /* and */ within your custom rules.

alert http (  
msg:"HTTP URL rule";  
flow:to_server,established;  
http_uri;  
content:"/myurl";  
classtype:misc-activity;  
rem: “This rule doesn’t need the service keyword since http is in the
header”;  
/\* This is a longer inline comment  
which can also be multi-line \*/  
sid:1000000; )

These are just a few of the many new features in the Snort 3 rules language. For more information, see www.snort.org or the Cisco Secure Firewall YouTube channel.

Recommendations

The Firepower Recommendations feature was unavailable in the first Snort 3 capable release (7.0) but returned in the 7.1 and following releases. Also note that the name changed as of release 7.2 where the term Firepower was removed from the name of the feature, from 7.2 forward it's just Recommendations.

Understanding how Recommendations are migrated between releases is a bit complex. Let’s break it down by the various upgrade scenarios.

Upgrade from 6.x to 7.0 and Remaining on Snort 2

If you do not plan to use Snort 3 on the 7.0 release, you don’t need to take any action regarding Recommendations. If you are currently using Recommendations in your Snort 2 policies, these recommended rule states will be migrated to the Snort 3 versions as manual overrides. This happens on the FMC when you upgrade from 6.x to 7.0. It will also happen if you synchronize the intrusion policies manually following a 7.0 upgrade. In addition, rules with manually enabled/disabled rule states are also migrated to the Snort 3 policy.

This means you will likely end up with a large number of rule overrides in your Snort 3 policy. That’s ok because these will be addressed on your next upgrade to release 7.1 or greater.

Upon upgrading from 7.0 to 7.1 or greater, the system will recognize the overrides added to your Snort 3 policies as a result of Recommendations. During the upgrade process, you will have the opportunity to remove these overrides. This will revert your Snort 3 policies to only keeping the actual manual overrides from their Snort 2 equivalents. After upgrading, you can then re-run recommendations in your Snort 3 policies if desired.

Upgrade from 6.x to 7.0 and Moving to Snort 3

If you plan to upgrade to the 7.0 release and migrate to Snort 3, you will not be able to take advantage of Firepower Recommendations. You have two options, 1) remove Recommendations from your Snort 2 policies before upgrading 2) allow your current Snort 2 Recommendations to be migrated to Snort 3 as rule overrides.

Each of the options above has some considerations. You will have to select the best one according to the requirements of your environment.

Option 1: Remove Recommendations prior to upgrading to 7.0
Removing Recommendations means you lose the benefits of automatic policy customization. You cannot simply re-run Snort 2 Recommendations and re-synchronize your policies. You may want to evaluate the existing recommendations in Snort 2 and decide if you want to manually change some of the rule states in your Snort 3 policies. It means you will have to take a more active role in deciding which rules to enable/disable. You should also revisit this periodically as new rules are added through LSP updates.

Option 2: Allow the system to migrate your Recommendations to your Snort 3 policies
If you allow the system to migrate your Recommendations as overrides, you will start out with Snort 3 policies equivalent to their Snort 2 versions. However, over time the Snort 3 Recommendation overrides will not be automatically updated even if you re-synchronize your Snort 2 policies. The assumption here is that you have been regularly updating your Snort 2 Recommendations which is a recommended best practice. This means your Snort 2 and Snort 3 policies will begin to diverge as you continue to update Snort 2 Recommendations which are not migrated to your Snort 3 policies.

The good news is once you upgrade again to a release that supports Recommendations (7.1 or higher) the system will allow you to back out the Recommendations overrides that were migrated. You can then configure and update Recommendations in your Snort 3 policies.

Due to the way Recommendations work on Snort 2, additional rules enabled in a policy are always set to Generate Events (Alert action for Snort 3). This means the migrated Recommendation overrides present in the Snort 3 policy will always use Alert as the enabled rule action or Disabled if Recommendations is configured to disable rules.

Upgrade from 6.x to 7.1 or Higher Releases

For the 7.1 and higher releases, Recommendations are supported on Snort 3. Existing Snort 2 Recommendations will not be migrated to the Snort 3 versions of your policies. After upgrading, you can enable
Recommendations in much the same manner as before. While the user interface is new, the process and outcome of running Recommendations are the same (only faster).

Advanced Settings

Intrusion policy Advanced Settings are not available in Snort 3. However, just because there are no Advanced Settings doesn’t mean that all of these features are unavailable. These include:

• Sensitive Data Detection
• Global Rule Thresholding
• SNMP Alerting
• Syslog Alerting

For Sensitive Data Detection, custom Snort 3 rules can be created using the sd_pattern keyword. There is no need to enable anything specific to provide this detection. These rules can detect built-in patterns like U.S. Social Security numbers with or without dashes, credit card numbers, and custom regex patterns. The main difference in Snort 3 is that there is no option to mask sensitive data in captured packets matching these rules.

alert tcp (
msg:"SENSITIVE-DATA Credit Card Numbers";
sd_pattern:"credit_card",threshold 20; 
service:ftp-data,http,imap,pop3,smtp; 
sid:1200011;)  

alert tcp (
msg:"SENSITIVE-DATA Email Address";
sd_pattern:"^\S+@\S+\.\S+$",threshold 20; 
service:ftp-data,http,imap,pop3,smtp; 
sid:1200012;) 

alert tcp (
msg:"SENSITIVE-DATA U.S. Phone Numbers";
sd_pattern:"^[(]?\d{3}[)]?[(\s)?.-]\d{3}[\s.-]\d{4}$",threshold 20; 
service:ftp-data,http,imap,pop3,smtp; 
sid:1200013;) 

alert tcp (
msg:"SENSITIVE-DATA U.S. Social Security - without dashes";
sd_pattern:"us_social_nodashes",threshold 20; 
service:ftp-data,http,imap,pop3,smtp; 
sid:1200014;) 

alert tcp (
msg:"SENSITIVE-DATA U.S. Social Security - with dashes";
sd_pattern:"us_social",threshold 2; 
service:ftp-data,http,imap,pop3,smtp; 
sid:1200015;)  

alert http ( 
msg:"Custom SD Pattern";  
sd_pattern:"\d\d\d{2}", threshold 4; 
sid:1200016;)

📘

Note

These are examples only and should not be used in a production environment.

Global Rule Thresholding is enabled by default in both Snort versions. This threshold limits intrusion rule alerting to one alert every 60 seconds per rule, per destination IP address. In Snort 2, this threshold can be adjusted or disabled. Snort 3 uses a fixed threshold.

As previously mentioned, SNMP alerting is not available in Snort 3 Intrusion policies. Still, you can create Correlation rules on your FMC to send SNMP alerts for specific Snort rules if desired.

Syslog alerting moved in release 7.0 from the Intrusion policy to the Access Control policy Logging tab. The functionality remains the same, but it can now be configured for both Snort version policies there.

Policy Layers

User-created layers are not available for Snort 3 policies. While some of the built-in layers will return in later releases (Base Layer, Group Overrides, Recommendations, User Overrides), adding additional custom layers will not. You may be able to retain some of this functionality by using a custom policy as the Base Layer for another policy. However, if you regularly create new custom layers and merge layers, a new procedure will be required to replace this functionality as it is not planned for any subsequent releases.

Policy Mechanics

You should also be aware of a few changes to how policy editing works. When editing a policy, changes are committed as soon as they are made in the user interface. There is no Save or Commit button. This means there
is no easy way to back out recent changes or discard edits before they are written to the policy.

As a result of the change above, you can no longer add audit comments to a policy change.

Changes to Snort 3 Intrusion policies are tracked on a per-change level in the audit log. Audit log entries give details about who made the change, which policy, and the modified rule.

Intrusion policy comparison reports are not available for Snort 3 policies. Also, Intrusion policy reports are generated for the Snort 2 and Snort 3 versions of the policy. However, the Snort 3 report contains only policy summary information and details on group and rule user overrides.

There is also no multi-user locking or notification on Snort 3 Intrusion policies. Users should ensure that multiple administrators do not simultaneously edit the same Intrusion policy rules. However, one advantage to this is that multiple administrators can now work on different parts of the same policy simultaneously.

Synchronizing Policies

You may have noticed that after you first upgrade to a 7.x software release, each of your Intrusion policies has a synchronization status icon below it. If you don't have any custom Snort rules this icon will probably be green.

This indicates that the Snort 3 version of the policy is in sync with the Snort 2 version. There will likely be a few less rules in the Snort 3 policy due to some of the consolidation between rule sets, but the protection level will be the same.

If a policy is out of sync you will see an orange arrow below the policy name.

Clicking the orange arrow will bring up the synchronization summary.

There are two important items to note about this synchronization feature.

First, it was designed to be run just prior to moving to Snort 3 on your devices. The goal is it to take the current state of the Snort 2 policy and replicate that to the Snort 3 policy. After this, the idea is that you stop modifying the Snort 2 policy and only update the Snort 3 policy. This feature was not meant as a way for you to continuously keep the policies in sync as you maintain a hybrid Snort 2 and Snort 3 environment.

Second, the synchronization is one way, Snort 2 -> Snort 3. In addition, changes to the Snort 3 policy are not tracked. Once the policies are in sync, if you change rule states in your Snort 3 policy, the synchronization state will remain green. In short, this is not a reliable way to tell if your policies are the same, it only shows if you have changed your Snort 2 policy.

Network Analysis Policy

There have been some significant changes to editing the Network Analysis Policy in Snort 3.

Besides the considerable UI changes, the policy itself has changed as well. Instead of preprocessors, the Snort 3 policy uses inspectors. These provide much of the same features and functions as their Snort 2 counterparts. Because of the architectural differences between Snort 2 and 3, the upgrade process will not attempt to migrate or translate these settings.

Detection mode and Normalizer

One change you may note is that the Normalizer (Inline Normalization) Inspector is enbled in all Talos Network Analysis policies. In addition, these poicies are all in Prevention mode as opposed to Detection mode. It is important that users do not change these settings before consuting with TAC. Because of the differences in Snort 3 processing, disabling the Normalizer or changing the policy mode can have serious unintended consequences.

Previous Customizations

After upgrading your FMC to a 7.x release, any customizations to your Network Analysis policies will not be present in the Snort 3 equivalent policies. Instead, you will see policies using default base settings depending on which Talos policy was used. Migrating any settings is a manual process if you have changed the Snort 2 version of these policies and want to incorporate those into the Snort 3 versions.

Each Network Analysis policy is tailored and tested to work with its associated Talos Intrusion policy. In many cases, we have found that previous Snort 2 policy changes do not apply to Snort 3 because of the differences in how it processes traffic. This will be an opportunity for many customers to revert to a Talos-provided configuration that improves both efficiency and efficacy.

Unless you have made significant changes to your Snort 2 Network Analysis policy, it is unlikely that this policy will present any issues or roadblocks upgrading to Snort 3.

Other Policies

There are no changes between Snort 2 and Sort 3 for Malware & File, SSL, Network Discovery, Correlation, Prefilter, Identity or DNS policy.

Additional Resources

For more information about the Cisco Secure Firewall, please see the following resources:

• YouTube Snort 3 Playlist.

Release Notes

In addition to the above information, you should carefully read the Release Notes and pay attention to any relevant information such as corrected or known defects. Cisco CX Services also offers a bug scrub service providing a customized and comprehensive defect search for a specific release. Contact your Cisco sales team for more information.

Release 7.0

Selected Defects

The following defects may be of concern for some customers. This list is not inclusive of all defects in this release. Please consult the 7.0 Release Notes.

Table 2: Release 7.0 Selected Defects

Release 7.1

Selected Defects

The following defects may be of concern for some customers. This list is not inclusive of all defects in this release. Please consult the 7.1 release notes.

Table 3: Release 7.1 Selected Defects