CN116436648A

CN116436648A - Verification information sending method, verification table item obtaining method, device and equipment

Info

Publication number: CN116436648A
Application number: CN202310293070.XA
Authority: CN
Inventors: 黄明庆; 刘明星; 耿男; 谭镇
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-03-17
Filing date: 2023-03-17
Publication date: 2023-07-14

Abstract

The application discloses a verification information sending method, a verification list item obtaining device and equipment, wherein the verification list item is used AS first network equipment in a first AS (application server) of an origin autonomous domain AS, and verification information corresponding to the first AS and neighbor AS corresponding to a second AS for verification are obtained. The neighbor AS refers to the last hop AS of the second AS in the direction from the first AS to the second AS. The first network device sends the verification information and the neighbor AS to the second AS, and the verification AS verifies the source address of the received service message based on the verification information and the neighbor AS. That is, the first AS in the present application may send the authentication information and the neighboring AS corresponding to the authentication AS, without sending the authentication information to all the AS on the path with the first AS the originating AS, thereby reducing the communication overhead.

Description

Verification information sending method, verification table item obtaining method, device and equipment

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a method, an apparatus, and a device for sending verification information.

Background

In general, after receiving a message, a device in the network acquires a destination address of the message, searches a forwarding route for the destination address, and if the forwarding route is found, performs normal forwarding, otherwise discards the message. Thus, when forwarding the message, the device in the network does not care about the source address of the message, and has a multiplicable opportunity for source address spoofing attack. The source address spoofing attack means that an intruder frequently accesses the device or the host where the destination address is located by constructing a series of messages with fake source addresses, and even if the response message of the victim host or the device cannot return to the intruder, the attacked object is damaged to a certain extent.

To prevent source address based network attacks, a source address verification scheme is proposed, such as unicast reverse route lookup (unicast reverse path forwarding, URPF). The URPF searches whether an interface corresponding to the source address is matched with the input interface in the forwarding table by acquiring the source address and the input interface of the message and taking the source address as a destination address. If not, the source address is considered spoofed and the message is discarded. In this way, the URPF can effectively prevent the occurrence of malicious attacks in the network by modifying the source address. Since the URPF needs to rely on a forwarding table, when there is a route asymmetry in the network, a situation of erroneously discarding a packet is easy to occur. Based on this, a distributed source address verification (distributed source address validation, DSAV) scheme is proposed, which, when executed, the device for verifying source addresses will build a source address verification table (source address validation, SAV) recording source addresses and corresponding legal ingress interfaces. If the input interface of the message is inconsistent with the legal input interface corresponding to the source address of the message, the source address of the message is considered to be fake, and the message is discarded. However, when source address verification is performed in different autonomous domains (autonomous system, AS), a large number of AS may be involved, resulting in large computational and communication overhead.

Disclosure of Invention

The application provides a verification information sending method, a verification list item obtaining device and verification equipment, so that communication overhead is reduced when inter-domain source address verification is realized.

In a first aspect of the present application, there is provided a method for transmitting authentication information, the method including: the method comprises the steps that a first network device obtains authentication information of a first AS to which the first network device belongs and neighbor AS of a second AS used for authentication; the first network device sends authentication information and neighbor ases to the second AS. Wherein the neighbor AS is the last hop of the second AS in the direction from the first AS to the second AS. That is, in the present application, the first AS may send the authentication information and the neighboring AS corresponding to the authentication AS, without sending the authentication information to all the AS on the path with the first AS the originating AS, thereby reducing the communication overhead.

The first network device may be a controller, a border network device, or a Route Reflector (RR) in the first AS. For example, the border network devices may be autonomous system border routers (autonomous system boundary router, ASBRs). The authentication information may include a source prefix corresponding to the first AS and/or an identity of the first AS. When the authentication information includes the identifier of the first AS, the second AS acquires the source prefix to be authenticated according to the identifier of the first AS after acquiring the authentication information.

Specifically, the first network device may obtain the neighbor AS by:

a first network device obtains a first AS path taking a first AS AS an endpoint, wherein the first AS path comprises a second AS; the first network device obtains neighbor AS of the second AS based on the first AS path.

Under the application scene of fast rerouting or load sharing, a main/standby path exists or a path for realizing load sharing is provided, so as to avoid the situation of filtering legal messages by mistake. Based on this, when the first network device obtains the neighbor AS of the second AS, the first network device may also obtain a second AS path with the first AS an endpoint, where the second AS path includes the second AS, and the second AS path is a standby path and/or a load sharing path corresponding to the first AS path.

The first network device receives neighbor AS of a second AS sent by a boundary network device of the first AS. The neighbor AS of the second AS, which is sent by the border network device of the first AS, is an AS determined by the border network device in the first AS according to the self routing table and/or the redirection path.

The first network device obtains a neighbor AS of the second AS according to the self routing table and/or the redirection path.

In one possible implementation, the first network device sending authentication information and the neighbor AS to the second AS may include: the first network device acquires an address of a second network device in a second AS; and the first network equipment sends the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment. The second network device may be a controller, RR or border network device in the second AS. That is, when the first network device transmits authentication information and neighbor AS to the second AS, the address of the second network device may be acquired first, and then the authentication information and neighbor AS may be transmitted to the network device indicated by the address.

In one possible implementation, the first network device may further send a message to the second network device, where the message includes an identifier of the first AS, an identifier of the second AS, and an identifier of the neighboring AS.

Specifically, the message may include an originating AS identification field, a verifying AS identification field, and a neighbor AS identification field, where the originating AS identification field includes an identification of the first AS, the verifying AS identification field includes an identification of the second AS, and the neighbor AS identification field includes an identification of the neighbor AS.

In one possible implementation, the first network device may also obtain the identity of the second AS and the address of the next hop before sending the authentication information and the neighbor AS to the second AS. The address of the next hop may be a controller in the second AS, a border network device in the second AS, or a route reflector in the second AS. In a specific implementation, the identity of the second AS and the address of the next hop may be configured on the first network device in advance.

In a second aspect of the present application, there is provided a method for obtaining a verification entry, the method including: the second network equipment in the second AS for verification receives verification information of the first AS and neighbor AS of the second AS, wherein the verification information of the first AS is sent by the first network equipment in the first AS; the second network device obtains the authentication entry based on the authentication information and the neighbor AS. The verification table entry comprises a source prefix corresponding to the first AS and an inlet interface used for communicating with the neighbor AS. That is, after receiving the authentication information and the neighbor AS sent by the first network device, the second network device located in the authentication AS generates an authentication entry by using the authentication information and the neighbor AS, so AS to verify the validity of the received service message by using the authentication entry.

In one possible implementation, when the boundary network device is included in the second AS, the second network device may further send the received authentication information and the neighbor AS to the boundary network device, so that each boundary network device may obtain the authentication entry based on the authentication information and the neighbor AS.

Wherein the authentication information may comprise a source prefix and/or an identity of the first AS. If the authentication information includes a source prefix, the second network device may obtain the authentication entry by: the second network device obtains AS to which a third network device communicating with the interface belongs; if the AS to which the third network device belongs is a neighbor AS, the second network device determines that the interface is an incoming interface; the second network device obtains a validation entry based on the source prefix and the ingress interface.

If the authentication information includes an identification of the first AS, the second network device may authenticate the entry by: the second network device obtains AS to which a third network device communicating with the interface belongs; if the AS to which the third network device belongs is a neighbor AS, the second network device determines that the interface is an incoming interface; the second network equipment obtains a source prefix based on the identification of the first AS and the corresponding relation; the second network device obtains the authentication entry based on the source prefix and the ingress interface. The corresponding relation comprises an identifier of the first AS and a source prefix.

In one possible implementation, the second network device may further perform the following operations: the second network equipment receives a service message, wherein the service message comprises a source Internet Protocol (IP) address; and the second network equipment determines the validity of the service message according to the verification list item, the source IP address and the interface for receiving the service message. For example, after the second network device receives the service message, the source prefix is determined according to the source IP address in the service message, and an ingress interface corresponding to the source prefix is searched from the verification table through the source prefix, and if the ingress interface is matched with an interface used by the second network device to receive the service message, the service message can be indicated to be a legal message.

In a third aspect of the present application, there is provided an authentication information transmission apparatus applied to a first network device, the apparatus comprising: the processing unit is used for acquiring verification information of a first autonomous domain AS to which the processing unit belongs and neighbor AS of a second AS for verification, wherein the neighbor AS is a last hop of the second AS in the direction from the first AS to the second AS; and the sending unit is used for sending the verification information and the neighbor AS to the second AS.

In a possible implementation manner, the processing unit is specifically configured to obtain a first AS path taking the first AS an endpoint, where the first AS path includes the second AS; and acquiring neighbor AS of the second AS based on the first AS path.

In a possible implementation manner, the processing unit is specifically configured to obtain a second AS path taking the first AS an endpoint, where the second AS path includes the second AS, and the second AS path is a standby path or a load sharing path of the first AS path.

In a possible implementation manner, the processing unit is specifically configured to receive a neighboring AS of the second AS sent by the border network device in the first AS, where the neighboring AS of the second AS sent by the border network device in the first AS is an AS determined by the border network device in the first AS according to a self routing table and/or a redirection path.

In a possible implementation manner, the processing unit is specifically configured to obtain, by the first network device, a neighboring AS of the second AS according to the self routing table and/or the redirection path.

In one possible implementation, the first network device is a controller, RR or border network device.

In a possible implementation manner, the sending unit is specifically configured to obtain an address of a second network device in the second AS, where the second network device is a controller, an RR, or a border network device; and sending the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment.

In a possible implementation manner, the sending unit is further configured to send a packet to the second network device, where the packet includes an identifier of the first AS, an identifier of the second AS, and an identifier of the neighboring AS.

In a possible implementation manner, the originating AS identification field in the message includes an identification of the first AS, the verifying AS identification field in the message includes an identification of the second AS, and the neighbor AS identification field in the message includes an identification of the neighbor AS.

In a possible implementation manner, the processing unit is further configured to obtain an identifier of the second AS and an address of a next hop, where the next hop is one of a controller in the second AS, a border network device in the second AS, or a route reflector in the second AS.

In one possible implementation manner, the verification information includes at least one of a source prefix corresponding to the first AS and an identity of the first AS.

In a fourth aspect of the present application, there is provided an authentication entry obtaining apparatus applied to a second network device in a second AS for authentication, the apparatus including: a receiving unit, configured to receive authentication information of a first AS and neighbor AS of the second AS, where the authentication information is sent by a first network device in the first AS; and the processing unit is used for obtaining a verification list item based on the verification information and the neighbor AS, wherein the verification list item comprises a source prefix corresponding to the first AS and an inlet interface used for communicating with the neighbor AS.

In one possible implementation, the apparatus further includes: a transmitting unit; the sending unit is configured to send the authentication information and the neighboring AS to a border network device in the second AS.

In a possible implementation manner, the verification information includes the source prefix, and the processing unit is specifically configured to obtain an AS to which a third network device in communication with the interface belongs; if the AS to which the third network device belongs is the neighbor AS, determining that the interface is the access interface; the authentication entry is obtained based on the source prefix and the ingress interface.

In a possible implementation manner, the verification information includes an identifier of the first AS, and the processing unit is specifically configured to obtain an AS to which a third network device that communicates with an interface belongs; if the AS to which the third network device belongs is the neighbor AS, determining that the interface is the access interface; acquiring the source prefix based on the identifier of the first AS and a corresponding relation, wherein the corresponding relation comprises the identifier of the first AS and the source prefix; the authentication entry is obtained based on the source prefix and the ingress interface.

In a possible implementation manner, the receiving unit is further configured to receive a service packet, where the service packet includes a source internet protocol IP address; the processing unit is further configured to determine validity of the service packet according to the verification entry, the source IP address, and an interface for receiving the service packet.

In a fifth aspect of the present application, there is provided a network device comprising: a processor and a memory;

the memory is used for storing instructions or computer programs;

the processor is configured to execute the instructions or the computer program in the memory, so that the network device performs any one of the possible implementation methods of the first aspect or the first aspect, or performs any one of the possible implementation methods of the second aspect or the second aspect.

In a sixth aspect of the present application, there is provided a network system, the system comprising: a first network device and a second network device; the first network device is configured to perform the first aspect or any one of the possible implementation methods of the first aspect; the second network device is configured to perform the second aspect or any one of the possible implementation methods of the second aspect.

In a seventh aspect of the present application, there is provided a computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the first aspect or any one of the possible implementation methods of the first aspect or to perform the second aspect or any one of the possible implementation methods of the second aspect.

In an eighth aspect of the present application, there is provided a computer program product comprising a program which, when run on a processor, causes a computer or network device to perform the first aspect or any one of the possible implementation methods of the first aspect or to perform the second aspect or any one of the possible implementation methods of the second aspect.

By means of the technical scheme, the authentication information corresponding to the first AS and the neighbor AS corresponding to the second AS used for authentication are acquired AS the first network equipment in the first AS of the originating AS. The neighbor AS refers to the last hop AS of the second AS in the direction from the first AS to the second AS. The first network device sends the verification information and the neighbor AS to the second AS, and the verification AS verifies the source address of the received service message based on the verification information and the neighbor AS. That is, the first AS in the present application may send the authentication information and the neighboring AS corresponding to the authentication AS, without sending the authentication information to all the AS on the path with the first AS the originating AS, thereby reducing the communication overhead.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1a is a network architecture diagram provided in an embodiment of the present application;

FIG. 1b is a diagram of another network architecture provided in an embodiment of the present application;

fig. 2 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 3 is a signaling interaction diagram for obtaining a verification entry according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a DPP protocol packet according to an embodiment of the present application;

fig. 5 is a schematic view of another application scenario provided in the embodiment of the present application;

fig. 6 is a schematic view of another application scenario provided in an embodiment of the present application;

fig. 7 is a schematic structural diagram of a verification information sending device according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a verification table entry obtaining device according to an embodiment of the present application;

Fig. 9 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of another network device according to an embodiment of the present application.

Detailed Description

In order to make those skilled in the art better understand the solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, but not all embodiments.

At present, the DSAV method can be divided into two scenes of an intra-domain and an inter-domain, the inter-domain scheme is mainly used for verifying source addresses with autonomous domain granularity, and the smallest deployment node is a single AS. In particular, the SAV table is dynamically generated and updated according to the learned routing information, and then the source address in the received message is checked by using the SAV table.

For example, in the inter-domain source address verification schematic shown in fig. 1a, in the application scenario, the source prefix corresponding to AS1 is P1, the source prefix corresponding to AS2 is P2, and the source prefix corresponding to AS3 is P3. Taking verification for the source prefix P1 and the source prefix P2 AS an example, an SAV table is created in AS 2. AS shown in fig. 1, the border network device in the AS2 is connected with the border network device in the AS1 through an a1 interface, and the border network device in the AS2 is connected with the border network device in the AS2 through an a2 interface. The SAV table established in AS2 records the corresponding relation between P1 and a1 and the corresponding relation between P2 and a 2. After AS2 receives the message sent by AS1, the validity of the source address in the received message is judged through the SAV table.

When performing the DSAV scheme between domains, the following protocol messages are generally involved:

the Source prefix issues (Source prefix advertisement, SPA) a protocol message that mainly contains 2 fields, namely an AS identification (Origin ASN) field of the originating AS and a legal Source prefix (Source Prefixes) field corresponding to the originating AS. The originating AS sends the SPA protocol message so that the AS for verification can learn the source prefix which needs to be verified.

The destination prefix detection (destination prefix probing, DPP) protocol message mainly includes 5 fields, which are a source address field of the DPP message, a destination address field of the DPP message, an AS identification (Origin ASN) field of an originating AS, an as_path set (as_path_set) field selected by the originating AS according to a routing table, and a sequence number field of the DPP message, respectively. The Origin ASN and AS_path_set fields are key fields for generating the SAV table.

In order to facilitate understanding of the implementation process of the inter-domain DSAV method, refer to an application scenario diagram shown in fig. 1b, in this diagram, AS1 to AS5 respectively have source prefixes P1 to P5, and each have an inter-domain DSAV verification mechanism deployed on a border network device of a respective autonomous domain, so that other AS are prevented from forging their own source addresses by running an inter-domain DSAV protocol. Wherein AS1 serves AS an originating AS, and other AS serves AS a verifying AS. The verification AS generates a source address verification table by receiving SPA and DPP messages sent by the AS1, records the source prefix of the AS1 and a corresponding legal access interface, and avoids receiving the messages forging the source address of the AS 1.

The specific working procedure is as follows:

1. AS1 acts AS an originating AS, generates and broadcasts SPA protocol messages through a border network device, such AS an autonomous system border router (autonomous system boundary router, ASBR). For example, the SPA protocol packet sent by AS1 in broadcast form is shown in table 1:

TABLE 1

SPA protocol message
	Origin ASN:AS1
Source Prefixes { P1, etc. originate from the prefix set of AS1 }

After the AS1 broadcasts the SPA protocol message to the AS2 to the AS8, other AS in the network all receive the SPA protocol message and all generate the source address record table entries AS shown in table 2 below.

TABLE 2

2. The boundary network equipment of the AS1 acquires the AS_path set according to the routing table entry (routing information base, RIB), and generates and transmits a DPP protocol message. Specifically, the RIB is shown in table 3 below:

TABLE 3 Table 3

The edge network device constructs a DPP protocol message AS shown in fig. 1b, including the AS identity of the originating AS and all as_paths in the RIB table. The shorter as_path is included in the longer as_path, and need not be included in the DPP protocol packet.

3. AS2 serves AS a verification AS, and generates a source address verification table after receiving the DPP protocol message sent by AS 1. The source address verification table generated by the border network device of the AS2 is shown in the following table 4:

TABLE 4 Table 4

Wherein P1 is the source IP prefix of AS1, which can be obtained from a source address record table; the ingress interfaces are all interfaces for interconnection of AS2 and AS1, and are judged according to the last hop AS of the DPP message.

4. AS2 serves AS a verification AS, and after a source address verification table is generated, the DPP protocol message is relayed to the next hop AS.

The origin_asn field in the relay DPP message generated by the AS2 remains unchanged, the own AS identifier is removed from the as_path, and then a new DPP message is constructed and sent to the next hop AS in the as_path. For example, when the as_path is [ AS2, AS3], after removing the AS2, the next hop is AS3; when the AS_path is [ AS2, AS4, AS5], the AS2 is removed, and the AS of the next hop is AS4.

5. After other AS receives the DPP message, according to steps 3-4, generating an SAV table and relaying the DPP message until AS_path is empty. At this time, AS2 to AS5 each generate an SAV table for the source prefix of AS 1.

6. After receiving the service message, other AS verifies whether the source IP of the service message is true based on the SAV table. Currently, there are two verification modes, respectively a whitelist verification mode or a gray list verification mode.

White list verification mode: preventing any messages whose source address is unknown or illegally reaches the interface.

Gray list verification mode: only packets with known source addresses but illegally arriving on the interface are discarded, and packets with unknown source addresses are accepted in this mode.

Specifically, the processing conditions of the messages in the 2 verification modes are as follows:

from the above, in order to enable the verifying AS to generate an accurate SAV table, the inter-domain DSAV scheme adopts a manner that the originating AS sends the DPP message, and other ases generate the SAV table and relay the DPP message. This solution requires that all AS border network devices on the as_path deploy inter-domain DSAV mechanisms and all need to generate new DPP protocol messages. This implementation has the following problems: 1. the protocol overhead is enormous. If a large number of ases exist, the as_path protocol formed by the method is larger, and the vast majority of ases cannot be transmitted in the DPP protocol message. In addition, each ASBR of the source AS needs to generate a DPP message, and verifying that the ASBR of the AS needs to generate and relay the DPP message causes additional computational overhead and communication overhead. 2. According to the inter-domain DSAV scheme, all ASs on the AS_path selected by the originating AS sequentially generate an SAV table according to the AS_path hop-by-hop relay detection mode, which requires that boundary network equipment of all ASs on the AS_path deploy an inter-domain DSAV mechanism.

In view of this, the present application provides an authentication information transmission method in which an AS for authentication, i.e., a second AS, can be predetermined. The network device in the originating AS, i.e. the first network device in the first AS, first obtains authentication information of the first AS and a neighbor AS of the second AS, the neighbor AS being the last hop of the second AS in the direction from the first AS to the second AS. That is, the direction of traffic from the originating AS to the verifying AS is indicated by the neighbor AS. The first network device then sends the authentication information and the neighbor AS to the second AS. That is, the first network device may only need to send authentication information and neighbor ases to the second AS, without sending authentication information to all ases on the as_path, and without deploying an inter-domain DSAV mechanism by the border network device of all ases on the as_path, which not only reduces communication overhead, but also is suitable for more network scenarios. The verification information may be an AS identifier of the first AS or a source prefix corresponding to the first AS.

The system architecture of the embodiments of the present application is illustrated below.

Fig. 2 is a network system architecture diagram provided in the embodiment of the present application, and the network system shown in fig. 2 includes 7 ases, AS1 to AS7 respectively. The AS1 serves AS an originating AS, the source prefix to be verified is P1, the AS3 serves AS a verification AS, and an SAV table is generated in network equipment of the AS3, so that the AS 5-AS 7 are prevented from forging the traffic of the AS 1. The network device in the AS1 may determine that all AS forwarding paths using the AS1 AS an originating AS are [ AS1, AS2, AS3, AS5], [ AS1, AS2, AS3, AS6], [ AS1, AS2, AS3, AS7], [ AS1, AS2, AS4, AS3, AS5], [ AS1, AS2, AS4, AS6], [ AS1, AS2, AS4, AS3, AS7] according to the as_path attribute in the RIB table or the AS forwarding paths collecting the redirected traffic. After the network device in the AS1 obtains the forwarding paths, it may determine that the neighboring AS of the verification AS is the AS2 and the AS4, and then the network device in the AS1 sends the collected verification information and the neighboring AS (for example, AS2 and AS 4) corresponding to the AS3, so that the network device in the AS3 generates the SAV table according to the received verification information and the neighboring AS.

In order to facilitate understanding of the technical solution provided in the embodiments of the present application, the following description will be made with reference to an application scenario shown in fig. 2.

Referring to fig. 3, the flowchart of a method for obtaining a verification entry according to an embodiment of the present application includes:

S301: the first network device acquires authentication information of a first AS to which the first network device belongs and neighbor ASs of a second AS for authentication.

In this embodiment, the network device in the originating AS, i.e., the first network device, collects authentication information about the first AS and neighbor AS to which the authentication AS, i.e., the second AS, corresponds. The neighbor AS is a last hop AS corresponding to the second AS in the direction from the first AS to the second AS, and the verification information comprises an AS identifier of the first AS and/or a source prefix corresponding to the first AS. For example, in the application scenario shown in fig. 2, the first AS is denoted AS1, the second AS is denoted AS3, and the neighboring AS corresponding to AS3 in the direction from AS1 to AS3 is denoted AS2 and AS4.

Before acquiring a neighbor AS corresponding to a second AS, the first network device first acquires an identifier of the second AS, and further determines the neighbor AS corresponding to the second AS. The identification of the second AS used for authentication may be configured on the first network device in advance, or the first network device may select an AS from the AS paths with the first AS an endpoint according to a preconfigured selection rule AS an authentication AS. The selection rule may be set according to an actual application condition, and the embodiment is not limited herein. For example, the selection rule is that the AS having the most neighbor AS in the AS path with the first AS the end point is selected AS the verification AS. For example, in the application scenario shown in fig. 2, AS3 corresponds to the largest number of neighboring AS including AS2, AS4, AS5, AS6, and AS7, and AS3 is the verification AS.

The first network device may be a boundary network device, a controller, or an RR in the first AS, where the first network device is configured to collect authentication information in the first AS and a neighboring AS corresponding to the second AS. For example, when the verification information is a source prefix corresponding to the first AS, the source prefix that needs to be verified may be configured in advance on the first network device; when the verification information is the AS identifier of the first AS, a corresponding relationship between the AS identifier of the first AS and the source prefix may be configured on the first network device in advance, and the first network device sends the corresponding relationship to the second AS.

The first network device may obtain a neighboring AS of the second AS by:

first, a first network device obtains a first AS path taking a first AS AS an endpoint, wherein the first AS path comprises a second AS; the first network device obtains neighbor AS of the second AS based on the first AS path.

In this embodiment, the first network device may first acquire a first AS path with the first AS an endpoint, and determine a neighboring AS of the second AS from the AS included in the first AS path. The first AS path with the first AS an end point may include an AS path with the first AS an originating AS and an AS path with the first AS an end point AS. For example, in the application scenario shown in fig. 2, the first AS path may include [ AS1- > AS2- > AS3 … ], [ AS1- > AS2- > AS4- > AS3 … ], [ AS5- > AS3- > AS4- > AS2- > AS1], [ AS5- > AS3- > AS2- > AS1], [ AS6- > AS3- > AS4- > AS2- > AS1], [ AS6- > AS3- > AS2- > AS1], and so on. Since the neighboring AS of the second AS is the last hop AS corresponding to the second AS in the direction from the first AS to the second AS, the neighboring AS corresponding to the second AS may be determined AS2 and AS4 from [ AS1- > AS2- > AS3 … ] and [ AS1- > AS2- > AS4- > AS3 … ] in the first AS path. It should be noted that, AS can be seen from table 3, when the first network device obtains the first AS path with the AS1 AS the originating AS through the RIB table, the obtained first AS path does not include the originating AS, i.e., AS1.

The first network device obtains a first AS path taking the first AS an endpoint, which may include obtaining, by the first network device, the first AS path taking the first AS an endpoint according to an as_path attribute and/or a redirection path in a local routing table, and/or obtaining, by other network devices in the first AS, the first AS path taking the first AS an endpoint according to an as_path attribute and/or a redirection path in the local routing table, and then sending, by the other network devices, the obtained first AS path to the first network device.

For example, when the first AS includes a plurality of border network devices, a certain border network device may be preconfigured AS a designated router (designated router, DR), or one border network device may be selected from the plurality of border network devices AS a DR according to a selection rule. The selection rule may be configured according to an actual application, for example, the selection rule is to preferentially select, AS DR, a border network device having a border gateway protocol (border gateway protocol, BGP) neighbor relation with the second AS. For example, in the application scenario shown in fig. 2, it is assumed that AS1 includes 3 border network devices, respectively ASBR1, ASBR2, and ASBR3, where ASBR2 has a BGP neighbor relation with AS2, and ASBR2 is selected AS DR. Or when the first AS includes a border network device, controller, or RR, the controller or RR may be selected AS the DR. After the DR is selected, each border network device in the first AS may obtain a first AS path according to the as_path attribute and/or the redirection path in the local routing table corresponding to the border network device, and send the first AS path to the DR, where the DR obtains a neighboring AS of the second AS based on the first AS path.

In some application scenarios, a redundant link can be provided in a backup route form through fast route (FRR), so that the route can be quickly switched when a fault occurs, the message forwarding is ensured not to be interrupted, and the reliability of the network is enhanced. Or in the load sharing scene, the main path and the standby path exist for forwarding the message at the same time. When the neighbor AS of the second AS is acquired, if the scene is ignored, the collected neighbor AS of the second AS may be partially missing, so that legal messages are filtered by mistake. Based on this, when the first network device obtains the neighbor AS of the second AS, the first network device may also obtain a second AS path with the first AS an endpoint, where the second AS path includes the second AS, and the second AS path is a standby path and/or a load sharing path corresponding to the first AS path. Specifically, the first network device may obtain the backup path or the load sharing path by querying the routing table, and if a neighbor AS corresponding to the second AS exists in the backup path or the load segmentation path, obtain the neighbor AS. In the presence of a routing reflector, the first network device may not be able to determine the complete forwarding path, in which case the complete forwarding path may be advertised to the first network device by the routing reflector by initiating the add-path feature. Wherein the add-path feature is used to advertise multiple paths of the same source prefix. Typically, when advertising BGP routes, the network device advertises the best path. By enabling the add-path feature, the network device advertises the optimal path and the suboptimal path when advertising BGP routes.

Second, the first network device receives a neighboring AS of the second AS sent by the border network device in the first AS. The neighbor AS of the second AS sent by the border network device in the first AS is an AS determined by the border network device in the first AS according to the self routing table and/or the redirection path.

In this embodiment, the border network device in the first AS may determine a neighboring AS of the second AS according to the routing table and/or the redirection path of the border network device in the first AS, and send the neighboring AS of the second AS to the first network device. For example, the border network device in the first AS may obtain an AS path with the first AS an endpoint according to its own routing table and/or redirection path, determine a neighboring AS of the second AS from the AS path, and send the determined neighboring AS of the second AS to the first network device. The AS paths acquired by the border network device may include a primary path and a standby path that use the first AS an endpoint, and/or at least two AS paths that use the first AS an endpoint to implement load sharing. The above-mentioned AS path includes a second AS, specifically, the primary path and the standby path both include the second AS, and at least two AS paths for implementing load sharing include the second AS.

Thirdly, the first network device obtains the neighbor AS of the second AS according to the self routing table and/or the redirection path.

For example, the first network device may obtain an AS path with the first AS an endpoint according to its own routing table and/or redirection path, and determine a neighboring AS of the second AS from the AS path. The AS path may include a primary path and a backup path that use the first AS an endpoint, and/or at least two AS paths that use the first AS an endpoint to implement load sharing. The above-mentioned AS path includes a second AS, specifically, the primary path and the standby path both include the second AS, and at least two AS paths for implementing load sharing include the second AS.

S302: the first network device sends authentication information and neighbor ases to the second AS.

After the first network device acquires the verification information of the first AS and the neighbor AS corresponding to the second AS, the verification information and the neighbor AS are sent to the second AS. For example, the first network device will send authentication information and neighbor ases to a certain network device in the second AS.

In one possible implementation, the first network device obtains an address of a second network device in the second AS; and the first network equipment sends the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment. The second network device may be a controller, RR or border network device in the second AS. In specific implementation, an address of the second network device may be configured in the first network device in advance, and when the first network device sends the authentication information and the neighbor AS to the second AS, the address of the configured second network device is obtained, and the authentication information and the neighbor AS are sent to the network device indicated by the address. Or the first network device acquires the address of the second network device which establishes the BGP neighbor relation with the second network device in the second AS, and sends verification information and the neighbor AS to the network device indicated by the address.

In one possible implementation, the first network device may further send a message to the second network device, where the message includes an identifier of the first AS, an identifier of the second AS, and an identifier of the neighboring AS. The message may be a DPP message, and the format of the DPP message is shown in fig. 4, and includes a message Type (Type) field, a Length field, an originating AS identifier (Origin ASN) field, a verifying AS identifier (verification ASN) field, and a neighbor AS identifier (Ingress neighbor ASN) field. The message Type (Type) field is used to indicate the Type of the message, for example, the message Type field indicates that the message is a message for advertising a neighbor AS. The originating AS identification field in the message comprises the identification of the first AS, the verifying AS identification field in the message comprises the identification of the second AS, and the neighbor AS identification field in the message comprises the identification of the neighbor AS. Wherein, when the second AS has a plurality of neighbor ases, the neighbor AS identification field will include the plurality of neighbor ases. For example, in the application scenario shown in fig. 2, AS3 corresponds to 2 neighboring AS, AS2 and AS4, respectively, and the neighboring AS identification field will include AS2 and AS4. The first network device may periodically send a DPP protocol packet to the second network device, so that the second network device updates the verification table according to the latest received DPP protocol packet.

S303: and the second network equipment in the second AS receives the verification information and the neighbor AS, and obtains a verification list item based on the verification information and the neighbor AS.

In this embodiment, after receiving the authentication information and the neighbor AS sent by the first network device, the second network device generates the authentication entry by using the authentication information and the neighbor AS. The verification table entry comprises a source prefix corresponding to the first AS and an inlet interface used for communicating with the neighbor AS. Wherein an ingress interface for communicating with a neighbor AS refers to an interface on a second AS in a direction from the neighbor AS to the second AS.

In one possible implementation manner, when the second network device is a DR in the second AS, in order to enable the border network devices in the second AS to generate the verification table entry, to implement verification of the source prefix, the second network device sends the verification information and the neighbor AS to the border network devices in the second AS after receiving the verification information and the neighbor AS. For example, in the application scenario shown in fig. 2, it is assumed that AS3 includes 5 ASBRs, including ASBR1, ASBR2, ASBR3, ASBR4, and ASBR5, where ASBR1 is a second network device. ASBR1 establishes BGP connection with AS2, ASBR2 establishes BGP connection with AS4, ASBR3 establishes BGP connection with AS5, ASBR4 establishes BGP connection with AS6, and ASBR5 establishes BGP connection with AS 7. When ASBR1 receives the authentication information and neighbor AS sent by AS1, it forwards the authentication information and neighbor AS to other ASBRs.

The second network device obtains the verification entry based on the verification information and the neighbor AS, and may include: the second network device obtains AS to which a third network device communicating with the interface belongs; if the AS to which the third network device belongs is a neighbor AS, the second network device determines that the interface is an incoming interface; the second network device obtains the authentication entry based on the authentication information and the ingress interface. That is, the second network device determines the network device to which each interface corresponding to the second network device is connected, and obtains the AS to which the network device belongs. If the AS is a neighbor AS, the interface connecting the network device is an in interface.

In one possible implementation, the second network device obtains an AS to which a third network device in communication with the interface belongs, including: and the second network equipment acquires the AS to which the connected third network equipment belongs according to the configuration information on the interface. The configuration information includes an AS to which the interface is connected to the third network device. That is, an AS identifier of an AS to which the third network device that communicates with the interface belongs may be configured on the interface, and the second network device determines the AS to which the third network device that communicates with the interface belongs through the above configuration. Or the second network device determines a third network device establishing an external border gateway protocol (external border gateway protocol, EBGP) neighbor relation with the interface; the second network device obtains the AS to which the third network device belongs.

The second network device obtains the verification list item based on the verification information and the access interface, and the second network device comprises:

if the verification information comprises the source prefix, the second network equipment establishes a corresponding relation between the access interface and the source prefix, and a verification table item is obtained. That is, if the verification information includes a source prefix that needs to be verified, the second network device may obtain the verification entry according to the ingress interface and the source prefix.

If the verification information comprises the identifier of the first AS, the second network device obtains a source prefix based on the identifier of the first AS and the corresponding relation; the second network device obtains a validation entry based on the source prefix and the ingress interface. The corresponding relation comprises an AS identifier and a source prefix of the first AS. Specifically, the above-mentioned correspondence may be configured on the second network device in advance, or after determining the source prefix that needs to be verified by the source address, the first network device sends the correspondence including the AS identifier of the first AS and the source prefix to the second network device.

After the second network device obtains the verification table entry, it may perform source address verification on the received service packet. Specifically, the second network device receives a service message, where the service message includes a source IP address; and the second network equipment determines the validity of the service message according to the verification list item, the source IP address and the interface for receiving the service message. That is, after receiving the service message, the second network device obtains a source IP address by parsing the service message, and obtains a source prefix by parsing the source IP address. After the source prefix corresponding to the service message is obtained, the access interface corresponding to the source prefix is searched from the verification list item. And the second network equipment determines that the service message is legal according to the interface for receiving the service message and the searched access interface. After the second network device determines that the service message is a legal message, the service message can be forwarded.

From the foregoing, it can be seen that the source address verification mode includes a whitelist verification mode and a gray list verification mode, and the verification result obtained by the second network device may be different in different verification modes. For example, if the verification mode configured by the second network device is a white list verification mode, and if the verification list item includes a source prefix corresponding to the service message and an interface for receiving the service message is matched with the searched incoming interface, the service message is a legal message; if the verification list item comprises a source prefix corresponding to the service message, but the interface for receiving the service message is not matched with the searched access interface, the service message is an illegal message; if the verification list item does not include the source prefix corresponding to the service message, the service message is an illegal message. If the verification mode configured by the second network equipment is a gray list verification mode, if the verification list item comprises a source prefix corresponding to the service message and an interface for receiving the service message is matched with the searched access interface, the service message is a legal message; if the verification list item comprises a source prefix corresponding to the service message, but the interface for receiving the service message is not matched with the searched access interface, the service message is an illegal message; if the verification list item does not include the source prefix corresponding to the service message, the service message is legal.

AS a first network device in a first AS of an originating AS, obtaining authentication information corresponding to the first AS and neighbor AS corresponding to a second AS for authentication. The neighbor AS refers to the last hop AS of the second AS in the direction from the first AS to the second AS. The first network device sends the verification information and the neighbor AS to the second AS, and the verification AS verifies the source address of the received service message based on the verification information and the neighbor AS. That is, the first AS in the present application may send the authentication information and the neighboring AS corresponding to the authentication AS, without sending the authentication information to all the AS on the path with the first AS the originating AS, thereby reducing the communication overhead.

From the foregoing, it can be seen that the first network device may be a controller, RR or border network device in the first AS, and the second network device may be a controller, RR or border network device in the first AS, where the expression forms of the first network device and the expression forms of the second network device may be combined arbitrarily. In order to facilitate understanding of the technical implementation of the present application, the following description will take, as an example, a case where the first network device and the second network device are both boundary network devices, and the first network device and the second network device are both controllers, respectively.

The first scenario, the first network device and the second network device are both boundary network devices

In the scene, BGP neighbor relation is established between boundary network equipment in a first AS and boundary network equipment in a second AS, and the boundary network equipment in the first AS announces neighbor AS to the boundary network equipment of the second AS by sending DPP protocol message, so that the boundary network equipment of the second AS generates an SAV table according to the neighbor AS. For ease of understanding, the boundary network device will be described below as an ASBR.

For example, when the first AS includes a plurality of border network devices, in order to avoid that each border network device in the first AS sends an SPA message and a DPP message to the second network device, communication overhead is reduced, one border network device may be selected AS DR from the plurality of border network devices through manual configuration or selection rules, that is, the first network device. Similarly, when a plurality of border network devices are included in the second AS, one border network device may be selected AS DR, i.e., the second network device, from the plurality of border network devices by manual configuration or selection rules. Based on this, an eBGP neighbor relationship may be established between the first network device and the second network device. Specifically, the AS identifier of the second AS and the address of the second network device may be configured on the first network device, and the AS identifier of the first AS and the address of the first network device may be configured on the second network device, so that the first network device and the second network device may communicate with each other.

For example, AS1 is a first AS and AS is a second AS shown in fig. 5. The AS1 comprises 3 boundary network devices, namely ASBR1, ASBR2 and ASBR3; AS3 includes 5 border network devices ASBR4 through ASBR8. Wherein ASBR1 and ASBR4 are each selected as DR. I.e. ASBR1 for the first network device and ASBR4 for the second network device.

The interaction process is specifically as follows:

(1) The ASBR1 collects the source prefix in the first AS, generates an SPA protocol message, and sends the SPA protocol message to the second network device. The SPA protocol message comprises an AS identifier and a source prefix of the first AS. Specifically, a source prefix that needs to perform source address verification may be configured in advance on the ASBR1, or the ASBR1 determines an IP address prefix in a route corresponding to the first AS a first hop AS in the as_path AS the source prefix.

(2) After receiving the SPA protocol message, the ASBR4 forwards the SPA protocol message to other border network devices, so that each border network device in the second AS can receive the SPA protocol message sent by the ASBR1 and generate a source address record table, AS shown in table 2.

(3) And the boundary network equipment in the first AS collects all AS paths forwarded by the local domain traffic and determines neighbor AS corresponding to the second AS according to the collected AS paths. The AS paths collected by the boundary network equipment are one AS path attribute (including backup paths such AS FRR) from BGP route announcements in a local routing table, and the other AS path from AS paths after inter-domain traffic redirection.

(4) And the boundary network equipment sends the neighbor AS corresponding to the second AS to the ASBR1. I.e. the ASBR1 integrates the neighbor AS sent by the respective border network devices.

(5) ASBR1 generates DPP message according to the integrated neighbor AS and sends the DPP message to ASBR4. The DPP protocol message comprises an AS number identifier of a first AS, an AS identifier of a second AS and a neighbor AS list. For example, in the application scenario shown in fig. 5, the DPP protocol packet includes AS1 (AS identifier of originating AS), AS3 (AS identifier of verifying AS), and neighbor AS list [ AS2, AS4].

(6) After receiving the DPP protocol message, ASBR4 is diffused to other border network devices in the second AS.

(7) ASBR4 or other boundary network devices receive the DPP protocol message and generate SAV tables. When ASBR4 generates an SAV table according to the DPP protocol message, inquiring a source address record table according to an originating AS number in the DPP protocol message, and determining a source prefix to be verified. ASBR4 checks the neighbor AS list and if ASBR4 uses a direct connection port (physical interface) to establish eBGP neighbor relation with a neighbor AS, it can determine that the physical interface connected with the neighbor AS is a legal ingress interface. If ASBR4 establishes eBGP neighbor relation with a certain neighbor AS using a loop-back interface, the second network device determines an outgoing interface obtained through route iteration to the neighbor AS a physical interface for communication with the neighbor AS, and determines the physical interface AS a legal incoming interface.

In this embodiment, when the ASBR4 forwards the SPA protocol packet and the DPP protocol packet to other border network devices, the intermediate forwarding device that cannot identify the protocol packet forwards the protocol packet as a common BGP packet, and does not process the protocol packet.

In a second scenario, the first network device and the second network device are both controllers

In this scenario, the controller in the first AS communicates with the controller in the second AS, transmits an SPA protocol packet and a DPP protocol packet, and forwards the foregoing protocol packet to the border network device in the second AS, thereby generating an SAV table. For example, in the application scenario shown in fig. 6, AS1 is a first AS, and includes a border network device R1 and a controller C1; AS3 is a second AS, comprising a border network device R2 and a controller C2.

The specific interaction process is as follows:

(1) A communication connection is established. For example, the controller C1 of the AS1 establishes a connection with the border network device R1 of the present AS; the controller C2 of the AS3 establishes connection with the boundary network equipment R2 of the AS; a transmission control protocol (transmission control protocol, TCP) connection may be established between controller C1 of AS1 and controller C2 of AS3 to transmit protocol messages. The controller C1 and the boundary routing device R1 may communicate with each other through BGP, BGP monitoring protocols (BGP monitoring protocol, BMP) and other protocols; the controller C2 and the border router R2 may also communicate with each other through BGP, BMP, or other protocols.

(2) The controller C1 collects source prefixes in the AS 1. For example, the controller C1 may collect the source prefixes in the AS1 by: one way is to add a source prefix in the controller C1 by manual configuration; another way is for the controller C1 to collect BGP routes for border network devices in AS1 and determine the source prefix from routes with AS1 AS the originating AS.

(3) The controller C1 constructs an SPA protocol message and sends the SPA protocol message to the controller C2. The SPA protocol message comprises an AS identifier of the first AS and a corresponding source prefix.

(4) The controller C2 synchronizes the SPA protocol packet to the border network device R2, and the border network device R2 generates a source address record table.

(5) The controller C2 collects all AS paths of the flow of the local domain and determines a neighbor AS list corresponding to the second AS according to the AS paths; or receiving a neighbor AS list sent by each boundary network device.

(6) The controller C1 constructs a DPP protocol message and sends the controller C2. The DPP protocol packet includes an AS identifier of the first AS, an AS identifier of the second AS, and an AS identifier of the neighbor AS.

(7) The controller C2 synchronizes the DPP protocol packet to all the border network devices in the second AS, so that each border network device generates an SAV table.

When the first network device is a border network device and the second network device is a controller or an RR, or when the first network device is an RR and the second network device is a border network device, a controller or an RR, the first network device is a border network device; or when the first network device is a controller and the second network device is a border network device or RR, the specific implementation of the first network device sending the verification information to the second network device and the neighboring AS may refer to the embodiments shown in fig. 3, fig. 5 or fig. 6, and this embodiment is not described herein again.

Based on the above method embodiments, the embodiments of the present application provide an authentication information sending device and an authentication entry obtaining device, and will be described below with reference to the accompanying drawings.

Referring to fig. 7, the diagram is a structural diagram of an authentication information sending apparatus provided in the embodiment of the present application, where the apparatus is applied to a first network device, or the apparatus may implement the functions of ASBR1, ASBR2, or ASBR3 in the embodiment shown in fig. 5, or the apparatus may implement the functions of the controller C1 in the embodiment shown in fig. 6. The apparatus 700 may include: a processing unit 701 and a transmitting unit 702. Wherein the processing unit 701 may perform S301 in the above method embodiment, and the transmitting unit 702 may perform S302 in the above method embodiment.

Specifically, the processing unit 701 is configured to obtain authentication information of a first autonomous domain AS to which the first autonomous domain AS belongs and a neighbor AS of a second AS for authentication, where the neighbor AS is a previous hop of the second AS in a direction from the first AS to the second AS;

a sending unit 702, configured to send the authentication information and the neighboring AS to the second AS.

In a possible implementation manner, the processing unit 701 is specifically configured to obtain a first AS path taking the first AS an endpoint, where the first AS path includes the second AS; and acquiring neighbor AS of the second AS based on the first AS path.

In a possible implementation manner, the processing unit 701 is specifically configured to obtain a second AS path taking the first AS an endpoint, where the second AS path includes the second AS, and the second AS path is a standby path or a load sharing path of the first AS path.

In a possible implementation manner, the processing unit 701 is specifically configured to receive a neighboring AS of the second AS sent by a border network device in the first AS, where the neighboring AS of the second AS sent by the border network device in the first AS is an AS determined by the border network device in the first AS according to a self routing table and/or a redirection path.

In a possible implementation manner, the processing unit 701 is specifically configured to obtain, by the first network device, a neighboring AS of the second AS according to a self routing table and/or a redirection path.

In one possible implementation, the first network device is a controller, a route reflector RR or a border network device.

In a possible implementation manner, the sending unit 702 is specifically configured to obtain an address of a second network device in the second AS, where the second network device is a controller, an RR, or a border network device; and sending the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment.

In a possible implementation manner, the sending unit 702 is further configured to send a packet to the second network device, where the packet includes an identifier of the first AS, an identifier of the second AS, and an identifier of the neighboring AS.

In a possible implementation manner, the processing unit 701 is further configured to obtain an identifier of the second AS and an address of a next hop, where the next hop is one of a controller in the second AS, a border network device in the second AS, or a route reflector in the second AS.

In this embodiment, the implementation of each unit may refer to a specific implementation process of the first network device in the foregoing method embodiment, which is not described herein again.

Referring to fig. 8, the drawing is a verification entry obtaining apparatus provided in the embodiment of the present application, where the apparatus is applied to a second network device in a second AS for verification, or the apparatus may implement a function of any one of ASBR4-ASABR8 devices in the embodiment shown in fig. 5, or the apparatus may implement a function of a controller C2 in the embodiment shown in fig. 6. The apparatus 800 may include: a receiving unit 801 and a processing unit 802. The receiving unit 801 is configured to receive the authentication information and the neighboring AS sent by the first network device in S302, and the processing unit 802 is configured to execute S303 in the foregoing method embodiment.

A receiving unit 801, configured to receive authentication information of a first AS and a neighboring AS of the second AS, where the authentication information is sent by a first network device in the first AS;

a processing unit 802, configured to obtain, based on the authentication information and the neighboring AS, an authentication entry, where the authentication entry includes a source prefix corresponding to the first AS and an ingress interface for communicating with the neighboring AS.

In one possible implementation, the apparatus further includes: a transmitting unit (not shown in fig. 8) connected to the receiving unit for transmitting the authentication information and the neighbor AS to the border network device in the second AS.

In a possible implementation manner, the verification information includes the source prefix, and the processing unit 802 is specifically configured to obtain an AS to which a third network device in communication with an interface belongs; if the AS to which the third network device belongs is the neighbor AS, determining that the interface is the access interface; the authentication entry is obtained based on the source prefix and the ingress interface.

In a possible implementation manner, the verification information includes an identifier of the first AS, and the processing unit 802 is specifically configured to obtain an AS to which a third network device that communicates with an interface belongs; if the AS to which the third network device belongs is the neighbor AS, determining that the interface is the access interface; acquiring the source prefix based on the identifier of the first AS and a corresponding relation, wherein the corresponding relation comprises the identifier of the first AS and the source prefix; the authentication entry is obtained based on the source prefix and the ingress interface.

In a possible implementation manner, the receiving unit 801 is further configured to receive a service packet, where the service packet includes a source internet protocol IP address;

the processing unit 802 is further configured to determine validity of the service packet according to the verification entry, the source IP address, and an interface for receiving the service packet.

In this embodiment, the implementation of each unit may refer to a specific implementation process of the second network device in the foregoing method embodiment, which is not described herein again.

It should be noted that, in the embodiment of the present application, the division of the units is schematic, which is merely a logic function division, and other division manners may be implemented in actual practice. Each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. For example, in the above embodiment, the processing unit and the transmitting unit may be the same unit or may be different units. The integrated units may be implemented in hardware or in software functional units.

The hardware structure of the aforementioned apparatus 700 and the aforementioned apparatus 800 may be the structure shown in fig. 9, and fig. 9 is a schematic structural diagram of a network device provided in the embodiment of the present application, where the network device may be, for example, a first network device or a second network device in the embodiment of the aforementioned method.

The network device 900 includes: a processor 910, a communication interface 920, and a memory 930. Where the number of processors 910 in the communication device 900 may be one or more, one processor is illustrated in fig. 9. In the present embodiment, processor 910, communication interface 920, and memory 930 may be connected by a bus system or other means, with a bus system 940 being shown in FIG. 9 as an example.

The processor 910 may be a CPU, an NP, or a combination of a CPU and NP. The processor 910 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof.

Memory 930 may include volatile memory (RAM), such as random-access memory; the memory 930 may also include a nonvolatile memory (non-volatile memory), such as a flash memory (flash memory), a Hard Disk Drive (HDD) or a Solid State Drive (SSD); memory 930 may also include combinations of the above types of memory. The memory 930 may store, for example, the aforementioned segment routing SR policies, etc.

Optionally, the memory 930 stores an operating system and programs, executable modules or data structures, or a subset thereof, or an extended set thereof, where the programs may include various operational instructions for implementing various operations. The operating system may include various system programs for implementing various underlying services and handling hardware-based tasks. The processor 910 may read the program in the memory 930 to implement the method provided in the embodiment of the present application.

The memory 930 may be a memory device in the communication device 900 or may be a memory device independent of the communication device 900.

The bus system 940 may be a peripheral component interconnect (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The bus system 940 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 9, but not only one bus or one type of bus.

The hardware structure of the aforementioned apparatus 700 and the aforementioned apparatus 800 may be the structure shown in fig. 10, and fig. 10 is a schematic structural diagram of a network device provided in the embodiment of the present application, where the network device may be, for example, a first network device or a second network device in the embodiment of the aforementioned method.

The network device 1000 includes: a main control board 1010 and an interface board 1030.

The main control board 1010 is also called a main processing unit (main processing unit, MPU) or a routing processing card (route processor card), and the main control board 1010 controls and manages various components in the network device 1000, including routing computation, device management, device maintenance, and protocol processing functions. The main control board 1010 includes: a central processing unit 1011 and a memory 1012.

Interface board 1030 is also referred to as a line interface unit card (line processing unit, LPU), line card, or service board. Interface board 1030 is used to provide various service interfaces and to enable forwarding of data packets. The service interfaces include, but are not limited to, ethernet interfaces, such as flexible ethernet service interfaces (Flexible Ethernet Clients, flexE Clients), POS (Packet over SONET/SDH) interfaces, etc. Interface board 1030 includes: a central processor 1031, a network processor 1032, a forwarding table entry memory 1034, and a physical interface card (physical interface card, PIC) 1033.

Central processor 1031 on interface board 1030 is used to control and manage interface board 1030 and communicate with central processor 1011 on main control board 1010.

The network processor 1032 is configured to implement forwarding processing of the packet. Network processor 1032 may be in the form of a forwarding chip. Specifically, the processing of the uplink message includes: processing a message input interface and searching a forwarding table; the processing of the downstream message includes forwarding table lookup and the like.

The physical interface card 1033 is used to implement the docking function of the physical layer, from which the original traffic enters the interface board 1030, and from which the processed messages are sent out from the physical interface card 1033. The physical interface card 1033 includes at least one physical interface, also referred to as a physical port. The physical interface card 1033, also called a daughter card, may be mounted on the interface board 1030 and is responsible for converting the photoelectric signals into messages and forwarding the messages to the network processor 1032 for processing after the messages are legally checked. In some embodiments, the central processor 1031 of the interface board 1003 may also perform the functions of the network processor 1032, such as implementing software forwarding based on a general purpose CPU, so that the network processor 1032 is not required in the physical interface card 1033.

Optionally, the network device 1000 includes a plurality of interface boards, for example, the network device 1000 further includes an interface board 1040, the interface board 1040 includes: a central processor 1041, a network processor 1042, a forwarding table entry store 1044, and a physical interface card 1043.

Optionally, the network device 1000 also includes a switching fabric 1020. The switch fabric 1020 may also be referred to as a switch fabric unit (switch fabric unit, SFU). In the case of a network device having a plurality of interface boards 1030, the switching fabric 1020 is used to complete the data exchange between the interface boards. For example, interface board 1030 and interface board 1040 may communicate via switch fabric 1020.

The main control board 1010 and the interface board 1030 are coupled. For example. Main control board 1010, interface board 1030 and interface board 1040 are connected with system back board by system bus to realize intercommunication. In one possible implementation, an inter-process communication protocol (inter-process communication, IPC) channel is established between the main control board 1010 and the interface board 1030, and communication is performed between the main control board 1010 and the interface board 1030 through the IPC channel.

Logically, network device 1000 includes a control plane that includes a main control board 1010 and a central processor 1031, and a forwarding plane that includes various components that perform forwarding, such as a forwarding table entry memory 1034, a physical interface card 1033, and a network processor 1032. The control plane performs the functions of router, generating forwarding table, processing signaling and protocol messages, configuring and maintaining the state of the device, etc., and the control plane issues the generated forwarding table to the forwarding plane, where the network processor 1032 forwards the message received by the physical interface card 1033 based on the forwarding table issued by the control plane. The forwarding table issued by the control plane may be stored in forwarding table entry memory 1034. In some embodiments, the control plane and the forwarding plane may be completely separate and not on the same device.

It should be understood that the operations on the interface board 1040 are consistent with the operations of the interface board 1030 in the embodiment of the present application, and for brevity, will not be described again. It should be understood that the network device 1000 of the present embodiment may correspond to the first network device in the foregoing method embodiments, and the main control board 1010, the interface board 1030, and/or the interface board 1040 in the network device 1000 may implement the various steps in the foregoing method embodiments, which are not described herein for brevity.

It should be understood that the master control board may have one or more pieces, and that the master control board may include a main master control board and a standby master control board when there are more pieces. The interface boards may have one or more, the more data processing capabilities the network device is, the more interface boards are provided. The physical interface card on the interface board may also have one or more pieces. The switching network board may not be provided, or may be provided with one or more blocks, and load sharing redundancy backup can be jointly realized when the switching network board is provided with the plurality of blocks. Under the centralized forwarding architecture, the network device may not need to exchange network boards, and the interface board bears the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device may have at least one switching fabric, through which data exchange between multiple interface boards is implemented, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing power of the network devices of the distributed architecture is greater than that of the devices of the centralized architecture. Alternatively, the network device may be in the form of only one board card, i.e. there is no switching network board, the functions of the interface board and the main control board are integrated on the one board card, and the central processor on the interface board and the central processor on the main control board may be combined into one central processor on the one board card, so as to execute the functions after stacking the two, where the data exchange and processing capability of the device in this form are low (for example, network devices such as a low-end switch or a router). Which architecture is specifically adopted depends on the specific networking deployment scenario.

In some possible embodiments, the network device may be implemented as a virtualized device. For example, the virtualized device may be a Virtual Machine (VM) running a program for sending message functions, the virtual machine deployed on a hardware device (e.g., a physical server). Virtual machines refer to complete computer systems that run in a completely isolated environment with complete hardware system functionality through software emulation. The virtual machine may be configured as a network device. For example, the network device may be implemented based on a generic physical server in combination with network function virtualization (network functions virtualization, NFV) technology. The network device is a virtual host, a virtual router, or a virtual switch. Those skilled in the art can virtually obtain the network device with the above functions on the general physical server by combining with the NFV technology through reading the present application, and details are not repeated here.

It should be understood that the network devices in the above various product forms have any function of the first network device or the second network device in the above method embodiments, which is not described herein.

The embodiment of the application also provides a chip, which comprises a processor and an interface circuit, wherein the interface circuit is used for receiving the instruction and transmitting the instruction to the processor; a processor, such as one specific implementation of a processing unit in the apparatus 800 shown in fig. 8, may be used to perform the methods described above. Wherein the processor is coupled to a memory for storing programs or instructions which, when executed by the processor, cause the system-on-a-chip to implement the method of any of the method embodiments described above.

Alternatively, the processor in the system-on-chip may be one or more. The processor may be implemented in hardware or in software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, or the like. When implemented in software, the processor may be a general purpose processor, implemented by reading software code stored in a memory.

Alternatively, the memory in the system-on-chip may be one or more. The memory may be integral with the processor or separate from the processor, and is not limited in this application. For example, the memory may be a non-transitory processor, such as a ROM, which may be integrated on the same chip as the processor, or may be separately provided on different chips, and the type of memory and the manner of providing the memory and the processor are not specifically limited in this application.

The system-on-chip may be, for example, a field programmable gate array (field programmable gate array, FPGA), an application-specific integrated chip (ASIC), a system-on-chip (SoC), a central processing unit (central processor unit, CPU), a network processor (network processor, NP), a digital signal processing circuit (digital signal processor, DSP), a microcontroller (micro controller unit, MCU), a programmable controller (programmable logic device, PLD) or other integrated chip.

The embodiment of the application also provides a network equipment system, which comprises a first network equipment and a second network equipment, wherein the first network equipment performs the corresponding related method of the above embodiments S301-S302; the second network device executes the related method corresponding to S303 in the above embodiment.

The present application also provides a computer readable storage medium comprising instructions or a computer program which, when run on a computer, causes the computer to perform the method provided by the above embodiments.

The present embodiments also provide a computer program product comprising instructions or a computer program which, when run on a computer, causes the computer to perform the method provided by the above embodiments.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims of this application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, e.g., the division of units is merely a logical service division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each service unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software business units.

The integrated units, if implemented in the form of software business units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Those of skill in the art will appreciate that in one or more of the examples described above, the services described herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The foregoing embodiments have been provided for the purpose of illustrating the objects, technical solutions and advantageous effects of the present application in further detail, and it should be understood that the foregoing embodiments are merely exemplary embodiments of the present application.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A verification information transmitting method, characterized in that the method comprises:

the method comprises the steps that a first network device obtains verification information of a first autonomous domain AS to which the first network device belongs and a neighbor AS of a second AS for verification, wherein the neighbor AS is a last hop of the second AS in a direction from the first AS to the second AS;

the first network device sends the authentication information and the neighbor AS to the second AS.

2. The method of claim 1, wherein the first network device obtains neighbor AS of the second AS for authentication, comprising:

the first network device obtains a first AS path taking the first AS AS an endpoint, wherein the first AS path comprises the second AS;

the first network device obtains neighbor AS of the second AS based on the first AS path.

3. The method of claim 2, wherein the first network device obtains neighbor AS of the second AS for authentication, comprising:

the first network device obtains a second AS path taking the first AS AS an endpoint, wherein the second AS path comprises the second AS, and the second AS path is a standby path or a load sharing path of the first AS path.

4. The method of claim 1, wherein the first network device obtains neighbor AS of the second AS for authentication, comprising:

the first network device receives neighbor AS of the second AS sent by the boundary network device in the first AS, wherein the neighbor AS of the second AS sent by the boundary network device in the first AS is the AS determined by the boundary network device in the first AS according to a self routing table and/or a redirection path.

5. The method of claim 1, wherein the first network device obtains a neighbor AS corresponding to the second AS for authentication, comprising:

and the first network equipment acquires the neighbor AS of the second AS according to the self routing table and/or the redirection path.

6. The method according to any of claims 1 to 5, wherein the first network device is a controller, a routing reflector RR or a border network device.

7. The method according to any of claims 1 to 6, wherein the first network device sending the authentication information and the neighbor AS to the second AS comprises:

the first network device obtains an address of a second network device in the second AS, wherein the second network device is a controller, RR or boundary network device;

And the first network equipment sends the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment.

8. The method of claim 7, wherein the method further comprises:

the first network device sends a message to the second network device, wherein the message comprises the identifier of the first AS, the identifier of the second AS and the identifier of the neighbor AS.

9. The method of claim 8, wherein an originating AS identification field in the message comprises an identification of the first AS, wherein a verifying AS identification field in the message comprises an identification of the second AS, and wherein a neighbor AS identification field in the message comprises an identification of the neighbor AS.

10. The method according to any one of claims 1 to 9, further comprising:

the first network device obtains an identifier of the second AS and an address of a next hop, where the next hop is one of a controller in the second AS, a border network device in the second AS, or a route reflector in the second AS.

11. A method according to any of claims 1 to 10, wherein the authentication information comprises at least one of a source prefix corresponding to the first AS and an identity of the first AS.

12. A method for obtaining a verification entry, the method comprising:

a second network device in a second AS for verification receives verification information of a first AS and neighbor AS of the second AS, wherein the verification information of the first AS is sent by the first network device in the first AS;

the second network device obtains a verification table entry based on the verification information and the neighbor AS, wherein the verification table entry comprises a source prefix corresponding to the first AS and an inlet interface for communicating with the neighbor AS.

13. The method according to claim 12, wherein the method further comprises:

the second network device sends the authentication information and the neighbor AS to a border network device in the second AS.

14. The method according to claim 12 or 13, wherein the authentication information comprises the source prefix, and wherein the second network device obtains an authentication entry based on the authentication information and the neighbor AS, comprising:

the second network equipment acquires an AS to which a third network equipment communicated with an interface belongs;

if the AS to which the third network device belongs is the neighbor AS, the second network device determines that the interface is the access interface;

the second network device obtains the authentication entry based on the source prefix and the ingress interface.

15. The method according to claim 12 or 13, wherein the authentication information comprises an identification of the first AS, and wherein the second network device obtains an authentication entry based on the authentication information and the neighbor AS, comprising:

the second network device obtains the source prefix based on the identifier of the first AS and a corresponding relation, wherein the corresponding relation comprises the identifier of the first AS and the source prefix;

16. The method according to any one of claims 12 to 15, further comprising:

the second network equipment receives a service message, wherein the service message comprises a source Internet Protocol (IP) address;

and the second network equipment determines the validity of the service message according to the verification list item, the source IP address and the interface for receiving the service message.

17. An authentication information transmitting apparatus, the apparatus being applied to a first network device, the apparatus comprising:

The processing unit is used for acquiring verification information of a first autonomous domain AS to which the processing unit belongs and neighbor AS of a second AS for verification, wherein the neighbor AS is a last hop of the second AS in the direction from the first AS to the second AS;

and the sending unit is used for sending the verification information and the neighbor AS to the second AS.

18. The apparatus according to claim 17, wherein the processing unit is specifically configured to:

acquiring a first AS path taking the first AS AS an endpoint, wherein the first AS path comprises the second AS;

and acquiring neighbor AS of the second AS based on the first AS path.

19. The apparatus of claim 18, wherein the processing unit is configured to obtain a second AS path with the first AS an endpoint, the second AS path including the second AS, the second AS path being a backup path or a load sharing path of the first AS path.

20. The apparatus according to claim 17, wherein the processing unit is specifically configured to receive a neighboring AS of the second AS sent by a border network device in the first AS, where the neighboring AS of the second AS sent by the border network device in the first AS is an AS determined by the border network device in the first AS according to a self routing table and/or a redirection path.

21. The apparatus according to claim 17, wherein the processing unit is specifically configured to obtain, by the first network device, a neighboring AS of the second AS according to a self routing table and/or a redirection path.

22. The apparatus according to any of claims 17 to 21, wherein the first network device is a controller, a routing reflector RR or a border network device.

23. The apparatus according to any one of claims 17 to 22, wherein the transmitting unit is specifically configured to:

acquiring an address of a second network device in the second AS, wherein the second network device is a controller, an RR or a boundary network device;

and sending the verification information and the neighbor AS to the second network equipment according to the address of the second network equipment.

24. The apparatus of claim 23, wherein the sending unit is further configured to send a message to the second network device, the message including an identity of the first AS, an identity of the second AS, and an identity of the neighbor AS.

25. The apparatus of claim 24, wherein an originating AS identification field in the message comprises an identification of the first AS, wherein a verifying AS identification field in the message comprises an identification of the second AS, and wherein a neighbor AS identification field in the message comprises an identification of the neighbor AS.

26. The apparatus according to any of the claims 17 to 25, wherein the processing unit is further configured to obtain an identity of the second AS and an address of a next hop, the next hop being one of a controller in the second AS, a border network device in the second AS, or a routing reflector in the second AS.

27. An apparatus according to any one of claims 17 to 26, wherein the authentication information comprises at least one of a source prefix corresponding to the first AS and an identity of the first AS.

28. An authentication entry retrieval apparatus, the apparatus being applied to a second network device in a second AS for authentication, the apparatus comprising:

a receiving unit, configured to receive authentication information of a first AS and neighbor AS of the second AS, where the authentication information is sent by a first network device in the first AS;

and the processing unit is used for obtaining a verification list item based on the verification information and the neighbor AS, wherein the verification list item comprises a source prefix corresponding to the first AS and an inlet interface used for communicating with the neighbor AS.

29. The apparatus of claim 28, wherein the apparatus further comprises:

and the sending unit is used for sending the verification information and the neighbor AS to boundary network equipment in the second AS.

30. The apparatus according to claim 28 or 29, wherein the authentication information comprises the source prefix, the processing unit being specifically configured to:

acquiring an AS to which a third network device communicated with an interface belongs;

if the AS to which the third network device belongs is the neighbor AS, determining that the interface is the access interface;

the authentication entry is obtained based on the source prefix and the ingress interface.

31. The apparatus according to claim 28 or 29, wherein the authentication information comprises an identity of the first AS, and wherein the processing unit is configured to:

acquiring the source prefix based on the identifier of the first AS and a corresponding relation, wherein the corresponding relation comprises the identifier of the first AS and the source prefix;

32. The device according to any one of claims 28 to 31, wherein,

the receiving unit is further configured to receive a service packet, where the service packet includes a source internet protocol IP address;

The processing unit is further configured to determine validity of the service packet according to the verification entry, the source IP address, and an interface for receiving the service packet.

33. A network device, the routing device comprising: a processor coupled to a memory having stored therein at least one computer program instruction that is loaded and executed by the processor to cause the network device to implement the method of any of claims 1 to 11 or to implement the method of any of claims 12 to 16.

34. A computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the method of any one of the preceding claims 1 to 11 or to implement the method of any one of the claims 12 to 16.