Facilitates fast reroute in high-availability networks

Abstract

Embodiments of the present disclosure relate to facilitating fast rerouting in a high-availability network. A system for efficiently determining a set of next-hop switches from a switch is provided. During operation, the system can determine multiple next-hop switches for an Internet Protocol (IP) address prefix. The system can then store a list of identification information in an entry of a forwarding data structure of the switch, the list of identification information indicating multiple next-hop switches corresponding to the IP address prefix. The identification information of the multiple next-hop switches can be stored in a list in a preference order for forwarding services matching the IP address prefix. Upon receiving a packet having a destination IP address matching the IP address prefix, the system can select an entry from the forwarding data structure to determine a next-hop switch for forwarding the packet. The system can then determine the next-hop switch for the packet from the entry based on the preference order.

Description

Technical Field

[0001] The present disclosure relates to communication networks and, more particularly, to a method and system for facilitating efficient selection of a next-hop switch from a forwarding data structure while facilitating high availability between routes. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An example of a network that facilitates a set of next-hop switches associated with corresponding backup routes for a network prefix according to one aspect of the present disclosure is shown.

[0003] Figure 2 An example of a forwarding data structure supporting a set of next-hop switches associated with corresponding backup routes for a network prefix is ​​shown according to one aspect of the present application.

[0004] Figure 3 An example of selecting a next-hop switch from a forwarding data structure during a period when a primary route is unavailable according to one aspect of the present application is shown.

[0005] Figure 4A A flow chart according to one aspect of the present application is provided, which illustrates a process in which a switch merges a set of next-hop switches associated with corresponding backup routes into a forwarding data structure for a network prefix.

[0006] Figure 4B The flowchart shows a process of a switch determining a next-hop switch for forwarding a packet from a set of next-hop switches according to one aspect of the present application.

[0007] Figure 5A The flowchart shows a process of a switch selecting a next-hop switch from a forwarding data structure during a period when a primary route is unavailable according to one aspect of the present application.

[0008] Figure 5B A flow chart illustrating a process in which a switch merges routing updates associated with a network prefix into a corresponding set of next-hop switches in a forwarding data structure according to one aspect of the present application.

[0009] Figure 6 An example of a switch that supports efficient determination of a set of next-hop switches associated with corresponding backup routes for a network prefix according to one aspect of the present disclosure is shown.

[0010] In the drawings, like reference numerals denote like drawing elements. DETAILED DESCRIPTION

[0011] The following description is presented to enable any person skilled in the art to make and use the present invention, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein can be applied to other examples and applications without departing from the spirit and scope of the present invention. Therefore, the present invention is not limited to the aspects shown, but is to be accorded the widest scope consistent with the claims.

[0012] The Internet is a delivery medium for a wide variety of applications running on both physical and virtual devices. These applications drive a growing amount of network traffic. Consequently, device providers are racing to build switches with multiple capabilities, such as an enhanced routing process that can determine loop-free backup routes (e.g., multiple routes) for a network prefix. The routing process can then determine multiple next-hop switches for the corresponding route prefix. This routing can facilitate local protection of unicast traffic in Layer 3 networks (e.g., Internet Protocol (IP) networks) by using backup routes after topology changes caused by failures.

[0013] A routing process (e.g., a Border Gateway Protocol (BGP) instance) may receive routing or link updates from a neighboring network. Such updates may correspond to a network prefix, such as an IP prefix. Based on the updates, the routing process may determine a valid route (or path) to the corresponding prefix. Thus, the switch may populate a routing data structure (RD) (e.g., a routing information base (RIB)) with the routes determined by the routing process. The routes associated with a prefix may indicate what the next-hop switch for the prefix should be. Based on the information in the RDS, the switch may store an identifier of the next-hop switch associated with the prefix in a forwarding data structure (FD) (e.g., a forwarding information base (FIB)). Since the FDS is populated based on the routing process, determining the next-hop switch from multiple alternative routes for the corresponding network prefix may require a large amount of computation.

[0014] Various aspects described herein address the problem of efficiently providing a set of next-hop switches for a network prefix in an FDS by: (i) determining an alternate route from a switch based on topology information; (ii) determining a set of next-hop switches for the prefix based on the alternate route; and (iii) storing corresponding identifiers of the set of next-hop switches associated with the prefix in the FDS of the switch. Topology information can indicate how the switch is coupled to different provider networks. Instead of a routing process in which the switch computes routes for a large number of prefixes, the switch can track the next-hop switches (e.g., gateway switches) of different provider networks and use them for the prefix.

[0015] Typically, an edge switch may be coupled to multiple provider networks (e.g., Internet service provider (ISP) networks). Each of the provider networks may support a large number of network prefixes (e.g., IP prefixes). Using existing technologies, if a switch participates in the routing process (e.g., BGP instance) of each of the provider networks, the routing process on the switch may need to calculate a large number of routes for the IP prefixes. For example, one provider network may provide a valid route (or path) for one prefix, while another provider network may provide a valid route for another prefix. Therefore, if the switch determines an alternate route, the switch may need to determine an alternate route through all provider networks for the corresponding prefix. As a result, the routing process at the switch may become inefficient.

[0016] In addition, alternative next-hop switches for the prefix can be stored in the switch's RDS. The next-hop switch in the next-hop switches can be a "selected next-hop switch," which can be the preferred next hop for the prefix. The routing process can determine the selected next-hop switch using a metric that indicates the lowest-cost path. The metric can be based on one or more of the following: number of hops, latency, link capacity, remaining capacity, security, and preference. Typically, the routing process can determine the next-hop switch indicated in the selected route and store the identifier of the determined next-hop switch for the prefix in the FDS. Thus, even if multiple routes are calculated by the routing process, the FDS can maintain the identifier of the next-hop switch for the selected route.

[0017] To address this issue, the switch's FDS can maintain an adjacency list generated from topology information associated with the switch based on next-hop tracking (NHT). Therefore, the set of next-hop switches in the adjacency list can be referred to as an NHTS. The adjacency list can be an ordered list of next-hop switches based on corresponding forwarding preferences. If the switch is an edge switch, the switch can be coupled to multiple provider networks. Preferences can then be based on provider networks, with one provider network being preferred over the others. Preferences can also be based on corresponding path costs.

[0018] Since the switch can be an edge switch, the corresponding next-hop switch from the switch can belong to the provider network. Because the switch can be an edge switch of a different autonomous system (AS), the provider network will not establish a route to another provider network through the switch. In other words, the provider network may not select the switch as a transit router for the prefix. Therefore, the next-hop switch can provide a loop-free backup route from the switch. The switch can then determine that the next-hop switch provides the backup route based on the network topology information because the next-hop switch belongs to a different provider network. Therefore, the switch can deploy an NHT system that can track the corresponding next-hop switches belonging to different provider networks. The NHT system can obtain topology information associated with the switch and identify the next-hop switches of different provider networks.

[0019] The NHT system can obtain topology information based on one or more of the following: topology discovery protocols, tracking route advertisements from different provider networks based on their different identifiers (e.g., AS numbers), notifications from management or provisioning platforms, and manual entries. By tracking the next-hop switches, the NHT system can discover corresponding loop-free backup routes through the next-hop switches. The NHT system can then generate entries for the prefixes in the FDS using an adjacency list that includes the identifiers of the next-hop switches in order of forwarding preference. Once the NHT system can track the next-hop switches for a prefix, the NHT system can generate an adjacency list instead of the routing process to determine loop-free backup routes for the prefix. In this way, the NHT system can effectively facilitate the set of next-hop switches for the corresponding prefix.

[0020] Alternatively, the switch may also obtain the next-hop route based on the switch's routing process. The routing process may determine a loop-free backup for fast rerouting (e.g., based on Request for Comments (RFC) 5286). For example, the routing process may receive a route advertisement for a prefix reachable via the provider network from a provider network. Based on the route advertisement, the routing process may determine a loop-free backup route for the corresponding prefix. Each of the backup routes for the prefix may indicate a corresponding next-hop switch. The routing process may store the next-hop switch in the RDS in association with the prefix. Based on the entry in the RDS, the switch may store the information and propagate it to the FDS. The NHT system may use the information from the RDS to generate an entry for the prefix in the FDS with an adjacency list. Since the routing process may determine multiple loop-free paths, the NHT system may generate an adjacency list with lower computational overhead.

[0021] After receiving a packet, the switch can look up the destination address (e.g., IP address) of the packet in the FDS. If the destination address matches a prefix based on the longest prefix match, the switch can determine the corresponding adjacency list. Based on the order of the next-hop switches (e.g., the initial switch) in the adjacency list, the switch can select a next-hop switch for forwarding. If the primary route becomes unavailable, the NHT system can determine the unavailability based on the routing process and the RDS. The switch can then select a subsequent next-hop switch from the adjacency list and can remove the next-hop switch associated with the unavailability from the adjacency list. In this way, the adjacency list in the FDS can facilitate fast convergence against unavailability with low computational overhead.

[0022] In this disclosure, the term "switch" is used in a general sense, and it can refer to any stand-alone or fabric switch operating in any network layer. "Switch" should not be interpreted as limiting the examples of the present invention to layer 2 networks. Any device that can forward traffic to an external device or another switch can be called a "switch." Any physical or virtual device that can forward traffic to a terminal device (for example, a virtual machine or switch running on a computing device) can be called a "switch." Examples of "switches" include, but are not limited to, layer 2 switches, layer 3 routers, routing switches, components of a Gen-Z network, or a fabric switch that includes multiple smaller physical and / or virtual switches of similar or different kinds.

[0023] The term "packet" refers to a group of bits that can be transmitted across a network. "Packet" should not be interpreted as limiting the examples of the present invention to a specific layer of the network protocol stack. Other terms referring to groups of bits can be used instead of "packet", such as "message", "frame", "cell", "datagram", or "transaction". In addition, the term "port" can refer to a port that can receive or send data. "Port" can also refer to the hardware, software, and / or firmware logic that can facilitate the operation of the port.

[0024] Figure 1An example of a network that facilitates a set of next-hop switches associated with corresponding backup routes for network prefixes is shown in accordance with one aspect of the present application. Network 100 may include multiple switches and devices and may include different kinds of network components, such as layer 2 and layer 3 hops and tunnels. In some examples, network 100 may be an Ethernet, InfiniBand, or other network and may use corresponding communication protocols, such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. In network 100, edge switches 112 and 114 may be coupled to a set of provider networks 120 (e.g., an ISP network). Provider network 120 may include switches 101, 102, 103, 104, 105, and 106. The corresponding switches of network 100 may deploy instances of a relational database and may be associated with media access control (MAC) addresses and IP addresses.

[0025] The corresponding links in network 100 can be physical links or tunnels spanning one or more physical links. Examples of tunnels can include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Network Virtualization Encapsulation (Geneve), Internet Protocol Security (IPsec), and Multiprotocol Label Switching (MPLS). For example, switches 112 and 114 can be customer edge (CE) switches of an MPLS network, while the switches in provider network 120 can be provider edge (PE) switches. The corresponding switch pairs in network 100 can be BGP peers and advertise routing information based on their corresponding BGP. Here, provider network 120 can include provider network 122 and another provider network 124, provider network 122 can include switches 101, 103, and 105, and another provider network 124 can include switches 102, 104, and 106. The corresponding provider networks can be within corresponding administrative domains (e.g., hierarchical ASs).

[0026] Each provider network in provider networks 120 may support a large number of network prefixes (e.g., IP prefixes). Using existing techniques, if switch 112 participates in the routing process for each provider network in provider networks 120, routing process 130 on switch 112 may need to calculate a large number of routes for the IP prefixes. For example, provider network 122 may provide a valid route (or path) for one prefix, while provider network 124 may provide a valid route for another prefix. Therefore, if switch 112 determines an alternate route for a prefix, switch 112 may need to determine an alternate route for the corresponding prefix through networks 122 and 124. Therefore, due to the large computational overhead on switch 112, routing process 130 may become inefficient.

[0027] Additionally, alternate routes for the prefix may be stored in an RDS 132 of the switch 112. The RDS 132 may indicate a routing table or RIB of the switch 112. One of the alternate routes may be a "selected route" in the RDS 132. The selected route may be the preferred route for the prefix. The routing process 130 may determine the selected route using a metric indicating a lowest-cost path. The metric may be based on one or more of the following: number of hops from the switch 112, latency on a link, link capacity, remaining capacity, security, and preferences configured in the switch 112. Typically, the routing process 130 may determine a next-hop switch indicated in the selected route and store an identifier of the determined next-hop switch for the prefix in an FDS 134 of the switch 112. The FDS 134 may indicate a forwarding table or FIB of the switch 112. Thus, even if the routing process 130 computes multiple routes, the FDS 134 may maintain an identifier of the next-hop switch for the selected route.

[0028] To address this issue, switch 112 may deploy an NHT system 150 that may maintain an adjacency list for the corresponding prefixes determined by routing process 130. The adjacency list may include corresponding identifiers of a set of next-hop routes, such as switches 101 and 102, in the order of the forwarding preference of switch 112. The corresponding entry of the FDS may then include the prefix and the corresponding adjacency list. Since switch 112 may be an edge switch, the forwarding preference may indicate whether the packet is forwarded via prover network 122 or 124. The preference may also be based on the corresponding link or path cost. For example, NHT system 150 may obtain the corresponding path cost associated with the corresponding route through switches 101 and 102 and determine the order of the adjacency list accordingly.

[0029] Because switch 112 may be an edge switch in a different AS, provider network 122 or 124 does not establish a route to the other provider network through switch 112. In other words, provider network 122 or 124 may not select switch 124 as a transit router for the prefix. Therefore, next-hop switches 101 and 102 can provide a loop-free backup route from switch 112. NHT system 150 can then determine, based on the topology information of network 100, that next-hop switches 101 and 102 provide the backup route because switches 101 and 102 belong to different provider networks 122 and 124, respectively. Therefore, NHT system 150 can track next-hop switches 101 and 102. NHT system 150 can obtain topology information associated with switch 112 and identify next-hop switches 101 and 102.

[0030] NHT system 150 can obtain topology information based on one or more of the following: topology discovery protocols, tracking route advertisements from provider networks 122 and 124, notifications from management or provisioning platforms, and manual entries. By tracking next-hop switches 101 and 102, NHT system 150 can discover corresponding loop-free backup routes through next-hop switches 101 and 102. NHT system 150 can then generate an entry for the prefix in FDS 134 using an adjacency list that includes the identifiers of switches 101 and 102 in order of forwarding preference. Once NHT system 150 can track the next-hop switches for a prefix, it can generate the adjacency list instead of relying on routing process 130 to determine loop-free backup routes for the prefix. In this way, NHT system 150 can efficiently facilitate the selection of next-hop switches for the corresponding prefix.

[0031] Switch 112 can also obtain next-hop routes through provider networks 122 and 124 based on routing process 130. Routing process 130 can determine loop-free alternatives for fast rerouting (e.g., based on RFC 5286) and store them in RDS 132. NHT system 150 can then obtain next-hop information for the corresponding prefix from RDS 132 and generate a corresponding adjacency list for FDS 134, rather than just the next-hop switch. Because routing process 130 can determine alternative paths for the corresponding prefix, NHT system 150 can generate adjacency lists for the prefixes with less additional computational overhead. Switch 112 can forward packets matching the prefixes to the next-hop switch based on the order of the adjacency list. If the route through the next-hop switch becomes unavailable, switch 112 can easily select a subsequent next-hop switch from the adjacency list, thereby promoting rapid convergence with less computational overhead.

[0032] The total number of adjacency lists can correspond to the factorial of the number of next-hop switches. Figure 1 In the example of FIG1 , there are two provider networks 122 and 124. Therefore, the number of possible adjacency lists can be a factorial of 2 (e.g., 2!). Here, such adjacency lists can be {switch 101, switch 102} and {switch 102, switch 101}. Because the number of adjacency lists can be significantly smaller than the number of routes advertised by provider networks 122 and 124, determining the next-hop switch based on next-hop tracking can be an efficient way to populate FDS 134.

[0033] Figure 2An example of a forwarding data structure according to one aspect of the present application is shown that supports a set of next-hop switches associated with corresponding backup routes for a network prefix. Switch 112 can maintain a route entry in RDS 132 and a corresponding forwarding entry in FDS 134. The corresponding entry in RDS 132 can include a priority 202, a network 204 (represented by the network prefix), and a next-hop switch 206 for network 204. Here, priority 202 can indicate whether the entry corresponds to a "selected route." The selected route can be a primary route for network 204. The entry can also include a metric 208 associated with a path to determine the next-hop switch 206, such as a path cost. The selected route can be selected based on metric 208. On the other hand, the corresponding entry in FDS 134 can include a network 212 corresponding to network 204 of RDS 132 and an adjacency list 214 for network 212.

[0034] During operation, the NHT system 150 can obtain (e.g., using a link discovery protocol) the network addresses 222 and 224 of switches 101 and 102, respectively. The corresponding network addresses can include one or more of the following: a MAC address and an IP address. The NHT system 150 can then track routing information exchanges associated with addresses 222 and 224. Based on the routing information, the NHT system 150 can determine that prefix 230 can be reached via addresses 222 and 224. Therefore, the NHT system 150 can determine that switches 101 and 102 are the next-hop switches for prefix 230. The NHT system 150 can then generate an entry for prefix 230 in the FDS 134, with an adjacency list that includes addresses 222 and 224 in order of forwarding preference. For example, if provider network 122 is the preferred network for switch 112, address 222 can appear first in the adjacency list.

[0035] NHT system 150 may also populate adjacency list 214 using entries from RDS 132. When network 100 converges, routing process 130 may receive route advertisements for prefix 230 from provider networks 122 and 124, which are reachable via provider networks 122 and 124. Based on the route advertisements, routing process 130 may determine loop-free backup routes 232 and 234 for prefix 230 via provider networks 122 and 124, respectively. Routing process 130 may then generate corresponding entries for prefix 230 corresponding to routes 232 and 234. The entry corresponding to route 232 may include prefix 230, address 222, and route cost 232 as network 204, next-hop switch 206, and metric 208, respectively. On the other hand, the entry corresponding to route 234 may include prefix 230, address 224, and route cost 234 as network 204, next-hop switch 206, and metric 208, respectively.

[0036] Based on forwarding priorities such as metric 208, routing process 130 can determine which route is the preferred route. Assume that route 232 via provider network 122 is the preferred route. Therefore, priority 202 can indicate that the entry corresponding to route 232 is the "selected route." Therefore, the destination address of the packet matching prefix 230 (e.g., based on the longest prefix match) can be forwarded to address 222 (i.e., switch 101). A typical FIB entry can include address 222 as the next-hop switch based on prefix 230 of the selected route. Unlike FIB entries, entries of the FDS can include adjacency list 214 instead of the next-hop switch.

[0037] NHT system 150 can populate adjacency list 214 by including the next-hop switches in all entries for prefix 230 from RDS 132. Adjacency list 214 for prefix 230 can then include addresses 222 and 224. The ordering of adjacency list 214 can be based on the corresponding values ​​of metric 208. Because routing process 130 can determine multiple loop-free paths in routes 232 and 234, NHT system 150 can generate adjacency list 214 with low computational overhead. In this way, FDS 134 can facilitate packet forwarding via the selected route while facilitating efficient rerouting for prefix 230.

[0038] Figure 3 FIG2 illustrates an example of selecting a next-hop switch from a forwarding data structure during a period when a primary route is unavailable, according to one aspect of the present disclosure. Upon receiving packet 302, switch 112 may look up the destination address (e.g., IP address) of packet 302 in FDS 134. If the destination address matches prefix 230 based on a longest prefix match, switch 112 may determine an adjacency list with addresses 222 and 224. Based on the order of the adjacency list, switch 112 may select address 222 for forwarding packet 302. Switch 101 may then be selected as the next-hop switch for packet 302.

[0039] Assume that event 310 causes primary route 232 via provider network 122 to become unavailable. Event 310 may include one or more of the following: a link failure, a node failure, a power cycle of a switch, and a software upgrade of the switch. Routing process 130 may discover the unavailability of route 232 (e.g., using Bidirectional Forwarding Detection (BFD)). Routing process 130 may then update the corresponding entry in RDS 132. NHT system 150 may then select a subsequent next-hop switch from the adjacency list. In this example, the subsequent next-hop switch for switch 102 of provider network 124 is represented by address 224 in the adjacency list (indicated by a dashed line). NHT system 150 may remove address 222 associated with the unavailability from the adjacency list.

[0040] When packet 304 arrives at switch 112 after event 300, switch 112 can look up the destination address of packet 304 in FDS 134. If the destination address matches prefix 230 based on longest prefix match, switch 112 can determine the adjacency list with address 224. Since the adjacency list now only includes one address, switch 112 can select address 224 to forward packet 304. Switch 102 can then be selected as the next-hop switch for packet 304. Because subsequent next-hop switches can be easily selected from the adjacency list, switch 112 can use FDS 134 to forward packet 304 even if packet 304 arrives shortly after event 300. In this way, the adjacency list in FDS 134 can facilitate rapid convergence to unavailability with low computational overhead.

[0041] Figure 4A A flow chart illustrating a process by which a switch merges a set of next-hop switches associated with corresponding backup routes into a forwarding data structure for a network prefix according to one aspect of the present application is provided. During operation, the switch may determine route(s) for the network prefix (operation 402). The switch may then determine whether multiple loop-free routes have been determined (operation 404). This determination may be based on tracking next-hop switches for different provider networks or from a routing process of the switch. If multiple loop-free routes have been determined, the switch may determine a next-hop switch from the corresponding routes (operation 406).

[0042] The switch may also determine the order of next-hop switches based on the forwarding preference (operation 408). The switch may then generate an adjacency list for the next-hop switches in the determined order (operation 408). The adjacency list may include the corresponding addresses (e.g., IP addresses) of the next-hop switches in the determined order. On the other hand, if multiple loop-free routes are not determined, the switch may determine the next-hop switch from the route (operation 412) and generate an adjacency list for the next-hop switch (operation 414). Here, the adjacency list may include a single identifier. After determining the adjacency list (operation 408 or 414), the switch may program the FDS with the adjacency list for the network prefix (operation 410).

[0043] Figure 4B A flow chart illustrating a process by which a switch determines a next-hop switch for forwarding a packet from a set of next-hop switches, according to one aspect of the present disclosure. Upon receiving a packet, the switch may look up the packet's destination address in the FDS (operation 452) and determine whether a match is found (e.g., based on a longest prefix match) (operation 454). If a match is found, the switch may obtain an adjacency list from the FDS based on the match (operation 456) and determine whether multiple next-hop switches exist in the adjacency list (operation 458). If multiple next-hop switches exist, the switch may determine the next-hop switch from the adjacency list based on the order (operation 460).

[0044] On the other hand, if there are not multiple next-hop switches, the switch can determine the next-hop switch from the adjacency list (operation 466). After determining the next-hop switch (operation 460 or 466), the switch can identify the egress port associated with the next-hop switch (e.g., the egress port from the MAC address mapped to the next-hop switch) and forward the packet via the egress port (operation 462). However, if no match is found, the switch can indicate an error to a user (e.g., an administrator) (operation 464).

[0045] Figure 5A A flow chart illustrating a process for a switch to select a next-hop switch from a forwarding data structure during unavailability of a primary route according to one aspect of the present disclosure is shown. During operation, the switch may determine the unavailability associated with the selected route (i.e., the primary route) (operation 502) and identify the entry affected by the unavailability in the FDS (operation 504). The switch may then remove the identifier of the initial (or first) next-hop switch from the adjacency list in the entry (operation 506) and determine whether the adjacency list is empty (operation 508).

[0046] If the adjacency list is empty, the switch may wait for the NHT system to repopulate the adjacency list (operation 510). On the other hand, if the adjacency list is not empty, the switch may continue packet forwarding based on the adjacency list (operation 512). The switch may then determine whether all relevant entries in the FDS have been updated (operation 514). If not all relevant entries have been updated, the switch may continue to identify the next entry affected by the unavailability in the FDS (operation 504).

[0047] Figure 5B A flow chart illustrating a process by which a switch merges routing updates associated with a network prefix into a corresponding set of next-hop switches in a forwarding data structure according to one aspect of the present application. During operation, the switch may determine a routing update associated with the prefix (operation 552) and determine whether an adjacency list for the prefix exists (operation 554). If the prefix exists, the switch may propagate the routing update to the adjacency list for the prefix (operation 556). On the other hand, if the prefix does not exist, the switch may program the FDS with the adjacency list for the prefix, as in conjunction with Figure 4A as described (operation 556).

[0048] Figure 6 An example of a switch that supports efficient determination of a set of next-hop switches associated with corresponding backup routes for a network prefix according to one aspect of the present disclosure is shown. In this example, a switch 600 may include multiple communication ports 602, a packet processor 610, and a storage device 650. The switch 600 may also include switch hardware 660 (e.g., processing hardware of the switch 600, such as an application-specific integrated circuit (ASIC) chip) that includes information based on which switch 600 processes a packet (e.g., determines an output port for the packet). In other words, the switch hardware 660 includes switch circuitry for the switch 600. The packet processor 610 may extract and process header information from a received packet. The packet processor 610 may identify a switch identifier (e.g., a MAC address and / or an IP address) associated with the switch 600 in a header of the packet.

[0049] The communication port 602 may include an inter-switch communication channel for communicating with other switches and / or user devices. The communication channel may be implemented via a conventional communication port and based on any open or proprietary format. The communication port 602 may include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header. The communication port 602 may also include one or more IP ports capable of receiving IP packets. The IP port is capable of receiving IP packets and may be configured with an IP address. The packet processor 610 may process Ethernet frames and / or IP packets. The corresponding port of the communication port 602 may operate as an inbound port and / or an outbound port.

[0050] The switch 600 may maintain a database 652 (e.g., in a storage device 650). The database 652 may be a relational database and may run on one or more database management system (DBMS) instances. The database 652 may store information associated with the routing, configuration, and interfaces of the switch 600. Such information may include the RDS and FDS of the switch 600. The switch 600 may include a next hop logic block 630 that may facilitate next hop tracking of the switch 600. The next hop logic block 630 may correspond to Figure 1 The NHT system 150 of FIG. 6A may include a tracking logic block 632 , a programming logic block 634 , a next hop selection logic block 636 , and a switching logic block 638 .

[0051] Tracking logic 632 can facilitate tracking next-hop switches for different provider networks. Tracking can be based on topology information associated with switch 600 or the routing process of switch 600. Programming logic 634 can generate an adjacency list for corresponding prefixes reachable via the provider network based on the tracking. Programming logic 634 can then program the adjacency list in the FDS of switch 600. Next-hop selection logic 636, in conjunction with switch hardware 660, can identify the adjacency list applicable to the packet and select a next-hop switch from the adjacency list to forward the packet. If a route becomes unavailable, switching logic 638 can remove the next-hop switch affected by the unavailability from the corresponding adjacency list.

[0052] One aspect of the present technology can provide a system for efficiently determining a set of next-hop switches from a switch. During operation, the system can determine multiple next-hop switches for an Internet Protocol (IP) address prefix. The system can then store a list of identification information in an entry of a forwarding data structure of the switch, the list of identification information indicating the multiple next-hop switches corresponding to the IP address prefix. The identification information of the multiple next-hop switches can be stored in a list in a preference order for forwarding services matching the IP address prefix. Upon receiving a packet with a destination IP address matching the IP address prefix, the system can select an entry from the forwarding data structure to determine a next-hop switch for forwarding the packet. The system can then determine the next-hop switch for the packet from the entry based on the preference order.

[0053] In a variation of this aspect, the system can determine the multiple next-hop switches by determining multiple loop-free routes of the IP address prefix from the switch and determining multiple next-hop switches from the multiple loop-free routes.The multiple loop-free routes can be determined using a routing protocol instance of the switch.

[0054] In another variation, the system may store information associated with the plurality of loop-free routes in corresponding entries in a routing data structure of a switch associated with an IP prefix. The system may then generate the list by identifying a plurality of next-hop switches from the plurality of loop-free routes in the routing data structure.

[0055] In a variation of this aspect, the plurality of next-hop switches belong to at least two service provider networks.

[0056] In another variation, the system may determine the plurality of next-hop switches by obtaining topology information associated with the switch; identifying switches in a service provider network coupled to the switch from the topology information; and tracing the identified switches as the plurality of next-hop switches.

[0057] In a variation of this aspect, the system may determine an order of preference based on forwarding preferences associated with IP address prefixes.Then, the system may sort the identification information in the list based on the order of preference.

[0058] In another variation, the order of preference is based on one or more of: respective path costs associated with a plurality of next-hop switches, a preferred provider network, and a preselection based on a user configuration.

[0059] In a variation of this aspect, the system may determine the next hop switch by determining that an initial next hop switch in the list is unavailable and selecting a subsequent next hop switch in the list as the next hop switch for the packet.

[0060] In another variation, the system may remove the initial next-hop switch from the list.

[0061] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium that can store code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disks, tapes, CDs (compact disks), DVDs (digital versatile disks or digital video disks), or other media capable of storing computer-readable media now known or later developed.

[0062] The methods and processes described in the detailed description can be implemented as code and / or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes implemented as data structures and code and stored in the computer-readable storage medium.

[0063] The methods and processes described herein can be performed by and / or included in hardware modules or devices. These modules or devices may include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software modules or code segments at specific times, and / or other programmable logic devices now known or later developed. When the hardware modules or devices are activated, they execute the methods and processes included therein.

[0064] The foregoing description of the examples of the present invention is for illustration and description purposes only. They are not intended to be exhaustive or to limit the present disclosure. Therefore, many modifications and variations will be apparent to those skilled in the art. The scope of the present invention is defined by the appended claims.

Claims

1. A method comprising: Implement routing protocols on network devices in the network; Determining, by the network device based on the routing protocol, routing information indicating a plurality of next-hop devices for an Internet Protocol (IP) address prefix; storing the routing information associated with the IP address prefix in a routing data structure; generating an adjacency list based on the routing information in the routing data structure, the adjacency list including identification information of the plurality of next-hop devices in order of preference; generating an entry comprising the adjacency list and the IP address prefix in a forwarding data structure separate from the routing data structure; receiving a packet having a header including a destination IP address; looking up the destination IP address of the packet in the forwarding data structure using longest prefix matching; In response to determining a match between the destination IP address and the IP address prefix based on the lookup, selecting the entry from the forwarding data structure for determining a next hop device for forwarding the packet; as well as The next hop device for the packet is determined from the adjacency list in the entries based on the preference order.

2. The method according to claim 1, wherein determining the plurality of next-hop devices further comprises: determining, by the routing protocol, routing information including a plurality of loop-free routes for the IP address prefix from the network device; as well as The multiple next-hop devices are determined from the routing information.

3. The method according to claim 2, further comprising: storing the routing information in association with the IP address prefix in a corresponding entry in the routing data structure; and Generating the adjacency list includes: merging identification information of the multiple next-hop devices from the routing information into the routing data structure. The method of claim 1 , wherein a corresponding subset of the plurality of next-hop devices belongs to at least two service provider networks.

5. The method of claim 4, wherein determining the plurality of next-hop devices for the IP address prefix further comprises: obtaining topology information associated with the network device; identifying, from the topology information, corresponding network devices coupled to the network device in the at least two service provider networks; as well as The identified network devices in the at least two service provider networks are tracked as the plurality of next-hop devices.

6. The method according to claim 1, further comprising: determining the preference order based on forwarding preferences associated with the IP address prefixes; as well as The identification information in the adjacency list is sorted based on the preference order.

7. The method of claim 6, wherein the forwarding preference is based on one or more of the following: respective path costs associated with the plurality of next-hop devices; Preferred provider network; and Based on user-configured preselection.

8. The method of claim 1 , wherein determining the next hop device for the packet further comprises: After an initial next hop device in the adjacency list is unavailable, a subsequent next hop device in the adjacency list is selected as the next hop device for the packet.

9. The method according to claim 8, further comprising: In response to the initial next-hop device being unavailable, removing the initial next-hop device from the adjacency list.

10. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method comprising: Implement routing protocols on network devices in the network; Determining, by the network device based on the routing protocol, routing information indicating a plurality of next-hop devices for an Internet Protocol (IP) address prefix; storing the routing information associated with the IP address prefix in a routing data structure; generating an adjacency list based on the routing information in the routing data structure, the adjacency list including identification information of the plurality of next-hop devices in order of preference; generating an entry comprising the adjacency list and the IP address prefix in a forwarding data structure separate from the routing data structure; receiving a packet having a header including a destination IP address; looking up the destination IP address in the forwarding data structure using longest prefix matching; In response to determining a match between the destination IP address and the IP address prefix based on the lookup, selecting the entry from the forwarding data structure for determining a next hop device for forwarding the packet; as well as The next hop device for the packet is determined from the adjacency list in the entries based on the preference order.

11. The non-transitory computer-readable storage medium of claim 10, wherein determining the plurality of next-hop devices further comprises: determining, by the routing protocol, the routing information including a plurality of loop-free routes for the IP address prefix from the network device; as well as The multiple next-hop devices are determined from the routing information.

12. The non-transitory computer-readable storage medium of claim 11 , wherein the method further comprises: storing the routing information in association with the IP address prefix in a corresponding entry in the routing data structure; and Generating the adjacency list includes: merging identification information of the multiple next-hop devices from the routing information into the routing data structure.

13. The non-transitory computer-readable storage medium of claim 10, wherein a corresponding subset of the plurality of next-hop devices belongs to at least two service provider networks.

14. The non-transitory computer-readable storage medium of claim 13, wherein determining the plurality of next-hop devices for the IP address prefix further comprises: obtaining topology information associated with the network device; identifying, from the topology information, corresponding network devices coupled to the network device in the at least two service provider networks; as well as The identified network devices in the at least two service provider networks are tracked as the plurality of next-hop devices.

15. The non-transitory computer-readable storage medium of claim 10, wherein the method further comprises: determining the preference order based on forwarding preferences associated with the IP address prefixes; as well as The identification information in the adjacency list is sorted based on the preference order.

16. The non-transitory computer-readable storage medium of claim 15, wherein the forwarding preference is based on one or more of: respective path costs associated with the plurality of next-hop devices; Preferred provider network; and Based on user-configured preselection.

17. The non-transitory computer-readable storage medium of claim 10, wherein determining the next hop device for the packet further comprises: After an initial next hop device in the adjacency list is unavailable, a subsequent next hop device in the adjacency list is selected as the next hop device for the packet.

18. The non-transitory computer-readable storage medium of claim 17, wherein the method further comprises: In response to the initial next-hop device being unavailable, removing the initial next-hop device from the adjacency list.

19. A computing system comprising: at least one processing resource; Forwarding hardware, used to store and forward data structures; at least one non-transitory computer-readable storage medium storing instructions for execution by the at least one processing resource to: implement a routing protocol operating in a network; determining, based on the routing protocol, routing information indicating a plurality of next-hop devices for an Internet Protocol (IP) address prefix; storing the routing information associated with the IP address prefix in a routing data structure of the computing system; generating an adjacency list based on the routing information in the routing data structure, the adjacency list including identification information of the plurality of next-hop devices in order of preference; storing an entry comprising the adjacency list and the IP address prefix in the forwarding data structure separate from the routing data structure; receiving a packet having a header including a destination IP address; looking up the destination IP address of the packet in the forwarding data structure using longest prefix matching; In response to determining a match between the destination IP address and the IP address prefix based on the lookup, selecting the entry from the forwarding data structure for determining a next hop device for forwarding the packet; as well as The next hop device for the packet is determined from the adjacency list in the entries based on the preference order.

20. The computing system of claim 19, wherein the non-transitory computer-readable storage medium further stores instructions for execution by the at least one processing resource to: After an initial next hop device in the adjacency list is unavailable, a subsequent next hop device in the adjacency list is selected as the next hop device for the packet.

Images