Management Method, Device, Storage Medium and Electronic Device for Sub-Gateway in FTTR Network

Abstract

A management method, device, storage medium, and electronic device for a sub-gateway in an FTTR network. The FTTR network includes a main gateway and at least one sub-gateway. A sub-gateway in the FTTR network is a target sub-gateway with terminal devices connected to it. The target sub-gateway accesses the main gateway in bridge mode. The next-hop address of a packet 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, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment. The method is applied to the target sub-gateway and includes: receiving a request packet sent by the terminal device; before the request packet enters the bridge, processing the request packet according to a preset processing policy, where the processing policy is to locally process packets accessing the local management IP address of the target sub-gateway, so that the same terminal device can locally manage the main gateway and the target sub-gateway.

Description

Technical Field

[0001] This document relates to network communication technologies, and particularly to a method, apparatus, 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 backbone of modern social communication infrastructure, with profound social value and impact. Among them, the FTTR (Fiber To The Room) technology, as a new networking method, uses the main gateway and sub-gateways of the FTTR network to replace network cables with optical fibers and lay optical fibers to each room, ensuring full-house network coverage. How to locally manage the main gateway and sub-gateways is an urgent problem to be solved. Summary of the Invention

[0003] Embodiments of this application provide a method, apparatus, 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, where the FTTR network includes a main gateway and at least one sub-gateway. One of the sub-gateways in the FTTR network is a target sub-gateway with terminal devices connected below. The target sub-gateway accesses the main gateway in bridge mode, and the next-hop address of a packet 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, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment. The method is applied to the target sub-gateway and includes:

[0005] Receiving a request packet sent by the terminal device, where the request packet carries the local management IP address of the gateway to be managed.

[0006] Before the request packet enters the bridge, processing the request packet according to a preset processing policy, where the processing policy is to locally process a packet accessing the local management IP address of the target sub-gateway.

[0007] An apparatus for managing a sub - gateway in an FTTR network, where the FTTR network includes a main gateway and at least one sub - gateway. One of the sub - gateways in the FTTR network is a target sub - gateway with terminal devices connected to it. The target sub - gateway accesses the main gateway in bridge mode, and the next - hop address of the packets 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, and the IP address of the terminal device and the local management IP address of the main gateway are in the same network segment. The apparatus is applied to the target sub - gateway and includes:

[0008] A receiving module, configured to receive a request packet sent by the terminal device, where the request packet carries the local management IP address of the gateway to be managed.

[0009] A processing module, configured to process the request packet according to a preset processing policy before the request packet enters the bridge, where the processing policy is to locally process the packets accessing the local management IP address of the target sub - gateway.

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

[0011] An electronic device includes a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to execute the method described above.

[0012] In an embodiment of the present application, after the target sub - gateway is configured to access the main gateway in bridge mode, if a request packet sent by the terminal device is received, the request packet is processed according to a preset processing policy before the request packet enters the bridge, where the processing policy is to locally process the packets accessing the local management IP address of the target sub - gateway, enabling the target sub - gateway to locally process the request packets that meet the processing policy, and realizing the local management of the main gateway and the target sub - gateway by the same terminal device without affecting normal services and reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

[0013] Other features and advantages of the present application will be described in the following specification, and part of them will become obvious from the specification or be understood by implementing the present application. Other advantages of the present application can be realized and obtained through the solutions described in the specification and the accompanying drawings. Description of the Drawings

[0014] The accompanying drawings are used to provide an understanding of the technical solutions 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 solutions of the present application and do not constitute a limitation to the technical solutions of the present application.

[0015] Figure 1 It is a schematic structural diagram of the FTTR network provided by the embodiment of the present application;

[0016] Figure 2 It is a schematic flowchart of the management method of the sub-gateway in the FTTR network provided by the embodiment of the present application;

[0017] Figure 3 It is a schematic diagram of the processing mode of the target sub-gateway provided by the embodiment of the present application;

[0018] Figure 4 It is an interaction schematic diagram of the management method of the sub-gateway in the FTTR network provided by the embodiment of the present application;

[0019] Figure 5 It is a deployment schematic diagram of the gateway device in the FTTR network provided by the embodiment of the present application;

[0020] Figure 6 It is a schematic structural diagram of the management device of the sub-gateway in the FTTR network provided by the present application. Detailed implementation manners

[0021] The present application describes multiple embodiments, but the description is exemplary rather than restrictive, and it is obvious to those of ordinary skill in the art that there can be more embodiments and implementation solutions within the scope covered by the embodiments described in the present application. Although many possible feature combinations are shown in the accompanying drawings and discussed in the detailed implementation manners, many other combination ways of the disclosed features are also possible. Unless specifically restricted, any feature or element of any embodiment can be combined with any other feature or element in any other embodiment, or can replace any other feature or element in any other embodiment.

[0022] The present application includes and contemplates combinations with features and elements known to those of ordinary skill in the art. The embodiments, features, and elements already disclosed in the present application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in the present application can be implemented alone or in any suitable combination. Therefore, the embodiments are not subject to other limitations except those made according to the appended claims and their equivalent replacements. In addition, various modifications and changes can be made within the protection scope of the appended claims.

[0023] 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 depend on the specific order of the steps described herein, the method or process should not be limited to the specific order of steps described. As will be understood by those of ordinary skill in the art, other step orders are possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation on the claims. In addition, the claims directed to the method and / or process should not be limited to performing their steps in the order written, and those skilled in the art can readily understand that these orders can vary and still remain within the spirit and scope of the embodiments of the present application.

[0024] In the embodiments of the present application, the FTTR network includes a main gateway and at least one sub-gateway, wherein one of the sub-gateways in the FTTR network is a target sub-gateway to which terminal devices are connected.

[0025] Figure 1 It is a schematic structural diagram of the FTTR network provided for the embodiments of the present application. As Figure 1 shown, the FTTR network includes a main gateway and N + 1 sub-gateways, where the N + 1 sub-gateways are respectively a target sub-gateway, sub-gateway 1, sub-gateway 2, sub-gateway 3,..., and sub-gateway N, and the value of N can be 0 or any positive integer.

[0026] Among them, the target sub-gateway accesses the main gateway in bridge mode, and the next-hop address of the packet from the LAN side in the target sub-gateway is the local management IP address of the main gateway; among them, bridge mode is a working mode of network devices that allows network devices to forward packets at the data link layer rather than route packets at the network layer. In Figure 1 the shown structure, the packet from the LAN side can be a request packet for a terminal device to remotely access the gateway.

[0027] Among them, 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.

[0028] Among them, the local management IP address is the IP address assigned to the gateway for managing and configuring the gateway in the local network. By accessing the local management IP address of the gateway, external devices can remotely access the gateway for monitoring, updating, and troubleshooting.

[0029] The target sub-gateway with a terminal device attached is connected to the main gateway in bridge mode, and the next-hop address of the packets 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 is connected to the main gateway in bridge 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 packets sent by the terminal device can be directly sent to the main gateway through the bridge.

[0030] When the terminal device sends a request packet for local management of the main gateway, the request packet can be successfully sent to the main gateway. Therefore, normal communication can be established between the main gateway and the terminal device, and local management of the main gateway by the terminal device can be achieved.

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

[0032] To solve the above technical problems, the embodiments of the present application propose the following solutions, including:

[0033] Figure 2 It is a schematic flow diagram of the method for managing the sub-gateway in the FTTR network provided by the embodiments of the present application. As Figure 2 shown, the method is applied to the target sub-gateway, and the method includes:

[0034] Step 201, receive a request packet sent by a terminal device, where the request packet carries the local management IP address of the gateway to be managed;

[0035] 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.

[0036] Among them, the local management IP address of the gateway to be managed in the request packet 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 packet carries the local management IP address of the main gateway, the request packet is used for local management of the main gateway; when the request packet carries the local management IP address of the target sub-gateway, the request packet is used for local management of the target sub-gateway.

[0037] Among them, 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, thereby achieving the purpose of carrying the local management IP address of the gateway to be managed.

[0038] Step 202: Before the request message enters the bridge, process the request message according to a preset processing policy, where the processing policy is to locally process the message accessing the local management IP address of the target sub-gateway.

[0039] Among them, before the target sub-gateway sends the received request message through the bridge, since the processing policy 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 meets this processing policy. Therefore, the request message is locally processed by the target sub-gateway and will not participate in the forwarding operation of the bridge, 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 meet this processing policy. Therefore, the request message will continue to participate in the sending operation of the bridge and is sent by the target sub-gateway to the main gateway through the bridge, realizing the local management of the main gateway.

[0040] The method provided by the embodiments of the present application, after the target sub-gateway is configured to access the main gateway in bridge mode, if a request message sent by a terminal device is received, then before the request message enters the bridge, process the request message according to a preset processing policy, where the processing policy is to locally process the message accessing the local management IP address of the target sub-gateway, enabling the target sub-gateway to locally process the request message that meets the processing policy, and realizing the local management of the main gateway and the target sub-gateway by the same terminal device without affecting normal services and without reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

[0041] The method provided by the embodiments of the present application will be described below:

[0042] In an exemplary embodiment, the method for obtaining the processing policy includes:

[0043] After the target sub-gateway successfully registers with the main gateway, obtain the processing policy from the main gateway.

[0044] Specifically, after the target sub-gateway registers with the main gateway, if the registration of the target sub-gateway is successful, the main gateway will send this 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 this processing policy.

[0045] Preferably, the destination address of the packet carrying the processing policy is the local management IP address of the target sub-gateway;

[0046] Wherein, when the number of sub-gateways in the FTTR network is at least two, the local management IP addresses of 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.

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

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

[0049] Specifically, the processing policy is the processing rule in the BR_ROUTING chain in the broute table of ebtables in the Linux system, where the processing rule is to redirect the received packet to the target sub-gateway.

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

[0051] 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 the second layer (data link layer) or routed at the third layer (network layer).

[0052] The rules in the BR_ROUTING chain can be set according to conditions such as the source MAC address, destination MAC address, and protocol type of the data packet. In the BR_ROUTING chain, the ACCEPT target means that the data packet will be bridged and forwarded, while the DROP target means that the data packet will be routed. This mechanism enables network administrators to finely control the forwarding behavior of data packets. For example, rules can be set to ensure that data packets with a specific MAC address are routed to a specific network interface, or to control whether specific types of traffic are allowed to pass through the bridge.

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

[0054] Specifically, by setting a processing rule in the BR_ROUTING chain, the destination MAC (dst MAC) address of the message received by the target sub-gateway is modified to the MAC address of the target sub-gateway.

[0055] In the embodiment of the present application, the processing rule in the BR_ROUTING chain is a redirection rule, where 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.

[0056] Furthermore, the redirection rule can be implemented by using the PREROUTING chain.

[0057] Among them, the PREROUTING chain is another built-in chain in ebtables, which processes the message before it is bridged and forwarded. The message is modified by using the PREROUTING chain. In the embodiment of the present application, the destination MAC address of the message is modified to the MAC address of the target sub-gateway by using the PREROUTING chain.

[0058] In an exemplary embodiment, processing the request message according to a preset processing policy includes:

[0059] Using the bridge net firewall (Bridge Netfilter) and kernel module in the Linux system to process the request message; where:

[0060] The bridge net firewall matches the destination IP address of the request message according to the processing policy. If the match is successful, the bridge net firewall processes the request message according to the processing policy to obtain a processed message, where the destination MAC address of the processed message is the MAC address of the target sub-gateway;

[0061] The bridging clean firewall modifies the packet type of the processed packet to a local packet according to the destination MAC address of the processed packet, obtains a modified packet, and sends it to the kernel module;

[0062] The kernel module responds to the modified packet according to the packet type of the modified packet.

[0063] Preferably, a hook function is set at the hook point named BR_PRE_ROUTING in the bridging clean firewall, and the hook function is used to call and execute the processing policy.

[0064] Among them, BR_PRE_ROUTING is a hook point in Bridge Netfilter, which is called before a packet enters the Linux kernel bridge. The function of this hook point is to provide an opportunity to filter, modify or perform other necessary operations on the packet before it is further processed by the bridge. By using BR_PRE_ROUTING, preprocessing can be performed on the packets passing through the bridge before they reach the IP layer.

[0065] 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.

[0066] From the above process, it can be seen that, without affecting normal services and without degrading network quality, the processing rules in the BR_ROUTING chain in the broute table are executed by using the hook function set in BridgeNetfilter, and there is no need for excessive code modification, which has good versatility.

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

[0068] Specifically, before the bridging clean firewall matches the request packet by using the processing policy, the data forwarding table (Forwarding Database, FDB) of the target sub-gateway is updated according to the request packet;

[0069] Among them, the kernel module sends the response packet corresponding to the modified packet by using the updated data forwarding table.

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

[0071] Figure 3Schematic diagram of the processing method of the target sub - gateway provided by the embodiments of this application. As Figure 3 shown, in the Figure 3 schematic diagram shown, it involves multiple built - in chains in ebtables, which are respectively used for different data processing stages:

[0072] BR_LOCAL_IN chain: This chain is used to process packets that have passed through 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 a broadcast or multicast packet. In the Linux kernel, the BR_LOCAL_IN chain is executed before the packet is passed to the local network stack, allowing for final filtering or modification.

[0073] 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, enabling the administrator to control the forwarding, discarding, or modification of the packet. In the Linux kernel, this chain provides routing and forwarding functions at the data link layer.

[0074] BR_LOCAL_OUT chain: This chain manages packets generated locally, that is, packets generated by the local machine and ready to be sent through the bridge. Before the packet passes through IP - layer routing and is ready to be sent, the BR_LOCAL_OUT chain is called. In the Linux kernel, this chain is executed before the packet is sent to the network, allowing for final filtering or modification.

[0075] BR_POST_ROUTING chain: This chain processes the packet just before it leaves the local machine, for final checking and modification.

[0076] In the Figure 3 shown process, the processing process of the target sub - gateway is as follows:

[0077] The hook function set at the hook point BR_PRE_ROUTING in Bridge Netfilter calls the processing rules in the BR_BROUTING chain in the broute table, and uses this processing rule to match the destination IP address of the received request packet;

[0078] If the match is successful, the hook function modifies the destination MAC address of the request packet to the MAC address of the target sub - gateway, obtaining the processed packet; Bridge Netfilter modifies the processed packet to a local machine data packet according to the destination MAC address of the processed packet, and after being processed by all hook functions on the BR_LOCAL_IN chain, it is sent to the local, as specifically shown by the arrow marked 2;

[0079] If the match fails, after being processed by all the hook functions on the BR_FORWARD chain, the request message will be forwarded by the bridge. For details, see the arrow marked 1.

[0080] In addition, for the messages generated by the target sub-gateway (such as the response message corresponding to the request message), after being processed by all the hook functions on the BR_LOCAL_OUT chain, they will be directly output. For details, see the arrow marked 3.

[0081] Among them, before the message is output, all the hook functions on the BR_POST_ROUTING chain can be used to check or modify the message to be sent.

[0082] As can be seen from the above process, on the premise of not affecting the normal business and not reducing the network quality, by using multiple existing built-in chains in ebtables and the inherent functions in Bridge Netfilter, the local management of the main gateway and the target sub-gateway by the same terminal device is realized without excessive code modification, which has good generality.

[0083] Figure 4 This is an interaction schematic diagram of the management method of the sub-gateway in the FTTR network provided by the embodiment of the present application. As Figure 4 shown, the method sequentially includes:

[0084] Subnet registration process:

[0085] Step 1: The target sub-gateway sends a registration message to the main gateway;

[0086] Step 2: After the target subnet registration is successful, the main gateway sends a processing policy to the target sub-gateway, where the processing policy is a processing rule set based on the local management IP address of the target sub-gateway, and this processing rule is used for the target sub-gateway to perform local processing on the received request message;

[0087] Step 3: The target sub-gateway configures this processing policy.

[0088] Main gateway management process:

[0089] 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. Among them, the target sub-gateway generates a default route, and the next-hop address of this default route points to the IP address of this VLAN in the main gateway. The terminal devices connected to the target sub-gateway will obtain IP addresses through the DHCP server in the VLAN of the main gateway. Among them, the IP addresses of the terminal devices and the local management IP address of the main gateway are in the same network segment. 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.

[0090] Step 4: The terminal device sends a request message to access the main gateway, and the request message to access the main gateway is forwarded to the main gateway by the bridge;

[0091] Step 5: The main gateway sends a response message of the main gateway, and the response message of the main gateway is forwarded to the terminal device by the bridge.

[0092] Management process of the target sub - gateway:

[0093] Step 6: The terminal device sends a request message to access the target sub - gateway;

[0094] Step 7: The target sub - gateway records the correspondence between the LAN port and the MAC address of the terminal device in the request message in the FDB table, and performs a matching operation on the request message and the processing policy;

[0095] Step 8: If the matching is successful, the target sub - gateway modifies the destination MAC address of the request message to the MAC address of the target sub - gateway to obtain a processed message, and modifies the packet type of the request message to PACKET_HOST according to the destination MAC address of the processed message to obtain a modified message; during the bridge forwarding process, it is judged according to the FDB table that the destination MAC address of the modified message is the local MAC address, and the modified message is reported to the kernel module;

[0096] 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 packet type in the modified message, and then responds to the modified message to obtain a response message;

[0097] Step 10: The target sub - gateway determines the LAN port in the FDB table according to the destination MAC address (i.e., the MAC address of the terminal device) in the response message, and sends the response message through this LAN port.

[0098] From the above interaction process, it can be seen that the same terminal device can perform local management on the main gateway and the sub - gateway.

[0099] Figure 5 It is a deployment schematic diagram of the gateway device in the FTTR network provided by the embodiment of the present application. As Figure 5 shown, the FTTR network includes 1 main gateway and 3 sub - gateways. The 3 sub - gateways are sub - gateway 1, sub - gateway 2, and sub - gateway 3 respectively. The local management IP addresses of the 3 sub - gateways are the same. The local management IP address of the main gateway is not in the same network segment as the local management IP address of each sub - gateway. 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. Among them Figure 5The neutron gateway 2 is the target sub - gateway in the above text, with a MAC address of 00:00:00:00:02; there are terminal devices connected under the sub - gateway 2, where the IP address of the terminal device is 192.168.1.3 and the MAC address is 00:00:00:00:01. The IP address of the terminal device and the local management IP address of the main gateway are in the same network segment.

[0100] In Figure 5 each sub - gateway is connected to the main gateway through the bridging method. The next - hop address of each sub - gateway for the LAN - side packets is 192.168.1.1, so that each sub - gateway can directly forward the received packets for accessing the local management address of the main gateway to the main gateway through the bridge.

[0101] After successful network deployment, taking the local management of the sub - gateway 2 by the terminal device as an example, the following operations are performed:

[0102] Step A: The main gateway issues a processing policy, which is set based on the local management address of the sub - gateway. The processing policy instructs to perform a filtering operation on the received packets at the data - link layer;

[0103] Specifically, the processing policy is used to perform local processing on the packets with a destination IP address of 192.168.2.1.

[0104] For example, the processing policy can be an ebtables rule. The content of the rule in the ebtables rule is PREROUTING dest ip 192.168.2.1, and the content of the action is redirect.

[0105] Step B: The sub - gateway 2 configures the processing policy.

[0106] In addition, since the local management IP addresses of each sub - gateway are the same, each sub - gateway can receive the processing policy and will configure the processing policy.

[0107] Step C: The terminal device connects to the sub - gateway 2 through the lan1 port in the LAN port of the sub - gateway 2 and sends a request packet through the lan1 port of the sub - gateway 2 to achieve the purpose of accessing the sub - gateway 2.

[0108] Step D: The sub - gateway receives the request packet;

[0109] Since all interfaces of the sub - gateway 2 are under one bridge, a new FDB entry is generated during the bridge forwarding process of the sub - gateway 2 for the request packet, recording the relationship between the interface and the mac address, as shown in Table 1:

[0110] LAN port MAC address Local lan1 00:00:00:00:00:02 Yes lan1 00:00:00:00:00:01 No

[0111] Table 1

[0112] Step E, the sub-gateway 2 generates a response message corresponding to the request message;

[0113] Specifically, the hook function in Bridge Netfilter matches the received request message with the rules in the ebtables rules. After successful matching, 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, and the processed message is obtained;

[0114] If Bridge Netfilter determines that the destination MAC address of the processed message in the FDB table is a local message, it 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;

[0115] The kernel module determines that a response needs to be made to the modified message according to the packet type of the modified message, and generates a response message, where the destination MAC address of the response message is 00:00:00:00:00:01.

[0116] Step F, the sub-gateway 2 sends the response message through the lan1 port according to the FDB table.

[0117] Step G, the terminal device receives the response message to implement local management of the sub-gateway 2.

[0118] By adding ebtables rules for the sub-gateway through the main gateway, without affecting normal services and without reducing network quality, while implementing local management of the main gateway, local management of the sub-gateway can also be performed.

[0119] Figure 6 It is a schematic structural diagram of the management device for the sub-gateway in the FTTR network provided by this application. As Figure 6 shown, the device is applied to the target sub-gateway, and the device includes:

[0120] A receiving module 601, configured to receive the request message sent by the terminal device, where the request message carries the local management IP address of the gateway to be managed;

[0121] A processing module 602, configured to process the request message according to a preset processing policy before the request message enters the bridge, where the processing policy is to locally process the message accessing the local management IP address of the target sub-gateway.

[0122] The device provided by the embodiment of the present application, after the target sub-gateway is configured to access the main gateway in bridge mode, if a request message sent by a terminal device is received, before the request message enters the bridge, the request message is processed according to a preset processing policy, where the processing policy is to perform local processing on the message accessing the local management IP address of the target sub-gateway, so that the target sub-gateway can perform local processing on the request message that meets the processing policy, and realize the local management of the main gateway and the target sub-gateway by the same terminal device without affecting normal services and reducing network quality, thereby improving the comprehensiveness of gateway management in the FTTR network.

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

[0124] The embodiment of the present application provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the method described above.

[0125] Those of ordinary skill in the art can understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, and their appropriate combinations. In the hardware implementation, the division of the functional modules / units mentioned above 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 executed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium). As is well known to those of ordinary skill 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 technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, tape, 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, as is well known to those of ordinary skill in the art, a communication medium typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium.

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 the local management IP address of the gateway to be managed, wherein the local management IP address in the request message is the local management IP address of the main gateway or the local management IP address of the target sub-gateway; Before the request message enters the bridge, the request message is processed according to a processing strategy preset in a forwarding data FDB table, wherein the processing strategy includes a first rule and a second rule of a LAN port connected to the terminal device, wherein the first rule is to process a message accessing the local management IP address of the target sub-gateway as a message whose destination MAC address is the MAC address of the target sub-gateway for local processing; and the second rule is to send a message whose destination MAC address is the MAC address of the terminal device through the LAN port; wherein: If the local management IP address in the request message is the local management IP address of the target sub-gateway, then according to the first rule, obtaining a processed message corresponding to the request message, wherein the destination MAC address of the processed message is the MAC address of the target sub-gateway; Generate a response message corresponding to the processed message, wherein the destination MAC address in the response message is the MAC address of the terminal device, and send the response message through the LAN port according to the second rule.

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 rule in the BR_ROUTING chain in the broute table of ebtables in the Linux system, wherein the first rule is to redirect the received message to the target sub-gateway; and the second rule is the correspondence between the MAC address of the terminal device and the LAN port.

5. The method according to claim 4, characterized in that: The first 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 to 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 the processing strategy preset in the FDB table 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 first rule 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, wherein the local management IP address in the request message is the local management IP address of the main gateway or the local management IP address of the target sub-gateway; A processing module, configured to process the request message according to a processing strategy preset in an FDB table before the request message enters the bridge, wherein the processing strategy includes a first rule and a second rule of a LAN port connected to the terminal device, wherein the first rule is to process a message accessing the local management IP address of the target sub-gateway as a message whose destination MAC address is the MAC address of the target sub-gateway for local processing; and the second rule is to send a message whose destination MAC address is the MAC address of the terminal device through the LAN port; wherein: If the local management IP address in the request message is the local management IP address of the target sub-gateway, then according to the first rule, obtaining a processed message corresponding to the request message, wherein the destination MAC address of the processed message is the MAC address of the target sub-gateway; Generate a response message corresponding to the processed message, wherein the destination MAC address in the response message is the MAC address of the terminal device, and send the response message through the LAN port according to the second rule.

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