Management method and device for sub-gateways in FTTR network, storage medium and electronic device

Abstract

A method and device for managing sub-gateways in an FTTR network, a storage medium and an electronic device, the FTTR network comprises a main gateway and at least one sub-gateway, one sub-gateway in the FTTR network is a target sub-gateway on which a terminal device is hung, the target sub-gateway is accessed to the main gateway in a bridging mode, and the terminal device is connected to the main gateway in a bridging mode. The next hop address of the message from the LAN side in the target sub-gateway is the local management IP address of the main gateway; the local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, and the method is applied to the target sub-gateway and comprises the following steps: receiving a request message sent by the terminal device; and before the request message enters the network bridge, the request message is processed according to a preset processing strategy, and the processing strategy is to perform local processing on the message accessing the local management IP address of the target sub-gateway, so that the same terminal device can perform local management on the main gateway and the target sub-gateway.

Description

Technical Field

[0001] The present invention relates to network communication technology, and more particularly to a method, device, storage medium and electronic device for managing a sub-gateway in an FTTR network. Background Art

[0002] Optical communication, especially fiber-based communication technology, has become the pillar of modern communication infrastructure, with far-reaching social value and impact. FTTR (Fiber To The Room) technology is a new networking method. Through the main gateway and sub-gateway of the FTTR network, optical fiber is used to replace network cables and laid to every room, ensuring network coverage of the whole house. How to manage the main gateway and sub-gateway locally is an urgent problem to be solved. Summary of the invention

[0003] Embodiments of the present application provide a method, device, storage medium, and electronic device for managing a sub-gateway in an FTTR network.

[0004] A method for managing a sub-gateway in an FTTR network, the FTTR network comprising a main gateway and at least one sub-gateway, wherein one of the sub-gateways in the FTTR network is a target sub-gateway with a terminal device attached thereto, wherein the target sub-gateway accesses the main gateway in a bridging mode, and the next hop address of a message from a LAN side in the target sub-gateway is a local management IP address of the main gateway; the local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, wherein the method is applied to the target sub-gateway, and the method comprises: Receiving a request message sent by the terminal device, wherein the request message carries a local management IP address of a gateway to be managed; Before the request message enters the network bridge, the request message is processed according to a preset processing strategy, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway.

[0005] A management device for a sub-gateway in an FTTR network, the FTTR network comprising a main gateway and at least one sub-gateway, wherein one of the sub-gateways in the FTTR network is a target sub-gateway with a terminal device attached thereto, wherein the target sub-gateway accesses the main gateway in a bridging mode, and the next hop address of a message from a LAN side in the target sub-gateway is a local management IP address of the main gateway; the local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, wherein the device is applied to the target sub-gateway, and the device comprises: A receiving module, configured to receive a request message sent by the terminal device, wherein the request message carries a local management IP address of a gateway to be managed; The processing module is configured to process the request message according to a preset processing strategy before the request message enters the bridge, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway.

[0006] A storage medium stores a computer program, wherein the computer program is configured to execute the method described above when running.

[0007] An electronic device comprises a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the method described above.

[0008] In an embodiment of the present application, after the target sub-gateway is configured to access the main gateway in bridging mode, if a request message sent by a terminal device is received, the request message is processed according to a preset processing strategy before the request message enters the bridge, wherein the processing strategy is to locally process messages accessing the local management IP address of the target sub-gateway, so that the target sub-gateway can locally process request messages that meet the processing strategy, and local management of the main gateway and the target sub-gateway by the same terminal device is achieved without affecting normal business and without reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

[0009] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by implementing the present application. Other advantages of the present application can be realized and obtained by the schemes described in the description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings are used to provide an understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0011] Figure 1 A schematic diagram of the structure of the FTTR network provided in the embodiment of the present application; Figure 2 A flowchart of a method for managing a neutron gateway in an FTTR network provided in an embodiment of the present application; Figure 3 A schematic diagram of a processing method of a target sub-gateway provided in an embodiment of the present application; Figure 4 An interactive schematic diagram of a method for managing a sub-gateway in an FTTR network provided in an embodiment of the present application; Figure 5 A schematic diagram of the deployment of a gateway device in an FTTR network provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of the management device of the FTTR network neutron gateway provided in this application. DETAILED DESCRIPTION

[0012] The present application describes multiple embodiments, but the description is exemplary rather than restrictive, and it is obvious to those skilled in the art that there may be more embodiments and implementations within the scope of the embodiments described in the present application. Although many possible feature combinations are shown in the drawings and discussed in the specific embodiments, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with any other feature or element in any other embodiment, or may replace any other feature or element in any other embodiment.

[0013] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in the present application may also be combined with any conventional features or elements to form a unique invention scheme. Any features or elements of any embodiment may also be combined with features or elements from other invention schemes to form another unique invention scheme. Therefore, it should be understood that any feature shown and / or discussed in the present application may be implemented individually or in any appropriate combination. Therefore, except for the limitations made according to the attached claims and their equivalents, the embodiments are not subject to other restrictions. In addition, various modifications and changes may be made within the scope of protection of the attached claims.

[0014] In addition, when describing representative embodiments, the specification may have presented the method and / or process as a specific sequence of steps. However, to the extent that the method or process does not rely on the specific order of the steps described herein, the method or process should not be limited to the steps of the specific order described. As will be understood by those of ordinary skill in the art, other sequences of steps are also possible. Therefore, the specific sequence of the steps set forth in the specification should not be interpreted as a limitation to the claims. In addition, the claims for the method and / or process should not be limited to the steps of performing them in the order written, and those skilled in the art can easily understand that these sequences can be changed and still remain within the spirit and scope of the embodiments of the present application.

[0015] In an embodiment of the present application, the FTTR network includes a main gateway and at least one sub-gateway, wherein one sub-gateway in the FTTR network is a target sub-gateway having a terminal device attached thereto.

[0016] Figure 1 This is a schematic diagram of the structure of the FTTR network provided in the embodiment of the present application. Figure 1 As shown, the FTTR network includes a main gateway and N+1 sub-gateways, wherein the N+1 sub-gateways are respectively a target sub-gateway, sub-gateway 1, sub-gateway 2, sub-gateway 3, ..., and sub-gateway N, wherein the value of N can be 0 or any positive integer.

[0017] The target sub-gateway is connected to the main gateway in bridge mode, and the next hop address of the message from the LAN side in the target sub-gateway is the local management IP address of the main gateway; bridge mode is a working mode of a network device, which allows the network device to forward messages at the data link layer instead of routing and forwarding messages at the network layer. Figure 1 In the structure shown, the message from the LAN side may be a request message for the terminal device to remotely access the gateway.

[0018] The local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment.

[0019] The local management IP address is the IP address assigned to the gateway, which is used to manage and configure the gateway in the local network. External devices can access the local management IP address of the gateway so that the gateway can be remotely accessed for monitoring, updating, and troubleshooting.

[0020] The target sub-gateway with the terminal device attached thereto accesses the main gateway in bridging mode, and the next hop address of the message from the LAN side in the target sub-gateway is the local management IP address of the main gateway. Therefore, when the target sub-gateway accesses the main gateway in bridging mode, since the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, all messages sent by the terminal device can be directly sent to the main gateway through the bridge.

[0021] When the terminal device sends a request message for local management of the main gateway, the request message can be successfully sent to the main gateway, so the main gateway and the terminal device can communicate normally, and the terminal device can implement local management of the main gateway.

[0022] Since all messages sent by the terminal device are sent to the main gateway through the bridge, when the terminal sends a request message for local management of the target sub-gateway, the request message will be sent directly to the main gateway through the bridge, and access to the target sub-gateway will not be achieved. Therefore, the terminal device cannot achieve local management of the target sub-gateway.

[0023] To solve the above technical problems, the present application proposes the following solutions, including: Figure 2 The flowchart of the method for managing a sub-gateway in a FTTR network provided in the embodiment of the present application is as follows. Figure 2 As shown, the method is applied to the target sub-gateway, and the method includes:

[0024] Step 201: Receive a request message sent by a terminal device, wherein the request message carries a local management IP address of a gateway to be managed; Among them, the terminal device accesses the network through the LAN port of the target sub-gateway and obtains the IP address of the terminal device through the DHCP (Dynamic Host Configuration Protocol) server of the main gateway. Therefore, the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, ensuring normal communication between the terminal device and the main gateway.

[0025] Among them, the local management IP address of the gateway to be managed in the request message can be the local management IP address of the main gateway or the local management IP address of the target sub-gateway; among them, when the request message carries the local management IP address of the main gateway, the request message is used to locally manage the main gateway; when the request message carries the local management IP address of the target sub-gateway, the request message is used to locally manage the target sub-gateway.

[0026] The request message can carry the local management IP address of the gateway to be managed by using the local management IP address of the gateway to be managed as the destination IP address of the request message.

[0027] Step 202: before the request message enters the network bridge, the request message is processed according to a preset processing strategy, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway; Among them, before the target sub-gateway sends the received request message through the bridge, since the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway, when the request message carries the local management IP address of the target sub-gateway, the request message satisfies the processing strategy, and therefore, the request message is locally processed by the target sub-gateway and will not participate in the forwarding operation of the bridge, thereby realizing the local management of the target sub-gateway. When the request message carries the local management IP address of the main gateway, the request message does not satisfy the processing strategy, and therefore, the request message will continue to participate in the sending operation of the bridge, and will be sent by the target sub-gateway to the main gateway through the bridge, thereby realizing the local management of the main gateway.

[0028] The method provided by the embodiment of the present application, after the target sub-gateway is configured to access the main gateway in bridging mode, if a request message sent by a terminal device is received, the request message is processed according to a preset processing strategy before the request message enters the bridge, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway, so that the target sub-gateway can locally process the request message that meets the processing strategy, and local management of the main gateway and the target sub-gateway by the same terminal device is achieved without affecting normal business and without reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

[0029] The method provided in the embodiment of the present application is described below: In an exemplary embodiment, the method of obtaining the processing strategy includes: After the target sub-gateway successfully registers with the main gateway, the processing strategy is obtained from the main gateway.

[0030] Specifically, after the target sub-gateway registers with the main gateway, if the target sub-gateway is successfully registered, the main gateway will send the processing policy to the target sub-gateway so that the target sub-gateway can respond to the access operation of the terminal device according to the processing policy.

[0031] Preferably, the destination address of the message carrying the processing strategy is the local management IP address of the target sub-gateway; When the number of sub-gateways in the FTTR network is at least two, the local management IP addresses of the other sub-gateways in the FTTR network except the target sub-gateway are the same as the local management IP address of the target sub-gateway.

[0032] By setting the local management IP address of each sub-gateway in the FTTR network to the same IP address, the processing strategy can be transmitted to each sub-gateway, so that the processing method of other sub-gateways in the FTTR network except the target sub-gateway is the same as that of the target sub-gateway, ensuring that the terminal devices connected to any sub-gateway in the FTTR network can locally access their corresponding sub-gateways. Therefore, even if the number of sub-gateways with terminal devices attached changes, for example, a terminal device is connected to another sub-gateway, or a terminal device that has been connected to the target sub-gateway is disconnected from the target sub-gateway, the main gateway does not need to perform special management on the above sub-gateways, reducing the maintenance cost of the main gateway.

[0033] In an exemplary embodiment, the process of the target sub-gateway processing the request message according to the processing policy is implemented based on the broute table of ebtables in the Linux system.

[0034] Specifically, the processing strategy is a processing rule in the BR_ROUTING chain in the broute table of ebtables in the Linux system, wherein the processing rule is to redirect the received message to the target sub-gateway.

[0035] ebtables is a tool for configuring tables and rules for Ethernet bridging in the Linux kernel. It can control and modify packets passing through Ethernet bridging. Similar to iptables, ebtables focuses on processing Ethernet packets at layer 2 (data link layer), while iptables processes IP packets at layer 3 (network layer).

[0036] In ebtables, the broute table is used to process packets on Ethernet bridge devices. The BR_ROUTING chain in this table is a built-in chain that processes packets before they reach the bridge decision point. The main function of the BR_ROUTING chain is to decide whether the packet should be bridged and forwarded at Layer 2 (data link layer) or routed at Layer 3 (network layer).

[0037] The rules in the BR_ROUTING chain can be set based on the source MAC address, destination MAC address, protocol type, and other conditions of the data packet. In the BR_ROUTING chain, the ACCEPT target indicates that the data packet will be forwarded by the bridge, while the DROP target indicates that the data packet will be routed. This mechanism enables network administrators to fine-tune the forwarding behavior of data packets. For example, rules can be set to ensure that data packets with specific MAC addresses are routed to specific network interfaces, or to control whether specific types of traffic are allowed to pass through the bridge.

[0038] In the embodiment of the present application, the received message is routed to the target sub-gateway using the working mechanism of the BR_ROUTING chain.

[0039] Specifically, a processing rule is set in the BR_ROUTING chain so that the target sub-gateway modifies the destination MAC (dst MAC) address of the received message into the MAC address of the target sub-gateway.

[0040] In the embodiment of the present application, the processing rule in the BR_ROUTING chain is a redirection rule, wherein the redirection rule is used to modify the destination MAC address of the message received by the target sub-gateway to the MAC address of the target sub-gateway.

[0041] Furthermore, the PREROUTING chain can be used to implement the redirection rule.

[0042] The PREROUTING chain is another built-in chain in ebtables that processes the message before it is forwarded by the bridge. The PREROUTING chain is used to modify the message. In the embodiment of the present application, the PREROUTING chain is used to modify the destination MAC address of the message to the MAC address of the target sub-gateway.

[0043] In an exemplary embodiment, the processing the request message according to a preset processing strategy includes: The request message is processed by using the Bridge Netfilter and kernel module in the Linux system; wherein: The bridge clean firewall matches the destination IP address of the request message according to the processing strategy. If the match is successful, the bridge clean firewall processes the request message according to the processing strategy to obtain a processed message, wherein the destination MAC address of the processed message is the MAC address of the target sub-gateway; The bridge-net firewall modifies the data packet type of the processed message to a local data packet according to the destination MAC address of the processed message, obtains the modified message, and sends it to the kernel module; The kernel module responds to the modified message according to the data packet type of the modified message.

[0044] Preferably, a hook point named BR_PRE_ROUTING in the bridge net firewall is provided with a hook function, wherein the hook function is used to call and execute the processing strategy.

[0045] BR_PRE_ROUTING is a hook point in Bridge Netfilter, which is called before the data packet enters the bridge of the Linux kernel. The function of this hook point is to provide an opportunity to filter, modify or perform other necessary operations on the data packet before the data packet is further processed by the bridge. Using BR_PRE_ROUTING, you can pre-process the message passing through the bridge before the data packet reaches the IP layer.

[0046] In the embodiment of the present application, the hook function calls and executes the processing rules in the BR_BROUTING chain in the broute table.

[0047] From the above process, it can be seen that without affecting normal business and reducing network quality, the hook function set in BridgeNetfilter is used to execute the processing rules in the BR_ROUTING chain in the broute table without making too much code modification, which has good versatility.

[0048] In addition, the target sub-gateway obtains a response message corresponding to the modified message, and sends the response message to the terminal device through the LAN port, thereby realizing data interaction between the target sub-gateway and the terminal device.

[0049] Specifically, before the bridge-net firewall matches the request message using the processing strategy, a data forwarding database (FDB) of the target sub-gateway is updated according to the request message; The kernel module uses the updated data forwarding table to send a response message corresponding to the modified message.

[0050] In the above implementation, after receiving the request message, the target sub-gateway updates the FDB to provide an operation basis for sending a response message locally.

[0051] Figure 3 A schematic diagram of a processing method for a target sub-gateway provided in an embodiment of the present application. Figure 3 As shown, in Figure 3The schematic diagram shown involves multiple built-in chains in ebtables, which are used for different data processing stages:

[0052] BR_LOCAL_IN chain: This chain is used to process packets that have passed the bridge and are about to enter the local network stack. It is called when the destination MAC address of the packet matches the bridge interface, or when the packet is broadcast or multicast. In the Linux kernel, the BR_LOCAL_IN chain is executed before the packet is passed to the local network stack, allowing final filtering or modification.

[0053] BR_FORWARD chain: This chain processes packets whose destination MAC address is not local and needs to be forwarded to other ports. Before the packet is forwarded by the bridge, the BR_FORWARD chain is called, allowing the administrator to control the forwarding, discarding or modification of the packet. In the Linux kernel, this chain provides routing forwarding functions at the data link layer.

[0054] BR_LOCAL_OUT chain: This chain manages locally generated messages, that is, messages generated by the local machine and ready to be sent through the bridge. The BR_LOCAL_OUT chain is called before the message is routed through the IP layer and is ready to be sent. In the Linux kernel, this chain is executed before the message is sent to the network, allowing final filtering or modification.

[0055] BR_POST_ROUTING chain: This chain processes the message before it leaves the local machine for final inspection and modification.

[0056] exist Figure 3 The processing flow of the target sub-gateway in the process shown is as follows: The hook function set in the hook point BR_PRE_ROUTING in the Bridge Netfilter calls the processing rule in the BR_BROUTING chain in the broute table and uses the processing rule to match the destination IP address of the received request message; If the match succeeds, the hook function modifies the destination MAC address of the request message to the MAC address of the target sub-gateway to obtain the processed message; Bridge Netfilter modifies the processed message to a local data packet according to the destination MAC address of the processed message, and sends it to the local after being processed by all hook functions on the BR_LOCAL_IN chain. For details, see the arrow marked 2; If the match fails, the request message will be forwarded through the bridge after being processed by all hook functions on the BR_FORWARD chain, as shown in the arrow marked 1. In addition, for the message generated by the target sub-gateway (such as the response message corresponding to the request message), it is directly output after being processed by all the hook functions on the BR_LOCAL_OUT chain, as shown in the arrow marked 3; Among them, before executing the message output, all hook functions on the BR_POST_ROUTING chain can be used to check or modify the message to be sent.

[0057] From the above process, it can be seen that without affecting normal business and reducing network quality, the existing multiple built-in chains in ebtables and the inherent functions in Bridge Netfilter can be used to achieve local management of the main gateway and the target sub-gateway by the same terminal device without excessive code modification, which has good versatility.

[0058] Figure 4 The interactive diagram of the management method of the FTTR network neutron gateway provided in the embodiment of the present application. Figure 4 As shown, the method comprises in sequence:

[0059] Sub-gateway registration process: Step 1: The target sub-gateway sends a registration message to the main gateway; Step 2: After the target sub-gateway is successfully registered, the main gateway sends a processing strategy to the target sub-gateway, wherein the processing strategy is a processing rule set based on the local management IP address of the target sub-gateway, wherein the processing rule is used by the target sub-gateway to locally process the received request message; Step 3: The target sub-gateway configures the processing strategy.

[0060] Management process of the main gateway: After the main gateway and the target sub-gateway are successfully networked, all interfaces on the target sub-gateway are bound to a bridge in the VLAN where the main gateway is located, where the target sub-gateway generates a default route, and the next hop address of the default route points to the IP address of the VLAN in the main gateway. The terminal device hanging on the target sub-gateway will obtain an IP address through the DHCP server in the VLAN of the main gateway, where the IP address of the terminal device is in the same network segment as the local management IP address of the main gateway. Therefore, when the terminal device accesses the main gateway, the message sent by the terminal device will be directly sent to the main gateway through the bridge.

[0061] Step 4: The terminal device sends a request message for accessing the main gateway, wherein the request message for accessing the main gateway is forwarded to the main gateway via the bridge; Step 5: The main gateway sends a response message of the main gateway, wherein the response message of the main gateway is forwarded to the terminal device via the bridge.

[0062] Management process of target sub-gateway: Step 6: The terminal device sends a request message to access the target sub-gateway; Step 7: The target sub-gateway records the correspondence between the LAN port in the request message and the MAC address of the terminal device in the FDB table, and matches the request message with the processing strategy; Step 8: If the match succeeds, the target sub-gateway modifies the destination MAC address of the request message to the MAC address of the target sub-gateway, obtains the processed message, and modifies the data packet type of the request message to PACKET_HOST according to the destination MAC address of the processed message, and obtains the modified message; in the bridge forwarding process, the destination MAC address of the modified message is determined to be the local MAC address according to the FDB table, and the modified message is reported to the kernel module; Step 9: The kernel module in the target sub-gateway determines that the modified message is a message sent to the local machine through the data packet type in the modified message, and then responds to the modified message to obtain a response message; Step 10: The target sub-gateway determines the LAN port in the FDB table according to the destination MAC address in the response message (ie, the MAC address of the terminal device), and sends the response message through the LAN port.

[0063] From the above interaction process, it can be seen that the same terminal device can locally manage the main gateway and the sub-gateway.

[0064] Figure 5 This is a schematic diagram of the deployment of gateway devices in the FTTR network provided in the embodiment of the present application. Figure 5 As shown, the FTTR network includes 1 main gateway and 3 sub-gateways, wherein the 3 sub-gateways are sub-gateway 1, sub-gateway 2 and sub-gateway 3, wherein the local management IP addresses of the 3 sub-gateways are the same, wherein the local management IP address of the main gateway and the local management IP address of each sub-gateway are not in the same network segment, wherein the local management IP address of the main gateway is 192.168.1.1, and the local management IP address of each sub-gateway is 192.168.2.1, wherein Figure 5 Neutron gateway 2 is the target sub-gateway mentioned above, and its MAC address is 00:00:00:00:02; sub-gateway 2 has a terminal device attached to it, and its IP address is 192.168.1.3, and its MAC address is 00:00:00:00:01. The IP address of the terminal device is in the same network segment as the local management IP address of the main gateway.

[0065] exist Figure 5In the example, each sub-gateway is connected to the main gateway through a bridge, and the next-hop address of each sub-gateway for the message on the LAN side is 192.168.1.1, so that each sub-gateway can forward the received message for accessing the local management address of the main gateway directly to the main gateway through the bridge.

[0066] After the network is successfully established, take the local management of sub-gateway 2 by the terminal device as an example to illustrate the following operations: Step A, the main gateway issues a processing strategy, wherein the processing strategy is set based on the local management address of the sub-gateway, wherein the processing strategy indicates to filter the received message at the data link layer; Specifically, the processing strategy is used to locally process the message whose destination IP address is 192.168.2.1.

[0067] For example, the processing strategy may be an ebtables rule, in which the content of the rule is PREROUTING dest ip 192.168.2.1, and the content of the action is redirect.

[0068] Step B: Sub-gateway 2 configures the processing strategy.

[0069] In addition, since the local management IP address of each sub-gateway is the same, each sub-gateway can receive the processing policy and configure the processing policy.

[0070] Step C: The terminal device is connected to the sub-gateway 2 through the lan1 port in the LAN port of the sub-gateway 2, and sends a request message through the lan1 port of the sub-gateway 2 to achieve the purpose of accessing the sub-gateway 2.

[0071] Step D, the sub-gateway receives the request message; Since all interfaces of sub-gateway 2 are under one bridge, the request message generates a new FDB table entry during the bridge forwarding process of sub-gateway 2, recording the relationship between the interface and the MAC address, as shown in Table 1: LAN port MAC Address local lan1 00:00:00:00:00:02 yes lan1 00:00:00:00:00:01 no Table 1 Step E: Sub-gateway 2 generates a response message corresponding to the request message; Specifically, the hook function in Bridge Netfilter matches the received request message with the rules in the ebtables rules. After the match is successful, the destination MAC address of the request message is modified to 00:00:00:00:00:02 according to the action in the ebtables rules to obtain the processed message; The Bridge Netfilter determines in the FDB table that the destination MAC address of the processed message is a local message, and then modifies the packet type of the request message to a local packet (PACKET_HOST), obtains the modified message, and sends the modified message to the kernel module; The kernel module determines that a response needs to be made to the modified message according to the data packet type of the modified message, and generates a response message, wherein the destination MAC address of the response message is 00:00:00:00:00:01.

[0072] Step F: Sub-gateway 2 sends the response message through the lan1 port according to the FDB table.

[0073] Step G: The terminal device receives the response message and implements local management of the sub-gateway 2.

[0074] By adding ebtables rules to the sub-gateway through the main gateway, the sub-gateway can be managed locally while the main gateway is managed locally without affecting normal business and reducing network quality.

[0075] Figure 6 This is a schematic diagram of the structure of the management device of the FTTR network neutron gateway provided in this application. Figure 6 As shown, the device is applied to the target sub-gateway, and the device includes:

[0076] The receiving module 601 is configured to receive a request message sent by the terminal device, wherein the request message carries a local management IP address of a gateway to be managed; The processing module 602 is configured to process the request message according to a preset processing strategy before the request message enters the bridge, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway.

[0077] The apparatus provided in the embodiment of the present application, after the target sub-gateway is configured to access the main gateway in bridging mode, if a request message sent by a terminal device is received, then before the request message enters the bridge, the request message is processed according to a preset processing strategy, wherein the processing strategy is to locally process messages accessing the local management IP address of the target sub-gateway, so that the target sub-gateway can locally process request messages that meet the processing strategy, and local management of the main gateway and the target sub-gateway by the same terminal device is achieved without affecting normal business and without reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

[0078] An embodiment of the present application provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the method described above when running.

[0079] An embodiment of the present application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the method described above.

[0080] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or transient medium). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

Claims

1. A method for managing a sub-gateway in an FTTR network, wherein the FTTR network comprises a main gateway and at least one sub-gateway, wherein one sub-gateway in the FTTR network is a target sub-gateway with a terminal device attached thereto, wherein the target sub-gateway accesses the main gateway in a bridging mode, and the next hop address of a message from a LAN side in the target sub-gateway is a local management IP address of the main gateway; The local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, wherein the method is applied to the target sub-gateway, and the method comprises: Receiving a request message sent by the terminal device, wherein the request message carries a local management IP address of a gateway to be managed; Before the request message enters the network bridge, the request message is processed according to a preset processing strategy, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway.

2. The method according to claim 1, characterized in that: The method for obtaining the processing strategy includes: After the target sub-gateway successfully registers with the main gateway, the processing strategy is obtained from the main gateway.

3. The method according to claim 2, characterized in that: The destination address of the message carrying the processing strategy is the local management IP address of the target sub-gateway; When the number of sub-gateways in the FTTR network is at least two, the local management IP addresses of the other sub-gateways in the FTTR network except the target sub-gateway are the same as the local management IP address of the target sub-gateway.

4. The method according to claim 1, characterized in that: The processing strategy is a processing rule in the BR_ROUTING chain in the broute table of ebtables in the Linux system, wherein the processing rule is to redirect the received message to the target sub-gateway.

5. The method according to claim 4, characterized in that: The processing rule is implemented according to the PREROUTING chain in the broute table, so that the target sub-gateway modifies the destination MAC address of the received message into the MAC address of the target sub-gateway.

6. The method according to any one of claims 1 to 5, characterized in that: The processing of the request message according to a preset processing strategy includes: The request message is processed by using a bridge-net firewall and a kernel module in a Linux system; wherein: The bridge clean firewall matches the destination IP address of the request message according to the processing strategy. If the match is successful, the bridge clean firewall processes the request message according to the processing strategy to obtain a processed message, wherein the destination MAC address of the processed message is the MAC address of the target sub-gateway; The bridge-net firewall modifies the data packet type of the processed message to a local data packet according to the destination MAC address of the processed message, obtains the modified message, and sends it to the kernel module; The kernel module responds to the modified message according to the data packet type of the modified message.

7. The method according to claim 6, characterized in that: A hook function is set at a hook point named BR_PRE_ROUTING in the bridge net firewall, wherein the hook function is used to call and execute the processing strategy.

8. A management device for a sub-gateway in an FTTR network, the FTTR network comprising a main gateway and at least one sub-gateway, wherein one of the sub-gateways in the FTTR network is a target sub-gateway with a terminal device attached thereto, wherein the target sub-gateway accesses the main gateway in a bridging mode, and the next hop address of a message from a LAN side in the target sub-gateway is a local management IP address of the main gateway; The local management IP address of the target sub-gateway and the local management IP address of the main gateway are in different network segments, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment, wherein the device is applied to the target sub-gateway, and the device includes: A receiving module, configured to receive a request message sent by the terminal device, wherein the request message carries a local management IP address of a gateway to be managed; The processing module is configured to process the request message according to a preset processing strategy before the request message enters the bridge, wherein the processing strategy is to locally process the message accessing the local management IP address of the target sub-gateway.

9. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 7.

Images