Patent Description:
<FIG> depicts an example visibility network <NUM>. As shown, visibility network <NUM> includes a number of taps <NUM> that are deployed within a core network <NUM>. Taps <NUM> are configured to replicate data and control traffic that is exchanged between network elements in core network <NUM> and forward the replicated traffic to a packet broker <NUM> (note that, in addition to or in lieu of taps <NUM>, one or more routers or switches in core network <NUM> can be tasked to replicate and forward data/control traffic to packet broker <NUM> using their respective SPAN or mirror functions). Packet broker <NUM> can perform various packet processing functions on the replicated traffic, such as removing protocol headers, filtering/classifying packets based on user-defined filters/rules, and so on. Packet broker <NUM> can then forward the processed traffic to one or more analytic probes/tools <NUM>, which can carry out various calculations and analyses on the traffic in accordance with the business goals/purposes of visibility network <NUM>.

With respect to traffic filtering, existing packet brokers can accept and apply user- defined filters that are based on parameters explicitly present in the traffic replicated from a core network (referred to herein as "first-order" parameters). For example, assume that core network <NUM> of <FIG> is a mobile network and that the traffic replicated from core network <NUM> is GTP-C/GTP-U traffic. In this scenario, existing implementations of packet broker <NUM> can accept/apply user-defined filters based on first-order parameters that explicitly appear in GTP traffic such as IMSI, IMEI, APN, QCI, RAT, ULI, etc..

However, existing packet brokers generally cannot accept or apply user-defined filters based on parameters that may be associated with, but are not explicitly present in, the traffic replicated from the core network (referred to herein as "second-order" parameters). For instance, returning to the GTP example above, existing implementations of packet broker <NUM> cannot accept/apply user-defined filters based on second-order parameters that do not appear in GTP traffic such as, e.g., characteristics of the end-user device connected to a particular GTP session (CPU type, RAM amount, screen size, device type, etc.), geographic location of the end-user device, and others.

If an operator of a visibility network wishes to analyze replicated traffic based on second-order parameters, it is possible to work around this limitation by configuring the network's packet broker to forward all replicated traffic to the analytic probes/tools. The analytic probes/tools can then store the traffic and perform a post-hoc analysis of the stored data to identify the packets of interest. However, in cases where the volume of traffic generated by the core network is high, this approach will generally require a significant amount of compute and storage resources on the analytic probes/tools in order to store and analyze all of the replicated traffic, which undesirably increases the cost and complexity of the visibility network.

<CIT> discloses regulating and analyzing network communications on the basis of geographic security assertions, which may be configured in a graphical user interface. <CIT> discloses managing visibility filters from a centralized filter control module.

Aspects of the present invention are defined by the accompanying claims. Techniques for implementing a smart filter generator in a visibility network are provided in embodiments of the invention. In one set of embodiments, the smart filter generator can maintain at least one mapping between (<NUM>) a first-order parameter found in network traffic replicated from a core network monitored by the visibility network, and (<NUM>) a second-order parameter related to the first-order parameter, where the second-order parameter is not found in the network traffic replicated from the core network. The smart filter generator can further receive, from a user, a user-defined packet filter definition comprising a filtering criterion that makes use of the second-order parameter. The smart filter generator can then translate, based on the at least one mapping, the filtering criterion into a version that makes use of the first-order parameter, and can generate a new packet filter comprising the translated version of the filtering criterion.

The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of particular embodiments.

In the following description, for purposes of explanation, numerous examples and details are set forth in order to provide an understanding of various embodiments.

Embodiments of the present disclosure describe a smart filter generator that can communicate with, or be integrated within, a packet broker of a visibility network to facilitate the filtering of traffic replicated from a core network based on second-order parameters (i.e., parameters that are not explicitly present in the replicated traffic). According to one set of embodiments, the smart filter generator can maintain a knowledge base comprising one or more sets of mappings between (<NUM>) second-order parameters that a user may be interested in using as a basis for filtering traffic from the core network, and (<NUM>) first-order parameters
associated with the second-order parameters. Merely by way of example, if the core network is a mobile network, the knowledge base may comprise a first set of mappings between various user equipment (UE) device characteristics (second-order parameters) and IMEI TAC (first-order parameter); a second set of mappings between various geographic identifiers or classifiers (second-order parameters) and EnodeB ID/IP address (first-order parameters); a third set of mappings between various UE software/browser/OS identifiers (second-order parameters) and a user agent string (first-order parameter); and so on. Each of these different sets of mappings can be stored as separate databases in the knowledge base.

The smart filter generator can further receive, from a user, a packet filter definition that includes a filtering criterion comprising one or more of the second-order parameters included in the knowledge base and one or more corresponding values. For example, the user may provide a packet filter definition that performs a "drop" action on all traffic meeting the filtering criterion (device type="iPhone").

Upon receiving the user-defined packet filter definition, the smart filter generator can consult the knowledge base and translate, based on the mappings in the knowledge base, the second-order parameters and values included in the filtering criterion into corresponding first-order parameters and values. For example, returning to the example above, the smart filter generator can access the device database of the knowledge base and retrieve a list of all IMEI TACs mapped to the device type "iPhone.

The smart filter generator can then generate a new packet filter definition that includes, as its filtering criterion, the one or more first-order parameters and values determined via the translation. Finally, this newly generated packet filter definition can be communicated to the packet broker, which can apply the packet filter (in the form of, e.g., an access control list, or ACL) to traffic that is replicated/received from the core network.

With the general approach described above, the smart filter generator can enable the packet broker to effectively accept and apply user-defined packet filters that are based on second-order parameters not typically found in that traffic. This allows the visibility network to identify/analyze traffic based on such parameters, without needing to perform resource-intensive post-hoc analysis or querying on the analytic probes/tools. As a result, the complexity and cost of the visibility network (in particular with respect to the compute/storage needs of the analytic probes/tools) can be kept low.

The foregoing and other aspects of the present disclosure are described in further detail below.

<FIG> depicts a visibility network <NUM> in accordance with an embodiment of the present disclosure. As shown, visibility network <NUM> includes a number of taps <NUM> that are deployed in a core network <NUM> and are configured to replicate traffic exchanged in network <NUM> to a packet broker <NUM>. In <FIG>, core network <NUM> is a mobile LTE network that comprises network elements specific to this type of network, such as an eNodeB <NUM>, a mobility management entity (MME) <NUM>, a serving gateway (SGW) <NUM>, and a packet data network gateway (PGW) <NUM> which connects to an external packet data network such as the Internet. Further, in this particular example, taps <NUM> are configured to replicate and forward GTP-C and GTP-U traffic that is exchanged on certain interfaces of core network <NUM>. However, it should be appreciated that core network <NUM> can be any other type of computer network known in the art, such as a mobile <NUM> network, a landline local area network (LAN) or wide area network (WAN), etc..

Upon receiving the replicated traffic via taps <NUM>, packet broker <NUM> can perform various types of packet processing functions on the traffic (e.g., filtering, classifying, correlating, etc.) as configured by a user/administrator and can forward the processed traffic to one or more analytic probes/tools <NUM> for analysis. In one embodiment, packet broker <NUM> can be implemented solely in hardware, such as in the form of a network switch or router that relies on ASIC or FPGA-based packet processors to execute its assigned packet processing functions based on rules that are programmed into hardware memory tables (e.g., CAM tables) resident on the packet processors and/or line cards of the device. In another embodiment, packet broker <NUM> can be implemented solely in software that runs on, e.g., one or more general purpose physical or virtual computer systems. In yet another embodiment, packet broker <NUM> can be implemented using a combination of hardware and software, such as a combination of a hardware -based basic packet broker and a software-based "session director" cluster as described in co-ownedUS-A-<NUM>-<NUM>, entitled "Software-based Packet Broker,".

As noted in the Background section, while existing packet brokers can accept and apply user-defined packet filters that filter replicated traffic based on first-order parameters
(i.e., parameters that are present in the replicated traffic), existing packet brokers generally cannot filter replicated traffic based on second-order parameters (i.e., parameters which do not appear in the replicated traffic). It is possible to identify traffic that matches one or more second-order parameters by querying the analytic probes/tools of the visibility network or implementing additional/special probes in the core network to select the traffic of interest; however, these solutions generally increase the cost and complexity of the visibility network.

To address the foregoing and other similar limitations, visibility network <NUM> of <FIG> is enhanced to include a novel smart filter generator (SFG) <NUM>. SFG <NUM> can be implemented in software, hardware, or a combination thereof. Further, SFG <NUM> can be implemented as an entity that is separate from packet broker <NUM> (as shown in <FIG>), or as an integral component of packet broker <NUM>. As described in further detail below, SFG <NUM> can enable packet broker <NUM> to extend its traffic filtering capabilities to filter replicated traffic from core network <NUM> based on second-order parameters that are not readily available in the replicated traffic. Examples of such second-order parameters in the context of mobile LTE network <NUM> include end-user equipment capabilities, client browser type, roaming subscriber info, and geographic attributes (e.g., ZIP code, postal address, GPS coordinates, etc.). In this way, SFG <NUM> can provide more flexible and useful filtering functions to the user/operators of visibility network <NUM>, without increasing the cost and/or complexity of the network.

It should be appreciated that <FIG> is illustrative and not intended to limit embodiments of the present disclosure. For example, the various entities shown in <FIG> may be arranged according to different configurations and/or include subcomponents or functions that are not specifically described. One of ordinary skill in the art will recognize other variations, modifications, and alternatives.

<FIG> depicts a high-level workflow <NUM> that can be executed by SFG <NUM> of <FIG> to facilitate the filtering of replicated traffic on packet broker <NUM> based on second-order parameters according to an embodiment.

Starting with block <NUM>, SFG <NUM> can receive, via one or more data provisioning interfaces (e.g., CSV using SCP or FTP, CLI, REST API using JSON or XML, SNMP, etc.), mappings between (<NUM>) second-order parameters that a user/operator of packet broker <NUM> may wish to use as a basis for filtering traffic from core network <NUM>, and (<NUM>) first-order parameters that explicitly appear in that traffic. For example, as mentioned previously, in the case where the core network is a mobile LTE network as shown in <FIG>, the second-order parameters may include UE device capabilities, geographic location information, user agent information, etc., while the first-order parameters may include IMSI, IMEI, APN, QCI, RAT, ULI, MCC, MNC, etc. The mappings may be entered manually by a user or in an automated manner via a provisioning application or script.

At block <NUM>, SFG <NUM> can store the received mappings in a local knowledge base. As discussed in further detail below, this knowledge base can comprise a number of separate databases, where each database is configured to maintain mappings for a particular related set of second-order and first-order parameters (e.g., one database for device capability-related parameters, another database for location-related parameters, etc.).

Once the knowledge base has been populated with parameter mappings pertaining to at least one second-order parameter P1 and at least one corresponding first-order parameter P2, SFG <NUM> can receive, via a user configuration interface (e.g., CLI, REST API, etc.), a definition of a packet filter from a user, where the user-defined packet filter definition includes a filtering criterion based on second-order parameter P2 (block <NUM>). For example, if P2 is a UE "deviceType" parameter, the packet filter definition received at block <NUM> may include the filtering criterion (deviceType="iPhone").

Then, at blocks <NUM>-<NUM>, SFG <NUM> can parse the user-defined packet filter definition, identify the use of second-order parameter P2 in the filter's filtering criterion, and translate, based on the mappings in the knowledge base, the filtering criterion into a version that makes use of corresponding first-order parameter P1 (rather than second-order parameter P2). For instance, returning to the deviceType example above, if the knowledge base includes mappings between the deviceType "iPhone" and two IMEI TACs "ABCDEFG" and "<NUM>," SFG <NUM> can translate the filtering criterion from (deviceType="iPhone") to (IMEI TAC=["ABCDEFG", "<NUM>"]).

Once the filtering criterion has been translated, SFG <NUM> can generate a new packet filter definition that makes use of the translated criterion (block <NUM>). Finally, at block <NUM>, SFG <NUM> can communicate the newly generated packet filter definition to packet broker <NUM>, which in turn can configure itself to apply the packet filter (in the form of, e.g., an ACL) and thereby use it to filter replicated traffic received from core network <NUM>.

It should be appreciated that workflow <NUM> of <FIG> is illustrative and various modifications are possible. For example, although shown sequentially, in certain embodiments the execution of blocks <NUM>-<NUM> (which pertain to the receipt and storage of parameter mappings in the knowledge base) may overlap with blocks <NUM>-<NUM> (which pertain to packet filter generation). This may occur if, e.g., SFG <NUM> receives additional/updated mapping information from users or from an automated provisioning component (e.g., a central support portal) on a periodic basis. One of ordinary skill in the art will recognize other variations, modifications, and alternatives.

<FIG> is a block diagram of one possible architecture (<NUM>) for SFG <NUM> according to an embodiment. As shown, architecture <NUM> includes a provisioning sub-system <NUM> that exposes various provisioning interfaces (e.g., CSV, CLI, REST API, and SNMP) usable for populating a knowledge base <NUM> with parameter mappings. As mentioned previously, this provisioning can be carried out manually by a user or automatically via, e.g., a remote update agent/server that is configured to update the contents of knowledge base <NUM> on a periodic basis.

Knowledge base <NUM> comprises a number of databases <NUM>, <NUM>, <NUM>, and <NUM> which are used to store the parameter mapping data provisioned via provisioning sub-system <NUM>. Each of these databases may store parameter mappings pertaining to a particular type of filter that a user may wish to define; for example, in <FIG>, knowledge base <NUM> includes device, location, user agent, and home network databases. However, it should be appreciated that these are merely exemplary and other types of databases are also possible.

In one set of embodiments, the interface between provisioning sub-system <NUM> and knowledge base <NUM> can be, e.g., an ODBC interface if a MySQL-like database system is used. In other embodiments, the interface between provisioning sub-system <NUM> and knowledge base <NUM> can make use of standard inter-process communication (IPC) if a memory-based data structure is used to host the databases of knowledge base <NUM>.

The following are example database schemas for the device, location, user agent, and home network databases shown in <FIG> respectively:
<IMG>.

In addition to provisioning sub-system <NUM> and knowledge base <NUM>, SFG architecture <NUM> further includes a user interface sub-system <NUM> and a filter generation sub-system <NUM>. As shown, user interface sub-system <NUM> exposes a CLI and/or REST API interface which enables one or more users to provide/enter packet filter definitions. Upon receiving a user-defined packet definition, user interface subsystem <NUM> can pass the definition to filter generation sub-system <NUM>. In response, filter generation sub-system <NUM> can parse the user-defined packet filter definition, translate the second-order parameters/values included in the filtering criteria of the user-defined packet definition into corresponding first-order parameters/values based on the parameter mappings in knowledge base <NUM>, and generate a new packet filter definition with the translated criteria.

Finally, filter generation sub-system <NUM> can communicate the newly generated packet filter definition to packet broker <NUM> via an appropriate interface. In cases where SFG <NUM> is implemented as a software process running within packet broker <NUM>, SFG <NUM> can communicate the packet filter definition (i.e., program it on the packet broker) using a local CLI interface. Alternatively, in cases where SFG <NUM> is implemented as a separate/remote entity, SFG <NUM> can communicate the packet filter definition to packet broker <NUM> via a remote CLI interface or a REST API interface. One of ordinary skill in the art will recognize other variations, modifications, and alternatives.

The remaining sections of this disclosure provide examples of four types of user-defined, second-order filters that may be supported by SFG <NUM> in the context where core network <NUM> is a mobile LTE network: (<NUM>) subscriber property-based filters, (<NUM>) location/address-based filters, (<NUM>) end user equipment (UE) device-based filters, and (<NUM>) user plane-based filters.

This type of filter can enable a user to drop/redirect/replicate/sample the traffic generated by roaming subscribers. The listing below shows an example set of CLI commands that may be entered by the user for providing a definition of this type of filter to SFG <NUM>. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Roaming
sd (config-SEF_Filter) > add rule Roaming=<ALL |Country Name |Operator
Name> Action=< Port-Group | Drop | Sample | Replicate>.

Upon receiving this filter definition, SFG <NUM> can use the "SEF" type field to query the home network database. The result of this query is the network identifier (MNC and MCC) of the network on which the packet broker is deployed. This could be one pair of MCC-MNC or a list. SFG <NUM> can then generate a new filter using wild cards, as IMSI has MCC and MNC as constituent fields.

In certain embodiments, this particular type of filter can be enhanced to filter based on name of the country of origin of subscribers. For example, subscribers roaming from Japan or USA can be filtered. This can be achieved by modifying the query to filter the given country name.

This type of filter can also be further enhanced to filter by the specific operator and/or country of origin of subscribers (e.g., Vodafone subscribers from the UK).

This type of filter can enable a user to drop/redirect/replicate/sample the traffic generated by subscribers who are tethering from their mobile devices. The listing below shows an example set of CLI commands that may be entered by the user for providing a definition of this type of filter to SFG <NUM>. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Tethering
sd (config-SEF_Filter) > add rule Tethering=<Device Name> Action=< Port-
Group | Drop | Sample | Replicate>.

Upon receiving this filter definition, SFG <NUM> can use the "SEF" type field to query the device database. Two values can be retrieved from the device database in response to this query: (<NUM>) an IMEI TAC code belonging to the device in input, and (<NUM>) Operating System. From (<NUM>), the user agent database can be queried to extract the possible user agents the operating system may support. From these two lists, two packet filters can be generated and applied in succession (i.e., chained) on packet broker <NUM>.

This type of filter can enable a user to drop/redirect/replicate the traffic generated by subscribers present in a particular location. The listing below shows an example set of CLI commands that may be entered by the user for providing a definition of this type of filter to SFG <NUM>. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Location
sd (config-SEF_Filter) > add rule Location=<Zip Code | GPS Lat Long1 GPS
Lat Long2 > Action=< Port-Group | Drop | Sample | Replicate>.

Upon receiving this filter definition, SFG <NUM> can use the "SEF" type field to query the location database. The result of this query is a list of EnodeB IDs. SFG <NUM> can then generate a packet filter based on eNodeB ID and communicate the filter to packet broker <NUM>.

In certain embodiments, this filter can be enhanced to filter based on postal address/ZIP code and/or the name of a particular city or region such as "South San Francisco.

This type of filter can enable a user to drop/redirect/replicate the traffic generated from end user equipment with specific capabilities. The listing below shows an example set of CLI commands that may be entered by the user for providing a definition of this type of filter to SFG <NUM>. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Device
sd (config-SEF_Filter) > add rule Device=< Device Type | Device
Manufacturer | Device Model | Screen Size | Memory Size | Operating System
> Action=< Port-Group | Drop | Sample | Replicate >.

Upon receiving this filter definition, SFG <NUM> can use the "SEF" type field to query the device database. The result of this query is a list of IMEI TAC codes. SFG <NUM> can then generate a packet filter based on the retrieved list of IMEI TACs and can communicate this filter to packet broker <NUM>.

In certain embodiments, this filter can be enhanced to filter based on any parameter present in the device database schema or any combination of those parameters. For example, Device = Smart Phone AND Screen Size larger than <NUM>" AND Memory Size larger than 4GB.

This type of filter enables a user to drop/redirect/replicate the traffic generated from a specific browser. The listing below shows an example set of CLI commands that may be entered by the user for providing a definition of this type of filter to SFG <NUM>. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Useragent
sd (config-SEF_Filter) > add rule Device=< Browser Type | Browser
Type=<value> Version=<Value> > Action=< Port-Group | Drop | Sample |
Replicate >.

Upon receiving this filter definition, SFG <NUM> can use the "SEF" type field to query the user agent database. The result of this query is a list of user agents in regex format. SFG <NUM> can then generate a packet filter based on the retrieved list and can communicate the filter to packet broker <NUM>.

In certain embodiments, this filter can be enhanced to filter based on any parameter present in the user agent database schema or any combination of those parameters. For example, Browser = Mozilla AND version = <NUM>.

In certain embodiments, this filter action (which enables a user to generate S-Flow records for the traffic generated from a filter) can be added any of the filters described above. The listing below shows an example set of CLI commands that may be entered by the user for enabling an S-Flow filter action with respect to a device-type filter. sd (config) > filter_type=SEF
sd (config-SEF_Filter) > set SEF_Type=Device | Tethering | Location |
Useragent | Roaming
sd (config-SEF_Filter) > set sflow = <enable/disable>
sd (config-SEF_Filter) > add rule Device=< Device Type | Device Model |
Screen Size | Memory Size > Action=< Port-Group >.

When this action clause is enabled, SFG <NUM> can enable S-Flow records at the corresponding port of packet broker <NUM>. Hence, S-Flow records belonging to the match in any filter can be generated.

<FIG> depicts an example network device (e.g., switch/router) <NUM> according to an embodiment. Network switch/router <NUM> can be used to implement (either wholly in in part) packet broker <NUM> described throughout this disclosure.

As shown, network switch/router <NUM> includes a management module <NUM>, a switch fabric module <NUM>, and a number of line cards <NUM>(<NUM>)-<NUM>(N). Management module <NUM> includes one or more management CPUs <NUM> for managing/controlling the operation of the device. Each management CPU <NUM> can be a general purpose processor, such as a PowerPC, Intel, AMD, or ARM-based processor, that operates under the control of software stored in an associated memory (not shown).

Switch fabric module <NUM> and line cards <NUM>(<NUM>)-<NUM>(N) collectively represent the data, or forwarding, plane of network switch/router <NUM>. Switch fabric module <NUM> is configured to interconnect the various other modules of network switch/router <NUM>. Each line card <NUM>(<NUM>)-<NUM>(N) can include one or more ingress/egress ports <NUM>(<NUM>)-<NUM>(N) that are used by network switch/router <NUM> to send and receive packets. Each line card <NUM>(<NUM>)-<NUM>(N) can also include a packet processor <NUM>(<NUM>)-<NUM>(N). Packet processor <NUM>(<NUM>)-<NUM>(N) is a hardware processing component (e.g., an FPGA or ASIC) that can make wire speed decisions on how to handle incoming or outgoing traffic.

It should be appreciated that network switch/router <NUM> is illustrative and not intended to limit embodiments of the present disclosure. Many other configurations having more or fewer components than switch/router <NUM> are possible.

<FIG> depicts an example computer system <NUM> according to an embodiment. Computer system <NUM> can be used to implement (either wholly or in part) packet broker <NUM> described throughout this disclosure.

As shown in <FIG>, computer system <NUM> can include one or more general purpose processors (e.g., CPUs) <NUM> that communicate with a number of peripheral devices via a bus subsystem <NUM>. These peripheral devices can include a storage subsystem <NUM> (comprising a memory subsystem <NUM> and a file storage subsystem <NUM>), user interface input devices <NUM>, user interface output devices <NUM>, and a network interface subsystem <NUM>.

Bus subsystem <NUM> can provide a mechanism for letting the various components and subsystems of computer system <NUM> communicate with each other as intended. Although bus subsystem <NUM> is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses.

Network interface subsystem <NUM> can serve as an interface for communicating data between computer system <NUM> and other computing devices or networks. Embodiments of network interface subsystem <NUM> can include wired (e.g., coaxial, twisted pair, or fiber optic Ethernet) and/or wireless (e.g., Wi-Fi, cellular, Bluetooth, etc.) interfaces.

User interface input devices <NUM> can include a keyboard, pointing devices (e.g., mouse, trackball, touchpad, etc.), a scanner, a barcode scanner, a touch-screen incorporated into a display, audio input devices (e.g., voice recognition systems, microphones, etc.), and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computer system <NUM>.

User interface output devices <NUM> can include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices, etc. The display subsystem can be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system <NUM>.

Storage subsystem <NUM> can include a memory subsystem <NUM> and a file/disk storage subsystem <NUM>. Subsystems <NUM> and <NUM> represent non-transitory computer-readable storage media that can store program code and/or data that provide the functionality of various embodiments described herein.

Memory subsystem <NUM> can include a number of memories including a main random access memory (RAM) <NUM> for storage of instructions and data during program execution and a read-only memory (ROM) <NUM> in which fixed instructions are stored. File storage subsystem <NUM> can provide persistent (i.e., nonvolatile) storage for program and data files and can include a magnetic or solid-state hard disk drive, an optical drive along with associated removable media (e.g., CD-ROM, DVD, Blu-Ray, etc.), a removable flash memory-based drive or card, and/or other types of storage media known in the art.

It should be appreciated that computer system <NUM> is illustrative and not intended to limit embodiments of the present disclosure. Many other configurations having more or fewer components than computer system <NUM> are possible.

The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. For example, although certain embodiments have been described with respect to particular process flows and steps, it should be apparent to those skilled in the art that the scope of the present invention is not strictly limited to the described flows and steps. Steps described as sequential may be executed in parallel, order of steps may be varied, and steps may be modified, combined, added, or omitted. As another example, although certain embodiments have been described using a particular combination of hardware and software, <NUM> it should be recognized that other combinations of hardware and software are possible, and that specific operations described as being implemented in software can also be implemented in hardware and vice versa.

Claim 1:
A method comprising, in a visibility network (<NUM>) which receives network traffic replicated from a core network (<NUM>) monitored by the visibility network (<NUM>) and includes a packet broker (<NUM>) arranged to apply a generated packet filter to the replicated network traffic:
maintaining, by a smart filter generator, SFG (<NUM>), at least one mapping between:
a first-order parameter found in network traffic replicated from the core network (<NUM>); and
a second-order parameter related to the first-order parameter, wherein the second-order parameter is not found in the network traffic replicated from the core network (<NUM>);
receiving, by the SFG (<NUM>) from a user, a user-defined packet filter definition comprising a filtering criterion that makes use of the second-order parameter;
translating, by the SFG (<NUM>), based on the at least one mapping, the filtering criterion into a version that makes use of the first-order parameter;
generating, by the SFG (<NUM>), the packet filter comprising the translated version of the-filtering criterion;
wherein the at least one mapping comprises multiple sets of mappings between first-order parameters and second-order parameters, each set of mappings corresponding to a related group of parameters, and
communicating the generated packet filter to the packet broker (<NUM>) of the visibility network (<NUM>).