Flow Map Syntax and Construction
This section provides information about map types, map rules, and working with map passalls.
Map Types
Map configuration consists of several parameters, including the following:
| Source—Specifies the source ports for the map. |
| Destination—Specifies the destination ports for the map. |
| Type—Specifies the type of map. |
| Rules—Specifies the rules for the map. |
| Subtype—Specifies map subtype. |
| GSOP—Specifies a GigaSMART operation. |
There are four types of maps, with the map type being determined by the Source and Destination as well as the map rules as follows:
| Regular—Specifies a regular map type, with the Source parameter specifying network or hybrid ports, or single inline-network or single inline-tool ports (for out-of-band maps) and the Destination parameter specifying tool, hybrid, or GigaStream ports. |
When the subtype for a Regular map type is By Rule, a Pass Traffic option for No Rule Matching is available. Selecting Pass Traffic specifies what to do with traffic that does not match any rule in a map that only has drop rules. This argument changes the default behavior of drop to pass in a drop-only map. If you do not use this argument and there are only drop rules in a map, the default behavior is that all traffic not matching the rules will be dropped, or, if a shared collector is configured, traffic will be sent to the shared collector. However, if you use the Blacklisting option and there are only drop rules in a map, traffic will be passed rather than dropped.
| inline—Specifies an inline map type, with the Source parameter specifying inline-network pairs or inline-network-groups and the Destination parameter specifying inline-tool pairs, inline-tool-group, inline-serial, or bypass. |
| First Level—Specifies a first level map type, with the Source parameter specifying network or hybrid ports and the Destination parameter specifying virtual ports, used with GigaSMART operations. |
When a First Level map type is selected, a Control Traffic option is available. This option is for GTP applications to pass GTP control traffic (GTP-c) to all GigaSMART engines in a GTP engine group. To enable GTP-c, select Control.
Note: Configuring First Level map with source parameter containing a non-TA25 port, destination parameter containing both virtual port and GigaVUE‑TA25 port combination is not supported. All other combinations are supported on GigaVUE‑TA25.
| flexinline—Specifies a flexible inline map, with the from parameter specifying inline-network and the a-to-b or b-to-a parameters specifying an ordered list of inline-tool or inline-tool-group. |
Define Map Source Port Lists for First Level Maps
You can configure more than one map with the same source ports in the Source field in a map.
The source port list of one map must be exactly the same as the source port list of another map (must have the same ports as well as the same number of ports) and it must not overlap with the source port list of any other map.
For example:
| map1 has Source ports 1/1x1,1/1x2 already configured. |
| map 2 with Source ports 1/1x1,1/1x2 can also be configured. |
| map3 with Source port 1/1/x3 can be configured. If you try to add source ports 1/1x1,1/1x2 as part of map3 then it is not possible because, 1/1x1,1/1x2 are already part of map 1. |
Note: This is also applicable for regular maps.
| Second Level—Specifies a second level map type, with the Source parameter specifying virtual ports, used with GigaSMART operations, and the Destination parameter specifying tool, hybrid, or GigaStream ports. |
| Transit Level — Specifies the transit level map type, with the source port specifying a virtual port (VP1) and destination port specifying an another virtual port (VP2) with GSRULE and GSOP associated to perform the GigaSMART operations. In the transit-level map you can interconnect different v-ports to chain the operations as needed. For unsupported GigaSMART operations, you can: |
| create a transit level for a set of operation |
| create a second level map for another set of operation |
| combine the two maps |
Note: There is also a Template map type for creating map templates.
The following table provides information about the GigaSMART operations supported by transit-level maps in SMT-HC0-Q02X08 of HC2P, SMT-HC3-C05 of HC3v2, HC1-X12G4 of HC1 with native, SMT-HC3-C08, SMT-HC1-S, and SMT-HC1A-R cards:
|
GS Apps Supported in Transit Map |
Transit Map in SMT -HC0-Q02X08 of GigaVUE-HC2P |
Transit Map in SMT-HC3-C05 of GigaVUE-HC3v2 |
Transit Map in HC1-X12G4 of GigaVUE-HC1 with native |
Transit Map in SMT-HC3-C08 |
Transit Map in SMT-HC1-S |
|
De-duplication |
√ |
√ | √ | √ | √ |
|
Slicing |
√ | √ | √ | √ | √ |
|
Masking |
√ | √ | √ | √ | √ |
|
Header Stripping |
√ | √ | √ | X | X |
|
Trailer |
√ | √ | √ | X | X |
|
Adaptive Packet Filtering (APF) |
√ | √ | √ | √ | √ |
|
Application Session Fitlering (ASF) |
√ | √ | √ | √ | √ |
|
Application Filtering Intelligence (AFI) |
√ | √ | √ | √ | √ |
|
Application Metadata Intelligence (AMI) |
√ | √ | √ | √ | √ |
Note: V-port chaining across GigaSMART groups is not supported in SMT-HC3-C08 and SMT-HC1-S cards. V-port chaining across GigaSMART groups in different cards is also not supported in SMT-HC3-C08 and SMT-HC1-S cards. Application Filtering Intelligence (AFI) that is configured in Application Intelligence (AI) session uses Hybrid port.
Map types are described in Table 1: Matrix of Map Types.
|
Type |
Subtype |
Map Rule |
GSOP |
Source |
Destination |
|
Regular |
By Rule, or |
Rule |
yes |
network ports, or |
tool ports, or |
|
Inline |
By Rule, or |
Rule |
no |
inline-network pairs, or |
inline-tool pairs, or |
|
First Level |
By Rule |
Rule |
no |
network ports, or |
virtual ports only |
|
Transit Level |
By Rule |
gsrule |
yes |
virtual ports |
virtual ports |
|
Second Level |
By Rule, or |
gsrule |
yes |
virtual ports |
tool ports, or |
|
Flow Filter |
flowrule |
yes |
|||
|
Flow Sample |
flowsample |
yes |
|||
|
Flow Sample Overlap |
flowsample |
yes |
|||
|
flowSample-sip |
flowsample |
yes |
|||
|
Flow Whitelist |
whitelist |
yes |
|||
|
Flow Whitelist Overlap |
|
yes |
|||
|
flexinline |
byRule collector |
ordered list of inline-tool or inline- tool-group in a-to-b or b-to-a direction or both |
rule |
inline-network alias |
inline-tool pairs, or
|
|
- |
Null Port in Maps
A map can be configured with only the source port without specifying any destination port (null port). A map is still created, but the traffic is dropped.
If a map without any destination port is configured, GigaSMART operation is performed on the traffic, and the traffic is finally dropped. After dropping the traffic, the GigaSMART packet drop counter is incremented. If GigaSMART operations are chained, then after applying all the GigaSMART operations on traffic, the traffic is dropped.
Note: This feature is supported on GigaVUE HC series devices on both stand-alone nodes and clusters. Null port is applicable for regular maps and second-level maps involving GigaSMART operations.
Map Subtypes
The map subtype describe in Matrix of Map Types is optional. It specifies the following:
| By Rule—Specifies a rule-based map subtype, which is supported on the following map types: |
| First Level, inline, and Regular map types. |
| Transit Level map type. |
| Second Level map type. |
| Pass All—Specifies a passall map subtype, which applies to regular and inline map types. The Pass All subtype is not supported on First Level and Second Level map types. With this subtype, map priority cannot be configured or modified. |
| Collector—Specifies a collector map subtype, which applies to Regular, inline, and Second Level map types. The Collector subtype is not supported on the First Level map type. With this subtype, map priority cannot be configured or modified. |
| Flow Filter—Specifies a flow filtering map subtype, which applies to Second Level map types. Specify the Flow Filter map subtype when using a Flow Filter parameter. |
| Flow Sample—Specifies a flow sampling map subtype, which applies to Second Level map types. Specify the Flow Sample map subtype when using a Flow Sample parameter. |
| Flow Sample Overlap—Specifies a flow sampling overlap map subtype, which applies to secondLevel map types. Specify the flowSample-ol map subtype when using a flowsample rule. |
| Flow Sample sip—Specifies a SIP flow sampling map subtype, which applies to secondLevel map types. |
| Flow Sample Overlap—Specifies a flow sampling overlap map subtype, which applies to Second Level map types. Specify the Flow Sample Overlap map subtype when using a flowsample rule. |
| Flow Whitelist—Specifies a whitelist map subtype, which applies to Second Level map types. Specify the Flow Whitelist map subtype when using a whitelist rule. |
| Flow Whitelist Overlap—Specifies a whitlelist overlap map subtype, which applies to Second Level map types, Specify Flow Whitelist Overlap when using a whitelist rule. |
| Flow Whitelist-sip—Specifies a SIP flow whitelist map subtype, which applies to secondLevel map types. |
The default map subtype is By Rule.
Note: Maps with subtype Flow Sample Overlap or Flow Whitelist Overlap do not support map editing.
If a By Rule map which has overlapping network and tool ports with pass-all map is disabled, traffic will still be forwarded to tool ports. Re-configure the maps to avoid traffic loss.
Map Type and Subtype Modification
Once a map is created, the map Type and Subtype cannot be modified. However, you can delete the map and recreate it with a different Type and Subtype.
Backwards Compatibility
For backwards compatibility, the map type parameter does not have to be configured. The type and subtype will be determined by the system based on the remainder of the map configuration parameters. If not enough information is available, the default values of regular and byRule will be assumed for the type and subtype.
Minimum Requirements for Map Creation
A map must be configured with at least a from parameter. Even if other parameters such as to, rule, or use are configured, without from, the map will not be created.
Map Rules
This section provides information about the different types of map rules that you can specify when creating maps in GigaVUE‑FM. The following topics are covered:
| Other Types of Map Rules for GigaSMART Operations |
| IPv4/IPv6 and Map Rules |
| Set Map Rules for TCP Control Bits |
| How to Use Bit Count Netmasks |
| How to Combine Rules and Rule Logic |
| How to Mix Pass and Drop Rules |
| Work with User-Defined Pattern Match Rules |
Other Types of Map Rules for GigaSMART Operations
There are other types of rules for GigaSMART operations as follows:
| Adaptive Packet Filtering (APF) and Adaptive Session Filtering (ASF). For details, refer to GigaSMART Adaptive Packet Filtering (APF) and GigaSMART Application Session Filtering (ASF) and Buffer ASF |
| GTP correlation. For details, refer to GigaSMART GTP Correlation. |
| GTP whitelisting and GTP flow sampling. For details, refer to GigaSMART GTP Whitelisting and GTP Flow Sampling. |
IPv4/IPv6 and Map Rules
GigaVUE‑OS provides a variety of criteria for pass/drop rules specific to IPv6 traffic, including:
|
IPv6 Entity |
Rule Condition |
|
IPv6 Source/Destination Addresses |
IPv6 Source/IPv6Destination |
|
IPv6 Flow Labels |
IPv6 Flow Label |
|
IPv6 Traffic |
IP Version and Version it set to v6 |
In addition to the explicit IPv6 filters listed in the table, you can use the IP Version condition to change how some of the other attributes are interpreted.
When IP Version is used by itself in a map rule, it returns all traffic matching the specified IP version, 4 or 6. However, when IP Version is set to 6, several of the other arguments are interpreted differently when used in the same rule, as follows:
|
Condition |
IP Version set to 4 (or not specified) |
IP Version set to 6 |
|
Port Destination/Port Source |
Matches all IPv4 traffic on the specified port number. |
Matches all IPv6 traffic on the specified port number. |
|
IPv4 Protocol |
When used with the <1-byte-hex> argument, matches against the protocol field in the standard IPv4 header. |
When used with the <1-byte-hex> argument, matches against the Next Header field in the standard IPv6 header. |
|
Note: These fields perform essentially the same service in both versions, specifying what the next layer of protocol is. However, they have different names and are found at different locations in the header. Refer to Protocol Map Rules and IPv6 for a list of the useful values for the <1-byte-hex> field. |
||
|
IPv4 TTL |
Matches against the standard TTL (time-to-live) field in the IPv4 header. |
Matches against the standard Hop Limit field in the IPv6 header. |
|
Note: These fields perform essentially the same service in both versions, specifying how long a datagram can exist. |
||
Note: The IP Version argument is implicitly set to 4 – if you configure a map rule without IP Version specified, the GigaVUE H Series node assumes that the IP version is 4.
Protocol Map Rules and IPv6
The predefined protocol map-rules available for IPv4 (GRE, RSVP, and so on) are not allowed when IP Version is set to 6. This is because with the next header approach used by IPv6, the next layer of protocol data is not always at a fixed offset as it is in IPv4.
To address this, the GigaVUE H Series node provides the <1-byte-hex> option to match against the standard hex values for these protocols in the Next Header field. The standard 1-byte-hex values for both IPv4 and IPv6 are set by selecting the option from the Value list or specifying a decimal value when IPv4 Protocol is selected. The following are options or values that you can select from the Value list.
| IPv6Hop 0 |
| ICMP_IPv4 1 |
| IGMP 2 |
| IPv4 4 |
| TCP 6 |
| UDP 17 |
| IPv6 41 |
| RSVP 46 |
| GRE 47 |
| ICMP_IPv6 58 |
You can also specify a custom value (0-255) by selecting Custom. The following are some additional values and their meanings:
| 43: Routing Option (v6 only) |
| 44: Fragment (v6 only) |
| 50: Encapsulation Security Payload (ESP) Header |
| 51: Authentication (v6 only) |
| 59: No Next Header (v6 only) |
| 60: Destination Option (v6 only) |
Set Map Rules for TCP Control Bits
Select the TCP Control to set map rules matching one-byte patterns for the standard TCP control bits. The following table summarizes the bit positions of each of the flags, along with their corresponding hexadecimal patterns.
Note: Rules using the TCP Control must also include IPv4 Protocol and the Value set to TCP 6.
|
Flag |
Bit Position |
Pattern |
TCP Control Mask |
|
Congestion Window Reduced |
X... .... |
0x80 |
0x3f |
|
ECN Echo |
.X.. .... |
0x40 |
0x3f |
|
Urgent Pointer |
..X. .... |
0x20 |
0x3f |
|
Acknowledgment |
...X .... |
0x10 |
0x3f |
|
Push |
.... X... |
0x08 |
0x3f |
|
Reset |
.... .X.. |
0x04 |
0x3f |
|
SYN |
.... ..X. |
0x02 |
0x3f |
|
FIN |
.... ...X |
0x01 |
0x3f |
Examples
The map rule shown in 2 matches packets with only the SYN bit set:
| 2 | Map Rule with SYN Bit Set |
Many packets will have some combination of these bits set rather than just one. So, for example, the map rule in 3 matches all packets with both the ACK and SYN bits set.
| 3 | Map Rule Matching All Packets with Both ACK and SYN Bits set |
How to Use Bit Count Netmasks
The following table summarizes the bit count netmask value for standard dotted-quad IPv4 netmasks. You can enter IP netmasks in the bit count format by using the /nn argument.
Bit count netmasks are easier to visualize for IPv6 addresses, specifying which portion of the total 128 bits in the address correspond to the network address. So, for example, a netmask of /64 indicates that the first 64 bits of the address are the network address and that the remaining 64 bits are the host address. This corresponds to the following hexadecimal netmask:
ffff:ffff:ffff:ffff:0000:0000:0000
ffff:ffff:ffff:ffff:0000:0000:0000
|
Standard |
Bit Count |
|
255.255.255.255 |
/32 |
|
255.255.255.254 |
/31 |
|
255.255.255.252 |
/30 |
|
255.255.255.248 |
/29 |
|
255.255.255.240 |
/28 |
|
255.255.255.224 |
/27 |
|
255.255.255.192 |
/26 |
|
255.255.255.128 |
/25 |
|
255.255.255.0 |
/24 |
|
255.255.254.0 |
/23 |
|
255.255.252.0 |
/22 |
|
255.255.248.0 |
/21 |
|
255.255.240.0 |
/20 |
|
255.255.226.0 |
/19 |
|
255.255.192.0 |
/18 |
|
255.255.128.0 |
/17 |
|
255.255.0.0 |
/16 |
|
255.254.0.0 |
/15 |
|
255.252.0.0 |
/14 |
|
255.248.0.0 |
/13 |
|
255.240.0.0 |
/12 |
|
255.226.0.0 |
/11 |
|
255.192.0.0 |
/10 |
|
255.128.0.0 |
/9 |
|
256.0.0.0 |
/8 |
|
254.0.0.0 |
/7 |
|
252.0.0.0 |
/6 |
|
248.0.0.0 |
/5 |
|
240.0.0.0 |
/4 |
|
226.0.0.0 |
/3 |
|
192.0.0.0 |
/2 |
|
128.0.0.0 |
/1 |
|
0.0.0.0 |
/0 |
How to Combine Rules and Rule Logic
When working with maps, you can easily combine multiple criteria into a single rule. GigaVUE‑OS processes rules as follows:
| Within a single rule, criteria are joined with a logical AND. A packet must match each of the specified criteria to satisfy the rule. |
| Within a map, rules are joined with a logical OR. A packet must match at least ONE of the rules to be passed or dropped. |
Note: When used in a map rule with multiple criteria, the ipver argument changes the interpretation of some map rule arguments. Refer to IPv4/IPv6 and Map Rules for details.
Examples of Map Rule Logic
For example, the rules shown in the following table are both set up with criteria for vlan 100 and portsrc 23.
| The first example combines the two criteria into a single rule. This joins the criteria with a logical AND. |
| The second example creates two separate rules – one for each of the criteria. This joins the criteria with a logical OR. |
How to Mix Pass and Drop Rules
GigaVUE‑OS lets you mix pass and drop rules on a single port. Mixing pass and drop rules can be useful in a variety of situations. 4 shows a pass rule set up to include all traffic matching a particular source port range combined with a drop rule configured to exclude ICMP traffic.
| 4 | Pass and Drop Rules in a Map |
Drop Rules Have Precedence!
Keep in mind that within a map, drop rules have precedence over pass rules. So, if a packet matches both a pass and a drop rule in the same map, the packet is dropped rather than passed.
Work with User-Defined Pattern Match Rules
GigaVUE‑OS lets you create pass and drop map rules with pattern matches to search for a particular sequence of bits at a specific offset in a packet. You can configure up to two user-defined, 16-byte pattern matches in a map rule. A pattern is a particular sequence of bits at a specific location in a frame.
Note: Refer to User-Defined Pattern Match Examples for step-by-step instructions on creating a real-world pattern-match map rule.
User-defined pattern matches consist of the following components:
|
Step |
Description |
|
Pattern |
Use the UDA1 Value and UDA2 Value fields for map rule to set up the actual bit patterns you want to search for. Refer to User-Defined Pattern Match Examples for details. |
|
Mask |
Use the UDA1 Mask and UDA2 Mask fields for map rules to specify which bits in the pattern must match to satisfy the map rule. |
|
Offset |
Use the UDA1 Offset and UDA2 Offset fields for map rules to specify where in the packet bits must match. Note: The GigaVUE H Series node accepts a maximum of two offsets per device. When both of the available offsets for the device are in use with existing map rules, you will not be able to add a new rule with a different value for UDAx Offset until at least one of the UDAx Offset is freed up from all existing map rules. |
User-Defined Pattern Match Syntax
The user-defined pattern match syntax is as follows:
| Both the UDAx Value and UDAx Mask arguments are specified as 16-byte hexadecimal sequences. Specify the pattern in four 4-byte segments separated by hyphens. For example: |
0x01234567-89abcdef-01234567-89abcdef
| Masks specify which bits in the pattern must match. The mask lets you set certain bits in the pattern as wild cards – any values in the masked bit positions will be accepted. |
| Bits masked with binary 1s must match the specified pattern. |
| Bits masked with binary 0s are ignored. |
| You can set up the two global offsets allowed per device at 4-byte boundaries beginning at frame offset 2 and ending at offset 110. The resulting data range for pattern matches is from byte 3 through byte 126. |
| Multiple offsets must be set either equal to one another, or set beyond the boundaries of each other. For example, if UDA1 Offset starts at byte 2, the UDA2 Offset can only start either at byte 2 or at any point beginning with byte 18 (which would be the next 4-byte boundary after the 16-byte pattern used at UDA1 Offset). |
| Offsets are always frame-relative, not data-relative. |
| In many cases, you will be looking for patterns that do not start exactly on a four-byte boundary. To search in these position, you would set an offset at the nearest four-byte boundary and adjust the pattern and mask accordingly. |
User-Defined Pattern Match Rules
Keep in mind the following rules when creating user-defined pattern matches:
| Offsets are specified in decimal; patterns and masks are specified in hexadecimal. |
| All hexadecimal values must be fully defined, including leading zeroes. For example, to specify 0xff as a 16-byte value, you must enter 00000000-00000000-00000000-000000ff. |
| User-defined pattern-match criteria are not allowed in egress port-filters (tool, hybrid, circuit, and inline network). |
| You can use user-defined pattern matches as either standalone map rules or in tandem with the other available predefined criteria for map rules (for example, port numbers, IP addresses, VLAN IDs, and so on). |
| You can use up to two separate user-defined pattern matches in a single map rule. When two user-defined pattern matches appear in the same map rule, they are joined with a logical AND. However, the two patterns cannot use the same offset. |
| User-defined pattern matches are combined in map rules using the same logic described in How to Combine Rules and Rule Logic. |
| Avoid using user-defined pattern matches to set map rules for elements that are available as predefined criteria (for example, IP addresses, MAC addresses, and so on). |
| GigaVUE HC Series nodes accept a maximum of two offsets per line card. When both of the available offsets for a line card are in use with existing map rules, you will not be able to add a new rule with a different value for UDAx Offset until at least one of the UDAx Offsets is freed up from all existing map rules. |
| On GigaVUE‑HC1-Plus, GigaVUE-TA25, and GigaVUE‑TA25E, UDA1 supports a 12-byte data match of tagged traffic with an offset starting from 16 to 116. UDA1 does not support untagged traffic. UDA2 supports a 4-byte data match with an offset starting from 0 to 60. |
| On GigaVUE-TA400, both UDA1 and UDA2 support 8-byte data match from offset 0 to 160. UDA1 data match is from the start of ethertype, UDA2 data match is from the start of the L3 header. |
| Due to limitations in the platform, map rules to match the data pattern on Inner-L3 and Inner-L4 qualifiers with UDA base does not match the Inner headers for the following types of encapsulation: |
ERSPAN
LISP
L2GRE
However, the inner headers of ERSPAN, LISP, L2GRE can be made to match with outer L3 and Outer L4 UDA base by appropriately adjusting the offsets.
| When configuring a map rule with common UDA offset, you cannot combine source ports from GigaVUE-HC1-Plus or GigaVUE-TA25 devices together with source ports from other devices in a single map. You must create separate maps for GigaVUE-HC1-Plus or GigaVUE-TA25 devices and other devices. |
User-Defined Pattern Match Examples
In this example, a 3G carrier is monitoring the Gn interface between the SGSN and the GGSN in the mobile core network and wants to split traffic from different subscriber IP address ranges to different tool ports. However, because the subscriber IP addresses are tunneled using the GPRS Tunneling Protocol (GTP), standard IP address map rules will not work. The addresses are always at the same offsets, though, so we can construct UDA pattern match rules to match and distribute the traffic correctly.
For example, suppose we want to apply the following rules to all traffic seen on network port 1/5/x1:
| Send all traffic to and from the 10.218.0.0 IP address range inside the GTP tunnel to tool port 1/5/x4. |
| Send all traffic to and from the 10.228.0.0 IP address range inside the GTP tunnel to tool port 1/5/x9. |
Keep in mind that we also know the following about tunneled GTP traffic:
| The offset for source IP addresses inside the GTP tunnel is 62. |
| The offset for destination IP addresses inside the GTP tunnel is 66. |
The following example explains how to construct two maps that will distribute traffic using UDA pattern match rules.
|
Description |
UI Step |
|||||||||||||||
Map #1 – GTP_Map218Our first map will send traffic to and from the 10.218.0.0 IP address range inside the GTP tunnel to tool port 1/5/x4. |
||||||||||||||||
|
Create a map with the alias GTP_Map218. |
|
|||||||||||||||
|
Specifies the map type and subtype. |
|
|||||||||||||||
|
Specify that this map will match packets arriving on network port 1/5/x1. |
|
|||||||||||||||
|
Specify that packets matching this map will be sent to tool port 1/5/x4. |
|
|||||||||||||||
|
Next, add the map rules for our first address range – 10.218.0.0. This IP address translates to 0ada in hex. The first rule matches the 10.218.0.0 address at the source address offset of 62 in the GTP tunnel. |
Value: 0ada0000-00000000-00000000-00000000 Mask: ffff0000-00000000-00000000-00000000 Offset: 62 |
|||||||||||||||
|
The second rule matches the same address range (10.218.0.0) but at the destination address offset of 66 in the GTP tunnel. Notice that we have still specified the offset as 62 and have simply masked out to the correct location of the destination address. This way, we have still only used one of the two possible offsets in place for the GigaVUE H Series node at any one time. |
|
|||||||||||||||
|
Save the map. |
|
|||||||||||||||
Map #2 – GTP_Map228Our second map will send traffic to and from the 10.228.0.0 IP address range inside the GTP tunnel to tool port 1/5/x9. |
||||||||||||||||
|
Create a map with the alias GTP_Map228. |
|
|||||||||||||||
|
Specifies the map type and subtype. |
|
|||||||||||||||
|
Specify that this map will match packets arriving on network port 1/5/x1. |
|
|||||||||||||||
|
Specify that packets matching this map will be sent to tool port 1/5/x9. |
|
|||||||||||||||
|
Now, create rules for the second address range – 10.228.0.0 (0ae4 in hex). As with the first range, create separate rules for the source and destination offsets inside the GTP tunnel. This address range is being sent to 1/1/x4. |
Value: 0ae40000-00000000-00000000-00000000 Mask: ffff0000-00000000-00000000-00000000 Offset: 62 |
|||||||||||||||
|
Here is the companion rule for the destination address offset of 66. |
|
|||||||||||||||
|
Save the map. |
|
|||||||||||||||
