CN109309605B - In-band network telemetry system and method - Google Patents
In-band network telemetry system and method Download PDFInfo
- Publication number
- CN109309605B CN109309605B CN201811415877.1A CN201811415877A CN109309605B CN 109309605 B CN109309605 B CN 109309605B CN 201811415877 A CN201811415877 A CN 201811415877A CN 109309605 B CN109309605 B CN 109309605B
- Authority
- CN
- China
- Prior art keywords
- data packet
- layer
- network
- packet
- analysis
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses an in-band network remote measuring system and a method, wherein the system comprises: the data packet capturing module is used for capturing a data packet of a data link layer, performing layer-by-layer header analysis operation on the data packet, and sending the data packet to a network layer, a transmission layer and an application layer for processing to obtain a processed data packet; the analysis and statistics module is used for carrying out IP address analysis, TCP/UDP and fracture analysis, statistical analysis and protocol analysis on the processed data packet at a network layer, a transmission layer and an application layer so as to obtain the time delay information of the data packet; and the packet changing module is used for changing the checksum area of the analyzed data packet header, printing the time delay information on the data packet and outputting the time delay information to the main control host. The system can monitor the network in real time, reduce labor cost, get rid of dependence on a special chip, modify bottom layer software and enhance functional applicability.
Description
Technical Field
The invention relates to the technical field of data communication, in particular to an in-band network telemetering system and an in-band network telemetering method.
Background
With the continued development of internal networks, network administrators are becoming increasingly important to keep track of the different types of traffic traversing the network. The purpose of the network remote sensing technology is to obtain information about network operation state and communication behavior between networks, wherein the information comprises static information related to configuration and dynamic information related to network time. Traffic remote sensing and analysis are important for more efficient troubleshooting and troubleshooting to avoid long-term hesitation of network services. Many tools are available to assist administrators in monitoring and analyzing network traffic. While network monitoring is a difficult and daunting task, network administrators are constantly striving to keep the network running smoothly. If a network is left alone for some time, the company's productivity may drop, and in the case of a public service department, the ability to provide basic services may be compromised. To remain active, rather than passive, an administrator needs to monitor traffic movement and performance throughout the network and verify that there are no security concerns in the network.
Barefoot Deep Insight is the first network monitoring system in the world to have a comprehensive understanding of each packet in the network. Its software runs on a commercial server, interprets, analyzes and queries various conditions that may impede the flow of packets, and proceeds in real-time and at line speed. The intelligent programmable triggering mechanism only allows interesting network events to be monitored and reported in real time, and irrelevant data is automatically filtered out. Machine learning can be used to achieve a state baseline of network performance and automatically detect anomalies at any time scale and nanosecond resolution.
It provides four basic facts for each packet in the network:
1: how to reach here? The sequence of devices along which the data packet follows its access path.
2: why do it go here? The data packet is a set of rules that each device along the path matches.
3: how much delay is there? The time in nanoseconds the packet is buffered in each switch.
4: why is there a delay? Packets, flows and applications that are shared by the packets with each queue.
Deep Insight can detect almost any anomaly in the network, it can detect a microburst, it can identify which application causes congestion, whether the packet is part of the network to which it does not belong, and whether the equivalent route ((empirical Class of materials and Physics, ECMP) is not balanced load balancing, it can even provide the operator with packets that are dropped individually and account for their dropping.
In the related art, a Software Defined Network (SDN) is an architecture aiming at making a Network flexible and flexible. In a software defined network, a network engineer or administrator can adjust the flow from a centralized console without touching individual switches in the network. Regardless of the specific connection between the server and the device, the centralized SDN controller instructs the switch to provide network services wherever needed. This process is remote from traditional network architectures where each network device makes traffic decisions based on its configured routing table.
As shown in fig. 1, a typical representation of an SDN architecture includes three layers: an application layer, a control layer, and an infrastructure layer. The application layer contains typical network applications or functions used by an organization, including intrusion detection systems, load balancing, or firewalls, among others. The control layer represents centralized SDN controller software, acting as the brain of a software defined network, which resides on a server, managing policies and traffic throughout the network. The infrastructure layer consists of physical switches in the network. The three layers communicate using respective northbound and southbound Application Programming Interfaces (APIs).
SDNs encompass multiple types of technologies including functional separation, network virtualization, and automation through programmability. SDN technology separates the network control plane from the data plane, which actually moves data packets from place to place when the control plane decides how they should flow through the network. Software-defined networks use what is sometimes referred to as an adaptive or dynamic mode of operation, in which switches issue routing requests to controllers for packets that do not have a particular route. This process is separate from adaptive routing, which issues routing requests through routers and algorithms based on the network topology, rather than through the controller. The virtualization aspect of SDN functions through a virtual overlay, which is a logically independent network over a physical network. Users can implement end-to-end coverage to abstract underlying network and segmented network traffic.
P4 is a high-level language for programming protocol independent packet processors. The P4 is used in cooperation with an SDN control protocol such as Open Flow, and the like, so that the abstraction level of network programming is improved, and the P4 can be used as a general interface between a controller and a switch.
The P4 language uses the Open Flow match-behavior Flow processing model. In this method, when a data item carried by a data packet matches a particular key, the data packet is modified according to the content of the action item. Language usage can efficiently describe match-behavior flows.
As shown in fig. 2, P4 is used to describe or specify data plane behavior and is not used to implement a data plane. Depending on system/device flexibility/complexity requirements, the data plane may run on fixed function ASICs (e.g., layer 2 switch ASICs) or on fully programmable general purpose CPUs (routers, Web proxy servers and firewalls). The P4 language has three main goals: (1) reconfigurability: the programmer should be able to change the way the switch processes the packets after deployment. (2) Protocol independence: the switch should not be bound to any particular network protocol. (3) Target independence: the programmer should be able to describe the packet processing functions independently of the specifics of the underlying hardware.
As shown in fig. 3, in-band networking telemetry (INT) is a new abstraction that allows packets to query switch internal states such as queue size, link utilization and queuing latency without interfering with the control plane CPU or causing additional delays, and can be economically and efficiently implemented in packet-level data plane telemetry.
Generally, INT relies on a probe packet having a variable length label stack retained in the packet header. The detection message is periodically generated at the network edge and is injected into the network core, and the detection message and the common flow are queued and forwarded together. In each router/switch along the forwarding path, the probe packet will extract the device internal state and push it to the INT label stack. At the last hop, the edge device will forward the probe packet with the end-to-end INT information to the remote controller for further analysis.
There are still many disadvantages in the related art, such as:
(1) hardware for the corresponding function needs to be specially designed. Each designed switch/router chip has its own low-level interface, similar to microcode programming, that is not applicable to other switches/routers. It is not easy to design and program a new switch chip with high efficiency, and the update cycle is limited in many ways.
(2) The designed hardware equipment has single function and weak compatibility.
(3) The details of the bottom layer are complicated, programming by software engineers is not facilitated, codes are not open, the technology is closed, and promotion and expansion are not facilitated.
(4) Because the system is limited by hardware, the update cycle is long, the versions are various, and the price is high
Disclosure of Invention
The present invention is directed to solving, at least to some extent, one of the technical problems in the related art.
Therefore, an object of the present invention is to provide an in-band network telemetry system, which can monitor a network in real time, reduce labor cost, get rid of dependence on a dedicated chip, modify underlying software, and enhance functional applicability.
Another object of the present invention is to provide an in-band network telemetry method.
In order to achieve the above object, an embodiment of the present invention provides an in-band network telemetry system, including: the data packet capturing module is used for capturing a data packet of a data link layer, performing layer-by-layer header analysis operation on the data packet, and sending the data packet to a network layer, a transmission layer and an application layer for processing to obtain a processed data packet; the analysis and statistics module is used for carrying out IP address analysis, TCP/UDP and fracture analysis, statistical analysis and protocol analysis on the processed data packet at the network layer, the transmission layer and the application layer so as to obtain the time delay information of the data packet; and the packet changing module is used for changing the analyzed checksum area of the data packet header, printing the time delay information on the data packet and outputting the time delay information to the main control host.
The in-band network telemetry system of the embodiment of the invention adds a classifier, a filter and the like on bottom layer software through programming to screen and filter required data packets, then carries out statistics of the network, prints the information on the data packets, finally modifies the packet header and forwards, encapsulates hardware details and is beneficial to programming.
In addition, the in-band network telemetry system according to the above embodiment of the present invention may have the following additional technical features:
further, in an embodiment of the present invention, the data packet capturing module is further configured to send the data packet to a higher-layer network stack for processing through a queuing rule after the data packet is received through a network card device driver, and perform program mounting at an entry of the processed data packet, and record a first system time for a system to call an entry processing function; and sending the data packet to a network layer or above, sending the data packet to a physical layer after the data packet is processed, carrying out program mounting on the data packet at an exit queue entrance, recording second system time for calling an exit processing function by a system, and sending the data packet from the network card equipment driver.
Further, in an embodiment of the present invention, the analysis statistics module is further configured to determine whether the data packet is a UDP packet transmitted through the IPV4, wherein if the data packet is the UDP packet transmitted through the IPV4, a source address and a destination address of the data packet are obtained.
Further, in an embodiment of the present invention, the analysis statistic module is further configured to check a checksum of the data packet, wherein if the checksum passes, the data packet is sent and/or accepted.
Further, in an embodiment of the present invention, the analysis and statistics module is further configured to obtain an IP header portion of the data packet, and determine whether the IP header portion is the same as a protocol number of the IPV4 according to a protocol field in an sk _ buff structure; if the protocol number of the data packet is the same as the protocol number of the IPV4, checking a transmission layer packet header of the data packet, and judging whether a UDP protocol field in sk _ buff is the same as the protocol number of the UDP data packet or not; and if the protocol number of the data packet is the same as the protocol number of the UDP data packet, judging whether the destination port number of the data packet is 8888, wherein if the destination port number of the data packet is 8888, recording the arrival system time of the data packet.
In order to achieve the above object, an embodiment of another aspect of the present invention provides an in-band network telemetry method, including: s1, capturing a data packet of a data link layer, performing layer-by-layer header analysis operation on the data packet, and sending the data packet to a network layer, a transmission layer and an application layer for processing to obtain a processed data packet; s2, performing IP address analysis, TCP/UDP and fracture analysis, statistical analysis and protocol analysis on the processed data packet at the network layer, the transmission layer and the application layer to obtain the time delay information of the data packet; s3, modifying the checksum area of the analyzed data packet header, printing the time delay information on the data packet, and outputting the time delay information to the main control host.
The in-band network telemetry method of the embodiment of the invention adds a classifier, a filter and the like on bottom layer software through programming to screen and filter required data packets, then carries out statistics of the network, prints the information on the data packets, finally modifies the packet header and forwards, encapsulates hardware details and is beneficial to programming.
In addition, the in-band network telemetry method according to the above embodiment of the present invention may further have the following additional technical features:
further, in an embodiment of the present invention, S1 further includes: s101, after receiving the data packet through a network card device driver, sending the data packet to a high-level network stack for processing through a queuing rule, carrying out program mounting at an entrance of the processed data packet, and recording first system time for calling an entrance processing function by a system; and S102, sending the data packet to a network layer and above, sending the data packet to a physical layer after the data packet is processed, carrying out program mounting on the data packet at an exit queue entrance, recording second system time for calling an exit processing function by a system, and sending the data packet from the network card device driver.
Further, in an embodiment of the present invention, S2 further includes: and interrupting whether the data packet is a UDP packet transmitted by the IPV4, wherein if the data packet is the UDP packet transmitted by the IPV4, the source address and the destination address of the data packet are obtained.
Further, in an embodiment of the present invention, S2 further includes: and checking the checksum of the data packet, wherein if the check is passed, the data packet is sent and/or accepted.
Further, in an embodiment of the present invention, S2 further includes: acquiring an IP head part of the data packet, and judging whether the IP head part is the same as the protocol number of the IPV4 according to a protocol field in an sk _ buff structure; if the protocol number of the data packet is the same as the protocol number of the IPV4, checking a transmission layer packet header of the data packet, and judging whether a UDP protocol field in sk _ buff is the same as the protocol number of the UDP data packet or not; and if the protocol number of the data packet is the same as the protocol number of the UDP data packet, judging whether the destination port number of the data packet is 8888, wherein if the destination port number of the data packet is 8888, recording the arrival system time of the data packet.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
The foregoing and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
FIG. 1 is a SND architecture diagram;
FIG. 2 is a diagram of the P4 processing mode;
FIG. 3 is an on-demand in-band network telemetry diagram routed through a source;
FIG. 4 is a schematic diagram of an in-band network telemetry system according to one embodiment of the present invention;
FIG. 5 is a schematic diagram of an in-band network telemetry system according to an embodiment of the present invention;
FIG. 6 is a diagram of a data packet capture architecture according to one embodiment of the present invention;
FIG. 7 is a schematic diagram of a sk _ buff structure according to an embodiment of the invention;
FIG. 8 is a flow diagram of packet analysis according to one embodiment of the present invention;
FIG. 9 is a recomputation checksum diagram according to one embodiment of the invention;
fig. 10 is a flow diagram of an in-band network telemetry method according to one embodiment of the invention.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
The in-band telemetry designed by the invention is a data plane technology which can acquire low-level queuing delay information of network equipment in real time. The technology can record the state information of the hop-by-hop switch equipment through which the data packet passes in the data packet and transmit the data packet to the centralized controller, and helps the controller to analyze the network state in real time. A network protocol stack real-time measurement mechanism based on an X86 universal server is provided, and can be used for network function virtualization, such as in a cloud computing environment like docker, and the like, and provides the capability of realizing network in-band telemetry by modifying low-layer software in a Linux router.
From the basic theory of the network traffic telemetry system, the essential content development trend of network telemetry is analyzed, a novel Linux router-based in-band network telemetry technology design is provided, and an eBPF technology is used in the embodiment of the invention.
The remote measuring system of the embodiment of the invention researches the basic function requirement and the performance requirement of the network flow remote measuring system, designs the network flow real-time dynamic remote measuring model and analyzes the transmission delay condition of the UDP data packet in the self-built network at the same time. Basically, in the requirement analysis, the design requirement is carried out on the network flow remote sensing system, then the overall design, the function and the structure design and the network topology design are carried out on the network system, and a system model is constructed by utilizing the UML. In order to meet the requirement of a centralized control system, a network environment information main control host is added in a given network topology, and a system which screens given data packets, prints delay information on the packet body and collects the data packets with special functions is designed.
Hereinafter, an in-band network telemetry system and method according to an embodiment of the present invention will be described with reference to the accompanying drawings, and first, an in-band network telemetry system according to an embodiment of the present invention will be described with reference to the accompanying drawings.
Fig. 4 is a schematic diagram of an in-band network telemetry system according to an embodiment of the invention.
As shown in fig. 4, the in-band network telemetry system 10 includes: a capture packet module 100, an analysis statistics module 200, and a change packet module 300.
As shown in fig. 5, the capture packet module 100 is configured to capture a packet of a data link layer, perform layer-by-layer header parsing on the packet, and send the packet to a network layer, a transmission layer, and an application layer for processing, so as to obtain a processed packet. The analysis and statistics module 200 is configured to perform IP address analysis, TCP/UDP and fracture analysis, statistical analysis, and protocol analysis on the processed data packet at the network layer, the transport layer, and the application layer to obtain the delay information of the data packet. The packet modification module 300 is configured to modify a checksum area of the analyzed packet header, print the delay information on the packet, and output the delay information to the host. The remote measuring system 10 can monitor the network in real time, reduce labor cost, get rid of dependence on a special chip, modify bottom layer software and enhance functional applicability.
Further, in the embodiment of the present invention, the data packet capturing module 100 may be further configured to send the data packet to a higher-layer network stack for processing after receiving the data packet through the network card device driver and passing through a queuing rule, mount a program at an entry of the processed data packet, and record a first system time for a system to call an entry processing function; and sending the data packet to a network layer and the network layer, sending the data packet to a physical layer after the processing is finished, carrying out program mounting on the data packet at an exit queue entrance, recording the second system time of calling an exit processing function by the system, and sending the data packet from a network card device driver.
Specifically, data monitoring and traffic remote sensing are mainly performed by network managers, the high efficiency and accuracy of practical application are studied, and a large amount of work of the system is focused on capturing and analyzing network data packets. After the network card device driver receives the data and passes through a series of queuing rules, the data is sent to a higher-layer network stack for continuous processing, program mounting is carried out at an entrance of a processing packet, and the system time of the system for calling the processing function is recorded as t 1. After that, the data packet is sent to the network layer and above, and after the processing is finished, the data packet is sent to the physical layer again. When it reaches the exit queue entry, where the same procedure is mounted, the system time for the system to call the exit handling function is recorded as t2, and finally the packet is sent from the device. As shown in fig. 6, the processing delay of the data packet in the system is:
further, during the process of capturing the data packet, a series of header parsing operations layer by layer need to be performed on the data packet. The important structure needing to be operated is a sk _ buff structure, and several important fields are compared as follows: unused chard head, unused chard end, unused chard data, and unused char tail, these fields represent the boundaries of the buffer and the data therein. As each layer prepares the buffer for its work, more space may be allocated for one header or more data. head and end point to the beginning and end of the allocated buffer space, while data and tail point to the beginning and end of the actual data. The data area really containing the transmission content and the transmission protocol is pointed to by a plurality of pointers in the sk _ buff structure, which is called the data area for short, and the size is as follows: (skb- > end-skb- > head); the size is fixed for each data packet, and the addresses pointed by the two pointers are not changed in the transmission process, and the data area is used for storing data sent by an application layer and protocol information of each layer. The relationship between the pointer and the data area in the sk _ buff structure is shown in fig. 7.
To obtain the protocol information of each layer in the sk _ buff structure, the protocol information may be implemented by pointer address offset, and the address representation manner is as follows:
(1) iph ═ struct iphdr (skb- > head + skb- > network _ head); this pointer points to the packet ip header structure.
(2) (u64) iph + offset of (struct iphdr, protocol); the address is added with a segment of offset on the basis of the ip head address, and points to the ip layer protocol.
(3) (u64) iph + offset of (struct iphdr, id)); the address adds a section of offset on the basis of the ip head address, points to the identification id of the ip data packet, and the id number is used for counting whether the packet passes through the network.
Table 1 shows a function of loading a background code written in the C language into the eBPF program, where when a system function ip _ rcv is called, the eBPF program calls an rx function written in the C language; similarly, when the system functions dev _ queue _ xmit and ip _ output are called, the eBPF program calls the iprcv and ipoutput functions, respectively. The egr function is then loaded into the egress flow control area in the form of SCHED _ CLS, "sfq", and snoops on the network card port ens33, followed by the addition of a previously written eBPF filter at the egress flow control.
TABLE 1
Table 2 shows one of the processing functions in the eBPF program, which defines a delay structure, prepares to store the system time and delay information of the cubic function call and initializes the system time and delay information to 0, and then combines the counts and delay structures by using the MAP mechanism of the BPF, thereby realizing the intercommunication between the kernel and the user mode. The bpf _ probe _ read function is used for reading a protocol number and an id number of a data packet and judging the protocol number and the id number by a safe mechanism; lookup _ or _ init function searches the data packet id number in the counts, if yes, assigns the data packet id number to a val variable, and if not, initializes the data packet id number to 0; the bpf _ ktime _ get _ ns function may obtain the system time.
TABLE 2
Further, as shown in fig. 8, when a packet passes through a predetermined hooking function, the eBPF program parses the packet and determines the protocol headers of each layer.
Specifically, the IP header part of the data packet is firstly obtained, the protocol number of the IPV4 is 0x0800, whether the IP header part is IPV4 or not is judged according to the protocol field in the sk _ buff structure, and if yes, the next judgment is carried out; if not, filtering; secondly, checking a transmission layer packet header, wherein the protocol number of a UDP data packet is 17, and similarly, according to whether a UDP protocol field in the sk _ buff is 17, if so, entering next-layer screening, and if not, filtering; then, it is determined whether the destination port number is 8888, which is normally idle, and the data packet addressed to the port can be regarded as an INT packet as a special filtering method. A packet that meets the above criteria will record the system time of arrival of the packet at that time.
As shown in fig. 9, the INT packet with special flag is found and the system time is recorded, what needs to be solved is how to print the delay information onto the data packet so that the information can be transmitted to the master host. The data packet is transmitted and received by checking the checksum of the data packet, if the data packet is correct, the data packet is received, otherwise, the data packet is discarded. The checksum of the IP datagram only checks the header of the datagram, the method of calculating the checksum of the UDP datagram is similar to that of the IP datagram,
however, the checksum in UDP is that both the header and the data portion are checked together and a dummy header needs to be encapsulated before the UDP checksum is calculated.
Function(s)
if(bpf_ntohs(skb->protocol)＝＝0x0800&&ip p＝＝17)
And judging whether the received data packet is a UDP packet transmitted by the IPV4, if so, performing the next acquisition of the source address and the destination address of the data packet, otherwise, not performing operation to find out the corresponding specific data packet.
Table 3 is a specific function of the acquisition information.
TABLE 3
Further, after the task of capturing the data packet is completed, the system time needs to be displayed, the time difference between the two times is obtained to obtain the time delay information, and then the time delay information is printed in the payload area, and meanwhile, the checksum area of the header of the data packet is modified. Since the function implementation of bpf is used in recalculating checksum, there is still a certain need to know the calculation method. Mainly comprises the following steps:
(1) firstly, setting 0 to be the checksum in the checksum data to be calculated;
(2) calculating the data of the checksum, dividing the data according to 2 bytes, forming a 16-bit value by every 2 bytes, and if the data of a single byte exists at last, complementing 0 of one byte to form 2 bytes;
(3) adding all 16-bit values to a 32-bit value;
(4) adding the upper 16 bits and the lower 16 bits of the 32-bit value to a new 32-bit value, and if the new 32-bit value is greater than 0xffff, adding the upper 16 bits and the lower 16 bits of the new value;
(5) and (4) inverting the 16-bit value obtained by the calculation in the previous step according to bits to obtain a checksum value, and storing the checksum value into a checksum field of the data.
The function prototype is: static u64bpf _14_ csum _ replace (u64r1, u64r2, u64from, u64to, u64flags), where the first parameter is typically the buffer structure skb, the second parameter is the relative offset that needs to be recalculated for the checksum position, the third parameter is the previous value to be modified, the fourth parameter is the modified value, and the last parameter is the size of the modified value. Table 4 shows key codes for implementing this function, when an ip packet is forwarded in a network in one hop, the value of the ttl field is decremented by one, and by using its property, the router tuning number that it experiences can be calculated, and the offset corresponding to the position of the print delay information can be calculated. Firstly copying the value in the payload area in the skb structure into oldTime, then comparing the value with Prime and recalculating the value of checksum, and secondly replacing a segment of the value of the original payload area with the value of Prime.
TABLE 4
The network environment is complicated and changeable, the network conditions are good and irregular, the network delay is frequent, the network congestion is suddenly blocked, and if the network congestion cannot be timely processed, great economic loss is brought to production workers and users, and even the personal safety is threatened. Meanwhile, a large amount of practical data is contained in the network, such as the time delay of each link, the packet queuing condition, and the like, which are information that can be used to express the network state. The in-band telemetry system of the embodiment of the invention can dynamically monitor the network state in real time in a extensive network environment, can know the network running state in real time on an independent observation host, displays the network state in a silent mode when no network problem exists, and starts an alarm when the network is abnormal, thereby saving various labor costs and preventing risks.
And the dependence on a special chip can be eliminated, the bottom layer software can be modified, and the functional applicability is enhanced. In the prior art, only hardware with specially designed single function supports dynamic in-band telemetry technology, for example, Barefoot Instrument realized by INT technology, and the designed bottom layer hardware meets corresponding requirements, needs a large amount of manual participation, is not beneficial to reform and update, and is not beneficial to function expansion. The Ebpf technology used by the embodiment of the invention is an open-source technology which basically modifies bottom layer software, has strong portability, is convenient for programmers to program and update and is applied to vast switch/router equipment.
In summary, the technology of the embodiment of the present invention implements a dynamic in-zone network telemetry mechanism by mounting a function hook to a corresponding system function through an Ebpf technology in a router based on a Linux protocol stack. The fixed-point positioning monitoring function is completed, a system acquisition kernel time stamp data information module is designed, the time for the data packet to pass through the router can be accurately recorded, finally, the data packet module can be modified and recorded through P4 and related technologies, and the appointed data packet is sent to a set port with a set main control host.
The Linux network protocol stack is the operation foundation of the technology, and provides a safe and friendly development environment. The TCP/IP protocol stack is the most popular network architecture at present, is the sum of a series of network protocols, and is the core framework for constituting network communication, and defines the way of connecting electronic equipment into the internet and the method for transmitting data in the internet. The TCP/IP protocol architecture adopts a 5-layer structure, which is an application layer, a transport layer, a network layer, a link layer, and a physical layer. Each layer is transparent to the layer above it, and each layer relies on the protocol provided by the next layer to fulfill its own needs.
The Extendedbpf technology is derived from the completely new design of BPF basic architecture, on one hand, it has been practical in performance tuning/monitoring, Kernel tracking (Kernel tracking), Traffic monitoring (Traffic Control), etc., and on the other hand, eBPF has achieved boundary security in the design and ease of use of programming interface. An application in the user space develops a self-contained space in a kernel to establish a database for interacting with a BPF program (BPF _ create _ map ()); the database itself is built in the form of key-value pairs, which can be accessed both from the user space and from the kernel space, with similar interfaces on both sides, and logically the same end. The Map mechanism brings great advantage of high efficiency, and simultaneously enriches the diversity of communication data.
According to the in-band network telemetry system provided by the embodiment of the invention, a classifier, a filter and the like are added on bottom layer software through programming to screen and filter required data packets, then statistics is carried out on the network, information of the data packets is printed on the data packets, finally, packet headers are modified and forwarded, hardware details are encapsulated, and the in-band network telemetry system is beneficial to programming.
Next, an in-band network telemetry method proposed according to an embodiment of the present invention is described with reference to the accompanying drawings.
Fig. 10 is a flow diagram of an in-band network telemetry method according to an embodiment of the invention.
As shown in fig. 10, the in-band network telemetry method includes:
in step S1, a data packet of the data link layer is captured, a layer-by-layer header parsing operation is performed on the data packet, and the data packet is sent to the network layer, the transport layer, and the application layer for processing, so as to obtain a processed data packet.
Further, in an embodiment of the present invention, S1 may further include: s101, after receiving a data packet through a network card device driver, sending the data packet to a high-level network stack for processing through a queuing rule, carrying out program mounting at an entrance of the processed data packet, and recording first system time for a system to call an entrance processing function; s102, sending the data packet to a network layer and above, sending the data packet to a physical layer after the processing is finished, carrying out program mounting on the data packet at an exit queue entrance, recording second system time of calling an exit processing function by a system, and sending the data packet from a network card device driver.
In step S2, after the network layer, the transport layer, and the application layer perform IP address analysis, TCP/UDP and fracture analysis, statistical analysis, and protocol analysis on the processed data packet, so as to obtain the delay information of the data packet.
Further, in an embodiment of the present invention, S2 may further include: and judging whether the data packet is a UDP packet transmitted by the IPV4, wherein if the data packet is the UDP packet transmitted by the IPV4, the source address and the destination address of the data packet are obtained.
Further, in an embodiment of the present invention, S2 may further include: and checking the data packet for a checksum, wherein if the check is passed, the data packet is sent and/or accepted.
Further, in an embodiment of the present invention, S2 may further include: acquiring an IP head part of the data packet, and judging whether the IP head part is the same as the protocol number of the IPV4 according to a protocol field in the sk _ buff structure; if the protocol number of the data packet is the same as the protocol number of the IPV4, checking a transmission layer packet head of the data packet, and judging whether a UDP protocol field in the sk _ buff is the same as the protocol number of the UDP data packet or not; if the protocol number of the data packet is the same as the protocol number of the UDP data packet, judging whether the destination port number of the data packet is 8888, wherein if the destination port number of the data packet is 8888, recording the arrival time of the data packet at the system.
In step S3, the checksum area of the analyzed packet header is modified, and the latency information is printed on the packet and output to the master host.
It should be noted that the foregoing explanation of the embodiment of the in-band network telemetry system also applies to the method of the embodiment, and is not repeated here.
According to the in-band network telemetry method provided by the embodiment of the invention, a classifier, a filter and the like are added on bottom layer software through programming to screen and filter required data packets, then network statistics is carried out, information of the data packets is printed on the data packets, finally, packet headers are modified and forwarded, hardware details are encapsulated, and the in-band network telemetry method is beneficial to programming.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.
Claims (8)
1. An in-band network telemetry system, comprising:
the data packet capturing module is used for capturing a data packet of a data link layer, performing layer-by-layer header analysis operation on the data packet, and sending the data packet to a network layer, a transmission layer and an application layer for processing to obtain a processed data packet; the method specifically comprises the following steps:
after the network card device driver receives the processed data packet, the data packet is sent to a network stack of a higher layer for continuous processing through a series of queuing rules, program mounting is carried out at an inlet of the processing packet, the system time of the system for calling the processing function is recorded as t1, then the data packet is sent to the network layer and the upper layer, the data packet is sent to the physical layer again after the processing is finished, when the data packet reaches an outlet queue inlet, the program mounting is carried out in the same way, the system time of the system for calling the outlet processing function is recorded as t2, finally the data packet is sent from the device, and the processing delay of the data packet in the system is as follows:
the analysis and statistics module is used for carrying out IP address analysis, TCP/UDP and port analysis, statistical analysis and protocol analysis on the processed data packet at the network layer, the transmission layer and the application layer so as to obtain the time delay information of the data packet; and
and the packet changing module is used for changing the analyzed checksum area of the data packet header, printing the time delay information on the data packet and outputting the time delay information to the main control host.
2. The in-band network telemetry system of claim 1, wherein the analysis statistics module is further configured to determine whether the data packet is a UDP packet transmitted via IPV4, wherein if the data packet is the UDP packet transmitted via IPV4, a source address and a destination address of the data packet are obtained.
3. The in-band network telemetry system of claim 1, wherein the analytics statistics module is further configured to check a checksum of the data packet, wherein the data packet is transmitted and/or received if the checksum passes.
4. The in-band network telemetry system of claim 1, wherein the analysis statistics module is further to,
acquiring an IP head part of the data packet, and judging whether the IP head part is the same as the protocol number of the IPV4 according to a protocol field in an sk _ buff structure;
if the protocol number of the data packet is the same as the protocol number of the IPV4, checking a transmission layer packet header of the data packet, and judging whether a UDP protocol field in sk _ buff is the same as the protocol number of the UDP data packet or not;
and if the protocol number of the data packet is the same as the protocol number of the UDP data packet, judging whether the destination port number of the data packet is 8888, wherein if the destination port number of the data packet is 8888, recording the arrival system time of the data packet.
5. An in-band network telemetry method, comprising the steps of:
s1, capturing a data packet of a data link layer, performing layer-by-layer header analysis operation on the data packet, and sending the data packet to a network layer, a transmission layer and an application layer for processing to obtain a processed data packet; the method specifically comprises the following steps:
after the network card device driver receives the processed data packet, the data packet is sent to a network stack of a higher layer for continuous processing through a series of queuing rules, program mounting is carried out at an inlet of the processing packet, the system time of the system for calling the processing function is recorded as t1, then the data packet is sent to the network layer and the upper layer, the data packet is sent to the physical layer again after the processing is finished, when the data packet reaches an outlet queue inlet, the program mounting is carried out in the same way, the system time of the system for calling the outlet processing function is recorded as t2, finally the data packet is sent from the device, and the processing delay of the data packet in the system is as follows:
s2, after the network layer, the transmission layer and the application layer perform IP address analysis, TCP/UDP and port analysis, statistical analysis and protocol analysis on the processed data packet, so as to obtain the time delay information of the data packet; and
s3, modifying the checksum area of the analyzed data packet header, printing the time delay information on the data packet, and outputting the time delay information to the main control host.
6. The in-band network telemetry method of claim 5, wherein S2 further comprises: and interrupting whether the data packet is a UDP packet transmitted by the IPV4, wherein if the data packet is the UDP packet transmitted by the IPV4, the source address and the destination address of the data packet are obtained.
7. The in-band network telemetry method of claim 5, wherein S2 further comprises: and checking the checksum of the data packet, wherein if the check is passed, the data packet is sent and/or received.
8. The in-band network telemetry method of claim 5, wherein S2 further comprises:
acquiring an IP head part of the data packet, and judging whether the IP head part is the same as the protocol number of the IPV4 according to a protocol field in an sk _ buff structure;
if the protocol number of the data packet is the same as the protocol number of the IPV4, checking a transmission layer packet header of the data packet, and judging whether a UDP protocol field in sk _ buff is the same as the protocol number of the UDP data packet or not;
and if the protocol number of the data packet is the same as the protocol number of the UDP data packet, judging whether the destination port number of the data packet is 8888, wherein if the destination port number of the data packet is 8888, recording the arrival system time of the data packet.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811415877.1A CN109309605B (en) | 2018-11-26 | 2018-11-26 | In-band network telemetry system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811415877.1A CN109309605B (en) | 2018-11-26 | 2018-11-26 | In-band network telemetry system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109309605A CN109309605A (en) | 2019-02-05 |
| CN109309605B true CN109309605B (en) | 2020-08-25 |
Family
ID=65222388
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811415877.1A Active CN109309605B (en) | 2018-11-26 | 2018-11-26 | In-band network telemetry system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109309605B (en) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112717380B (en) * | 2019-03-19 | 2023-04-07 | Oppo广东移动通信有限公司 | Network detection method and related device |
| CN112350844B (en) * | 2019-08-09 | 2024-03-29 | 华为技术有限公司 | Method and device for data transmission |
| CN111769998B (en) * | 2019-08-13 | 2022-07-05 | 北京京东尚科信息技术有限公司 | Method and device for detecting network delay state |
| CN110752993B (en) * | 2019-10-24 | 2022-02-25 | 新华三信息安全技术有限公司 | Message forwarding method and device |
| CN111224839B (en) * | 2019-12-26 | 2022-05-31 | 长沙星融元数据技术有限公司 | Verification method and device for in-band network remote control function, storage medium and electronic equipment |
| CN111371754B (en) * | 2020-02-24 | 2022-06-03 | 苏州盛科通信股份有限公司 | Service message with INT data segment and service message processing method |
| CN112564967B (en) * | 2020-12-02 | 2022-11-08 | 杭州谐云科技有限公司 | Cloud service topology self-discovery method and system based on eBPF, electronic device and storage medium |
| RU2754361C1 (en) * | 2021-01-30 | 2021-09-01 | Вадим Владимирович Коньшин | Method for producing caramel malt |
| CN113242142B (en) * | 2021-04-13 | 2022-04-29 | 清华大学 | In-band network telemetry method, device, electronic equipment and storage medium |
| CN113282350B (en) * | 2021-05-26 | 2023-01-13 | 重庆零壹空间科技集团有限公司 | Telemetering data interpretation method and device, computer equipment and readable storage medium |
| CN113364778B (en) * | 2021-06-07 | 2022-07-29 | 新华三技术有限公司 | Message processing method and device |
| CN114710316B (en) * | 2022-02-23 | 2023-05-30 | 北京邮电大学 | In-band telemetry data verification method and white box switch |
| CN114501190B (en) * | 2022-04-06 | 2022-07-15 | 中国科学技术大学 | In-band telemetry method of virtual SDN network in-band telemetry system based on segment routing |
| CN115102621B (en) * | 2022-06-08 | 2023-03-14 | 上海百功半导体有限公司 | Serdes interface control system of optical communication equipment |
| CN115442275B (en) * | 2022-07-27 | 2024-02-27 | 北京邮电大学 | Hybrid telemetry method and system based on hierarchical trusted streams |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101841470B (en) * | 2010-03-29 | 2012-10-10 | 东南大学 | High-speed capturing method of bottom-layer data packet based on Linux |
| CN108028775A (en) * | 2015-10-20 | 2018-05-11 | 思科技术公司 | Operations, Administration and Maintenance in trigger-type band in network environment |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3628286B2 (en) * | 2001-07-31 | 2005-03-09 | アンリツ株式会社 | IP header generator |
| CN107749802B (en) * | 2017-10-12 | 2020-07-03 | 北京邮电大学 | Experiment platform and experiment method supporting protocol-independent data packet processing |
-
2018
- 2018-11-26 CN CN201811415877.1A patent/CN109309605B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101841470B (en) * | 2010-03-29 | 2012-10-10 | 东南大学 | High-speed capturing method of bottom-layer data packet based on Linux |
| CN108028775A (en) * | 2015-10-20 | 2018-05-11 | 思科技术公司 | Operations, Administration and Maintenance in trigger-type band in network environment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109309605A (en) | 2019-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109309605B (en) | In-band network telemetry system and method | |
| EP3368996B1 (en) | On demand packet traffic monitoring for network packet communications within virtual processing environments | |
| EP2619676B1 (en) | Network interface controller for virtual and distributed services | |
| US8059532B2 (en) | Data and control plane architecture including server-side triggered flow policy mechanism | |
| CN105493450B (en) | The method and system of service exception in dynamic detection network | |
| CN100369423C (en) | Network simulation detection system and method | |
| US9419867B2 (en) | Data and control plane architecture for network application traffic management device | |
| EP1722508B1 (en) | Distributed traffic analysis | |
| EP3419221B1 (en) | Drop detection and protection for network packet monitoring in virtual processing environments | |
| CN102098227B (en) | Packet capture method and kernel module | |
| US10868728B2 (en) | Graph-based network management | |
| US20060165108A1 (en) | Method and system for unidirectional packet processing at data link layer | |
| CN101626323A (en) | Method and device for monitoring network data flow | |
| Coppens et al. | Scampi-a scaleable monitoring platform for the internet | |
| US9356876B1 (en) | System and method for classifying and managing applications over compressed or encrypted traffic | |
| CN109547257A (en) | Method for controlling network flow, device, equipment, system and storage medium | |
| KR20120008478A (en) | 10 gbps scalable flow generation and control, using dynamic classification with 3-level aggregation | |
| EP3092737B1 (en) | Systems for enhanced monitoring, searching, and visualization of network data | |
| CN114785718B (en) | Network target range flow acquisition and analysis system and method | |
| Shah et al. | Implementation and performance analysis of firewall on open vSwitch | |
| US11770315B2 (en) | Artificial intelligence based device identification | |
| AT&T | ||
| US10887204B2 (en) | Network infrastructure management | |
| KR100934714B1 (en) | Stepwise flow information based network traffic monitoring system | |
| Scano et al. | Enabling p4 network telemetry in edge micro data centers with kubernetes orchestration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |