Traffic Policy

Traffic Policy provide you with a unified way to configure how network traffic flows through your monitoring and security tools. It enables you to define rules and actions that determine how traffic received from s

ource ports is processed and forwarded to the appropriate tool ports.

With the unified Traffic Policy interface, previously separate configuration models are brought together into a single workflow:

■

When you select source and destination ports within the same cluster, Traffic Policy acts as the replacement for flow maps, providing a consistent way to filter, process, and forward traffic within a single cluster.

■

When you select source and destination ports across clusters, Traffic Policy replaces Fabric Maps, allowing you to configure end‑to‑end traffic distribution across multiple clusters using the same policy-driven approach.

■

When configuring Application Intelligence solutions, you define a single policy that captures your intent for how to filter, process, and distribute traffic. GigaVUE-FM then creates and maintains the required underlying objects, such as virtual ports (vPorts), GigaSMART operations (GSOPS), and different map levels.

Map Components in a Traffic Policy

Every Traffic Policy uses a small set of map components. These appear as blocks GigaVUE-FM. These components define how traffic enters the policy, how it is filtered and processed, and where it finally goes.

■

Source - The entry point for traffic into the policy.

o

Can be network ports, port groups, GigaStream Ports, inline networks, or inline network groups, depending on the use case.

o

The ports can be from a standalone device, within a cluster, or across clusters.

o

When you select the source port from a standalone node or within a cluster, all applications are available (subject to your license). When you select source ports across clusters, only the My GSOP application is available.

o

You can add multiple Source blocks in a traffic policy to ingest traffic from different ingress locations into the same Application Intelligence workflow, allowing you to apply a single, consistent policy to traffic coming from different parts of the network.

Note:  The ports can be searched using regEx pattern in the Quick Port Editor while configuring the source.

■

Source Ruleset – A set of L2–L4 header rules that filter traffic at the source. These are used in regular, first-level, and inline map types. These are not used in second-level maps as the maps rely on application‑level rules instead. The Source Ruleset has the following three rule types:

o

By Rule – Use this when you want to filter traffic based on specific L2–L4 conditions. For example, VLAN, IP subnet, protocol, DSCP, or TCP/UDP port, among others. You add one or more conditions (for example, IPv4/IPv6 source or destination, VLAN range, protocol, DSCP, TCP/UDP ports, pattern match), and GigaVUE-FM treats them as an OR/AND combination. Rules cannot be empty for this rule type. If no rules are defined, traffic from the source ports is sent to the collector map (if one is configured). If no collector map exists, the traffic is discarded.

o

Pass All – Use this when you want to accept all traffic from the selected source ports without any filtering. You cannot define any rules for this rule type because the intent is to match all traffic and send it to the destination.

o

Collector – Use this when the map acts as a collector for traffic forwarded from other maps with the same set of source ports, instead of directly filtering incoming packets. A Collector ruleset usually does not define match conditions. Similar to Pass All, you cannot define any rules for this rule type because the map receives whatever its upstream maps forward.

Note:  You can create only one collector map for a set of source ports through CLI/API. However, GigaVUE-FM allows you to create and manage multiple collector maps for Traffic Policy from the same set of source ports. During deployment, GigaVUE-FM merges the collector maps and deploy them as a single collector map in the device. It is recommended to create only one shared collector though GigaVUE-FM allows to create multiple collectors.

■

Application Ruleset – A set of application‑level rules that filter traffic based on application attributes or advanced matching, such as gsrule patterns or AFI rules, among others.

■

Applications – The Applications component lets you attach one or more GigaSMART operations and Application Intelligence functions to the selected traffic. You can choose from several options and chain them when needed.

o

My GSOP – Use this when you want to apply a custom chain of GigaSMARToperations that you define in a GigaSMART group. You can combine multiple operations in a GSOP profile. For details, refer to How to Combine GigaSMART Operations.

o

Deduplication – Use this when you want to remove duplicate packets from mirrored traffic before it is processed by AppViz, AFI, or AMI, so that each flow is analyzed only once and your dashboards and metadata exports reflect accurate traffic volumes. You do not need to create a separate GSOP for this. GigaVUE‑FM automatically creates and manages the required underlying objects based on your Traffic Policy intent.

o

Application Filtering – Use this when you want to pass or drop traffic based on applications instead of only IP or port values. You can select individual applications, application families, or tags and mark them as Pass or Drop. You can configure multiple Destination Traffic Priorities so that different sets of applications are directed to specific tools, with a clear priority order for each destination. You can add a maximum of five AFIs in a Traffic Policy.

o

Application Metadata – Use this when you want to export flow‑level records for monitored traffic to external collectors. Application Metadata Intelligence (AMI) generates unsampled NetFlow/IPFIX/CEF records with standard information elements, for example, 5tuple, bytes, packets, and basic attributes.

o

Application Visualization – Use this when you want to see which applications are present in the traffic and how much bandwidth they use before you add filtering or metadata export. It identifies thousands of applications and groups them by application, family, and tags. It displays traffic statistics in bytes, packets, and flows, and shows top applications over a selected time range.

Note:  AppViz is not mandatory for configuring Traffic Policy for Application Intelligence solutions. You can create and deploy Traffic Policy that uses only Application Filtering Intelligence (AFI) and/or Application Metadata Intelligence (AMI) without enabling AppViz, if you do not require dashboard‑level application statistics.

o

NetFlow – Use this when you want to generate flow records directly from maps. It filters the traffic at the packet level using map rules, while exporting summarized flow records or rich application metadata to analytics tools instead of, or in addition to, raw packets. You can add applications to the Traffic Policy based on the source ports you select and the licenses you purchase. When you select the source port from a standalone node or within a cluster, all applications are available (subject to your license). When you select source ports across clusters, only the My GSOP application is available.

■

Destination – The egress point for the processed traffic. Can be tool ports, tool GigaStream, null‑ports, tunnels (L2GRE, VXLAN), inline tool ports, inline tool groups, inline serial tool, fabric port groups, or vPorts, to name a few depending on the use case.

How Traffic Policy Choose Map Types

When you create a Traffic Policy, GigaVUE-FM derives the map type from the map components you use and where you place them in the flow.

■

Regular map – Connects a source directly to a destination with optional GSOP applied, but does not support application‑level rules.

o

Source is a network port or a hybrid port, and the destination is a tool port.

o

Rules reside in the Source Ruleset component and match on L2–L4 header rules.

o

Typical for out-of-band monitoring, where line-rate traffic from TAPs or SPANs is filtered and sent to tools. Suitable for simple “tap traffic and send to tools” use cases.

■

First-level map – Typically performs coarse filtering before handing traffic to a second-level map.

o

Source is a network port or a hybrid port, and the destination is a vPort or tool port. At least one vport is required for a first-level map.

o

Rules reside in the Source Ruleset component. The first‑level map forwards traffic from physical sources to vPorts, often as a preparation step for application processing in a second‑level map.

■

Second-level map – Processes traffic based on application-level rules and GigaSMART operations together.

o

Source is a vPort and the destination is a tool port, fabric port group, tool/hybrid port group, tool/hybrid circuit GigaStream.

o

You cannot select a Source Ruleset component here. You can only use the Application Ruleset component.

o

Second‑level maps often fan out to multiple destinations and can be prioritized when needed.

■

Transit-level map – When you chain multiple GSOPs between vPorts because some applications cannot run in a single GSOP.

o

Source and destination are vPorts. The map just performs GSOP and passes traffic on to the next vPort.

o

From these vPorts, you can attach multiple (prioritized) second‑level maps to branch traffic to different tools.

■

Inline map – When you want to route the traffic through tools in series, not just out‑of‑band to them.

o

Source is an inline network port or inline network group and destination is an inline tool port, inline tool group or an inline serial tool.

■

Inline first-level map – When you want to route the traffic through tools in series in a first-level map.

o

Source is an inline network port or inline network group and destination is a vPort.

■

Inline second-level map – When you want to route the traffic through tools in series in a second-level map.

o

Source is a vPort and destination is an inline tool port, inline tool group or an inline serial tool..

Map Priorities in Traffic Policy

When you have more than one Traffic Policy using the same source, map priority decides which policy sees the traffic first. Traffic Policy follow the same idea as classic flow maps and fabric maps. When rules overlap, the higher-priority map handles matching packets before the lower-priority maps. The Pass All and collector maps do not have priority. This behavior aligns with the existing implementation for flow maps and fabric maps, and it is preserved when those maps are migrated into Traffic Policies.

Priority Options

When a Traffic Policy shares a source with other Traffic Policy, you can change its priority using one of these options:

■

Highest – Move the policy to the top of the list for that source.

■

Lowest – Move the policy to the bottom of the list for that source.

You can create a map with the required priority. By default, maps are created with the lowest priority. You can change a map’s priority from lowest to highest at the policy level when you create or edit the policy.

How Traffic Policy Prioritize Maps

Traffic Policy keeps the order of policies per source in a structure called a map chain.

For each Traffic Policy, GigaVUE-FM tracks:

■

The Traffic Policy alias.

■

The Source Ruleset for each Source block.

■

The cluster and source ports used by that Source block.

For a given source on a cluster, GigaVUE-FM keeps an ordered list of traffic flows. This is the map chain. When you change priority, GigaVUE-FM updates this ordering and then updates the device-level map order to match it.

You do not manage map chains yourself. You change priority at the policy level, andGigaVUE-FM applies the changes to the underlying maps.

How Map Priority Affects Traffic Flow

When a packet arrives at a source that is used by multiple Traffic Policy, GigaVUE-FM follows this flow:

1.

It finds all deployed Traffic Policy that use the source on the same cluster.

2.

It orders them using the map chain (priority order).

3.

For each policy in order:

o

It applies the Source Ruleset and, if present, the Application Ruleset.

o

If a rule matches and the map has a Pass action, GigaVUE-FMforwards the packet to that Traffic Policy’s destinations.

o

If a rule matches and the map has a Drop action, the packet is dropped for that Traffic Policy.

o

If the packet does not match any rule in that policy, GigaVUE-FM moves on to the next Traffic Policy in the chain.

Best Practices for Map Priority

Use these guidelines to avoid surprises with overlapping traffic:

■

Check which Traffic Policy shares a source Before you change priority, review which Traffic Policy use the same source ports on each cluster.

■

Place specific Traffic Policy before broad ones Put Traffic Policys with narrow match conditions (for example, one subnet or one VLAN) above Traffic Policy that match a wide range of traffic.

■

Use Pass All with care A high-priority Pass All map can prevent lower-priority policies from ever seeing traffic on that source. Use Pass All only when you want a catch-all map at that point in the chain.

■

Validate changes with statistics After you change priority, review map statistics and policy level NRT data to confirm that the right policy is now handling the expected traffic.

Following these practices helps you control how overlapping Traffic Policy behave and keeps packet delivery predictable across your deployment.

Source Overlap Behavior in Traffic Policy

In a cluster, the same source ports are often used across multiple Traffic Policies. To avoid overlapping sources, when you remove a source port from one policy, you must also remove the corresponding source ports from all related policies. For example, if a cluster uses source ports 1/1/x1 and 1/1/x2 across several Traffic Policies and you remove 1/1/x1 from one policy, GigaVUE-FM also removes 1/1/x2 from that policy to keep the source set consistent and prevent source overlap within the cluster.

Traffic Policy Life Cycle

Each Traffic Policy follows a clear life cycle that gives you flexibility and control:

■

Create and draft – You can create a Traffic Policy and save it as a draft while you refine the policy and its components.

■

Edit rules – You can add, edit, or remove rules in the draft. You can sort, filter, and paginate rules to manage large configurations.

■

Deploy – When you deploy a policy,GigaVUE-FM pushes the required configuration to the devices and keeps the policy definition.

■

Update and redeploy – You can update a deployed policy, save the changes, and deploy again when needed.

■

Undeploy and delete – You can undeploy a policy to remove its configuration from the devices while keeping it in GigaVUE-FM, or delete it when you no longer need it.

Best Practices for Traffic Policy

Use the following best practices when creating or working with Traffic Policy:

■

Before you create a map that spans multiple clusters, ensure that inter‑cluster connectivity is already in place: configure circuit ports, circuit GigaStream, and manual topology links, or enable GDP on the circuit ports so that GigaVUE-FM can discover all connected clusters.

Important Notes

Keep in mind the following notes while working with Traffic Policy

■

When you create a regular multi-hop map with GSOP, you can place the GSOP at any point along the path between the source and destination cluster or node, including within the source or destination cluster. However, it cannot be placed beyond the source or destination cluster.

■

Circuit ID allocation and optimization for maps behave as follows (for both multi-hop maps and regular maps):

o

The limit that a single circuit GigaStream can source and decap traffic is 1024 multi-cluster maps, and multiple decap circuit GigaStreams can be configured within a cluster.

o

You can use the Circuit ID optimal allocation feature when you create new maps, it cannot be applied retroactively to existing maps.

o

Multi-hop maps do not support ingress VLAN port tagging on ports that participate in inter‑cluster circuit ID tunnels. For any map that uses circuit ID tunnels between clusters, do not configure ingress VLAN tagging on the associated ingress ports. This configuration is unsupported and can lead to unexpected behavior.

o

Circuit IDs are allocated per hop and per direction.

o

Circuit ID optimal allocation is not applicable to second‑level maps that use a fabric port group as the destination.

o

Circuit tunnels are not shared between first‑level maps, even when the maps are configured in Shared mode.

Limitations

Review the following limitations when you work with Traffic Policy

■

In multi‑hop scenarios, the configuration is stored only in GigaVUE-FM, not on the individual devices. If you move the devices to a different GigaVUE-FM instance, these map configurations cannot be rediscovered from the devices. To retain them, back up the configuration from the original instance and restore it on the new instance.

■

You cannot configure a map that uses encapsulation circuit ID on a source port that is already used in a passall map. If you try this from the CLI, GigaVUE-FM displays the following error message: "Cannot have encap on a map with a map-passall or port-pair on the source ports."

■

You can deploy or undeploy only one map at a time.