CN113923138B

CN113923138B - Communication device and network management method

Info

Publication number: CN113923138B
Application number: CN202010646439.7A
Authority: CN
Inventors: 吕国正; 吴俊达; 林玉秀
Original assignee: Realtek Semiconductor Corp
Current assignee: Realtek Semiconductor Corp
Priority date: 2020-07-07
Filing date: 2020-07-07
Publication date: 2023-03-31
Anticipated expiration: 2040-07-07
Also published as: CN113923138A

Abstract

A communication apparatus and a network management method. The communication device is configured to receive a data stream. The communication device comprises a monitoring port and a packet processor. The monitor port is configured to receive packets of a data flow. The packet processor is coupled to the monitor port, wherein the packet processor is configured to calculate a digest value of the packet, calculate an identifier of the packet according to the digest value of the packet, and look up a status value associated with the identifier in a lookup table to determine whether a discard event of the data flow has been recorded.

Description

Communication device and network management method

Technical Field

The present application relates to an electronic device and a management method, and more particularly, to a communication device and a network management method

Background

An Ethernet switch (Ethernet switch) is configured to drop packets (packets) during packet delivery due to the QoS policy or the forwarding mechanism. In this case, the network manager needs to analyze the counter recorded in the Management Information Base (Management Information Base) of each switch according to the network topology to obtain the reason why the packet is discarded. However, when the management information base is transmitted to the central network management layer, the network transmission amount is huge, the problems and the occurrence time points thereof observed by the network management personnel are not always real-time, and the management information base may be lost in the network, which results in the time and reasons that the envelopes cannot be traced and discarded.

Network Telemetry (Network Telemetry) is another method for implementing Network management. However, network telemetry can only look at the content of the original packet, with no experience path and quality of service status of the packet. If the experience path and the service quality state of the packet are desired, additional hardware is required to put the required data into the original packet. However, such an approach costs additional hardware cost and network bandwidth, and there is no uniform standard for the header format of the embedded data in the original packet.

Therefore, how to obtain the time and reason when the packet is discarded and the specific packet content is a technical problem that those skilled in the art want to solve.

Disclosure of Invention

This summary is provided to provide a simplified summary of the disclosure so that the reader can obtain a basic understanding of the disclosure. This summary is not an extensive overview of the disclosure and is intended to neither identify key or critical elements of the embodiments nor delineate the scope of the embodiments.

According to an embodiment of the present application, a communication device configured to receive a data stream includes a monitor port and a packet processor. The monitor port is configured to receive packets of the data flow. The packet processor is coupled to the monitor port, wherein the packet processor is configured to calculate a digest value of the packet, calculate an identifier of the packet according to the digest value of the packet, and look up a status value associated with the identifier in a lookup table to determine whether the discard event associated with the data flow has been recorded.

According to another embodiment, a network management method configured to analyze a data stream is disclosed, the network management method comprising the steps of: receiving a packet of the data stream; calculating a digest value of the packet; and calculating an identifier of the packet according to the digest value of the packet, and searching a state value associated with the identifier in a lookup table to determine whether a discarding event associated with the data stream has been recorded.

Drawings

The following detailed description, when read in conjunction with the accompanying drawings, will facilitate a better understanding of the contents of this disclosure. It should be noted that the various features of the drawings are not necessarily drawn to scale for illustrative purposes. In fact, the dimensions of the various features may be arbitrarily increased or reduced for clarity of illustration.

Fig. 1 shows a schematic configuration of a communication device according to some embodiments of the present application.

Fig. 2 shows a block diagram of a communication device according to some embodiments of the present application.

Fig. 3 is a flow chart illustrating a network management method according to some embodiments of the present application.

FIGS. 4A-4D show schematic diagrams of hashing algorithms according to some embodiments of the present application.

FIGS. 5A-5C show schematic diagrams of lookup tables according to some embodiments of the present application.

Detailed Description

The following disclosure provides many different embodiments for implementing different features of the application. The following describes embodiments of components and arrangements to simplify the present application. Of course, these embodiments are merely exemplary and not limiting. For example, the terms "first", "second", etc. are used in this application to describe components, and are used only for distinguishing the same or similar components or operations, and the terms are not used to limit technical components of the application, nor order or sequence of operations. In addition, the present application may repeat reference numerals and/or letters in the various embodiments, and the same technical terms may use the same and/or corresponding reference numerals in the various embodiments. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

Fig. 1 shows a schematic configuration of a communication device according to some embodiments of the present application. The communication device PE1 stores a destination port forwarding table TB. As shown in fig. 1, the client c1 wants to transmit a data flow DF to the client c2. Normally, the communication device PE1 should forward the data stream to the client c2 through the port P1. The forwarding paths should be communication devices CE1, PE3, PE4, CE2. However, the communication device PE1 may set an error or otherwise discard the packet of the data flow, for example, a virtual local area network filter (Egress VLAN filter) of the output port is set incorrectly, so that the packet is erroneously determined not to be eligible to be discarded through the port P1.

In order to monitor the reason for these packets being dropped, the communication device PE1 may start an event monitoring program.

In some embodiments, as shown in fig. 1, the communication device PE1 is provided with a monitoring port P2. For example, when the packet is dropped by the VLAN filter of the egress port, the packet is redirected to the monitor port P2. At this time, the header of the packet is augmented and modified, and then transmitted to the monitoring center M1, so that the network administrator can pool the discarded packet information for monitoring the discarded packet event.

In other embodiments, the communication device PE1 may configure a monitor port (e.g., the CPU port of the destination port forwarding table TB in fig. 1) to receive the dropped packet for subsequent diagnosis (diagnostic) when the packet is determined to be dropped.

Referring to fig. 2, a block diagram of a communication device 200 according to some embodiments of the present disclosure is shown. As shown in fig. 2, the communication device 200 includes a packet processor 210, a data port 220, a monitor port 230, and a memory 240. The packet processor 210 is coupled to a data port 220, a monitor port 230, and a memory 240. The data port 220 is configured to perform general data packet reception/forwarding. The communication device 200 may have a plurality of data ports 220, and for simplicity, one data port 220 is taken as an example. For example, the communication device 200 receives packets of a data stream through the data port 220. If the communication device 200 determines that the packet should be discarded, it is redirected to the monitor port 230. Monitor port 230 may be monitor port P2 of FIG. 1 or monitor port CPU port.

For further explanation of the communication apparatus 200 of the present application, please refer to fig. 3. Fig. 3 is a flow chart illustrating a network management method according to some embodiments of the present application.

In step S305, a packet of a data flow is received through the data port 220. In some embodiments, packets of the same data stream have the same characteristics. Therefore, the communication device 200 can obtain the data stream to which the packet belongs according to the characteristics of the packet.

In step S310, it is determined whether the packet conforms to a discard event. The discard event may be, but is not limited to, an event that the packet carries mismatched or incorrect information, resulting in that a correct destination port cannot be found, an illegal or suspected packet is intruded, the packet cannot be store and forward (store and forward) due to insufficient memory space of the communication device 200, a lookup table miss (lookup table miss), and the like, and thus the packet is determined to be discarded.

In some embodiments, if the packet is determined not to conform to a discard event, then at step S355, subsequent data forwarding is performed and the packet is sent to the destination location.

When the packet is determined to match the discard event, the packet is redirected to the monitor port 230 in step S315. In some embodiments, packets are stored in memory 240 through monitor port 230. The memory 240 includes a plurality of queues, each queue having a different priority. Depending on the nature of the packets and their priority, the packets are assigned to queues of different priorities after being redirected by the packets. The packet processor 210 reads the packets in the queue according to the priority to perform the subsequent diagnostic procedure (e.g., the packets in the queue with high priority are diagnosed by priority).

In some cases, if a large amount of monitor packets in a burst are redirected to the monitor port 230, i.e. a plurality of packets of the same type of data flow are stored in the memory 240, the communication device 200 needs to process a large amount of the same type of packet diagnosis, which causes a problem of wasting computation resources. To avoid this problem, in some embodiments, the communication device 200 performs a suppression filtering (suppression filter) procedure. In the suppression filter process, only the first packet in the same data stream received by the communication device 200 is redirected to the monitor port 230. If the packet of the same data flow has been diagnosed, the packet will not be redirected to the monitor port 230 if the packet of the data flow has a drop event. Thus, the packet processor 210 only needs to process one packet of the same data stream, and does not waste time and storage space on the discarding event of the same data stream. The inhibition filtration scheme is described below.

First, the communication apparatus 200 classifies data streams. In step S320, a digest value (digest value) of the packet is calculated by the packet processor 210 using the feature value of the packet and the drop event. The characteristic value of the packet may be, but is not limited to, a destination mac address, a source mac address, a destination ip address, a source ip address, an ethernet type, a vlan id, a fourth layer destination port, a fourth layer source port, a packet header, and a packet flow id recorded in the packet.

In some embodiments, the digest value is calculated based on a hash algorithm, a characteristic value of the packet, and a drop event. For example, the packet content is a binary value of length 32 bits. FIGS. 4A-4D show schematic diagrams of hashing algorithms according to some embodiments of the present application.

In some embodiments, as shown in fig. 4A, the hash algorithm may invert the original packet 400 by inverting the most significant bits (most significant bits) of the original packet 400 to the least significant bits (least significant bits) to obtain the packet 401. Then, the XOR operation is performed on the original packet 400 and the packet 401, and the result is the first digest value of the packet 400.

In some embodiments, as shown in fig. 4B, the hash algorithm may invert the original packet 400, resulting in two

inverted packets

403 and 404. Then, the XOR operation is performed on the packet 403 and the packet 404, and the result is the second digest value of the packet 400.

In some embodiments, as shown in fig. 4C, the hash algorithm may divide the original packet 400 into two segments and exchange the order of the two segments to obtain the packet 405. Then, the XOR operation is performed on the packet 405 and the original packet 400, and the operation result is the third digest value of the packet 400.

In some embodiments, as shown in fig. 4D, the hash algorithm may be an exclusive or operation on two packets 405, and the result is the fourth digest value of the packet 400. It should be noted that fig. 4A to 4D are illustrations of embodiments, and the present application is not limited to the hash algorithms.

In step S325, an identifier of the packet is calculated according to the digest value of the packet. For example, the digest value is 32 bits in length. The communication apparatus 200 can allocate 2 ³² Is used to record whether the digest value has already been recorded. However, to save memoryIn step S325, the present application compresses the length of the digest value to reduce the size of the lookup table. The lookup table is used to record the state value associated with the digest value.

In some embodiments, the length of the identifier is less than the length of the digest value. For example, the length of the digest value, e.g., 32 bits, is compressed to, e.g., 14 bits, and the compressed length of the digest value is referred to as an identifier. For example, a 32-bit length digest is divided into three 14-bit segments of data (where only 4 bits of data are in the last segment and the remaining fields are padded with zeros). The identifier of 14 bits in length is obtained by performing an exclusive or operation on the three pieces of data. The identifier corresponds to the address of the lookup table (e.g., address 0 to address 2) ¹⁴ -1). The address of the lookup table is referred to as a status value, which indicates whether a packet corresponding to the digest value has been received (described in detail below). Thus, only configuration 2 is required ¹⁴ The lookup table of size (d) can record the state value of the digest value with length of 32 bits. In other embodiments, the length of the identifier may be equal to the length of the digest value, and the application does not limit the length of the digest value after being compressed.

In step S330, the status value associated with the identifier is looked up in a look-up table. In some embodiments, since the hash algorithm is used to calculate the hash value, there is a possibility that collision may occur due to the data streams being different but calculating the same digest value (hash value). Therefore, the method and the device calculate the plurality of hash values of the same packet to avoid the collision problem. In the embodiment of the present application, four hash algorithms and four lookup tables are used to record the state values corresponding to the digest values of the data streams respectively. However, the present application does not limit the number of the lookup tables, and it is within the scope of the present application to record the state values using two or more lookup tables.

Referring to fig. 5A-5C, schematic diagrams of lookup tables according to some embodiments of the present application are shown. The identifiers generated after the digest values are compressed are calculated by a first hash algorithm 501, a second hash algorithm 502, a third hash algorithm 503, and a fourth hash algorithm 504, respectively, to generate a first hash value, a second hash value, a third hash value, and a fourth hash value. On the other hand, the first lookup table 511 corresponds to the first hash algorithm 501, and is used for recording the first state value at the content pointed to by the address of the first hash value. Similarly, the second lookup table 512 corresponds to the second hash algorithm 502 for recording the second state value at the content pointed to by the address of the second hash value. The third lookup table 513 corresponds to the third hash algorithm 503 for recording the third state value at the content pointed to by the address of the third hash value. The fourth lookup table 514 corresponds to the fourth hash algorithm 504 for recording the fourth state value at the content pointed to by the address of the fourth hash value. The packet processor 210 determines whether the data stream is received according to the four state values. For example, the status value is 0, which represents a discard event that the communication device 200 has not processed the data stream. If the status value is 1, it indicates that the discard event of the data stream has been processed.

In step S335, it is determined whether the status value is equal to an operation value. In some embodiments, the status value is used to determine whether packets of the data flow have been analyzed. It should be noted that the state value may be one or more bits, the number of bits of the state value is not limited in the present application, and the corresponding number of bits may be designed according to the actual number of states, for example, the state value may be a 2-bit value to represent four different states. In this embodiment, the state value is 1 bit. When the status value is 1, it represents that the communication apparatus 200 has analyzed the packet of the data flow, whereas when the status value is 0, it represents that the communication apparatus 200 has not analyzed the packet of the data flow. To simplify the description of the present application, the embodiment with an operation value of 1 is used to describe whether the packet has been analyzed, and one of ordinary skill can design the states and values of different situations according to the actual application.

As shown in fig. 5A, the contents pointed to by the four addresses, i.e., the status values, are 0, and 0, respectively. In other words, the communication device 200 does not analyze the packets of the data stream. Therefore, in step S340, the content of the packet is recorded in the monitoring event. For example, the packet is diagnosed and the diagnostic result is recorded in the monitoring event for the network administrator to refer to. In some embodiments, the contents of a packet include a timestamp when the packet was received, a drop event associated with the packet, an input port and an output port of the packet.

In step S345, the state value is modified to an operation value (e.g., 1). As shown in fig. 5B, the status values corresponding to the identifiers in the first lookup table to the fourth lookup table are all modified to 1, in step S350, which represents that the situation that the data flow has dropped the packet has been recorded.

In some embodiments, steps S305 to S330 are executed, the monitor port 230 receives a packet of a data flow, and a status value corresponding to the packet is correspondingly calculated. In step S335, if it is determined that the status values in the first lookup table to the fourth lookup table are all 1, as shown in fig. 5B, indicating that the packet discarding of the data flow is already recorded, the packet is discarded. This packet will not be subjected to a diagnostic procedure (e.g., forwarded to a monitoring center or logged to a monitoring event).

It should be noted that, if it is determined in step S335 that the state values of only a part of the lookup tables are 1 (for example, the state value of the first lookup table is 1, and the state values of the second to fourth lookup tables are 0), as shown in fig. 5C, it indicates that a collision occurs, and the communication apparatus 200 still processes the discarding event of the data stream. For example, the first packet of the first data flow computes a hash value 3173 via a first hash algorithm, and the contents of the address 3173 have been modified to 1 in a previous drop event. However, the second packet of the second data flow also computes a hash value 3173 using the first hash algorithm. When the state values corresponding to the hash values calculated by the second hash algorithm to the fourth hash algorithm of the second data stream are all 0, the hash values of the first packet and the second packet collide with each other. In effect, the second data stream is not processed by the communication device 200. At this time, the communication device 200 still processes the drop event of the second data stream. In this way, the hash algorithms can reduce the probability of misjudging whether the data stream is processed.

In some embodiments, the communication apparatus 200 sets a time-valid value (aging) to the digest value of the data stream. For example, if the age value of the digest value of the data stream exceeds a threshold (e.g., the age value is counted up to a threshold 255) or is below a threshold (e.g., the age value is counted down to a threshold 0), the state value in the lookup table is cleared. Thus, memory space can be freed up to record the state values of the new data stream. For another example, the communication device 200 periodically clears all status values in the lookup table (e.g., every day). Therefore, the lookup table can record the state value along with the periodicity of the data stream, and the use efficiency is improved.

In summary, the communication device and the network management method of the present application do not need to set additional hardware cost to embed the required management information into the packet (reduce chip cost), and the network administrator only needs to modify the settings on the communication device and forward the packet to the processor or the specific port, so as to monitor the discarded packet. In addition, when a packet discarding event occurs, the communication device records the management information base and the statistical counter, and also stores the packet, the reason and the timestamp of the problem, and only needs to record once (reducing the load of the processor) to generate an analysis report for further investigation and testing by network management personnel, so as to reduce the time of debugging process.

The foregoing outlines features of several embodiments so that those skilled in the art may better understand the present disclosure. Those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced herein without departing from the spirit and scope of the present application. The above should be understood as examples of the present application and the scope of protection should be determined by the claims.

[ description of reference numerals ]

c1, c2 client

DF data flow

CE1, CE2 communication device

PE1, PE2, PE3, PE4 communication device

M1 monitoring center

TB destination port forwarding table

P0, P1, P2, CPU port

200 communication device

210 packet processor

220 data port

230 monitor port

240 internal memory

400 original packet

401-405, packet

501-504 Hash Algorithm

511-514 lookup tables

S305 to S355 step

Claims

1. A communication device configured to receive a data stream, the communication device comprising:

a monitor port configured to receive a packet of the data flow; and

a packet processor coupled to the monitor port, wherein the packet processor is configured to calculate a digest value of the packet, calculate an identifier of the packet according to the digest value of the packet, look up a status value associated with the identifier in a lookup table to determine whether a discard event associated with the data flow has been recorded, and discard the packet if a discard event associated with the data flow has been recorded.

2. The communication device of claim 1, wherein the monitor port is further configured to receive the packet that matches the drop event, wherein the packet processor is further configured to receive the packet from the monitor port, and wherein the digest value of the packet is calculated using a characteristic value of the packet and the drop event before dropping the packet.

3. The communications device of claim 2, wherein the packet processor is further configured to compress the digest value having a first length into the identifier having a second length, wherein the second length is less than or equal to the first length.

4. The communications device of claim 2, wherein the packet processor is further configured to calculate a first digest value of the packet based on the feature value of the packet and the drop event using a first hashing algorithm, and the packet processor calculates a second digest value of the packet based on the feature value of the packet and the drop event using a second hashing algorithm.

5. The communications device of claim 4, wherein the packet processor is further configured to compress the first digest value into a first identifier and compress the second digest value into a second identifier.

6. The communications device of claim 5, further comprising:

a memory coupled to the packet processor, wherein the memory is configured to store a plurality of lookup tables, wherein the lookup tables include a first lookup table and a second lookup table, the first lookup table corresponding to the first hash algorithm and the second lookup table corresponding to the second hash algorithm.

7. The communications device of claim 6, wherein the memory further comprises a plurality of queues, each of the queues configured to temporarily store the packets of the data flow that meet the drop event, such that the packet processor reads the packets of each of the queues according to a priority of each of the queues.

8. The communications device of claim 6, wherein the packet processor is further configured to look up a first status value associated with the first identifier in the first lookup table to determine whether the first status value is an operational value, and to look up a second status value associated with the second identifier in the second lookup table to determine whether the second status value is the operational value.

9. The communications device of claim 8, wherein the packet processor is further configured to record the contents of the packet in a monitoring event and modify the first state value of the first lookup table to the operation value and modify the second state value of the second lookup table to the operation value if it is determined that the first state value is not the operation value and/or the second state value is not the operation value.

10. A network management method configured to analyze a data stream, the network management method comprising: receiving a packet of the data stream;

calculating a digest value of the packet; and

calculating an identifier of the packet according to the digest value of the packet, and looking up a state value associated with the identifier in a lookup table to determine whether a discard event associated with the data flow has been recorded.