FILTERING VLAN PACKETS HAVING MALFORMED TPIDS

Malformed VLAN packets can be detected by programming suitable rules in a TCAM in the packet processing pipeline. In some deployments, for example, the TCAM rule(s) can match on the parsed EtherType metadata. More specifically, the match can be based on the EtherType metadata being set to a value equal to known VLAN TPIDs, such as 0x8100, 0x88a8, rather than being set to a standard EtherType.

CROSS REFERENCE TO RELATED APPLICATIONS

Pursuant to 35 U.S.C. §119(a), this application is entitled to and claims the benefit of the filing date of India Provisional Patent Application No. 202141048769, filed Oct. 26, 2021 in India, the content of which is incorporated herein by reference in its entirety for all purposes.

BACKGROUND

The packet processing pipeline in a network device (e.g., switch, router, etc.) includes a parsing stage (parser) to parse an ingress packet and extract information (packet data and metadata) from the various fields of the packet. The metadata can be used in the downstream stages of the pipeline to further process the packet. When the parser is presented with a malformed packet, the malformed packet may be parsed incorrectly. The resulting metadata that is parsed from the malformed packet is likely to be garbled and otherwise meaningless. In some cases, the downstream stages of the pipeline can detect the garbled metadata and reject the malformed packet. In other cases, the downstream stages may not detect that the metadata is incorrect and hence may continue processing the packet not knowing the packet is malformed. This represents a potential exploit, where packets can be intentionally malformed in an attempt to bypass security features provided in the network device.

Packets on a virtual local area network (VLAN), for example, can be malformed in various ways. For instance, VLAN packets that contain more than two VLAN tags can be considered malformed. VLAN packets having unexpected tag protocol identifiers (TPIDs) can be deemed to be malformed. As noted above, a malformed packet can cause the parser to misclassify the packet, resulting in garbled metadata. In some cases, the metadata generated by parsing a malformed VLAN packet may not trigger or alert the downstream pipeline stages of the presence of the malformed packet. Continued processing of the malformed VLAN packet can have catastrophic results in a customer’s networks. For example, the misclassified packet may be labeled as a Layer 2 (L2) packet, which could cause the network device to simply switch the packet. In such a case, if the network device does not implement L2 access control lists (ACLs, e.g., port ACLs, MAC ACLs, etc.) or other suitable L2 security features to filter the malformed packet, the packet will be forwarded which can lead to breaches in security and other security related issues in the customer’s deployment.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. Particular embodiments as expressed in the claims may include some or all of the features in these examples, alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.

For discussion purposes to illustrate aspects of the present disclosure, examples of packets will use the Ethernet II framing format. Ethernet II frames are known and well understood, and defined in accordance with various Institute of Electronics and Electrical Engineers (IEEE) networking standards. Packets can be untagged, single-tagged, and multi-tagged (e.g., double, triple, etc.).

FIG.1shows the format for an untagged packet (Ethernet II frame). An untagged packet includes a destination media access control (DMAC) address that begins at byte offset 0 (byte 0), a source MAC (SMAC) address that begins at byte 6, an EtherType field at byte 12, and a payload that begins at byte 14. In a properly formed Ethernet II frame, the 2-byte EtherType field is expected to begin at offset 12 indicates the type of protocol that is encapsulated in the payload of the frame. A value of 0x800 in the EtherType field indicates that the payload contains an Internet Protocol v4 (IPv4) datagram. A value of 0x86dd indicates the payload contains an IPv6 datagram. Other EtherTypes are defined per various IEEE networking standards. For discussion purposes, the examples will use the EtherType for IPv4 datagrams, namely EtherType equals 0x0800.

FIG.2shows the format for a single-tagged VLAN packet. VLAN and VLAN packet formats are known and well understood, and defined in accordance with various IEEE networking standards. In the case of a single-tagged VLAN packet, a 4-byte VLAN tag is located between the SMAC address and the Ethertype field. Accordingly in a properly formed Ethernet II frame, the VLAN tag should begin at byte 12 and span four bytes. The EtherType field follows the VLAN tag and is pushed further down in the packet, occupying bytes 16 and 17 in the packet. The VLAN tag comprises two fields: a 2-byte TPID field and a 2-byte tag control information (TCI) field. The TCI field contains, among other information, the VLAN identifier.

The TPID serves to indicate that the frame is a VLAN packet. TPIDs are standardized according to various IEEE networking standards. For example, a TPID value of 0x8100 indicates the packet is a VLAN packet that is tagged in accordance with802. 1q (dot1q) which is an IEEE networking standard that defines VLAN tags.

ComparingFIG.1andFIG.2, it can be seen that an untagged frame can be distinguished from a dot1q (single-tagged) frame by looking at the 16-bit word that begins at byte 12 in the frame. For example, if bytes 12:13 in the frame is 0x800, then the packet is deemed to be untagged; if bytes 12:13 == 0x8100, the packet is deemed to be a single-tagged VLAN packet.

FIG.3shows the format for a double-tagged VLAN packet. The outer VLAN tag begins at byte 12 and the inner VLAN tag begins at byte 16. In a properly formed Ethernet II frame, the EtherType field should occupy bytes 20:21. The TPID in the outer VLAN tag can be 0x8a88 to indicate the packet is tagged in accordance with 802.1ad (dot1ad), the IEEE networking standard for double-tagged VLAN packets (also referred to as QinQ and VLAN stacking). The TPID in the inner VLAN tag can be 0x8100 to indicate that the payload contains a single-tagged VLAN packet.

Referring toFIG.4, the present disclosure is applicable to VLAN tagged packets having more than two stacked VLAN tags. For example,FIG.4shows a triple-tagged VLAN packet.

FIG.5depicts an example of a network device500in accordance with some embodiments of the present disclosure. As shown, network device500includes a management module502, an internal fabric module504, and a number of I/O modules506a-506p. Management module502includes the control plane (also referred to as control layer) of network device500and can include one or more management CPUs508afor managing and controlling operation of network device500in accordance with the present disclosure. Each management CPU508acan be a general purpose processor, such as but not limited to an Intel®/AMD® x86 or ARM® processor, that operates under the control of software stored in a memory508b, such as dynamic random access memory (DRAM). Control plane refers to all the functions and processes that determine which path to use, such as routing protocols, spanning tree, and the like.

Internal fabric module504and I/O modules (chips)506a-506pcollectively represent the data plane of network device500(also referred to as data layer, forwarding plane, etc.). Internal fabric module504is configured to interconnect the various other modules of network device500. Each I/O module506a-506pincludes a respective set of input/output (I/O) ports510a-510pwhich collectively constitute the ports of the network device for sending and receiving network packets. Each I/O module (chip) can be associated with an inner TPID where the inner TPID applies to all ports on the I/O module. Each port in an I/O module can be assigned or otherwise associated with a user-configurable (e.g., software programmable) outer TPID. The inner and outer TPIDs are discussed further below.

Each I/O module506a-506pcan include a packet processor512a-512pand a respective memory component514a-514p. Each packet processor512a-512pcan comprise a forwarding pipeline (e.g., application specific integrated circuit (ASIC), field programmable array (FPGA), digital processing unit, graphics coprocessors, content-addressable memory, and the like) configured to make decisions on how to process incoming (ingress) and outgoing (egress) network packets. Each memory component514a-514pcan include a ternary content-addressable memory (TCAM) to store rules, specified in accordance with the present disclosure, for processing or filtering packets.

Referring toFIG.6, the discussion will now turn to a high-level description of processing in a network device (e.g.,500,FIG.5), and in particular a packet processor (e.g.,512a) in the network device, for receiving and processing a packet in accordance with the present disclosure.

At operation602, the packet processor can receive an ingress packet on one of its ports (e.g.,510a). The packet processor can provide the ingress packet to a parsing stage in the processing pipeline of the packet processor.FIG.7, for example, shows a processing pipeline700in the packet processor comprising parsing stage702for parsing an ingress packet.

At operation604, the packet processor can parse the ingress packet in the parsing stage of the processing pipeline. In accordance with some embodiments, the parsing stage can parse (FIG.8) the EtherType field in the packet and store the parsed EtherType into an EtherType metadata, along with other metadata704(FIG.7) that can be parsed from the ingress packet.

At operation606, a lookup in TCAM706(FIG.7) can be performed using the EtherType metadata and portions of the ingress packet to identify a rule stored in the TCAM.

At operation608, an accessed rule706a(FIG.7) can be processed by rule processing logic708to produce an egress packet. The accessed rule can include actions to direct the rule processing logic to rewrite the ingress packet (e.g., change destination IP), to log information, or to drop the packet, and so on. Rules in accordance with the present disclosure are discussed below.

FIG.8shows a flow for processing in pipeline700(FIG.7), and in particular parsing stage702of the pipeline, to parse an ingress packet and categorize the packet as being untagged (FIG.1), single-tagged (FIG.2), or double-tagged (FIG.3). Pipeline architectures are known; for example, pipeline700can comprise a combination of programmed logic (e.g., field programmable gate array, FGPA, logic), microcode, and the like. The operations illustrate how the EtherType field can be parsed for tagged and untagged packets and stored into an EtherType metadata (e.g., in memory514ain the network device) for further processing downstream in the pipeline.

The tagging category can be based on the TPID(s) contained in the ingress packet. In some embodiments, a TPID can be categorized as being an “outer” TPID or an “inner” TPID. An outer TPID is a TPID that is associated on a port by port basis. Each port on the network device can be configured (e.g., software programmable) by the user with a value for its outer TPID. In some embodiments, a port can be associated with more than one outer TPID. An inner TPID is a TPID that is associated with the chip (e.g., I/O module506a) as a whole, which in turn associates each port on the chip with that inner TPID. In some embodiments, for example, the inner TPID can be hardwired into the chip; e.g. the inner TPID can be selected using jumpers on the circuit board. Accordingly, the inner TPID can be said to be fixed or otherwise is not configurable by software.

At802, the processing pipeline can receive an ingress packet. Processing can begin by providing the packet to the parsing stage in the pipeline. The ingress packet can be parsed according to the following:Double-tagged — In some embodiments, a packet is considered double-tagged when:bytes 12:13 match one of the outer TPIDs associated with the ingress port (Y branch at decision point804)bytes 16:17 match the inner TPID associated with the I/O module that supports the ingress port (Y branch at decision point806)Because the two bytes starting at byte 20 are interpreted as containing the Ethertype, byte 20 is the presumed (expected) starting location of the EtherType. Accordingly, the parsing stage will store the two bytes starting at byte 20 into the EtherType metadata (operation812).Single-outer-tagged — In some embodiments, a packet is considered single-outer-tagged when:bytes 12:13 match one of the outer TPIDs associated with the ingress port (Y branch at decision point804)bytes 16:17 do NOT match the inner TPID associated with the ingress port’s I/O module (N branch at decision point806)Because the two bytes starting at byte 16 are interpreted as containing the Ethertype, byte 16 is the presumed (expected) starting location of the EtherType. Accordingly, the parsing stage will store the two bytes starting at byte 16 into the EtherType metadata (operation814).Single-inner-tagged — In some embodiments, a packet is considered single-inner-tagged when:bytes 12:13 do NOT match any of the outer TPIDs associated with the ingress port (N branch at decision point804)bytes 16:17 match the inner TPID associated with the ingress port’s I/O module (Y branch at decision point808)Because the two bytes starting at byte 16 are interpreted as containing the Ethertype, byte 16 is the presumed (expected) starting location of the EtherType. Accordingly, the parsing stage will store the two bytes starting at byte 16 into the EtherType metadata (operation816).Untagged — In some embodiments, a packet is considered untagged when:bytes 12:13 do NOT match any of the outer TPIDs associated with the ingress port (N branch at decision point804)bytes 16:17 do NOT match the inner TPID associated with the ingress port’s I/O module (N branch at decision point808)Because the two bytes starting at byte 12 are interpreted as containing the Ethertype, byte 12 is the presumed (expected) starting location of the EtherType. Accordingly, the parsing stage will store the two bytes starting at byte 12 into the EtherType metadata (operation818).

At operation820, the processing pipeline can process the remainder of the packet to parse other metadata, and so on. In some embodiments, for example, when the packet is considered to be double-tagged, operation820can include additional processing to detect a triple-tagged packet (e.g.,FIG.4). For example, when a packet is deemed to be double-tagged the processing pipeline can parse for another TPID. If the processing pipeline parses a TPID == 0x88a8 or 0x8100 or 0x9100, the packet can be deemed to be triple-tagged and the processing pipeline can indicate the occurrence of such a packet, for example, by via appropriate pipeline metadata. Basically, a triple-tagged packet = double-tagged packet + next TPID == 0x88a8 or 0x8100 or 0x910

The discussion will now turn to examples of properly formed and malformed (improperly formed) VLAN packets. Consider the packets shown inFIGS.1,2, and3, which are deemed to be properly formed VLAN packets. Suppose they are received on a given port on the network device, and assume without loss of generality that the outer TPID for the given port is 0x8a88 and the I/O module (chip) to which the port is connected is programmed with an inner TPID of 0x8100. Applying the parsing sequence ofFIG.8to the packets shown inFIGS.1,2, and3, it can be seen that:The packet inFIG.1will be categorized as an untagged packet because bytes 12:13 are not equal to either the outer TPID (0x8a88) or the inner TPID (0x8100). The parser will parse the data at bytes 12:13 as the EtherType and set the EtherType metadata to the correct value of 0x800. In other words, bytes 12:13 are interpreted as containing the EtherType.The packet inFIG.2will be categorized as single-tagged packet, and in particular as a single-inner-tagged packet, because bytes 12:13 are not equal to the outer TPID (0x8a88) but is equal to the inner TPID (0x8100). The parser will parse the data at bytes 16:17as the EtherType and set the EtherType metadata to the correct value of 0x800. In other words, bytes 16:17 are interpreted as containing the EtherType.The packet inFIG.3will be categorized as a double-tagged packet because bytes 12:13 are equal to the outer TPID (0x8a88) and bytes 16:17 are equal to the inner TPID (0x8100). The parser will parse the data at bytes 20:21 as the EtherType and set the EtherType metadata to the correct value of 0x800. In other words, bytes 20:21 are interpreted as containing the EtherType.

We now consider examples of packets with malformed TPID configurations to illustrate how such packets can affect parsing of the EtherType metadata.

FIG.9shows an example of a malformed packet received on a port configured with outer TPID 0x8a88, on a chip programmed with inner TPID 0x8100. The packet has the format of a single-tagged VLAN packet, where the Ethertype is at bytes 16:17. However, per the flow inFIG.8, the packet will be mis-categorized as an untagged packet. The packet does not appear to the parser as a VLAN packet because bytes 12:13 of the packet hold the value 0x9100 which does not match the outer TPID (0x8a88) or the inner TPID (0x8100). Accordingly, the packet appears to the parser as an untagged packet (seeFIG.1) and will set the EtherType metadata according to the content of bytes 12:13 (per operation818) where the EtherType is located for untagged packets. However, bytes 12:13 in the packet inFIG.9contains 0x9100 and so the EtherType metadata will be set to 0x9100. Accordingly, any security ACLs or other security measures that target VLAN packets will be bypassed because the expected TPIDs were not detected. Absent suitable L2 security measures, the malformed packet (whether unintentional or intentional with malicious intent) may then be forwarded onto the next hop and into the network, thus putting the network at risk.

FIG.10shows another example of a malformed packet received on a port configured with outer TPID 0x8100, on a chip programmed with inner TPID 0x8100. Again, the packet has the format of a single-tagged VLAN packet. Again, per the flow inFIG.8, the packet will be mis-categorized as an untagged packet because bytes 12:13 of the packet (0x88a8) do not match either the outer TPID (0x8100) or the inner TPID (0x8100), and so the parser will not recognize the packet as being a VLAN packet but rather as an untagged packet. The EtherType metadata will be incorrectly set to the data at bytes 12:13, namely 0x8a88, at operation818.

FIG.11shows a malformed packet received on a port configured with outer TPID 0x8100, on a chip programmed with inner TPID 0x8100. The packet has the format of a double-tagged VLAN packet. Per the flow inFIG.8, however, the packet will be mis-categorized as a single-outer-tagged packet because bytes 12:13 of the packet (0x8100) match the outer TPID (0x8100) and bytes 16:17 of the packet (0x88a8) do not match the inner TPID (0x8100). The packet appears to the parser as a single-tagged VLAN packet (seeFIG.2, for example) and consequently expects the EtherType to be at bytes 16:17. Accordingly, the parser will set the EtherType metadata to the value at data at bytes 16:17, which inFIG.11is 0x8a88 (operation814).

FIG.12shows a malformed packet received on a port configured with outer TPID 0x8100, on a chip programmed with inner TPID 0x8100. The packet appears to be a double-tagged VLAN packet. Per the flow inFIG.8, however, the packet will be mis-categorized. Because bytes 12:13 of the packet (0x88a8) do not match the outer TPID (0x8100) nor the inner TPID (0x8100), the parser will miscategorize the packet as being an untagged packet. The parser will set the EtherType metadata to the data at bytes 12:13, where the EtherType is expected to be located for an untagged packet. However, bytes 12:13 in the example shown inFIG.12contain 0x8a88, instead of 0x0800 (the EtherType for IPv4).

In accordance with the present disclosure, malformed VLAN packets can be detected by programming suitable rules in the TCAM. In some embodiments, for example, the TCAM rule(s) can match on the parsed EtherType metadata. More specifically, in some embodiments, the match can be based on the EtherType metadata being set to a value equal to a VLAN TPID, such as 0x8100 (dot1q), 0x88a8 (dot1ad), rather than being set to a standard EtherType (e.g., 0x0800 for IPv4, 0x86dd for IPv6). In some embodiments, the match can be based on VLAN metadata parsed from the ingress packet, in addition to or instead of the parsed EtherType metadata. In some embodiments, for example, the match can be based on the VLAN ID contained in the ingress packet.

FIG.13shows a TCAM1300configured with rules defined in accordance with some embodiments. TCAMs and TCAM rules are known. Briefly, a TCAM rule comprises match criteria for matching packets and one or more actions that are invoked when the match criteria are met. The match criteria can match various data in a packet, including for example source and destination addresses, source and destination ports, protocol type, data in the payload, and so on. The match criteria can match metadata parsed from the packet; e.g., the EtherType metadata. Action(s) include dropping a packet, redirecting a packet, rewriting one or more fields in a packet, logging a message, and so on. For discussion purposes, a TCAM rule can be expressed or represented in the form of an IF - THEN statement:

where the conditions in the IF portion represent one or more match criteria and the THEN portion expresses the action(s) performed on a matched packet.

Rules (e.g.,1302,1304) are ordered in TCAM1300from top to bottom in decreasing priority. Rule1302has higher priority than rule1304, rule1304has priority than rule1306, and so on. TCAMs and their operation are very well known and understood. Briefly, when a TCAM lookup is performed, the first rule (starting with the highest priority rule) that matches on the ingress packet contents and/or corresponding metadata will be invoked, and the corresponding action(s) performed. No further rules in the TCAM are matched; the packet continues to the next stage in the packet processing pipeline.

Depending on the rule, the rule can match on contents of the ingress packet as the match criteria (e.g., source and destination MAC address, etc.), the rule can match on metadata parsed in the parsing stage (e.g., EtherType metadata) as the match criteria, or the rule can match on a combination of packet contents and metadata. Each of rules1302-1310, for example, matches on metadata, whereas rule1310matches on the packet content.

As shown by the foregoing examples, when a packet with malformed TPID(s) is parsed, the Ethertype metadata can be set to a TPID value (e.g., Ox8100, 0x88a8, etc.) rather than to a valid EtherType value (e.g.,, 0x0800, 0x86dd, etc.). TCAM rules can be defined to identify such packets. Rules1304-1308, for example, match on the EtherType metadata being set to a TPID value; packets matching one of these rules will be DROPPED, logged, and so on. It will be appreciated that in some embodiments, instead of matching the EtherType metadata to a TPID, the rule can match on:

However, because typical TCAMs cannot express the not equal (!=) operation with a single rule, embodiments, can check if EtherType == 0x8100 or if EtherType == 0x88a8 or if EtherType == 0x9100, instead.

Rule1302shows that malformed packets can be identified based on VLAN ID being a certain value; e.g., VLAN ID == 0; such packets are sometimes referred to as priority tagged packets. For example,

is a double-tagged packet where the first VLAN tag is TPID = 0x8100, VLAN =2 and the second VLAN tag (priority tag) is TPID = 0x8100, VLAN = 0. Accordingly, malformed packets can be prevented from propagating any further into the network, avoiding potential security breaches.

TCAM1300is programmed with rules for dropping packets. These rules represent a DENY list. It will be appreciated that the TCAM can be programmed with a PERMIT list (not shown) that allows packets to be forwarded.

In some embodiments, for example in strictly private deployments, the network can transmit custom network packets defined according to internal formats using user-defined fields (UDFs) that do not necessarily conform to IEEE standard formats. Although UDFs can still use the same TPID values and EtherType values defined in the IEEE standards, the start position of the TPID and EtherType values in the packet may not be at the standard byte positions (e.g. 12, 16, 20), depending on how where the UDFs are located in the custom network packets. In some embodiments, the pipeline can include an additional parsing stage to parse the packet and store parsed UDFs into corresponding UDF metadata. For example, a UDF may be defined to store a VLAN tag, but rather than starting at byte 12 (e.g., seeFIG.2), the UDF may start at some other byte location in the packet. Accordingly, in some embodiments, the TCAM rules can match on UDF metadata parsed by the parsing stage.

FIG.14shows a pipeline1400comprising a parsing stage1402to parse the ingress packet according to IEEE standards. Parsing stage1402can parse standards-based metadata1404such as the EtherType. Pipeline1400can include a UDF parsing stage1406to parse UDF-defined fields in the packet to produce UDF metadata1408. Standard metadata1404and UDF metadata1408can be used to match on a rule in TCAM1410. A matched rule can then be processed by rules processor1412to produce the egress packet.

FIG.15shows an example of a TCAM1500having rules based on UDF metadata1408as the match criteria. The rules can be based on matching one UDF (e.g., rules1502,1504) or multiple UDFs (e.g., rule1504). The rules can match on the UDF metadata having certain TPID values (e.g., 0x8100, 0x88a8, etc.).

FIG.16shows an example of a TCAM1600that is configured with rules to accommodate a parsing stage that can parse IEEE conforming packets (e.g.,1402,FIG.14) and a parsing stage (e.g.,1406) to parse non-conforming packets having UDFs. If an IEEE conforming packet is parsed, then rules1602,1604may be matched. If non-conforming packets are parsed, then rules1602,1604may not be matched because the UDFs containing any VLAN information of interest may be found elsewhere in the packet. However, rules1606,1608may be matched.

Further Examples

In accordance with the present disclosure, a method in a network device to detect and filter virtual local area network (VLAN) packets, comprises: receiving an ingress packet, the ingress packet containing one or more VLAN tags; determining a starting byte position in the ingress packet based on the one or more VLAN tags contained in the packet; storing into a data store data beginning at the starting byte position in the ingress packet; using data stored in the data store to identify a matched rule among a plurality of rules stored in a memory of the network device; and in response to identifying a matched rule, processing the ingress packet in accordance with one or more actions associated with the matched rule, wherein the one or more actions includes dropping the ingress packet.

In some embodiments, the starting byte position in the ingress packet is determined based on tag protocol identifiers (TPIDs) in the one or more VLAN tags.

In some embodiments, the data beginning at the starting byte position in the ingress packet is interpreted to contain a protocol that describes data contained in a payload of the ingress packet.

In some embodiments, the matched rule is identified when the data in the data store does not represent a protocol that describes data contained in a payload of the ingress packet. In some embodiments, the matched rule is identified when the data in the data store is a tag protocol identifier (TPID) value instead of a protocol that describes the data contained in the payload of the ingress packet.

In some embodiments, the matched rule is identified when the data store contains a TPID value.

In some embodiments, the matched rule is the highest priority rule among a plurality of rules.

In accordance with the present disclosure, a network device comprises: at least one packet processor; and a computer-readable storage medium comprising executable code for controlling the at least one packet processor to: receive an ingress packet comprising one or more VLAN tags and a payload portion; determine a location in the ingress packet based on the one or more VLAN tags in the packet; drop the ingress packet when data beginning at the determined location in the ingress packet does not represent a protocol that describes data in the payload portion; and forward the ingress packet when the data beginning at the determined location in the ingress packet represents a protocol that describes the data in the payload portion.

In some embodiments, the data beginning at the determined location in the ingress packet is interpreted to represent a protocol that describes the data in the payload portion.

In some embodiments, the determined location in the ingress packet is determined based on tag protocol identifiers (TPIDs) in the one or more VLAN tags.

In some embodiments, the ingress packet comprises a plurality of user-defined fields (UDFs), wherein the VLAN tags are located among the UDFs.

In some embodiments, the network device further comprises a memory having stored therein a plurality of rules. The computer-readable storage medium further comprises executable code for controlling the at least one packet processor to: store into a data store the data beginning at the determined location in the ingress packet; use the data stored in the data store to identify a rule from among the plurality of rules; and process the ingress packet in accordance with one or more actions associated with the identified rule, wherein the one or more actions includes dropping the ingress packet. In some embodiments, the identified rule is identified when the data in the data store is a tag protocol identifier (TPID) value. In some embodiments, the identified rule is identified when a VLAN ID in one of the VLAN tags is equal to 0. In some embodiments, the identified rule is the highest priority rule among a plurality of rules.

In accordance with the present disclosure, a network device comprises: at least one packet processor; a content addressable memory having stored therein a plurality of first rules; and a computer-readable storage medium comprising executable code for controlling the at least one packet processor to: receive an ingress packet comprising one or more VLAN tags; store into a data store content in the ingress packet identified based on the one or more VLAN tags in the packet; identify a rule from among the plurality of first rules using data stored in the data store; and process the ingress packet in accordance with one or more actions associated with the identified rule, wherein the plurality of first rules comprise match criteria that match on VLAN tag data.

In some embodiments, the one or more actions associated with the identified rule includes dropping the ingress packet.

In some embodiments, the plurality of first rules are the highest priority rules in the content addressable memory.

In some embodiments, at least one of the plurality of first rules matches on the data in the data store being a TPID value.

In some embodiments, at least one of the plurality of first rules matches on a VLAN ID in one of the VLAN tags being equal to 0.