Observer Analyzer : Observer Analyzer : Expert Probe Software : Probe Properties : Understanding the Packet Broker Integration tab
Understanding the Packet Broker Integration tab
When using network packet broker integration, you can dynamically reduce traffic flow to your GigaStor when it is at risk of oversubscription giving you the content you need. Additionally, metadata tags identify the network segment where the packets came from, providing you context when troubleshooting.
As a network administrator, you need really good content to be able to quickly troubleshoot your network environment. If you do not have the appropriate metadata or packets, determining where a problem is occurring and, more importantly, why the problem is occurring is very difficult. Content is king, and context is important. Dynamic traffic management gives you the content, and port tags give you the context.
Dynamic traffic management
Dropped packets are never desirable and they occur when a link is oversubscribed. If your analytics device does not have all of the packets of a conversation, troubleshooting is very difficult.
If your GigaStor is at risk of oversubscription, you should reduce the flow of traffic to the GigaStor. You have two options for reducing the traffic.
First, you can choose to pre-filter traffic using fixed, preset filters that you create. This is the minimalist approach. Second, you can allow all traffic and dynamically exclude traffic only when oversubscription occurs. We’ll explore each choice in a bit more detail.
With the minimalist approach to packet capture, you only capture the traffic that you think is relevant. In other words, you exclude everything from packet capture except the specific traffic you allow. For instance, you may decide that YouTube is not critical to your business and do not need to troubleshoot problems with that traffic. Therefore, you would never capture and save YouTube traffic. It is excluded with a pre-filter. This gives you longer retention capabilities for the content you do capture because your capture devices are not filling as quickly. Also, by not seeing YouTube and other non-critical traffic you are not overwhelmed with unnecessary information when troubleshooting. When you do identify a problem in your network, you can allow in more traffic by changing your pre-filters to troubleshoot the problem.
The opposite approach is to capture everything and use post-filters to find what you are looking for. If GigaStor is at risk of oversubscription, then using traffic filters that GigaStor dynamically and automatically apply to a Gigamon can reduce the flow. This eliminates the oversubscription risk while continuing to capture the most amount of traffic relevant to you. You can set the types of traffic that interest you up front and GigaStor automatically captures it. After the initial configuration, it is no longer a manual process you need to remember to implement to capture the content you need. The dynamic filters allow you to focus on the business critical applications.
Figure 77: When filters are applied and removed
Unlike pre-filters, which can be used anytime, dynamic filtering is only available when using a Gigamon network packet broker.
Contextual visibility
Using Gigamon-applied port tags, you know which network segments are experiencing performance issues.
For context, you can have numerous streams of information coming into GigaStor, but, when you are troubleshooting, it is very helpful to know where in your network the packets came from. This is where port tags help. With port tags you have the context of knowing where in your network the problem occurred.
Figure 78: Contextual visibility
Using the port tags helps you solve correlative analysis issues. For example, if you are troubleshooting a VoIP call that shows excessive jitter or a low MOS score, it is important to know what portion of the network you are seeing in the packet captures. One network segment may not be experiencing any problems at all, while the other network segment does. By filtering on conversation and port tags, you will be able to see the conversation from different perspectives and begin to draw conclusions.
How to configure packet broker integration
Using a network packet broker ensures that the Observer Platform has the right content at the right times so that you can troubleshoot your network.
Configuring packet broker integration allows GigaStor to work with systems such as GigaVUE.
Using filters created in GigaStor, you can filter traffic as it leaves your packet broker reducing the load the GigaStor. Using Gigamon-applied port tags allows you to identify packets that come from your network packet brokers.
Exactly these versions are required:
Gigamon Fabric Manager 3.3
Gigamon GigaVUE H series nodes 4.6
With this feature, you can choose to use port tags without enabling dynamic filters, or you can decide to use dynamic filters and not use port tags, or you can enable both. You decide what is best for your environment.
You might choose to filter traffic because you only want certain traffic to be kept on this GigaStor or because the traffic load temporarily exceeds the GigaStor FIFO abilities. If there are multiple filters, they are applied one at a time in descending order until the FIFO level drops below 50%.
1. Select a probe instance in the Probes list.
2. Right-click and choose Probe or Device Properties.
3. Choose the Packet Broker Integration tab.
4. Use the information in Packet Broker Integration to configure GigaStor to work with your packet broker.
Figure 79: Packet Broker Integration tab
GigaStor sends commands to your packet broker whenever FIFO levels are too high (above 50%). This temporarily reduces the traffic load coming into the GigaStor until FIFO levels drop below 20%.
What to do next: Turn on the NPB Port Tagging tab in GigaStor Control Panel in Setting the GigaStor general options.
Packet Broker Integration
Use the packet broker integration settings to configure the connection between GigaStor and your packet broker (for instance, GigaVUE).
Fabric Manager address
The DNS name or IP address of the GigaVUE-FM system.
Cluster ID
The cluster name or IP address of the GigaVUE-FM visibility fabric node.
Your GigaVUE-FM user name.
The password for your GigaVUE-FM user name.
Test Configuration
Use this button to validate your packet broker settings, including addresses, user name, and password. If you enter any invalid ports, a message box returns with a list of valid ports for the cluster.
Enable Gigamon port tagging
Provides contextual visibility by using the GigaVUE-FM-applied VLAN 802.1Q port tags that are added to every packet. This allows for filtering in GigaStor. Be sure to turn on NPB Port Tagging in Setting the GigaStor general options to show the NPB Port Tagging tab in GigaStor Control Panel where you can see the GigaVUE-FM port from which the packet came, the port tag, the number of packets from the port, the amount of bytes, and utilization.
Enable Dynamic Filtering
Allows the GigaStor to send filters to GigaVUE-FM whenever the FIFO load on the GigaStor reaches 50% and there is a risk of dropping packets. When this option is enabled, GigaStor clears any existing filters on Gigamon and replaces them with the new filters. When disabled, GigaStor removes all filters.
Tool ports attached to this instance
A list of Fabric Manager ports that are associated with the GigaStor active instance. They are listed in the format required by Fabric Manager: Chassis/Slot/Port. For example, 1/1/x1.
Port (Chassis/Slot/Port)
The first value is the GigaVUE chassis in which the port is found, the second value is the slot within the GigaVUE chassis where the port is found, and finally is the port itself. All three values are required and must be separated by the / character.
Enable rollback of filters
If selected, any filters in the Applications to be filtered list that have been applied to the packet broker are removed after the specified number of minutes. The minimum is one minute. The time frame you choose allows for a smooth rollback of filters so that a momentary drop in network traffic does not cause filters to be repeatedly applied and removed in a short timespan.
Applications to be filtered
This section defines the filters to push to GigaVUE to exclude certain content before the traffic is sent to GigaStor. Each time you add, remove, change, or reorder these filters, all filters on the GigaVUE system are deleted and replaced with these filters. This ensures that only the filters you specify in this list and no others are used.
The risk of dropping packets occurs when the FIFO reaches 50%. When that level is reached, a message is logged and the first filter in the list is applied. If applying the filter does not lower the FIFO level below 50% within one second, the next filter is applied. This process continues until the FIFO level remains below 50%. This ensures that a minimum number of filters is applied while allowing the most amount of traffic to be written to GigaStor.
The order of the filters is important. Filters are applied in descending order. In other words, the filter listed at the top is applied first, then the next if necessary, and so on. If the FIFO does not drop below 50% even after all filters have been applied, you should identify other application traffic to exclude. Filters are removed in reverse order starting with lowest priority (last) filter, then the next lowest, and so on until all filters are removed only after the GigaStor FIFO falls below 20% with that filter applied and the allotted time from the Enable rollback of filters field has passed. If the FIFO level goes back above 50% the filter that was just removed will be reapplied. The 50% and 20% threshold values are fixed and cannot be modified. Use the arrows buttons to change the order of your filters to find the arrangement that works best for you.
The buffer size of the active instance affects FIFO abilities. Changing the buffer size is described in Setting the GigaStor general options and may help in some instances; otherwise application filtering is needed.
You can choose to filter TCP-, UDP-, and SCTP-based applications, including any derived applications you created in How to add application definitions.
In GigaStor, an application can be defined using a port, port range, or port/IP address combination (or any combination of these). GigaVUE does not have a way to identify applications based on port/IP address. Therefore, the port/IP address combination will be removed from any filter before it is sent to GigaVUE. For example, if an application definition is 9000, 2343:, only 9000 will be passed to GigaVUE; 2343: will be dropped from the filter. Again, this is a limitation of GigaVUE.
A maximum of 100 tool port filter rules can be created. An application that uses a port range (9001-9005) counts as one rule not as five rules.
GigaStor uses a REST API to communicate with GigaVUE. If there are communication interruptions between the two systems for whatever reason, GigaStor will attempt several times to reissue the command until it is successful. If it is still not successful after several attempts, a message will be written to the log.
How Gigamon-applied port tags are identified
GigaStor identifies packets with headers applied by Gigamon because a Gigamon system tags packets using an 802.1Q tag.
The Gigamon administrator may apply port tags to each ingress port on the GigaVUE. For each ingress port a unique VLAN 802.1Q tag is used. This tag is applied using the outermost VLAN tag. When there is a VLAN 802.1Q tag on the inner frame, only the information in the outermost 802.1Q tag is used.
GigaStor queries the list of port tags used by Gigamon and maintains a copy of that list. When traffic is received by GigaStor it is compared against the list. If there is a match, the GigaStor knows exactly which ingress port on the Gigamon was used and displays the information accordingly.