A cross-vpn multicast method, device, network equipment and medium
By configuring a global dynamic mapping table in network devices, the security policy of virtual interface inheritance into interface binding is implemented, which solves the packet loss problem in cross-VPN multicast, ensures the continuity and security of multicast services, and improves the reliability and flexibility of network devices.
Patent Information
- Application Number
- CN202611479048.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-21
- Publication Date
- 2026-11-06
Smart Images
Figure CN123055482A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of virtual private network technology, and in particular to a cross-VPN multicast method, apparatus, network device and medium. Background Technology
[0002] With the widespread application of network virtualization technology, cross-VPN multicast services are becoming increasingly common in practical deployments. In cross-VPN multicast scenarios, the ingress and egress interfaces of multicast packets on network devices belong to different VPNs. When a network device receives a multicast packet through the ingress interface, it creates a cross-VPN virtual interface, loops back through the cross-VPN virtual interface to receive the multicast packet, and then forwards the multicast packet through the egress interface.
[0003] In the existing security configuration, each physical interface is associated with a corresponding security policy. When implementing cross-VPN multicast based on the security policy associated with each physical interface, after the network device receives multicast packets via loopback through the cross-VPN virtual interface, because this cross-VPN virtual interface is not a physical interface (i.e., it is not associated with a security policy), the network device cannot find a security policy matching the multicast packet and discards the multicast packet, resulting in service interruption. Summary of the Invention
[0004] The purpose of this application is to provide a cross-VPN multicast method, apparatus, network device, and medium to ensure the continuity of cross-VPN multicast services under security policy control. The specific technical solution is as follows:
[0005] In a first aspect, embodiments of this application provide a cross-VPN multicast method applied to a network device. The method includes: receiving a multicast packet from a first VPN via a first physical interface, wherein the destination VPN of the multicast packet is a second VPN; receiving the multicast packet via a target virtual interface that loops back through the target virtual interface, wherein the target virtual interface connects the first VPN and the second VPN; searching a global dynamic mapping table for a target mapping table entry that includes the target virtual interface and the second VPN, wherein the mapping table entry in the global dynamic mapping table includes a virtual interface, a destination VPN, and a security policy bound to the packet ingress interface; searching for a target security policy that matches the multicast packet from the security policies included in the target mapping table entry; and forwarding the multicast packet via a second physical interface corresponding to the multicast packet under the second VPN when the target security policy indicates permission.
[0006] In some embodiments, the method further includes: if the target mapping entry is not found in the global dynamic mapping table, then, according to the security policy bound to the first physical interface, a target mapping entry is established in the global dynamic mapping table, the target mapping entry including the security policy bound to the first physical interface; and the step of searching for a target security policy matching the multicast message from the security policies included in the target mapping entry is executed.
[0007] In some embodiments, the step of establishing a target mapping entry in the global dynamic mapping table according to the security policy bound to the first physical interface includes: obtaining a security policy to be inherited carrying a preset tag from the security policy bound to the first physical interface, the preset tag indicating that the security policy is used for cross-VPN multicast; establishing a target mapping entry in the global dynamic mapping table, and adding the security policy to be inherited to the target mapping entry.
[0008] In some embodiments, the method further includes: deleting the target virtual interface when the multicast forwarding from the first VPN to the second VPN ends; and deleting the target mapping entry that includes the target virtual interface.
[0009] In some embodiments, the mapping entry includes a hash value generated based on the virtual interface and the destination VPN; the step of searching for a target mapping entry in the global dynamic mapping table that includes the target virtual interface and the second VPN includes: generating a target hash value based on the target virtual interface and the second VPN; and searching for a target mapping entry in the global dynamic mapping table that includes the target hash value.
[0010] In some embodiments, the mapping entry may further include the packet ingress interface and the source VPN.
[0011] Secondly, embodiments of this application provide a cross-VPN multicast device applied to a network device. The device includes: a receiving module, configured to receive multicast packets from a first VPN via a first physical interface, wherein the destination VPN of the multicast packets is a second VPN; a loopback module, configured to receive the multicast packets via a target virtual interface, wherein the target virtual interface connects the first VPN and the second VPN; a lookup module, configured to look up a target mapping table entry in a global dynamic mapping table that includes the target virtual interface and the second VPN, wherein the mapping table entry in the global dynamic mapping table includes a virtual interface, a destination VPN, and a security policy bound to the packet ingress interface; and to look up a target security policy matching the multicast packets from the security policies included in the target mapping table entry; and a forwarding module, configured to forward the multicast packets via the second physical interface corresponding to the multicast packets under the second VPN when the target security policy indicates permission.
[0012] In some embodiments, the lookup module is further configured to, if the target mapping entry is not found in the global dynamic mapping table, establish a target mapping entry in the global dynamic mapping table according to the security policy bound to the first physical interface, wherein the target mapping entry includes the security policy bound to the first physical interface; and search for a target security policy that matches the multicast message from the security policies included in the target mapping entry.
[0013] In some embodiments, the lookup module is specifically used to obtain a security policy to be inherited carrying a preset tag from the security policy bound to the first physical interface, the preset tag indicating that the security policy is used for cross-VPN multicast; to establish a target mapping table entry in the global dynamic mapping table, and to add the security policy to be inherited to the target mapping table entry.
[0014] In some embodiments, the apparatus further includes: a deletion module, configured to delete the target virtual interface when multicast forwarding from the first VPN to the second VPN ends; and delete the target mapping entry including the target virtual interface.
[0015] In some embodiments, the mapping entry includes a hash value generated based on the virtual interface and the destination VPN; the lookup module is specifically configured to generate a target hash value based on the target virtual interface and the second VPN; and to look up a target mapping entry that includes the target hash value in the global dynamic mapping table.
[0016] In some embodiments, the mapping entry may further include the packet ingress interface and the source VPN.
[0017] Thirdly, embodiments of this application provide a network device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement any of the methods provided in the first aspect when executing the programs stored in the memory.
[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods provided in the first aspect.
[0019] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods provided in the first aspect.
[0020] Beneficial effects of the embodiments in this application:
[0021] In the technical solution provided in this application embodiment, a global dynamic mapping table is configured in the network device. This global dynamic mapping table includes entries for virtual interfaces, destination VPNs, and security policies bound to the incoming interface. In other words, the global dynamic mapping table enables virtual interfaces to inherit the security policies bound to the incoming interface. When a multicast packet forwarded across VPNs is received through a physical interface, the network device can look up the security policy inherited by the virtual interface from the incoming interface (i.e., the physical interface receiving the multicast packet) through the virtual interface connecting the two VPNs and the destination VPN. Following the found security policy, the multicast packet is forwarded under the destination VPN. This solves the packet loss problem caused by the network device's inability to find a matching security policy for the multicast packet when the cross-VPN virtual interface lacks a security policy, thus ensuring the continuity of cross-VPN multicast services under security policy control.
[0022] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description
[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.
[0024] Figure 1 A schematic diagram of the slow forwarding process for cross-VPN multicast;
[0025] Figure 2 This is a first schematic diagram of a cross-VPN multicast method provided in an embodiment of this application;
[0026] Figure 3 This is a second schematic diagram of the cross-VPN multicast method provided in the embodiments of this application;
[0027] Figure 4 A system architecture diagram for cross-VPN multicast provided in this application embodiment;
[0028] Figure 5 A schematic diagram of the dynamic mapping entry generation process provided in this application embodiment;
[0029] Figure 6 A schematic diagram of a cross-VPN multicast device provided in an embodiment of this application;
[0030] Figure 7 This is a schematic diagram of a network device provided in an embodiment of this application. Detailed Implementation
[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.
[0032] In cross-VPN multicast scenarios, due to the unique characteristics of multicast traffic, network devices employ a "slow forwarding" mechanism, which involves sending multicast packets to the Central Processing Unit (CPU) for software forwarding. The slow forwarding process for cross-VPN multicast is as follows: Figure 1 As shown, multicast packets enter the network device from the multicast source within VPN1 (source VPN). The network device forwards the multicast packets to the multicast receiver within VPN2 (destination VPN). The network device is configured with physical interface 1 and physical interface 2. Physical interface 1 is the ingress interface for multicast packets and belongs to security domain 1, while physical interface 2 is the egress interface for multicast packets and belongs to security domain 2. In the network device, the slow forwarding process for cross-VPN multicast is divided into two stages, as follows:
[0033] Phase 1 forwarding: Multicast packets enter the network device through physical interface 1, which belongs to VPN1 and is assigned to security domain 1. At this point, the incoming interface of the multicast packet is a valid physical interface 1, and the network device (i.e., the CPU) can correctly identify the security domain (i.e., security domain 1) to which the incoming interface belongs, thus matching the security policy bound to physical interface 1. If the security policy that successfully matches the multicast packet allows access from security domain 1 to other security domains (such as security domain 2), the network device searches the multicast forwarding table associated with VPN1, obtains the cross-VPN virtual interface, and loops back to receive multicast packets through the cross-VPN virtual interface, entering the forwarding context of VPN2.
[0034] Second-stage forwarding: After receiving the multicast packet through the cross-VPN virtual interface loopback, the network device looks up the multicast forwarding table associated with VPN2 to obtain the outgoing interface (i.e., physical interface 2) of the multicast packet; and forwards the multicast packet through physical interface 2.
[0035] However, during the second-stage forwarding process, the ingress interface for the multicast packet is a cross-VPN virtual interface. This cross-VPN virtual interface is not a physical interface on the network device, but rather a temporary logical interface created internally by the software. Its index is a virtual value allocated by the CPU, such as -1006630398. Because the cross-VPN virtual interface is not a physical interface configured by the administrator and is not bound to any security domain / policy, the network device cannot identify the security domain to which it belongs. Consequently, after receiving the multicast packet via the cross-VPN virtual interface, the network device's packet processing log shows that the ingress security domain (the ingress security domain corresponding to the ingress interface) is empty (e.g., Src-Zone=-), and the ingress interface is an abnormal value (e.g., If-In=-1006630398). Because it cannot find the corresponding inter-security policy (ingress zone pair) (i.e., policy matching fails), the multicast packet is discarded, causing a multicast service interruption.
[0036] To address the aforementioned issues, a solution is provided in related technologies, as follows: Multicast addresses are imported into security domains, enabling network devices to perform security policy matching based on multicast group addresses. For example, destination multicast addresses (such as FF1E::1, FF1E::6) are imported into security domain 1, and source address prefixes (such as 190:: / 64) are imported into security domain 2. When the destination multicast address of a multicast packet from security domain 1 is FF1E::1, and the source address prefix of the multicast packet is the source address prefix 190:: / 64 in security domain 2, the multicast forwarding table of VPN2 associated with security domain 2 is searched to obtain the outgoing interface of the multicast packet; and the multicast packet is forwarded through this outgoing interface. While this solution can address the issue of traffic disruption to some extent, it has significant limitations: administrators need to configure security domains separately for each multicast address, which is cumbersome and difficult to maintain; when multicast addresses change or are added, the security domain configurations need to be modified synchronously, lacking flexibility and scalability; furthermore, this solution cannot reuse fine-grained security policies already configured on physical interfaces, resulting in fragmented security policy management.
[0037] To ensure the continuity of cross-VPN multicast services under security policy control, embodiments of this application provide a cross-VPN multicast method, such as... Figure 2 As shown, applied to network devices, this method includes the following steps:
[0038] Step S201: Receive a multicast message from the first VPN through the first physical interface. The destination VPN of the multicast message is the second VPN.
[0039] Step S202: Receive multicast messages via loopback through the target virtual interface, which connects to the first VPN and the second VPN.
[0040] Step S203: In the global dynamic mapping table, find the target mapping table entry corresponding to the target virtual interface and the second VPN. The mapping table entry in the global dynamic mapping table includes the virtual interface, the destination VPN and the security policy bound to the packet ingress interface.
[0041] Step S204: Search for the target security policy that matches the multicast message from the security policies included in the target mapping table entry;
[0042] Step S205: When the target security policy indicates permission, the multicast message is forwarded through the second physical interface corresponding to the multicast message under the second VPN.
[0043] In the technical solution provided in this application embodiment, a global dynamic mapping table is configured in the network device. This global dynamic mapping table includes entries for virtual interfaces, destination VPNs, and security policies bound to the incoming interface. In other words, the global dynamic mapping table enables virtual interfaces to inherit the security policies bound to the incoming interface. When a multicast packet forwarded across VPNs is received through a physical interface, the network device can look up the security policy inherited by the virtual interface from the incoming interface (i.e., the physical interface receiving the multicast packet) through the virtual interface connecting the two VPNs and the destination VPN. Following the found security policy, the multicast packet is forwarded under the destination VPN. This solves the packet loss problem caused by the network device's inability to find a matching security policy for the multicast packet when the cross-VPN virtual interface lacks a security policy, thus ensuring the continuity of cross-VPN multicast services under security policy control.
[0044] In this embodiment, the network device can be a firewall, gateway, or other device that performs security policy management.
[0045] In step S201 above, the first physical interface is any physical interface on the network device that belongs to the first VPN. When the network device receives a multicast message, it can extract the ingress interface index, i.e., the index of the first physical interface, such as Route-Aggregation1.1001, from the ingress interface information of the multicast message.
[0046] In addition, network devices can obtain the source VPN (i.e., the first VPN) and destination VPN (i.e., the second VPN) corresponding to the multicast message from the forwarding table entries based on the first physical interface and the message header information of the multicast message (such as the destination multicast address and the source address).
[0047] In some embodiments, a security policy is bound to the first physical interface. The network device can search for a security policy matching the multicast message from the security policies bound to the first physical interface based on the message characteristics (such as source address, destination address, source port, destination address, and protocol). When the security policy matching the multicast message indicates permission (allowing the first VPN to access the second VPN and allowing the security domain to which the first physical interface belongs to access the destination security domain of the multicast message), the network device can execute step S202. When the security policy matching the multicast message indicates denial (denying the first VPN from accessing the second VPN and denying the security domain to which the first physical interface belongs from accessing the destination security domain of the multicast message), the network device can discard the multicast message. Managing multicast messages based on security policies improves network security.
[0048] In step S202 above, the target virtual interface is the virtual interface connecting the first VPN and the second VPN, i.e., the target virtual interface is a cross-VPN virtual interface. If the network device has already created a virtual interface connecting the first VPN and the second VPN, the network device determines this virtual interface as the target virtual interface and receives multicast packets through the target virtual interface. If the network device has not created a virtual interface connecting the first VPN and the second VPN, the network device creates such an interface as the target virtual interface and receives multicast packets through the target virtual interface. Afterwards, the second stage of the slow forwarding mechanism begins.
[0049] In step S203 above, the global dynamic mapping table includes at least one mapping table entry. Each mapping table entry includes a security policy bound to the virtual interface, the destination VPN, and the packet ingress interface (i.e., the source physical interface). In this embodiment, each mapping table entry may also include the packet ingress interface and the source VPN, etc., without limitation. The fields included in the global dynamic mapping table, and the data type and meaning of each field, can be found in Table 1.
[0050] Table 1
[0051]
[0052] By adopting the five-tuple structure of virtual interface, source physical interface, source VPN, destination VPN and inherited policy list, complete backtracking and precise inheritance of policy source are achieved.
[0053] In this embodiment, after the network device receives a multicast packet via loopback through the target virtual interface, the ingress interface of the multicast packet is the target virtual interface. The network device uses the target virtual interface and the second VPN (i.e., the destination VPN) as keys to query the global dynamic mapping table and obtain the destination mapping table entries corresponding to the target virtual interface and the second VPN, which are then used as the target mapping table entries.
[0054] In step S204 above, the network device obtains the security policies included in the target mapping table, such as the inherited policy list in Table 1 above. Based on the packet characteristics of the multicast packet (such as source address, destination address, source port, destination address, and protocol), the network device searches for a security policy matching the multicast packet from the obtained security policies, and the security policy matching the multicast packet is taken as the target security policy. When the target security policy indicates permission, i.e., allowing the first VPN to access the second VPN, and allowing the security domain to which the first physical interface belongs to access the destination security domain of the multicast packet, the network device can execute step S205. When the target security policy indicates denial, i.e., denying the first VPN from accessing the second VPN, and denying the security domain to which the first physical interface belongs from accessing the destination security domain of the multicast packet, the network device can discard the multicast packet. Controlling multicast packets based on security policies improves network security.
[0055] In step S205 above, when the target security policy indicates permission, the network device can look up the multicast forwarding table associated with the second VPN, obtain the outgoing interface (i.e., the second physical interface) of the multicast packet, and then send the multicast packet through the second physical interface.
[0056] In this embodiment, by constructing a global dynamic mapping table between virtual interfaces and source physical interfaces, virtual interfaces that previously could not identify security domains / policies during the second-stage forwarding of cross-VPN multicast can correctly match the security policies configured on the source physical interface. This completely eliminates the problems of security policy lookup failures between security domains and application-specific packet filter (ASPF) packet loss caused by empty security domain values. This embodiment ensures that cross-VPN multicast packets remain within the controllable range of security policies throughout the entire forwarding path, fundamentally solving the serious defect in related technologies where packets are dropped and services are interrupted due to virtual interfaces not being bound to security domains / policies. This significantly improves the reliability and continuity of cross-VPN multicast services.
[0057] In addition, in this embodiment, the virtual interface inherits the fine-grained rules of the security policy, such as precise matching based on source address, destination address, port, and protocol, maintaining fine-grained control of the security policy and achieving the organic unity of "precise access" and "security controllability". While ensuring service accessibility, it effectively prevents unauthorized multicast packets from bypassing security domain checks through the virtual interface, significantly enhancing the overall network security level.
[0058] Furthermore, this application's embodiment enhances the existing "slow forwarding" two-stage forwarding framework without altering the main packet forwarding path or affecting the normal processing flow of non-cross-VPN multicast traffic. Network devices only need to add global dynamic mapping table query and maintenance logic at the software level, without modifying the hardware forwarding pipeline. It is completely transparent to related services, has an extremely low deployment threshold and good version compatibility, is compatible with existing forwarding architectures, allows for smooth evolution without intrusion, and facilitates smooth upgrades on existing network devices.
[0059] In some embodiments, such as Figure 3 As shown, the above cross-VPN multicast method may include steps S301 to S306. Steps S301 to S305 are the same as steps S201 to S205, and will not be described again here.
[0060] Step S306: If no target mapping table entry is found in the global dynamic mapping table, then a target mapping table entry is created in the global dynamic mapping table according to the security policy bound to the first physical interface. The target mapping table entry includes the security policy bound to the first physical interface; then proceed to step S304.
[0061] In this embodiment, if a target mapping entry is found in step S303, the network device directly executes step S304; if no target mapping entry is found in step S303, the network device directly executes step S306, adding the target mapping entry to the global dynamic mapping table and adding the security policy bound to the first physical interface to the target mapping entry. Afterwards, the network device continues to execute steps S304 to S305.
[0062] For example Figure 4The system architecture shown includes VPN1 and VPN2 within the VPN domain. Network devices include an interface layer, a forwarding processing core (i.e., CPU), and a data storage layer. The data storage layer includes a policy rule base and a global dynamic mapping table. VPN1, acting as the source VPN, sends multicast packets. Upon receiving this multicast packet, the source physical interface in the interface layer forwards it to the forwarding processing core. The forwarding engine in the forwarding processing core detects the need for cross-VPN multicast forwarding, extracts the index of the source physical interface from the packet ingress interface information, retrieves the source VPN instance (VPN1) and the destination VPN instance (VPN2) from the forwarding table entries, creates a temporary virtual interface within the interface layer, and assigns a unique virtual interface index (e.g., -1006630398) to connect VPN1 and VPN2. The forwarding engine receives multicast packets via loopback through the virtual interface. Then, using the index of the source physical interface as the key, it queries the policy rule base for all security policies bound to that source physical interface. A new mapping entry is inserted into the global dynamic mapping table, including these security policies, the virtual interface, and the destination VPN (VPN2), thus associating the virtual interface with the mapping entry in the global dynamic mapping table. Next, the forwarding engine queries the global dynamic mapping table to obtain the target mapping entry corresponding to the virtual interface and VPN2. It then searches for the target security policy that matches the multicast packet from the security policies included in the target mapping entry. When the target security policy indicates permission, the multicast packet is forwarded to VPN2 through the destination physical interface corresponding to the multicast packet under VPN2.
[0063] In the technical solution provided in this application embodiment, when performing cross-VPN multicast forwarding, the network device automatically "inherits" the security policy bound to the source physical interface to the virtual interface used for cross-VPN multicast forwarding. This design enables security control capabilities to be seamlessly extended along the cross-VPN forwarding path without requiring any separate configuration of security policies for the virtual interface, nor requiring the import of multicast addresses (such as FF1E::1, FF1E::6) one by one into the security domain. This fundamentally solves the core pain points of related technologies, such as the inability of virtual interfaces to reuse fine-grained security policies bound to physical interfaces and the fragmentation of security policy management.
[0064] Furthermore, when multicast addresses are added, changed, or deleted, the dynamic mapping table entries in this embodiment can be automatically updated synchronously. Administrators only need to maintain the original security policy on the source physical interface, without modifying any security domain configurations, significantly reducing configuration complexity and operational costs. Related technologies require performing security domain import operations for each multicast address individually; when the number of multicast addresses is large, the configuration workload increases linearly and is highly error-prone. In contrast, this embodiment fundamentally eliminates the strong coupling between multicast addresses and security domain configurations, enabling network devices to flexibly adapt to dynamically changing service needs, possessing outstanding scalability advantages, and significantly improving the flexibility and scalability of policy management.
[0065] In some embodiments, step S306 above, establishing a target mapping entry in the global dynamic mapping table according to the security policy bound to the first physical interface, may include: obtaining a security policy to be inherited carrying a preset tag from the security policy bound to the first physical interface, the preset tag indicating that the security policy is used for cross-VPN multicast; establishing a target mapping entry in the global dynamic mapping table, and adding the security policy to be inherited to the target mapping entry.
[0066] In this embodiment, when configuring a security policy applied to the source physical aggregation port, the administrator can configure an additional behavior attribute for the security policy. This behavior attribute is an action to add a preset flag, which can be represented as an action allow-to-cross-VPN flag. The behavior attribute indicates that the security policy needs to be inherited in cross-VPN multicast forwarding scenarios. When the network device saves this security policy with the preset flag, the network device sets a flag (i.e., the preset flag) for this security policy in the security policy rule base, distinguishing it from ordinary security policies.
[0067] When a multicast packet is received from the source physical interface (i.e., the first physical interface), triggering cross-VPN multicast forwarding and creating a corresponding virtual interface to connect the source VPN and the destination VPN, the core processing flow is activated. The network device dynamically generates a mapping table entry in the global dynamic mapping table. For example, it selects one or more security policies with preset tags from the security policies bound to the first physical interface included in the security policy rule base as security policies to be inherited. These security policies to be inherited are combined into an inheritance policy list. Combining the virtual interface, the first physical interface, the source VPN, and the destination VPN, a mapping table entry in the global dynamic mapping table is obtained.
[0068] The technical solution provided in this application introduces a "cross-VPN inheritance" attribute tag into the security policy. Network devices can "inherit" all security policies with this attribute tag from the source physical interface to the virtual interface used for cross-VPN multicast forwarding. This reduces the number of security policies associated with the virtual interface and the number of security policies required to be matched when establishing multicast forwarding, thus improving multicast forwarding efficiency. Furthermore, administrators only need to add one attribute tag to the original security policy to complete the policy inheritance configuration for all cross-VPN multicast scenarios, significantly reducing configuration complexity and operational costs.
[0069] In some embodiments, the above-described cross-VPN multicast method may further include: deleting the target virtual interface when the multicast forwarding from the first VPN to the second VPN ends; and deleting the target mapping entry that includes the target virtual interface.
[0070] In this embodiment, the end of multicast forwarding from the first VPN to the second VPN indicates the end of the cross-VPN multicast forwarding session, such as when no multicast packets are received from the first VPN to the second VPN within a preset time. The network device binds the lifecycle of a mapping entry in the global dynamic mapping table to the corresponding virtual interface, such as binding the lifecycle of a target mapping entry to a target virtual interface. When multicast forwarding from the first VPN to the second VPN ends, the network device deletes the target virtual interface, thereby clearing the target mapping entry including the target virtual interface, ensuring that system resources are not occupied.
[0071] For example Figure 5 The dynamic mapping entry generation process shown involves the network device extracting the index of the source physical interface from the packet ingress interface information, obtaining the VPN context (i.e., the source VPN instance and destination VPN instance) from the forwarding table entry, creating a temporary virtual interface internally, and assigning a unique virtual interface index for connecting VPN1 and VPN2. In the second-stage forwarding process, the network device uses the source physical interface index as the key to scan all security policies bound to that source physical interface in the policy rule base; checks whether the currently scanned security policy carries a preset flag; if so, it adds the security policy to the inherited policy list; checks if a next security policy exists; if not, it directly checks if a next security policy exists; if a next security policy exists, it re-checks whether the currently scanned security policy carries a preset flag; if no next security policy exists, it means that all security policies bound to that source physical interface have been scanned, generating a mapping entry in the global dynamic mapping table. This mapping entry includes the virtual interface, source physical interface, source VPN instance, destination VPN instance, and inherited policy list. The network device binds the lifecycle of this mapping table entry to the virtual interface.
[0072] In the technical solution provided in this application, the lifecycle of mapping entries (i.e., dynamic policy-related entries) in the global dynamic mapping table is strictly bound to the virtual interface. When the cross-VPN multicast forwarding session ends or the virtual interface is deleted, the network device automatically cleans up the corresponding mapping entries. This mechanism ensures that mapping entries do not remain in the network device for a long time, avoiding the potential risks of permanent existence and continuous resource consumption of security domain imported entries under static configuration, and achieving automated management of security policies that are "built as needed and cleared after use".
[0073] In this embodiment, the global dynamic mapping entries are generated only during the cross-VPN multicast forwarding session and are automatically destroyed along with the virtual interface after the session ends, without occupying permanent storage space. The number of entries is related to the number of sessions, rather than linearly related to the number of multicast groups. Therefore, resource inflation does not occur as the multicast group size increases, resulting in minimal system resource consumption and supporting large-scale multicast deployments. In service scenarios requiring massive multicast groups, such as carrier-grade Internet Protocol Television (IPTV), video conferencing, and real-time data distribution, this embodiment can significantly reduce configuration workload, lower resource consumption, and significantly improve service deployment speed and system carrying capacity.
[0074] In some embodiments, the global dynamic mapping table may include a hash value generated based on the virtual interface and the destination VPN. In this case, step S203 above may include: generating a target hash value based on the target virtual interface and the second VPN; and searching for a target mapping table entry that includes the target hash value in the global dynamic mapping table.
[0075] In this embodiment, the global dynamic mapping table is a hash mapping table. This global dynamic mapping table uses the virtual interface and the destination VPN as keys. That is, the network device calculates the hash values of the virtual interface and the destination VPN, and uses these hash values as keys. After the network device loops back to receive multicast packets, it calculates the hash values of the target virtual interface and the second VPN, uses this as the target hash value, and searches the global dynamic mapping table for a mapping table entry that includes the target hash value, using this entry as the target mapping table entry.
[0076] In the technical solution provided in this application embodiment, during the second-stage forwarding, the network device can quickly hit the mapping table entry with O(1) time complexity, without having to traverse all security policies in the policy rule base, thus balancing search efficiency and the distinguishability of multiple VPN scenarios. Compared with the solution of directly traversing all policies one by one for matching, the search efficiency of this application embodiment does not deteriorate with the growth of policy size, and can still maintain excellent forwarding performance in high-traffic, multi-policy large-scale deployment scenarios, effectively avoiding the problem of excessive CPU resource consumption and ensuring high-performance forwarding.
[0077] Corresponding to the above-described cross-VPN multicast method, this application provides a cross-VPN multicast device, such as... Figure 6 As shown, the device is applied to a network device and includes:
[0078] The receiving module 601 is used to receive multicast messages from the first VPN through the first physical interface, wherein the destination VPN of the multicast messages is the second VPN.
[0079] Loopback module 602 is used to receive multicast packets via a target virtual interface, which is connected to the first VPN and the second VPN.
[0080] The lookup module 603 is used to look up a target mapping table entry in the global dynamic mapping table, which includes the target virtual interface and the second VPN. The mapping table entry in the global dynamic mapping table includes the security policy bound to the virtual interface, the destination VPN and the packet ingress interface. From the security policies included in the target mapping table entry, the lookup module 603 looks up the target security policy that matches the multicast packet.
[0081] The forwarding module 604 is used to forward multicast packets through the second physical interface corresponding to the multicast packets under the second VPN when the target security policy indicates that passage is allowed.
[0082] In some embodiments, the lookup module 603 is further configured to, if no target mapping entry is found in the global dynamic mapping table, establish a target mapping entry in the global dynamic mapping table according to the security policy bound to the first physical interface, wherein the target mapping entry includes the security policy bound to the first physical interface; and search for a target security policy that matches the multicast message from the security policies included in the target mapping entry.
[0083] In some embodiments, the lookup module 603 is specifically used to obtain a security policy to be inherited carrying a preset tag from the security policy bound to the first physical interface, the preset tag indicating that the security policy is used for cross-VPN multicast; to establish a target mapping table entry in the global dynamic mapping table, and to add the security policy to be inherited to the target mapping table entry.
[0084] In some embodiments, the cross-VPN multicast device further includes: a deletion module, configured to delete the target virtual interface when the multicast forwarding from the first VPN to the second VPN ends; and delete the target mapping entry including the target virtual interface.
[0085] In some embodiments, the mapping entry includes a hash value generated based on the virtual interface and the destination VPN; the lookup module 603 is specifically configured to generate a target hash value based on the target virtual interface and the second VPN; and to look up a target mapping entry that includes the target hash value in the global dynamic mapping table.
[0086] In some embodiments, the mapping table entry also includes the message ingress interface and the source VPN.
[0087] In the technical solution provided in this application embodiment, a global dynamic mapping table is configured in the network device. This global dynamic mapping table includes entries for virtual interfaces, destination VPNs, and security policies bound to the incoming interface. In other words, the global dynamic mapping table enables virtual interfaces to inherit the security policies bound to the incoming interface. When a multicast packet forwarded across VPNs is received through a physical interface, the network device can look up the security policy inherited by the virtual interface from the incoming interface (i.e., the physical interface receiving the multicast packet) through the virtual interface connecting the two VPNs and the destination VPN. Following the found security policy, the multicast packet is forwarded under the destination VPN. This solves the packet loss problem caused by the network device's inability to find a matching security policy for the multicast packet when the cross-VPN virtual interface lacks a security policy, thus ensuring the continuity of cross-VPN multicast services under security policy control.
[0088] This application also provides a network device, such as... Figure 7 As shown, the system includes a processor 701, a communication interface 702, a memory 703, and a communication bus 704. The processor 701, the communication interface 702 (i.e., the physical interface), and the memory 703 communicate with each other via the communication bus 704. The memory 703 is used to store computer programs; the processor 701, when executing the program stored in the memory 703, implements any of the aforementioned cross-VPN multicast methods.
[0089] The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.
[0090] The communication interface is used for communication between the aforementioned network devices and other devices.
[0091] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0092] The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0093] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements any of the above-described cross-VPN multicast methods.
[0094] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the above-described cross-VPN multicast methods.
[0095] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).
[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0097] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for apparatus, network devices, storage media, and program products are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0098] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.
Claims
1. A cross-VPN multicast method, characterized in that, Applied to network devices, the method includes: Through the first physical interface, a multicast message is received from the first VPN, wherein the destination VPN of the multicast message is the second VPN; The multicast message is received via loopback through a target virtual interface, which connects the first VPN and the second VPN. In the global dynamic mapping table, look up the target mapping table entry that includes the target virtual interface and the second VPN. The mapping table entry in the global dynamic mapping table includes the virtual interface, the destination VPN and the security policy bound to the packet ingress interface. From the security policies included in the target mapping table, find the target security policy that matches the multicast message; When the target security policy indicates permission, the multicast message is forwarded through the second physical interface corresponding to the multicast message under the second VPN.
2. The method according to claim 1, characterized in that, The method further includes: If the target mapping table entry is not found in the global dynamic mapping table, a target mapping table entry is created in the global dynamic mapping table according to the security policy bound to the first physical interface. The target mapping table entry includes the security policy bound to the first physical interface. Perform the step of searching for a target security policy that matches the multicast message from the security policies included in the target mapping table entry.
3. The method according to claim 2, characterized in that, The step of establishing a target mapping table entry in the global dynamic mapping table according to the security policy bound to the first physical interface includes: Obtain the security policy to be inherited from the security policy bound to the first physical interface, which carries a preset tag. The preset tag indicates that the security policy is used for cross-VPN multicast. A target mapping table entry is created in the global dynamic mapping table, and the security policy to be inherited is added to the target mapping table entry.
4. The method according to any one of claims 1-3, characterized in that, The method further includes: When the multicast forwarding from the first VPN to the second VPN ends, the target virtual interface is deleted; Delete the target mapping table entry that includes the target virtual interface.
5. The method according to any one of claims 1-3, characterized in that, The mapping entry includes a hash value generated based on the virtual interface and the destination VPN; The step of searching the global dynamic mapping table for the target mapping table entry that includes the target virtual interface and the second VPN includes: Generate a target hash value based on the target virtual interface and the second VPN; In the global dynamic mapping table, find the target mapping table entry that includes the target hash value.
6. The method according to any one of claims 1-3, characterized in that, The mapping entry also includes the message ingress interface and the source VPN.
7. A cross-VPN multicast device, characterized in that, Applied to network devices, the device includes: The receiving module is configured to receive multicast messages from a first VPN via a first physical interface, wherein the destination VPN of the multicast messages is a second VPN. The loopback module is used to receive the multicast packets via a target virtual interface, which connects the first VPN and the second VPN. The lookup module is used to search in the global dynamic mapping table for a target mapping table entry that includes the target virtual interface and the second VPN, wherein the mapping table entry in the global dynamic mapping table includes the virtual interface, the destination VPN, and the security policy bound to the packet ingress interface; and to search for a target security policy that matches the multicast packet from the security policies included in the target mapping table entry. The forwarding module is used to forward the multicast message through the second physical interface corresponding to the multicast message under the second VPN when the target security policy indicates permission.
8. The apparatus according to claim 7, characterized in that, The search module is further configured to, if the target mapping entry is not found in the global dynamic mapping table, establish a target mapping entry in the global dynamic mapping table according to the security policy bound to the first physical interface, wherein the target mapping entry includes the security policy bound to the first physical interface; and search for a target security policy that matches the multicast message from the security policies included in the target mapping entry.
9. The apparatus according to claim 8, characterized in that, The lookup module is specifically used to obtain a security policy to be inherited carrying a preset tag from the security policy bound to the first physical interface. The preset tag indicates that the security policy is used for cross-VPN multicast. The module also establishes a target mapping table entry in the global dynamic mapping table and adds the security policy to be inherited to the target mapping table entry.
10. The apparatus according to any one of claims 7-9, characterized in that, The device further includes: The deletion module is used to delete the target virtual interface when the multicast forwarding from the first VPN to the second VPN ends; and to delete the target mapping table entry including the target virtual interface.
11. The apparatus according to any one of claims 7-9, characterized in that, The mapping entry includes a hash value generated based on the virtual interface and the destination VPN; The search module is specifically used to generate a target hash value based on the target virtual interface and the second VPN; In the global dynamic mapping table, find the target mapping table entry that includes the target hash value.
12. The apparatus according to any one of claims 7-9, characterized in that, The mapping entry also includes the message ingress interface and the source VPN.
13. A network device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor, when executing the program stored in the memory, implements the method described in any one of claims 1-6.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.