CN105915455B - Method and device for realizing position identification separation protocol multi-homing - Google Patents

Method and device for realizing position identification separation protocol multi-homing Download PDF

Info

Publication number
CN105915455B
CN105915455B CN201610211670.7A CN201610211670A CN105915455B CN 105915455 B CN105915455 B CN 105915455B CN 201610211670 A CN201610211670 A CN 201610211670A CN 105915455 B CN105915455 B CN 105915455B
Authority
CN
China
Prior art keywords
xtr
eid
homing
xtrs
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610211670.7A
Other languages
Chinese (zh)
Other versions
CN105915455A (en
Inventor
林长望
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou H3C Technologies Co Ltd
Original Assignee
Hangzhou H3C Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou H3C Technologies Co Ltd filed Critical Hangzhou H3C Technologies Co Ltd
Priority to CN201610211670.7A priority Critical patent/CN105915455B/en
Publication of CN105915455A publication Critical patent/CN105915455A/en
Application granted granted Critical
Publication of CN105915455B publication Critical patent/CN105915455B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing

Abstract

The invention provides a method and a device for realizing multi-homing of a location identity separation protocol, wherein the method comprises the steps of establishing communication connection with other multi-homing XTRs in the same multi-homing XTR set, synchronizing local terminal identity EID states with the other multi-homing XTRs through the communication connection, wherein the EID states comprise states that a routing location R L OC is accessible or inaccessible to an EID network segment, determining a target R L OC address which can reach a target EID according to the EID states of the multi-homing XTRs in the same multi-homing XTR set when receiving a location request message aiming at the target EID, and returning a response message carrying the target R L OC address to a location request party device.

Description

Method and device for realizing position identification separation protocol multi-homing
Technical Field
The invention relates to the technical field of network communication, in particular to a method and a device for realizing position identification separation protocol multi-homing.
Background
The L ISP (L bearer/Identity Separation Protocol) is a Protocol based on host Identity (ID) and location Separation on the network side L ISP network is composed of two parts, namely a core network and an edge network, wherein R L OC (Routing L bearers) is used in the core network to identify routers, and EIDs (Endpoint Identifiers) are used in the edge network to identify terminals.
In an L ISP network, a L ISP site may be accessed by multiple XTRs (Egress/Ingress tunnel router, collectively referred to as edge device), traffic from a L ISP site to an external network may be load-shared or active-standby by the XTRs, and traffic from the external network to the L ISP site may also be load-shared by multiple XTRs.
For example, assume L ISP site HOST1 is accessed through XTR1 and XTR2 and HOST2 is accessed through XTR3 when HOST2 sends a message to HOST1, the message arrives at XTR3, XTR3 looks up the route whose destination address is that of HOST1, if not, then requests MR/MS for the location of HOST1, i.e., the R L OC address where HOST1 is located, MS forwards the location request message to one of XTR1 and XTR2 (say XTR1), and when XTR1 receives the location request message, returns XTR L OC addresses of XTR1 and XTR2 to XTR3 so that XTR3 can forward the message to XTR1 or XTR2 on a load-sharing basis.
However, it has been found in practice that in the existing L ISP multihoming implementation, a multihomed XTR (such as XTR1 and XTR2 in the above example) cannot sense whether the remaining multihomed XTRs are reachable to the local site EID, which may result in a message sending failure, for example, assuming that XTR2 is not reachable to HOST1 after the interface of XTR2 and HOST1 is disconnected in the above example, XTR1 does not know that, when XTR1 receives a location request, XTR1 will still return the R L OC addresses of both XTR1 and XTR2 to XTR3, and if XTR3 performs load sharing, send a message to XTR2, and after reaching XTR2, it will not reach HOST1, which results in a message sending failure.
Disclosure of Invention
The invention provides a method and a device for realizing location identity separation protocol multi-homing, which are used for solving the problem that a message is possibly failed to be sent under the L ISP multi-homing scene in the prior art.
According to a first aspect of the embodiments of the present invention, there is provided a method for implementing location identity separation protocol multihoming, which is applied to a multihomed edge device XTR in an L ISP network, and the method includes:
establishing communication connections with other multi-homed XTRs in the same multi-homed XTR set;
synchronizing local terminal identification (EID) states with the other multi-homed XTRs over the communication connection, the EID states including a state of routing location R L OC to EID segment reachable or unreachable;
when a position request message aiming at a target EID is received, according to the EID state of each multi-homing XTR in the same multi-homing XTR set, a target R L OC address which can reach the target EID is determined, and a response message carrying the target R L OC address is returned to position requesting equipment, wherein the target R L OC address is the R L OC address of the multi-homing XTR which can reach the target EID in the same multi-homing XTR set.
According to a second aspect of the embodiments of the present invention, there is provided a device for implementing location identity separation protocol multihoming, which is applied to a multihomed edge device XTR in an L ISP network, and includes:
a connection establishment unit for establishing communication connections with other multi-homed XTRs in the same multi-homed XTR set;
a synchronization unit, configured to synchronize local terminal identification, EID, states including a state where a routing location, R L OC, is reachable or unreachable to an EID network segment with the other multi-homed XTR over the communication connection;
and a message interaction unit, configured to, when receiving a location request message for a target EID, determine, according to the EID state of each multihomed XTR in the same multihomed XTR set, a target R L OC address that can reach the target EID, and return a response message carrying the target R L OC address to a location requester device, where the target R L OC address is an R L OC address of a multihomed XTR that can reach the target EID in the same multihomed XTR set.
By establishing communication connection with other multi-homing XTRs in the same multi-homing XTR set and synchronizing the local EID state through the communication connection, when a position request message for a target EID is received, a target R L OC address which can reach the target EID can be determined according to the EID state of each multi-homing XTR in the same multi-homing XTR set, and a response message carrying the target R L OC address is returned to a position requesting device, so that the message sending failure caused by returning the R L OC address of the unreachable target EID to the position requesting device is avoided.
Drawings
Fig. 1 is a schematic flowchart of a method for implementing a split-location identity protocol multihoming according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of a specific application scenario provided in the embodiment of the present invention;
fig. 3 is a schematic structural diagram of a device for implementing a location identity separation protocol multihoming according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of another apparatus for implementing a location identity separation protocol multihoming according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of another apparatus for implementing location identity separation protocol multi-homing according to an embodiment of the present invention.
Detailed Description
In order to make the technical solutions in the embodiments of the present invention better understood and make the above objects, features and advantages of the embodiments of the present invention more comprehensible, the technical solutions in the embodiments of the present invention are described in further detail below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a schematic flow chart of a method for implementing a split-location-identity protocol multihoming according to an embodiment of the present invention, and as shown in fig. 1, the method for implementing a split-location-identity protocol multihoming may include the following steps:
step 101, establishing communication connections with other multi-homed XTRs in the same multi-homed XTR set.
In an embodiment of the present invention, the above method can be applied to any XTR in a multi-homed XTR, wherein each multi-homed XTR belonging to the same multi-homed XTR set is called a co-homed XTR for other multi-homed XTRs in the multi-homed XTR set, i.e. each multi-homed XTR belonging to the same multi-homed XTR set is a co-homed XTR. For example, assuming XTR1 and XTR2 are multihomed XTRs, XTR1 is a homonymous XTR of XTR2 and XTR2 is a homonymous XTR of XTR 1. For convenience of description, the following description takes the execution body of the above method as the first XTR as an example. It should be appreciated, however, that the first XTR does not refer specifically to a fixed XTR, but rather may refer to any of the multiple-homed XTRs, and embodiments of the invention will not be repeated in the following.
In the embodiment of the present invention, a communication connection may be established between the affiliated XTRs, where the communication connection may include a TCP (Transmission Control Protocol) connection or a UDP (User Datagram Protocol) connection.
For example, R L OC addresses of other multi-homed XTRs (i.e., the homonymic XTR) may be configured on each multi-homed XTR belonging to the same multi-homed XTR set, so that the homonymic XTR may listen to the corresponding port number after the device is started through the configured mutual R L OC addresses, and actively initiate TCP connection with a large address to a small address.
Step 102, synchronize local EID states with other multi-homed XTRs over the communication connection.
In the embodiment of the present invention, after the first XTR establishes the communication connection with the co-owned XTR, the local EID state can be synchronized to the co-owned XTR through the communication connection, and the local EID state of the co-owned XTR sent by the co-owned XTR through the communication connection is received.
For example, assuming that XTR1 and XTR2 are homonymous XTRs, R L OC address of XTR1 is 1.1.1.1, R L OC address of XTR2 is 2.2.2.2, and 1.1.1.1.1 and 2.2.2 are both accessible to EID segment 10.1.1.0/24, after the communication connection is established between XTR1 and XTR2, the EID state of 1.1.1.1 accessible 10.1.1.0/24 can be synchronized to XTR2 through the communication connection, and similarly, XTR1 can also receive the EID state of 2.2.2.2 accessible 10.1.1.0/24 synchronized by XTR2 through the communication connection.
Further, in the embodiment of the present invention, when the EID state of the multi-homed XTR changes, the changed EID state needs to be synchronized to the co-homed XTR in real time.
Correspondingly, in the embodiment of the present invention, when the first XTR monitors that the local EID state changes, the EID state update message may be sent to the co-owned XTR through the communication connection, where the EID state update message carries the changed local EID state, so that the co-owned XTR performs the XTR state update according to the EID state update message.
For example, it is assumed that XTR1(R L OC address is 1.1.1.1) and XTR2(R L OC address is 2.2.2.2) are the same as the home XTR and establish communication connection with each other, when XTR1 detects a change in local EID state, if XTR1 senses that 10.1.1.0/24 routing is reachable or unreachable (if the corresponding eth interface is disconnected), XTR1 may send an EID state update message to XTR2, so that XTR2 updates the state of 1.1.1.1 to 10.1.1.0/24 from reachable to unreachable.
Further, in this embodiment of the present invention, when the first XTR monitors that the communication connection with a co-homed XTR (assumed to be the second XTR) is disconnected, the first XTR may age the entry corresponding to the EID state synchronized from the second XTR.
In the embodiment of the invention, when a first XTR receives an EID state updating message sent by the same attribution XTR, whether state table entries of R L OC and EID carried in the EID state updating message are stored or not can be judged (the table entries record the reachable or unreachable state of the R L OC to the EID), if yes, whether the EID state updating message is the EID deleting message or not is further judged, if yes, the corresponding state table entries of R L OC and EID are deleted, if not, the corresponding state table entries of R L OC and EID are updated, if not, whether the EID state updating message is the EID deleting message or not is further judged, if yes, the message is not responded, and if not, the corresponding state table entries of R L OC and EID are created.
Further, in this embodiment of the present invention, after synchronizing the local EID states between the affiliated XTRs, each XTR may carry its own EID state and the EID state of the affiliated XTR in the registration message sent to the MS, so that the MS can know that each R L OC is reachable or unreachable to the corresponding EID.
For example, XTR1, XTR2, and XTR3 are homogeneous XTRs, and R L OC addresses are 1.1.1.1.1, 2.2.2.2, and 3.3.3.3, respectively, where 1.1.1.1.1 and 2.2.2 to EID: 10.1.1.0/24 are known from the synchronized local EID states among XTR1, XTR2, and XTR3, and 3.3.3.3 to EID: 10.1.1.0/24 is not known, then XTR1, XTR2, and XTR3 may carry R L OC address lists 1.1.1.1, 2.2.2.2, and 3.3.3.3.3.3 when sending a registration message to MS that registers EID: 10.1.1.0/24, and set the reachable states of 1.1.1.1.1.1.1, 2.2.2.2, and 3.3.3.3.3.3.3.2 as well as the reachable states of DOWN 3.3.3.3.3.3.3.3.2.2.2.2 and UP message and 3.3.3.3.3.2.3.3.3.3.3.3.2.3.3.3.3.3.2.
Wherein, when the first XTR finds that both the first XTR and the homogeneous XTR are unreachable for a certain EID according to the local EID state of the first XTR and the homogeneous XTR, the first XTR can withdraw the registration of the EID to the MS; similarly, the cognate XTR of the first XTR can also deregister the EID to the MS.
Step 103, when receiving the location request message for the target EID, according to the EID status of each multi-homing XTR in the same multi-homing XTR set, determining a target R L OC address which can reach the target EID, and returning a response message carrying the target R L OC address to the location requesting device.
In the embodiment of the present invention, the target EID does not refer to a fixed EID, but may refer to any EID in the EID segment reachable by the first XTR in the initial state.
In this embodiment of the present invention, when the first XTR receives the location request message for the target EID, the first XTR may determine whether the first XTR and the same-home XTR can reach the target EID according to the EID states of the first XTR and the same-home XTRs, so as to determine an R L OC address (referred to as a target R L OC address, that is, the target R L OC address is the R L OC address of the multihomed XTR that can reach the target EID in the same multihomed XTR set), and further, the first XTR may return a response message carrying the target R L OC address to the location requesting device, so that the location requesting device sends the message to the target host through the XTR corresponding to the target R L OC address, thereby avoiding a failure in sending the message due to a change in the EID state of the multihomed XTR and no sensing of the other same-home XTRs.
It can be seen that, in the method flow described in fig. 1, by establishing a communication connection with other multi-homed XTRs in the same multi-homed XTR set and synchronizing the local EID state through the communication connection, when a location request message for a target EID is received, a target R L OC address that can reach the target EID can be determined according to the EID state of each multi-homed XTR in the same multi-homed XTR set, and a response message carrying the target R L OC address is returned to a location requesting device, so that a message sending failure due to the return of an R L OC address that cannot reach the target EID to the location requesting device is avoided.
Further, considering that when there is a forwarding table of a certain target host in a partial XTR of the peer-to-peer XTR and there is no forwarding table of the target host in the remaining XTRs, if there is a restart of the XTR of the forwarding table of the target host due to a failure or other reasons, the remaining XTRs need to request the forwarding table of the target host again to forward the traffic of the target host normally, which may result in that the XTR having the forwarding table of the target host restarts and the remaining XTRs do not yet request the forwarding table of the target host, a packet loss may occur in the packet to the target host, or when there is a primary-standby relationship with the peer-to-peer XTR, as in the case of configuring a Virtual Router Redundancy Protocol (VRRP) on the home XTR, a Virtual circuit is a Virtual circuit, wherein a certain XTR (assumed as XTR1) is the primary device, and the remaining xtrp standby devices are VRRP standby devices, when the XTR1 fails, the traffic is switched to the VRRP standby device, and then the XTR becomes a local Router switching request after the local Router is switched to the local network switch back to the Virtual circuit 3954, which may also cause the remote communication request to be switched to the remote peer-to the Virtual circuit interconnection 3946, and the Virtual circuit interconnection, which may cause the remote communication request after the Virtual circuit of the Virtual Router to be switched to the Virtual circuit of the Virtual circuit breaker.
Specifically, in the embodiment of the present invention, when the first XTR receives a map-reply (reply) or a map-notify (notify) message, the first XTR may parse the message and find whether a corresponding mapcache entry exists locally; if the map cache entry exists, the map cache entry is updated, otherwise, the first XTR can create a corresponding map cache entry locally, and further, the first XTR can synchronize the map cache entry to the co-homed XTR through the communication connection with the co-homed XTR; similarly, the first XTR may also receive mapcache entries synchronized with the home XTR over the communication connection.
Through the synchronization of the mapcache table entries, when any XTR in the XTRs belonging to the same group is restarted, the same table entry is stored in the other XTRs, so that the flow can still be forwarded normally, and the occurrence of packet loss in the flow switching process is avoided.
In the embodiment of the invention, when a first XTR receives a mapcache table item updating message sent by the XTR which belongs to the same, a local mapcache table can be firstly inquired, whether a corresponding table item exists is judged, if yes, whether the mapcache updating message is a mapcache table item deleting message is further judged, and if yes, the corresponding mapcache table item is deleted; otherwise, updating the corresponding mapcache table entry; if not, further judging whether the mapcache update message is a mapcache entry deletion message, if so, not processing the message; otherwise, creating a corresponding mapcache entry.
Further, as an optional implementation manner, in the embodiment of the present invention, when a data packet sent by the remote XTR is received and a forwarding table entry corresponding to a destination host of the data packet is not queried, the data packet may be redirected to the co-owned XTR, and the data packet is forwarded by the co-owned XTR.
Specifically, in this embodiment, when the first XTR receives a data packet sent by the remote XTR, the first XTR may first query a local forwarding entry according to the destination EID address of the data packet, determine whether a forwarding entry corresponding to the destination host exists, and if not, if the forwarding entry is lost due to restart or the like, the first XTR may redirect the data packet to the co-owned XTR, and forward the data packet by the co-owned XTR. Because the mapcache table entries are synchronized between the XTRs belonging to the same domain, after the XTRs belonging to the same domain receive the data message, the XTR belonging to the same domain does not need to re-request the forwarding table entries corresponding to the target host, and packet loss in the flow switching process is avoided.
Further, in the embodiment of the present invention, after the restart is completed, a mapcache entry request message may be sent to the co-homed XTR, so that when the co-homed XTR receives the mapcache request message, a response message carrying the locally stored mapcache entry is returned.
Specifically, in the embodiment of the present invention, after the first XTR is restarted, in order to avoid a packet loss when the traffic is switched to the first XTR due to no forwarding table entry on the first XTR (if the traffic is switched back when the first XTR becomes the master device again after the master-slave switching or the traffic is switched to the first XTR due to restart of other co-homed XTRs), the first XTR may send a mapcache table entry request message to the co-homed XTR to request the mapcache table entry locally stored in the co-homed XTR. After receiving the mapcache request message, the XTR with the home may return a response message carrying the locally stored mapcache entry to the first XTR.
It should be noted that, after the restart of the first XTR is completed, the first XTR may further send an EID state request message to the co-homed XTR, so that when the co-homed XTR receives the EID state request message, a response message carrying the local EID state is returned.
In order to enable those skilled in the art to better understand the technical solution provided by the embodiment of the present invention, the technical solution provided by the embodiment of the present invention is described below with reference to a specific application scenario.
Referring to fig. 2, fig. 2 is a schematic diagram of an architecture of a specific application scenario provided by an embodiment of the present invention, as shown in fig. 2, in the application scenario, an EID address of a HOSTA is 10.1.1.65, two XTRs exist at a L ISP site, which are XTR1 and XTR2, respectively, an R L OC address on XTR1 is 1.1.1.1, an R L OC address on XTR2 is 2.2.2.2, and XTR1 and XTR2 are in the same home.
HOSTB address is 20.1.1.1, only one XTR is located at L ISP site, R L OC address of XTR is 3.3.3.3.
Based on the above application scenario, before applying the technical solution provided by the embodiment of the present invention, L ISP multihoming is implemented as follows:
XTR1 and XTR2 register EID 10.1.1.0/24 and R L OC 1.1.1.1 and 2.2.2.2.2 addresses with MS respectively, when HOSTA communicates with HOSTB, it is assumed that HOSTA to HOSTB message passes through XTR1, so XTR1 will request 20.1.1.1 corresponding R L OC address, XTR1 will locally store 20.1.1.1/32 and R L OC address 3.3.3 mapcache entry (the mapcache entry includes mapping relationship from far-end EID (20.1.1.1/32) to far-end R L OC address (3.3.3.3) after receiving XTR3 response), and XTR2 has no entry.
When the eth1 interface of XTR1 is disconnected, XTR2 does not sense, XTR2 also registers 10.1.1.0/24, and R L OC addresses are 1.1.1.1.1 and 2.2.2.2, which causes the message from HOSTB to HOSTA, if the XTR1 is selected, the message cannot reach HOSTA after XTR1, and in addition, when XTR1 fails, because there is no 20.1.1.1/32 on XTR2, R L OC is 3.3.3.3 mapcache entry, which causes packet loss in the handover process.
The L ISP multi-homing implementation process provided by the embodiment of the present invention may include:
1. TCP connection is established between XTR1 and XTR2, and the XTR2 with large address actively initiates connection to XTR1 with address of 1.1.1.1;
2. XTR1 synchronizes the local EID status (1.1.1.1 can reach EID: 10.1.1.0/24) to XTR 2;
3. when learning that the Mapcache table entry is 20.1.1.1/32 and the R L OC address is 3.3.3.3 on XTR1, sending the table entry to XTR2 through TCP connection between XTR1 and XTR 2;
4. similarly, XTR2 performs similar processing to synchronize local EID status and learned mapcache entry to XTR 1;
5. when an eth1 interface on XTR1 is disconnected, routing of 10.1.1.0/24 is sensed to be unreachable on XTR1, a local EID is set to be 10.1.1.0/24 unreachable, XTR2 is informed, and EID with an R L OC address of 1.1.1.1 is set to be 10.1.1.0/24 unreachable;
6. XTR2 updates the EID state after receiving, when sending register message to MS, EID is 10.1.1.0/24, R L OC is 1.1.1.1 and is set as DOWN, R L OC is 2.2.2.2 and is set as UP, and triggering SMR (reverse mapping request), letting XTR3 re-request 10.1.1.0/24 mapping;
7. XTR3 re-requests 10.1.1.0/24 mapping, and subsequent messages from HOSTB to HOSTA will not select 1.1.1.1 as encapsulation;
8. if eth1 of XTR1 is not disconnected, when XTR1 learns the mapping to HOSTB, i.e. when EID is 20.1.1.1/32 and R L OC address is 3.3.3.3 mapcache, the connection between XTR1 and XTR2 is used for synchronizing the mapcache table entry to XTR 2;
9. after XTR2 receives the table entry, it saves the table entry;
10. when XTR1 is restarted, the table entry is on XTR2, when XTR2 receives the message from HOSTA to HOSTB, it can directly send the message to XTR3, and XTR3 receives the message and transfers it to HOSTB, so that the flow switching process is accelerated and the flow loss time is shortened.
As can be seen from the foregoing description, in the technical solution provided in the embodiment of the present invention, by establishing a communication connection with other multi-homed XTRs in the same multi-homed XTR set and synchronizing the local EID state through the communication connection, when a location request message for a target EID is received, a target R L OC address that can reach the target EID can be determined according to the EID state of each multi-homed XTR in the same multi-homed XTR set, and a response message carrying the target R L OC address is returned to a location requesting device, so that a message sending failure due to returning an R L OC address of an unreachable target EID to the location requesting device is avoided.
Referring to fig. 3, a schematic structural diagram of an apparatus for implementing a split-location protocol multihoming according to an embodiment of the present invention is provided, where the apparatus may be applied to the first XTR in the foregoing method embodiment, and as shown in fig. 3, the apparatus for implementing a split-location protocol multihoming may include:
a connection establishment unit 310 for establishing communication connections with other multi-homed XTRs in the same multi-homed XTR set;
a synchronization unit 320 for synchronizing the local terminal identification, EID, status including routing location, R L OC, to EID segment reachable or unreachable status with the other multi-homed XTR over the communication connection;
the message interaction unit 330 is configured to, when receiving a location request message for a target EID, determine, according to the EID state of each multihomed XTR in the same multihomed XTR set, a target R L OC address that can reach the target EID, and return a response message carrying the target R L OC address to a location requester device, where the target R L OC address is an R L OC address of a multihomed XTR in the same multihomed XTR set that can reach the target EID.
Referring to fig. 4, fig. 4 is a schematic structural diagram of another apparatus for implementing a split-protocol multihoming for a location identity, according to an embodiment of the present invention, as shown in fig. 4, based on the apparatus shown in fig. 3, the apparatus shown in fig. 4 may further include:
a registering unit 340, configured to send a registration message carrying the EID status of each multihomed XTR in the same multihomed XTR set to the mapping server MS.
Referring to fig. 5, fig. 5 is a schematic structural diagram of another apparatus for implementing a split-protocol multihoming for a location identity, according to an embodiment of the present invention, as shown in fig. 5, based on the apparatus shown in fig. 3, the apparatus shown in fig. 5 may further include:
a monitoring unit 350, configured to monitor whether a local EID state changes;
correspondingly, the synchronization unit 320 may be further configured to send an EID state update message to other multi-homed XTRs through the communication connection when the monitoring unit 350 monitors that the local EID state changes, so that the other multi-homed XTRs perform XTR state update according to the EID state update message.
In an alternative embodiment, the synchronization unit 320 may be further configured to synchronize the local map cache mapcache entry with other multi-homed XTRs through the communication connection.
In an optional embodiment, the message interaction unit 330 may be further configured to redirect the data message to another multi-homing XTR when the data message sent by the remote XTR is received and a forwarding table entry corresponding to the destination host is not queried, and forward the data message by the other multi-homing XTR.
In an optional embodiment, the synchronization unit 320 may be further configured to send, after the restart is completed, a mapcache entry request message to other multi-homing XTRs through the communication connection, so that when the other multi-homing XTRs receive the mapcache request message, a response message carrying the locally stored mapcache entry is returned through the communication connection.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the invention. One of ordinary skill in the art can understand and implement it without inventive effort.
As can be seen from the above embodiments, by establishing a communication connection with other multi-homed XTRs in the same multi-homed XTR set and synchronizing the local EID state through the communication connection, when a location request message for a target EID is received, a target R L OC address that can reach the target EID can be determined according to the EID states of the other multi-homed XTRs in the same multi-homed XTR set, and a response message carrying the target R L OC address is returned to a location requester device, thereby avoiding a message transmission failure caused by returning the R L OC address of an unreachable target EID to the location requester device.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims (12)

1. A method for implementing location identity separation protocol multi-homing, which is applied to a multi-home edge device (XTR) in a location identity separation protocol L ISP network, the method comprises the following steps:
establishing communication connection with other multi-homing XTRs in the same multi-homing XTR set, wherein each multi-homing XTR in the same multi-homing XTR set corresponds to the same EID network segment;
synchronizing local terminal identification (EID) states with other multi-homed XTRs through the communication connection, the EID states including a state where a routing location R L OC is reachable or unreachable to an EID network segment;
when a position request message aiming at a target EID is received, according to the EID state of each multi-homing XTR in the same multi-homing XTR set, a target R L OC address which can reach the target EID is determined, and a response message carrying the target R L OC address is returned to position requesting equipment, wherein the target R L OC address is the R L OC address of the multi-homing XTR which can reach the target EID in the same multi-homing XTR set.
2. The method of claim 1, further comprising:
and when sending a registration message to a mapping server MS, carrying the EID state of each multi-homing XTR in the same multi-homing XTR set in the registration message.
3. The method of claim 1, further comprising:
and when the local EID state is monitored to be changed, sending an EID state updating message to other multi-homing XTRs through the communication connection, so that the other multi-homing XTRs update the XTR state according to the EID state updating message.
4. The method of claim 1, further comprising:
and synchronizing local mapping cache mapcache entries with other multi-homed XTRs through the communication connection.
5. The method of claim 4, further comprising:
when a data message sent by a remote XTR is received and a forwarding table entry corresponding to a target host is not inquired, the data message is redirected to other multi-homing XTRs, and the data message is forwarded by the other multi-homing XTRs.
6. The method of claim 4, further comprising:
after restarting, through communication connection sends mapcache table item request message to other multi-homing XTRs to make other multi-homing XTRs receive when mapcache table item request message, through communication connection returns the response message of the mapcache table item that carries local storage.
7. An apparatus for implementing separation of location identity protocol multihoming, wherein the apparatus is applied to a multihomed edge (XTR) in an L ISP network, and the apparatus comprises:
the connection establishing unit is used for establishing communication connection with other multi-homing XTRs in the same multi-homing XTR set, and each multi-homing XTR in the same multi-homing XTR set corresponds to the same EID network segment;
a synchronization unit for synchronizing an EID status with the other multi-homed XTR over the communication connection, the EID status including a status of routing location R L OC to EID network segment reachable or unreachable;
and a message interaction unit, configured to, when receiving a location request message for a target EID, determine, according to the EID state of each multihomed XTR in the same multihomed XTR set, a target R L OC address that can reach the target EID, and return a response message carrying the target R L OC address to a location requester device, where the target R L OC address is an R L OC address of a multihomed XTR that can reach the target EID in the same multihomed XTR set.
8. The apparatus of claim 7, further comprising:
and the registration unit is used for sending a registration message carrying the EID state of each multi-homing XTR in the same multi-homing XTR set to the mapping server MS.
9. The apparatus of claim 7, further comprising:
the monitoring unit is used for monitoring whether the local EID state changes;
and the synchronization unit is further configured to send an EID state update message to other multihoming devices through the communication connection when the monitoring unit monitors that the local EID state changes, so that the other multihoming devices perform XTR state update according to the EID state update message.
10. The apparatus of claim 7,
and the synchronization unit is also used for synchronizing the local mapping cache mapcache table entries with other multi-homing XTRs through the communication connection.
11. The apparatus of claim 10,
and the message interaction unit is further configured to redirect the data message to other multi-homing XTRs when the data message sent by the remote XTR is received and a forwarding table entry corresponding to the destination host is not queried, and forward the data message by the other multi-homing XTRs.
12. The apparatus of claim 10,
and the synchronization unit is also used for sending a mapcache table item request message to other multi-homing XTRs through the communication connection after the restart is completed so that the other multi-homing XTRs receive the mapcache table item request message, and returning a response message carrying the locally stored mapcache table item through the communication connection.
CN201610211670.7A 2016-04-06 2016-04-06 Method and device for realizing position identification separation protocol multi-homing Active CN105915455B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610211670.7A CN105915455B (en) 2016-04-06 2016-04-06 Method and device for realizing position identification separation protocol multi-homing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610211670.7A CN105915455B (en) 2016-04-06 2016-04-06 Method and device for realizing position identification separation protocol multi-homing

Publications (2)

Publication Number Publication Date
CN105915455A CN105915455A (en) 2016-08-31
CN105915455B true CN105915455B (en) 2020-08-04

Family

ID=56744679

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610211670.7A Active CN105915455B (en) 2016-04-06 2016-04-06 Method and device for realizing position identification separation protocol multi-homing

Country Status (1)

Country Link
CN (1) CN105915455B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107659504B (en) * 2017-09-14 2019-11-12 中国人民解放军国防科技大学 First packet buffering method for guaranteeing integrity of LISP communication data

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103957161A (en) * 2014-04-04 2014-07-30 杭州华三通信技术有限公司 Packet forwarding method and device
CN103973574A (en) * 2014-05-19 2014-08-06 杭州华三通信技术有限公司 Data message forwarding method and device in position and identity separation protocol network
CN104022956A (en) * 2014-06-11 2014-09-03 杭州华三通信技术有限公司 Method and device for data message processing in location/ID separation protocol network

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102238058B (en) * 2010-04-20 2015-05-13 中兴通讯股份有限公司 Data message processing method, ingress tunnel router and system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103957161A (en) * 2014-04-04 2014-07-30 杭州华三通信技术有限公司 Packet forwarding method and device
CN103973574A (en) * 2014-05-19 2014-08-06 杭州华三通信技术有限公司 Data message forwarding method and device in position and identity separation protocol network
CN104022956A (en) * 2014-06-11 2014-09-03 杭州华三通信技术有限公司 Method and device for data message processing in location/ID separation protocol network

Also Published As

Publication number Publication date
CN105915455A (en) 2016-08-31

Similar Documents

Publication Publication Date Title
US10397045B2 (en) Method for migrating service of data center, apparatus, and system
KR101678711B1 (en) Load balancing across layer-2 domains
TWI736657B (en) Method and device for switching virtual internet protocol address
US7885180B2 (en) Address resolution request mirroring
EP3373547B1 (en) Method for realizing disaster tolerance backup
US10673736B2 (en) Traffic reduction in data center fabrics
EP2939399B1 (en) Methods and system for seamless network communications between ipv4 and ipv6 devices
US9634934B2 (en) Dynamic host configuration protocol relay in a multipod fabric
EP3306861B1 (en) Cluster communication
JP2011053918A (en) Network system, network relay apparatus, and control method therefor
CN111130981A (en) Proxy response method and device for MAC address
WO2014154087A1 (en) A gateway and its method of transfering data
CN108337158B (en) Unicast message forwarding method and device
CN109698767A (en) A kind of main/standby switching method and device
CN105340226A (en) Primary and secondary system handover method for dynamic route device, and apparatus thereof
US10530873B1 (en) Techniques for optimizing EVPN-IRB for IPv6-enabled data centers with top-of-rack deployments
CN113839862B (en) Method, system, terminal and storage medium for synchronizing ARP information between MCLAG neighbors
CN113132159B (en) Storage cluster node fault processing method, equipment and storage system
CN105915455B (en) Method and device for realizing position identification separation protocol multi-homing
CN111555970A (en) Network switching method, system and storage medium based on dual-computer redundancy system
US8023407B2 (en) Redundancy in a communication network
CN110417599B (en) Main/standby node switching method and node server
CN115225634B (en) Data forwarding method, device and computer program product under virtual network
JP6445421B2 (en) Communication apparatus and communication method
US20240039829A1 (en) Route refresh method, apparatus, and system

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant after: Xinhua three Technology Co., Ltd.

Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant before: Huasan Communication Technology Co., Ltd.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant