A terminal monitoring method in an FTTR networking, a gateway device and an apparatus

Abstract

This application provides a terminal monitoring method, gateway device, and apparatus for FTTR networking, relating to the field of network technology. It is applicable to scenarios such as home networks, enterprise campus networks, data centers, and carrier networks, and can also be applied to FTTR networking scenarios, specifically to gateway devices within FTTR networks. The method includes calling an eBPF program to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, parsing the frame headers of the intercepted packets to extract terminal information carried in the packets; transmitting the terminal information to a user-space process through BPF mapping; and calling the user-space process to perform terminal monitoring based on the terminal information. Applying the solution provided in this application enables high-performance, multi-protocol terminal monitoring in FTTR networking.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a terminal monitoring method, gateway device and apparatus in FTTR networking. Background Technology

[0002] In a Fiber to the Room (FTTR) networking scenario, a main gateway connects to multiple slave gateways, forming a star or cascaded topology. The main gateway needs to perform unified management and monitoring of all terminal devices on the Local Area Network (LAN) side, including terminal discovery and identification, online / offline status tracking, traffic statistics, terminal type, and access method identification.

[0003] Existing gateway terminal management systems typically employ two technical approaches to achieve terminal traffic detection and information learning: kernel-mode netfilter hooks or user-mode raw socket packet capture. However, both of these approaches have significant shortcomings in terms of high throughput, multi-protocol support, and deployment flexibility, making it difficult to meet the high-performance, multi-protocol (especially IPv6) terminal monitoring requirements of FTTR networking scenarios. Summary of the Invention

[0004] The purpose of this application is to provide a terminal monitoring method, gateway device, and apparatus in FTTR networking to achieve high-performance, multi-protocol terminal monitoring. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a terminal monitoring method in an FTTR network, applied to a gateway device in a fiber-to-the-room FTTR network, the method comprising:

[0006] The extended Berkeley packet filter (eBPF) program is invoked to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets.

[0007] The terminal information is transmitted to the user-space process through Berkeley Packet Filter (BPF) mapping.

[0008] The user-mode process is invoked to perform terminal monitoring based on the terminal information.

[0009] In one embodiment of this application, the eBPF program is a Fast Data Path (XDP) or a Flow Control Data Path (TC).

[0010] In one embodiment of this application, the step of invoking the user-mode process to perform terminal monitoring based on the terminal information includes:

[0011] The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information;

[0012] and / or

[0013] The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

[0014] In one embodiment of this application, after adding terminals whose last active timestamp is outside the most recent preset duration to the aging queue, the method further includes:

[0015] The eBPF program is invoked to send Address Resolution Protocol (ARP) requests to terminals added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0016] In one embodiment of this application, the method further includes:

[0017] After the eBPF program is updated, compile the updated eBPF program;

[0018] The compiled eBPF program is loaded into the kernel of the gateway device via hot loading, replacing the running eBPF program.

[0019] In one embodiment of this application, when the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

[0020] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address;

[0021] When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term.

[0022] When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname;

[0023] When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address.

[0024] When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

[0025] Secondly, embodiments of this application provide a gateway device located in a fiber-to-the-room (FTTR) network, the gateway device comprising:

[0026] processor;

[0027] transceiver;

[0028] A machine-readable storage medium storing machine-executable instructions that can be executed by the processor, the machine-executable instructions causing the processor to perform the following steps:

[0029] The extended Berkeley packet filter (eBPF) program is invoked to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets.

[0030] The terminal information is transmitted to the user-space process through Berkeley Packet Filter (BPF) mapping.

[0031] The user-mode process is invoked to perform terminal monitoring based on the terminal information.

[0032] In one embodiment of this application, the eBPF program is a Fast Data Path (XDP) or a Flow Control Data Path (TC).

[0033] In one embodiment of this application, the step of invoking the user-mode process to perform terminal monitoring based on the terminal information specifically includes:

[0034] The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information;

[0035] and / or

[0036] The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

[0037] In one embodiment of this application, after adding terminals whose last active timestamp is outside the most recent preset duration to the aging queue, the machine-executable instructions further cause the processor to perform the following steps:

[0038] The eBPF program is invoked to send Address Resolution Protocol (ARP) requests to terminals added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0039] In one embodiment of this application, the machine-executable instructions further cause the processor to perform the following steps:

[0040] After the eBPF program is updated, compile the updated eBPF program;

[0041] The compiled eBPF program is loaded into the kernel of the gateway device via hot loading, replacing the running eBPF program.

[0042] In one embodiment of this application, when the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

[0043] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address;

[0044] When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term.

[0045] When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname;

[0046] When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address.

[0047] When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

[0048] Thirdly, embodiments of this application provide a terminal monitoring device in an FTTR network, applied to a gateway device, the device comprising:

[0049] The information extraction module is used to call the extended Berkeley packet filter (eBPF) program to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets.

[0050] The information transmission module is used to transmit the terminal information to the user-space process through Berkeley Packet Filter (BPF) mapping.

[0051] The terminal monitoring module is used to invoke the user-mode process to perform terminal monitoring based on the terminal information.

[0052] In one embodiment of this application, the eBPF program is a Fast Data Path (XDP) or a Flow Control Data Path (TC).

[0053] In one embodiment of this application, the terminal monitoring module is specifically used for:

[0054] The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information;

[0055] and / or

[0056] The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

[0057] In one embodiment of this application, the apparatus further includes:

[0058] The terminal offline module is used to call the eBPF program to send Address Resolution Protocol (ARP) requests to terminals that have been added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0059] In one embodiment of this application, the apparatus further includes:

[0060] The program compilation module is used to compile the updated eBPF program after it has been updated.

[0061] The program replacement module is used to load the compiled eBPF program into the kernel of the gateway device via hot loading, replacing the running eBPF program.

[0062] In one embodiment of this application, when the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

[0063] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address;

[0064] When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term.

[0065] When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname;

[0066] When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address.

[0067] When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

[0068] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the methods described in the first aspect.

[0069] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods described in the first aspect above.

[0070] Beneficial effects of the embodiments in this application:

[0071] In the solution provided in this application embodiment, during terminal monitoring, the eBPF program utilizes BPF mapping to store the collected terminal information in a general storage space. User-space processes can directly read terminal information from this storage space, thereby enabling communication between the kernel-level eBPF program and the user-space process. This process eliminates the need for data copying, resulting in a short processing path and low latency. Zero-copy data transmission ensures high-performance requirements for terminal monitoring in high-bandwidth scenarios of FTTR networking. Compared to related technologies, packet throughput is significantly increased, and CPU usage on gateway devices is greatly reduced. Furthermore, since the eBPF program operates at Layer 2, it supports processing packets from multiple protocols, significantly improving the coverage and accuracy of terminal monitoring. Terminal discovery can be achieved even with statically configured IP addresses. Therefore, this embodiment can meet the multi-protocol terminal monitoring requirements in FTTR networking scenarios. Moreover, because interception is completed before packets enter the kernel protocol stack, no Layer 2 ingress packets are missed, ensuring the completeness of terminal information learning.

[0072] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0073] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0074] Figure 1 A flowchart illustrating a terminal monitoring method in an FTTR network provided in this application embodiment;

[0075] Figure 2 A schematic diagram of an eBPF program update process provided in an embodiment of this application;

[0076] Figure 3 This is a schematic diagram of the structure of a gateway device provided in an embodiment of this application;

[0077] Figure 4 This is a schematic diagram of the structure of a terminal monitoring device in an FTTR network provided in an embodiment of this application. Detailed Implementation

[0078] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0079] There are two main approaches to terminal monitoring in related technologies:

[0080] Option 1: Terminal monitoring is performed using a kernel module based on Linux netfilter hook functions.

[0081] This scheme develops an independent kernel module in kernel mode. By registering the netfilter hook function (nf_hook_ops) and attaching it to the two mount points NF_INET_FORWARD and NF_INET_LOCAL_IN in the IPv4 protocol stack, it performs three-layer parsing on forwarded and local uplink packets, extracts the terminal's Internet Protocol (IP) address and Media Access Control (MAC) address as terminal information, and then reports the terminal information to the user-space process for integration and management through the netlink mechanism, thereby performing terminal monitoring. The specific implementation is as follows: Register two netfilter hook functions, with the protocol family being the IPv4 protocol family under the netfilter framework (NetFilter Protocol IPv4, NFPROTO_IPV4), and the priority being the filtering priority of the IP protocol family under the netfilter framework (NetFilter IP Priority Filter, NF_IP_PRI_FILTER) + 1; In the hook functions, determine the interface direction of the packets (including forwarding from LAN to WAN and forwarding from LAN to the local machine), and parse the IP and MAC addresses as terminal information; send the terminal information to the user-space process through the netlink mechanism; the user-space process receives messages through netlink, maintains the terminal information table, performs terminal monitoring, and provides services to the outside world.

[0082] The problem with Option 1 is that it requires the development of an independent kernel module, which is tightly coupled with the kernel version. Kernel upgrades necessitate recompiling and adapting the kernel module, resulting in high maintenance costs. Furthermore, kernel module compilation carries high risks; kernel module failures can lead to kernel crashes or security vulnerabilities. Deploying and upgrading the kernel module also requires uninstalling the old version and loading the new one, impacting business continuity. Moreover, the detection logic of netfilter hook functions is hard-coded into the kernel module. Adding new protocol detection capabilities requires modifying the kernel module's source code and recompiling and loading it, resulting in long iteration cycles and hindering functional evolution.

[0083] Option 2: User-space raw_socket packet capture solution.

[0084] This solution captures protocol messages such as Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Network Basic Input / Output System (NetBIOS), and Internet Control Message Protocol version 6 (ICMPv6) in user space using raw_socket, parses the message content to extract terminal information, and realizes terminal monitoring.

[0085] The problem with Option 2 is that raw_socket copies all packets from kernel space to user space for processing. This involves data copying and context switching between kernel and user spaces, which puts high CPU usage on the gateway device and limits throughput in high-traffic environments, making it difficult to meet the performance requirements of high-bandwidth scenarios in FTTR networking. Furthermore, user-space packet capture relies on the kernel protocol stack to deliver packets to raw_socket, and some packets may be dropped during kernel protocol stack processing, resulting in incomplete terminal information learning.

[0086] To address the aforementioned issues, this application provides a terminal monitoring method, gateway device, and apparatus in FTTR networking.

[0087] See Figure 1 This application provides a terminal monitoring method in an FTTR network, which is applied to a gateway device in an FTTR network. The method includes the following steps S101-S103.

[0088] S101: Call the eBPF program to intercept the packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and parse the frame header of the intercepted packets to extract the terminal information carried in the packets.

[0089] S102: Transmit the above terminal information to the user-space process through BPF mapping;

[0090] S103: Invoke the above user-mode process to perform terminal monitoring based on the above terminal information.

[0091] As can be seen from the above, during terminal monitoring, the eBPF program utilizes BPF mapping to store the collected terminal information in a general-purpose storage space. User-space processes can directly read terminal information from this storage space, thereby enabling communication between the kernel-level eBPF program and the user-space process. This process eliminates the need for data copying, resulting in a short processing path and low latency. Zero-copy data transmission ensures high-performance requirements for terminal monitoring in high-bandwidth scenarios of FTTR networking. Compared to related technologies, packet throughput is significantly increased, and CPU usage on gateway devices is greatly reduced. Furthermore, since the eBPF program operates at Layer 2, it supports processing packets from multiple protocols, significantly improving the coverage and accuracy of terminal monitoring. Terminal discovery can be achieved even with statically configured IP addresses. Therefore, this embodiment can meet the multi-protocol terminal monitoring requirements in FTTR networking scenarios. Moreover, because interception is completed before packets enter the kernel protocol stack, no Layer 2 ingress packets are missed, ensuring the completeness of terminal information learning.

[0092] In one embodiment, the eBPF program runs on the network driver layer on the LAN side network interface of the gateway device. It is triggered to execute before the packet enters the kernel protocol stack and intercepts all Layer 2 packets entering the gateway device from the LAN side network interface.

[0093] In one possible implementation, the eBPF program parses the Ethernet frame header of the intercepted packets and identifies different protocol types based on the EtherType field. Different terminal information is extracted from packets of different protocol types.

[0094] In another possible embodiment, the extracted terminal information is encapsulated into a terminal information event structure and passed to the user-space process via a Berkeley Packet Filter (BPF) mapping. Specifically, the eBPF program stores the terminal information in a generic terminal information event structure, and the user-space process then reads the terminal information from the generic data structure, thereby realizing the transfer of terminal information between the eBPF program and the user-space process. In one embodiment, the eBPF program uses a BPF mapping of type BPF_MAP_TYPE_PERF_EVENT_ARRAY to pass the terminal information events to the user-space process with zero copy through a Perf Event Ring Buffer. The user-space process receives the terminal information reported by the eBPF program through the Perf Event Ring Buffer.

[0095] The aforementioned terminal information may include at least one of the following: message type (including ARP, Dynamic Host Configuration Protocol (DHCP), DHCPv6, Neighbor Discovery Protocol (NDP), NetBIOS), terminal MAC address, IP address (including IPv4 address and IPv6 address), hostname, DHCP option information, and last active timestamp (i.e., the timestamp when the gateway device received the message).

[0096] In another embodiment of this application, the user-mode process can maintain terminal information, maintain the active state of the terminal, perform aging detection, and provide external services such as terminal information query time notification to other modules through the UBus interface.

[0097] Compared to Solution 1, this embodiment uses an eBPF program, which requires no independent kernel module and is therefore secure and reliable. The eBPF program undergoes rigorous security checks before loading by the Linux kernel's built-in verifier, ensuring that the program will not cause risks such as memory out-of-bounds access or infinite loops. This eliminates the need to develop an independent kernel module, removing the risk of system crashes due to kernel module failures and ensuring system stability. Furthermore, deployment is convenient and driver-independent. The eBPF program supports mounting on LAN-side network interfaces, independent of specific network card drivers, and can be quickly deployed on any Linux gateway device, reducing adaptation and maintenance costs. Moreover, the eBPF program in this application runs at Layer 2 and can recognize various protocol messages such as ARP, DHCP / DHCPv6, NDP, and NetBIOS. Compared to Solution 1, this significantly improves the coverage and accuracy of terminal identification, enabling terminal discovery even with statically configured IP addresses. Additionally, this application combines a zero-copy transmission mechanism, significantly improving throughput and drastically reducing CPU usage compared to the netfilter hook function solution in Solution 1.

[0098] Compared to Scheme 2, the eBPF program in this embodiment runs at the network driver layer, completing detection before the packet enters the kernel protocol stack. This results in the shortest processing path and lowest latency. Combined with the zero-copy delivery mechanism, the throughput is significantly improved and CPU usage is greatly reduced compared to the raw_socket scheme in Scheme 2. Furthermore, since the eBPF program intercepts packets before they enter the kernel protocol stack, it does not miss any Layer 2 ingress packets. Compared to the raw_socket scheme, which may suffer from incomplete terminal information learning due to packet discarding by the kernel protocol stack, the solution in this embodiment ensures the completeness of terminal information learning.

[0099] In one embodiment of this application, the above-mentioned eBPF program is an eXpress Data Path (XDP) or a Traffic Control (TC) data path.

[0100] As can be seen from the above, in this implementation, XDP can be called to intercept packets before socket buffer allocation, or TC can be called to intercept packets after socket buffer allocation. Regardless of the method, packets can be detected before entering the protocol stack, and both methods can transmit terminal information based on BPF mapping, meeting the high bandwidth requirements of FTTR networking scenarios. Furthermore, both methods support multi-protocol parsing, satisfying the multi-protocol requirements of FTTR networking scenarios.

[0101] Specifically, XDP runs before the socket buffer (SKB) is allocated, and TC runs after the SKB is allocated but before the packet enters the kernel protocol stack. In one possible implementation, the higher-performance XDP is preferred for packet interception and packet information extraction. In addition, TC can be used as an alternative when XDP is unavailable.

[0102] When the eBPF program is XDP, the XDP mount point is located at the entry point of the network interface receive socket buffer (netif_receive_skb), which is independent of the specific network card driver. It can be quickly deployed on any network card without driver adaptation.

[0103] In one embodiment of this application, step S103 above includes step A and / or step B.

[0104] Step A: Invoke the aforementioned user-mode process to create or update the target terminal information in local storage based on the aforementioned terminal information. The aforementioned target terminal is the terminal corresponding to the aforementioned terminal information.

[0105] Step B: Invoke the aforementioned user-mode process to update the last active timestamp of the target terminal based on the aforementioned terminal information, and add terminals whose last active timestamp is outside the most recent preset duration to the aging queue.

[0106] As can be seen from the above, the user-mode process in this embodiment can realize the information management, active state maintenance and timeout aging maintenance of the terminal, so that the gateway device can dynamically synchronize the terminal information, maintain the active state of the terminal, and dynamically update the aging state of the terminal, thereby realizing comprehensive monitoring of the terminal.

[0107] In one possible embodiment, after the user-space process obtains the terminal information, it uses the MAC address in the terminal information as the primary key to check if there is any information corresponding to the MAC address in the stored information. If it does, it updates other information belonging to the same table entry as the MAC address with the content recorded in the obtained terminal information, and updates the online status of the target terminal to online. If there is no information corresponding to the MAC address in the stored information, it creates a new table entry, which records the obtained terminal information, and the online status recorded in the entry is online.

[0108] In another possible embodiment, whenever the user-space process can obtain the terminal information of the target terminal, it means that the target terminal is still sending packets, that is, the target terminal is still in an active state. Then the user-space process updates the last active timestamp of the target terminal. The time corresponding to the last active timestamp is the time when the gateway device receives the packet corresponding to the terminal information. The last active timestamp is a parameter in the table corresponding to the target terminal, and the table entry can be found by using the MAC address in the terminal information as the primary key.

[0109] If the last active timestamp is outside the most recent preset duration (e.g., 30 seconds or other durations by default), it means that the terminal has not sent any messages within the most recent preset duration. The terminal may have been offline. Therefore, the terminal is added to the aging queue. The earlier the terminal is in the aging queue, the earlier the time corresponding to its last active timestamp.

[0110] In one embodiment of this application, after adding terminals whose last active timestamp is outside the most recent preset duration to the aging queue, the following step C is further included.

[0111] Step C: Call the above eBPF program to send an ARP request to the terminal that has been added to the aging queue. If the above eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0112] As can be seen from the above, in the solution provided in this embodiment, the gateway device calls the eBPF program to determine the offline terminal through ARP active probing. While maintaining the advantage of the eBPF program passively monitoring terminal information, it makes up for the problem of untimely terminal offline determination in the purely passive terminal monitoring solution, reduces the delay in terminal offline determination, and improves the timeliness and accuracy of terminal offline determination.

[0113] In one embodiment of this application, a user-space process can send ARP requests to each terminal in the aging queue in the order of their arrival.

[0114] In one possible embodiment, if no ARP response is received within a preset response time after sending an ARP request, the terminal is determined to be offline and removed from the aging queue.

[0115] In another possible embodiment, if an ARP response is received within a preset response time after sending an ARP request, the terminal is determined to be online, the terminal is reset to an active state, the terminal's last active timestamp is updated to the timestamp of the moment the ARP response was received, and the terminal is removed from the aging queue.

[0116] In one embodiment of this application, see [link to embodiment]. Figure 2 The above method also includes the following steps S201-S202.

[0117] S201: After the eBPF program is updated, compile the updated eBPF program;

[0118] S202: Load the compiled eBPF program into the kernel of the aforementioned gateway device via hot loading, replacing the currently running eBPF program.

[0119] As can be seen from the above, the eBPF program is updated by hot loading in this embodiment of the application. When it is necessary to add protocol detection capabilities to the eBPF program or modify the detection logic, there is no need to modify the kernel source code, recompile the kernel module, or restart the system. The program update can be completed through user-space tools, which greatly shortens the function iteration cycle and facilitates long-term evolution.

[0120] eBPF programs are compiled in bytecode form and can be dynamically loaded into the kernel for execution via the libbpf library. When an eBPF program needs to be updated, only the new eBPF program bytecode needs to be compiled, and the running eBPF program can be hot-updated using user-space tools without restarting the system or uninstalling the kernel module, thus enabling the dynamic evolution of the detection logic.

[0121] In one embodiment of this application, when the above-mentioned eBPF program is XDP, the above-mentioned eBPF program runs in driver mode, hardware offload mode or general mode.

[0122] As can be seen from the above, XDP in this application can select between three modes to adapt to the actual situation of the gateway device. If the network card of the gateway device supports driver mode, using driver mode can obtain higher processing performance; if the network card of the gateway device is a smart network card, using hardware offloading mode can offload the terminal monitoring logic to the network card hardware for execution, further releasing the CPU resources of the gateway device host; the general mode is compatible with all network cards and is driver-independent, so no modification to the network card driver is required, making configuration the most convenient.

[0123] In one embodiment of this application, the execution mode of XDP can be selected from native mode, hardware offload mode, and generic mode according to the actual situation of the network card in the gateway device.

[0124] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's MAC address and / or IP address.

[0125] When the intercepted message is a DHCPv4 message, the aforementioned terminal information includes at least one of the following terminal information: MAC address, IP address, hostname, vendor type, and lease term;

[0126] When the intercepted message is a DHCPv6 message, the aforementioned terminal information includes at least one of the following terminal information: terminal identifier, IPv6 address, and hostname;

[0127] When the intercepted message is an NDP Neighbor Advertisement (NA) message, the above terminal information includes the terminal's MAC address and / or IPv6 address.

[0128] When the intercepted message is a NetBIOS message, the above terminal information includes: the terminal's hostname information.

[0129] As can be seen from the above, the embodiments of this application, based on the type of message sent by the terminal, adaptively collect different terminal information carried in the message, which can improve the accuracy of terminal information collection.

[0130] Among these, the mapping relationship between MAC addresses and IP addresses can be extracted from ARP packets for terminal IP address learning and updating. DHCPv4 and DHCPv6 packets are the main sources of key information such as the terminal's IP address, hostname, and lease term, and are crucial for enabling IPv6 terminal support. The mapping relationship between the terminal's IPv6 address and MAC address is extracted from NDP NA packets for terminal discovery in a pure IPv6 environment. Terminal hostname information is extracted from NetBIOS packets for name recognition of Windows devices.

[0131] Corresponding to the terminal monitoring method in the aforementioned FTTR network, this application provides a gateway device.

[0132] See Figure 3 A gateway device located in a fiber-to-the-room (FTTR) network, the gateway device comprising:

[0133] Processor 301;

[0134] Transceiver 304;

[0135] A machine-readable storage medium 302 stores machine-executable instructions that can be executed by the processor 301, the machine-executable instructions causing the processor 301 to perform the following steps:

[0136] The extended Berkeley packet filter (eBPF) program is invoked to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets.

[0137] The terminal information is transmitted to the user-space process through Berkeley Packet Filter (BPF) mapping.

[0138] The user-mode process is invoked to perform terminal monitoring based on the terminal information.

[0139] As can be seen from the above, during terminal monitoring, the eBPF program utilizes BPF mapping to store the collected terminal information in a general-purpose storage space. User-space processes can directly read terminal information from this storage space, thereby enabling communication between the kernel-level eBPF program and the user-space process. This process eliminates the need for data copying, resulting in a short processing path and low latency. Zero-copy data transmission ensures high-performance requirements for terminal monitoring in high-bandwidth scenarios of FTTR networking. Compared to related technologies, packet throughput is significantly increased, and CPU usage on gateway devices is greatly reduced. Furthermore, since the eBPF program operates at Layer 2, it supports processing packets from multiple protocols, significantly improving the coverage and accuracy of terminal monitoring. Terminal discovery can be achieved even with statically configured IP addresses. Therefore, this embodiment can meet the multi-protocol terminal monitoring requirements in FTTR networking scenarios. Moreover, because interception is completed before packets enter the kernel protocol stack, no Layer 2 ingress packets are missed, ensuring the completeness of terminal information learning.

[0140] like Figure 3 As shown, the gateway device may also include a communication bus 303. The processor 301, machine-readable storage medium 302, and transceiver 304 communicate with each other via the communication bus 303. The communication bus 303 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus 303 can be divided into an address bus, a data bus, a control bus, etc.

[0141] The transceiver 304 can be a wireless communication module. Under the control of the processor 301, the transceiver 304 interacts with other devices for data exchange.

[0142] Machine-readable storage medium 302 may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Alternatively, machine-readable storage medium 302 may also be at least one storage device located remotely from the aforementioned processor.

[0143] Processor 301 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0144] In one embodiment of this application, the eBPF program is a Fast Data Path (XDP) or a Flow Control Data Path (TC).

[0145] As can be seen from the above, in this implementation, XDP can be called to intercept packets before socket buffer allocation, or TC can be called to intercept packets after socket buffer allocation. Regardless of the method, packets can be detected before entering the protocol stack, and both methods can transmit terminal information based on BPF mapping, meeting the high bandwidth requirements of FTTR networking scenarios. Furthermore, both methods support multi-protocol parsing, satisfying the multi-protocol requirements of FTTR networking scenarios.

[0146] In one embodiment of this application, the step of invoking the user-mode process to perform terminal monitoring based on the terminal information specifically includes:

[0147] The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information;

[0148] and / or

[0149] The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

[0150] As can be seen from the above, the user-mode process in this embodiment can realize the information management, active state maintenance and timeout aging maintenance of the terminal, so that the gateway device can dynamically synchronize the terminal information, maintain the active state of the terminal, and dynamically update the aging state of the terminal, thereby realizing comprehensive monitoring of the terminal.

[0151] In one embodiment of this application, after adding terminals whose last active timestamp is outside the most recent preset duration to the aging queue, the machine-executable instructions further cause the processor to perform the following steps:

[0152] The eBPF program is invoked to send Address Resolution Protocol (ARP) requests to terminals added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0153] As can be seen from the above, in the solution provided in this embodiment, the gateway device calls the eBPF program to determine the offline terminal through ARP active probing. While maintaining the advantage of the eBPF program passively monitoring terminal information, it makes up for the problem of untimely terminal offline determination in the purely passive terminal monitoring solution, reduces the delay in terminal offline determination, and improves the timeliness and accuracy of terminal offline determination.

[0154] In one embodiment of this application, the machine-executable instructions further cause the processor to perform the following steps:

[0155] After the eBPF program is updated, compile the updated eBPF program;

[0156] The compiled eBPF program is loaded into the kernel of the gateway device via hot loading, replacing the running eBPF program.

[0157] As can be seen from the above, the eBPF program is updated by hot loading in this embodiment of the application. When it is necessary to add protocol detection capabilities to the eBPF program or modify the detection logic, there is no need to modify the kernel source code, recompile the kernel module, or restart the system. The program update can be completed through user-space tools, which greatly shortens the function iteration cycle and facilitates long-term evolution.

[0158] In one embodiment of this application, when the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

[0159] As can be seen from the above, XDP in this application can select between three modes to adapt to the actual situation of the gateway device. If the network card of the gateway device supports driver mode, using driver mode can obtain higher processing performance; if the network card of the gateway device is a smart network card, using hardware offloading mode can offload the terminal monitoring logic to the network card hardware for execution, further releasing the CPU resources of the gateway device host; the general mode is compatible with all network cards and is driver-independent, so no modification to the network card driver is required, making configuration the most convenient.

[0160] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address;

[0161] When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term.

[0162] When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname;

[0163] When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address.

[0164] When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

[0165] As can be seen from the above, the embodiments of this application, based on the type of message sent by the terminal, adaptively collect different terminal information carried in the message, which can improve the accuracy of terminal information collection.

[0166] See Figure 4 This application provides a terminal monitoring device in an FTTR network, applied to a gateway device, the device comprising:

[0167] The information extraction module 401 is used to call the extended Berkeley packet filter eBPF program to intercept the packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame header of the intercepted packets to extract the terminal information carried in the packets.

[0168] The information transmission module 402 is used to transmit the terminal information to the user-space process through Berkeley Packet Filter (BPF) mapping.

[0169] The terminal monitoring module 403 is used to call the user-mode process to perform terminal monitoring based on the terminal information.

[0170] As can be seen from the above, during terminal monitoring, the eBPF program utilizes BPF mapping to store the collected terminal information in a general-purpose storage space. User-space processes can directly read terminal information from this storage space, thereby enabling communication between the kernel-level eBPF program and the user-space process. This process eliminates the need for data copying, resulting in a short processing path and low latency. Zero-copy data transmission ensures high-performance requirements for terminal monitoring in high-bandwidth scenarios of FTTR networking. Compared to related technologies, packet throughput is significantly increased, and CPU usage on gateway devices is greatly reduced. Furthermore, since the eBPF program operates at Layer 2, it supports processing packets from multiple protocols, significantly improving the coverage and accuracy of terminal monitoring. Terminal discovery can be achieved even with statically configured IP addresses. Therefore, this embodiment can meet the multi-protocol terminal monitoring requirements in FTTR networking scenarios. Moreover, because interception is completed before packets enter the kernel protocol stack, no Layer 2 ingress packets are missed, ensuring the completeness of terminal information learning.

[0171] In one embodiment of this application, the eBPF program is a Fast Data Path (XDP) or a Flow Control Data Path (TC).

[0172] As can be seen from the above, in this implementation, XDP can be called to intercept packets before socket buffer allocation, or TC can be called to intercept packets after socket buffer allocation. Regardless of the method, packets can be detected before entering the protocol stack, and both methods can transmit terminal information based on BPF mapping, meeting the high bandwidth requirements of FTTR networking scenarios. Furthermore, both methods support multi-protocol parsing, satisfying the multi-protocol requirements of FTTR networking scenarios.

[0173] In one embodiment of this application, the terminal monitoring module 403 is specifically used for:

[0174] The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information;

[0175] and / or

[0176] The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

[0177] As can be seen from the above, the user-mode process in this embodiment can realize the information management, active state maintenance and timeout aging maintenance of the terminal, so that the gateway device can dynamically synchronize the terminal information, maintain the active state of the terminal, and dynamically update the aging state of the terminal, thereby realizing comprehensive monitoring of the terminal.

[0178] In one embodiment of this application, the apparatus further includes:

[0179] The terminal offline module is used to call the eBPF program to send Address Resolution Protocol (ARP) requests to terminals that have been added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

[0180] As can be seen from the above, in the solution provided in this embodiment, the gateway device calls the eBPF program to determine the offline terminal through ARP active probing. While maintaining the advantage of the eBPF program passively monitoring terminal information, it makes up for the problem of untimely terminal offline determination in the purely passive terminal monitoring solution, reduces the delay in terminal offline determination, and improves the timeliness and accuracy of terminal offline determination.

[0181] In one embodiment of this application, the apparatus further includes:

[0182] The program compilation module is used to compile the updated eBPF program after it has been updated.

[0183] The program replacement module is used to load the compiled eBPF program into the kernel of the gateway device via hot loading, replacing the running eBPF program.

[0184] As can be seen from the above, the eBPF program is updated by hot loading in this embodiment of the application. When it is necessary to add protocol detection capabilities to the eBPF program or modify the detection logic, there is no need to modify the kernel source code, recompile the kernel module, or restart the system. The program update can be completed through user-space tools, which greatly shortens the function iteration cycle and facilitates long-term evolution.

[0185] In one embodiment of this application, when the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

[0186] As can be seen from the above, XDP in this application can select between three modes to adapt to the actual situation of the gateway device. If the network card of the gateway device supports driver mode, using driver mode can obtain higher processing performance; if the network card of the gateway device is a smart network card, using hardware offloading mode can offload the terminal monitoring logic to the network card hardware for execution, further releasing the CPU resources of the gateway device host; the general mode is compatible with all network cards and is driver-independent, so no modification to the network card driver is required, making configuration the most convenient.

[0187] In one embodiment of this application, when the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address;

[0188] When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term.

[0189] When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname;

[0190] When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address.

[0191] When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

[0192] As can be seen from the above, the embodiments of this application, based on the type of message sent by the terminal, adaptively collect different terminal information carried in the message, which can improve the accuracy of terminal information collection.

[0193] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of the terminal monitoring method in any of the above-described FTTR networks.

[0194] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the terminal monitoring methods in the FTTR network described above.

[0195] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0196] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0197] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for gateway devices, apparatuses, computer-readable storage media, and computer program products are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0198] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for terminal monitoring in an FTTR networking, characterized in that, A gateway device applied in a fiber-to-the-room (FTTR) network, the method comprising: The extended Berkeley packet filter (eBPF) program is invoked to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets. The terminal information is transmitted to the user-space process through Berkeley Packet Filter (BPF) mapping. The user-mode process is invoked to perform terminal monitoring based on the terminal information.

2. The method according to claim 1, characterized in that, The eBPF program is either the Fast Data Path (XDP) or the Flow Control Data Path (TC).

3. The method according to claim 1, characterized in that, The step of invoking the user-mode process to perform terminal monitoring based on the terminal information includes: The user-mode process is invoked to create or update the target terminal information in local storage based on the terminal information, wherein the target terminal is the terminal corresponding to the terminal information; and / or The user-mode process is invoked to update the last active timestamp of the target terminal based on the terminal information, and terminals whose last active timestamp is outside the most recent preset duration are added to the aging queue.

4. The method according to claim 3, characterized in that, After adding terminals whose last active timestamp is outside the most recent preset duration to the aging queue, the process further includes: The eBPF program is invoked to send Address Resolution Protocol (ARP) requests to terminals added to the aging queue. If the eBPF program does not receive an ARP response from the terminal, it determines that the terminal is offline.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: After the eBPF program is updated, compile the updated eBPF program; The compiled eBPF program is loaded into the kernel of the gateway device via hot loading, replacing the running eBPF program.

6. The method according to any one of claims 1-4, characterized in that, When the eBPF program is XDP, the eBPF program runs in driver mode, hardware offload mode, or general mode.

7. The method according to any one of claims 1-4, characterized in that, When the intercepted message is an ARP message, the terminal information includes: the terminal's Media Access Control (MAC) address and / or IP address; When the intercepted message is a DHCPv4 message, the terminal information includes at least one of the following: MAC address, IP address, hostname, vendor type, and lease term. When the intercepted message is a DHCPv6 message, the terminal information includes at least one of the following: terminal identifier, IPv6 address, and hostname; When the intercepted message is a Neighbor Discovery Protocol (NDP) Neighbor Advertisement (NA) message, the terminal information includes the terminal's MAC address and / or IPv6 address. When the intercepted message is a NetBIOS message, the terminal information includes: the terminal's hostname information.

8. A gateway device, characterized in that, The gateway device is located in the Fiber to the Room (FTTR) network, and the gateway device includes: processor; transceiver; A machine-readable storage medium storing machine-executable instructions that can be executed by the processor, the machine-executable instructions causing the processor to perform the following steps: The extended Berkeley packet filter (eBPF) program is invoked to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets. The terminal information is transmitted to the user-space process through Berkeley Packet Filter (BPF) mapping. The user-mode process is invoked to perform terminal monitoring based on the terminal information.

9. A terminal monitoring device in an FTTR network, characterized in that, Applied to a gateway device, the device includes: The information extraction module is used to call the extended Berkeley packet filter (eBPF) program to intercept packets received by the gateway device from the local area network side before the packets enter the protocol stack in the kernel, and to parse the frame headers of the intercepted packets to extract the terminal information carried in the packets. The information transmission module is used to transmit the terminal information to the user-space process through Berkeley Packet Filter (BPF) mapping. The terminal monitoring module is used to invoke the user-mode process to perform terminal monitoring based on the terminal information.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images