Computing device performing computer networking and computer networking method

Abstract

The invention relates to a computing device performing computer networking and a computer networking method. This disclosure describes techniques for providing the same destination path diversity in a VPN using multiple routing distinguishers assigned to a single VRF. In one example, a method includes storing, by a device, a plurality of routes of a public address prefix for a virtual private network (VPN) to a single virtual routing and forwarding instance (VRF) of one or more virtual routing and forwarding instances (VRFs) configured for a network device of the network; and transmitting, by the apparatus, each of the plurality of routes having the common address prefixes of the different corresponding route differentiators to the network router.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Application No. 18 / 345,887, filed on June 30, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to computer networks, and more particularly, to packet forwarding within a virtual network. Background Art

[0004] A network or collection of networks, such as those deployed in a data center or a service provider network, may employ an Internet Protocol-based virtual private network (VPN). A more complete description of an example of an IP-based VPN is found in Rosen et al., “BGP / MPLS IP Virtual Private Networks (VPNs)”, Request for Comments 4364, Network Working Group, February 2006, which is hereby incorporated by reference in its entirety. A description of further details of BGP signaling IP / VPN is found in S. Mackie et al., “BGP-Signaled End-System IP / VPNs”, Network Working Group Internet-Draft, December 15, 2016, which is hereby incorporated by reference in its entirety. A description of multiprotocol extensions for BGP is found in T. Bates et al., “Multiprotocol Extensions for BGP-4”, Request for Comments 4760, Network Working Group, January 2007, which is hereby incorporated by reference in its entirety.

[0005] IP addresses imported and exported from a virtual routing and forwarding instance (VRF) used to implement a VPN can use a unique routing discriminator to disambiguate. When the same IP prefix appears in different VRFs, the routing discriminator can be connected to the VPN Internet Protocol (IP) prefix to provide disambiguation of the same prefix. Such an IP prefix can be referred to as a VPN address, and more specifically, for an IPv4 address, can be referred to as a VPNv4 address. For example, the same IPv4 prefix value may belong to different destinations and be imported into two different virtual routing and forwarding instances (VRFs). In the environment of a single provider edge (PE) router, each of the two VRFs can be assigned a unique routing discriminator to allow two extended VPNv4 prefixes to be announced by the PE router. Summary of the invention

[0006] In general, the present disclosure describes techniques for using multiple route distinguishers assigned to a single VRF to provide same-destination path diversity in a VPN. As a result, a provider edge device (PE) can advertise prefixes for multiple customer edge (CE) devices within a VRF using multiple route distinguishers to improve load balancing of traffic to the CE devices across the VPN.

[0007] In some examples, the same prefix with multiple next hops (each next hop corresponding to one of the CE devices) can be configured or imported as separate routes within a single VRF configured within a PE. The PE can (e.g., using one or more Multi-Protocol Border Gateway Protocol (MP-BGP) messages) advertise each corresponding prefix for the separate route using a different one of the route distinguishers assigned to the VRF. The prefixes are thus distinguished, and each prefix is ​​assigned and advertised with a different service label (e.g., an MPLS label) for use as a packet label when forwarding from a remote PE that imports the prefix.

[0008] A remote PE that imports the advertised prefix can therefore load balance between "paths" to multiple CE devices in the VPN, thereby increasing path diversity within the VPN. Although packets forwarded by a remote PE using the prefix and assigned service label may in some cases be forwarded across the network along the same physical path, a local PE that provides reachability to any CE device and receives such a packet will forward the packet to one of the CEs based on the routing entry for the prefix that was advertised along with the specific routing distinguisher and service label that was received with the packet. In some examples, one or more destinations reachable via a CE in the VPN (or the CE itself) are virtual workloads, such as virtual machines or Pods or other container-based endpoints.

[0009] The technology of the present disclosure can provide one or more technical advantages that provide practical applications. For example, the technology improves the load balancing of traffic across VPN to CE devices through remote PE. The add path method implemented by some routers extends MP-BGP to use an extended NLRI including an additional path discriminator ("path id") to announce multiple paths. However, the add path method causes a change in the format of the route announcement, and therefore must be understood by all routers that receive or propagate MP-BGP update (UPDATE) messages. Such routers may include ingress and egress PEs and route reflectors. Therefore, the introduction of the add path for a given address family indicator (AFI) / subsequent address family indicator (SAFI) destroys the infrastructure. In heterogeneous networks, not all PE vendors support adding paths. In addition, although the demand for path diversity may only be beneficial to a small portion of the prefixes announced, the use of the add path will affect all prefixes of a given SAFI, and may cause undesirable side effects due to the additional scale pressure on the routing information base (RIB) or forwarding information base (FIB). Unlike adding paths, the techniques of the present disclosure provide path diversity in a VPN in a transparent and less intrusive manner. The use of this technique can be performed by the egress PE alone, while the ingress PE and route reflector can function normally. In fact, the use of this technique by the PE may be limited to a single VRF.

[0010] In one example aspect, a method includes: storing, by a device, a plurality of routes for a public address prefix for a VPN to a single VRF of one or more VRFs of a network device configured for a network; and sending, by the device, each of the plurality of routes for the public address prefix having a different corresponding route distinguisher to a network router.

[0011] In other example aspects, a controller includes a processing circuit in communication with a memory, the processing circuit being configured to access the memory configured with instructions that, when executed, cause the processing circuit to: store multiple routes for a public address prefix for a VPN to a single VRF of one or more VRFs of a network device configured for a network; and output each of the multiple routes for the public address prefix having a different corresponding route distinguisher to a network router.

[0012] In a further example aspect, a computer-readable storage medium includes instructions that, when executed, cause one or more processors of a controller to: store multiple routes for a public address prefix for a VPN to a single VRF of one or more VRFs of a network device configured for a network; and send each of the multiple routes for the public address prefix having a different corresponding route distinguisher to a network router.

[0013] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a block diagram illustrating an example network system with a data center in which examples of the techniques described herein may be implemented.

[0015] Figure 2 is a more detailed description of the technology according to the present disclosure Figure 1 A block diagram of an example implementation of a data center.

[0016] Figure 3 is a block diagram illustrating an example network system in which examples of the techniques described herein may be implemented.

[0017] Figure 4 is a block diagram illustrating an example network system in which examples of the techniques described herein may be implemented.

[0018] Figure 5 is a block diagram illustrating other example network systems in which examples of the techniques described herein may be implemented.

[0019] Figure 6 is a block diagram illustrating an example routing advertisement for a virtual private network address including a routing distinguisher, in accordance with techniques of this disclosure.

[0020] Figure 7 is a flow chart illustrating example operation of a device in accordance with the techniques of this disclosure.

[0021] Like reference numerals refer to like elements throughout the drawings and text. DETAILED DESCRIPTION

[0022] Figure 1 is a block diagram of an example network system 5 having a data center 10 that illustrates an example in which the techniques described herein may be implemented. In the network system 5, controllers 32A-32B ("controllers 32"), compute nodes 26A-26X ("compute nodes 26"), provider edge (PE) routers 8A-8B ("PE routers 8"), and nodes of an Internet Protocol (IP) fabric 20 operate in accordance with the techniques described herein to ensure that customer traffic flows and customer applications executing within a cloud data center continue uninterrupted.

[0023] Typically, data center 10 provides an operating environment for applications and services for customers 4 that are coupled to data center 10 through service provider network 6. Customer 4 is coupled to service provider network 6 through provider edge (PE) devices 12. Data center 10 hosts infrastructure equipment such as networking and storage systems, redundant power supplies, and environmental controls. Service provider network 6 may be coupled to one or more networks managed by other providers, and thus may form part of a large-scale public network infrastructure (e.g., the Internet).

[0024] In some examples, data center 10 may represent one of many geographically distributed network data centers. Figure 1 As shown in the example of FIG. 1 , data center 10 is a facility that provides network services to customers 4. Customers 4 may be collective entities (such as businesses and governments) or individuals. For example, a network data center may host network services for several businesses and end users. Other example services may include data storage, virtual private networks, traffic engineering, file services, data mining, scientific computing or supercomputing, etc. In some examples, data center 10 is a separate network server, network peer, etc.

[0025] In this example, data center 10 includes a set of storage systems and application servers that are interconnected via an IP fabric 20 provided by one or more layers of physical network switches and routers. Computing nodes 26 are servers that serve as computing nodes for the data center. In some examples, the terms "computing node" and "server" are used interchangeably herein to refer to computing nodes 26. For example, each computing node 26 may provide a server for executing one or more customer-specific virtual machines ( Figure 1 The IP structure 20 is provided by a set of interconnected leaf switches 24A to 24N (collectively referred to as "leaf switches 24"), which are coupled to a distribution layer of spine switches 22A to 22M (collectively referred to as "spine switches 22"). The leaf switch 24 may also be referred to as a top-of-rack (TOR) switch. The spine switch 22 may also be referred to as a spine switch. Although not shown, the data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection and / or intrusion prevention devices, etc.), servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants, etc.), wireless access points, bridges, cable modems, application accelerators, or other network devices.

[0026] In this example, the leaf switches 24 and the spine switches 22 provide redundant (multi-homed) connections to the IP structure 20 to the compute nodes 26. The spine switches 22 aggregate traffic flows and provide high-speed connections between the leaf switches 24. The leaf switches 24 are network devices that provide layer 2 (e.g., MAC) and / or layer 3 (e.g., IP) routing and / or switching functions. The leaf switches 24 and the spine switches 22 each include a memory and one or more processors and are capable of executing one or more software processes. The PE router 8, also known as a gateway router, is a routing device that performs layer 3 routing to route network traffic between the data center 10 and the customer 4 through the service provider network 6. The PE router 8 provides redundant gateways to forward and receive packets between the IP structure 20 and the service provider network 6.

[0027] According to one or more examples of the present disclosure, controller 32A is a network controller (e.g., an SDN controller) that provides a logical (and in some cases, physically) centralized controller for facilitating the operation of one or more virtual networks within data center 10. The terms controller and virtual network controller ("VNC") may be used interchangeably in the present disclosure. In some examples, controller 32A operates in response to configuration input received from orchestration engine 30 via northbound application programming interface (API) 31, which in turn operates in response to configuration input received from administrator 28. Additional information about controller 32A operating in conjunction with other devices or other software defined networks of data center 10 may be found in International Application No. PCT / US2013 / 044378, filed on June 5, 2013, entitled "PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKET Flows," which is incorporated herein by reference as if fully set forth herein.

[0028] In some examples, orchestration engine 30 manages the functions of data center 10 (such as computing, storage, networking, and application resources). For example, orchestration engine 30 can create virtual networks for tenants within data center 10 or across data centers. Orchestration engine 30 can connect virtual machines (VMs) to the tenant's virtual network. Orchestration engine 30 can connect the tenant's virtual network to some external network, such as the Internet or a VPN. Orchestration engine 30 can implement security policies across the boundaries of a group of VMs or tenant networks. Orchestration engine 30 can deploy network services (e.g., load balancers) in the tenant's virtual network.

[0029] In some examples, controller 32A manages network and networking services such as load balancing, security, and allocation of resources to various applications from compute nodes 26 via southbound API 33. That is, southbound API 33 represents a set of communication protocols used by controller 32A to make the actual state of the network equal to the desired state specified by orchestration engine 30. For example, one such communication protocol may include a signaling protocol, such as Extensible Messaging and Presence Protocol (XMPP). For example, controller 32A implements high-level requests from orchestration engine 30 by configuring physical switches, e.g., leaf switches 24, spine switches 22; physical routers; physical service nodes (such as firewalls and load balancers); and virtual services (such as virtual firewalls in VMs). Controller 32A maintains routing, networking, and configuration information in a state database. Controller 32A transmits an appropriate subset of routing information and configuration information from the state database to a virtual router (VR) agent 36A to 36X ( Figure 1 VA in the .

[0030] Compute nodes and control nodes associated with different controllers may be arranged in a cluster. A cluster is a group of real and / or virtual servers forming a controller, including control nodes and compute nodes managed by the controller. For example, Figure 1 As shown, the system can include two independent controllers 32A and 32B, each of which can be associated with a different server cluster. In some examples, controller 32B manages a second set of computing nodes (not shown). In other examples, controller 32B manages a subset of computing nodes 26, while controller 32A manages a different, non-overlapping subset of computing nodes 26.

[0031] Typically, traffic between any two network devices (such as between network devices within IP structure 20, or between computing node 26 and client 4, or between computing nodes 26), for example, can use many different paths to traverse the physical network. For example, there may be multiple different paths of equal cost between two network devices. In some cases, packets belonging to network traffic from one network device to other network devices can be distributed among various possible paths at each network switching node using a routing strategy called multi-path routing. For example, a routing technique for routing packets along multi-paths of equal cost is described in Internet Engineering Task Force (IETF) RFC 2992, "Analysis of an Equal-Cost Multi-Path Algorithm". The technology of RFC 2992 analyzes a specific multi-path routing strategy involving allocating flows to bins by hashing packet header fields, which causes all packets from a specific network flow to be sent via a single deterministic path.

[0032] For example, a "flow" can be defined by five values ​​or "quintuples" used in the header of a packet, i.e., the protocol, source IP address, destination IP address, source port, and destination port used to route the packet through the physical network. For example, the protocol specifies the communication protocol (such as TCP or UDP), and the source port and destination port refer to the source port and destination port of the connection. A group of one or more packet data units (PDUs) that match a particular flow entry represents a flow. Flows can be broadly classified using any parameters of the PDU, such as source and destination data link (e.g., MAC) and network (e.g., IP) addresses, virtual local area network (VLAN) tags, transport layer information, multi-protocol label switching (MPLS) or general MPLS (GMPLS) labels, and the ingress port of the network device receiving the flow. For example, a flow can be all PDUs transmitted in a transmission control protocol (TCP) connection, all PDUs initiated by a specific MAC address or IP address, all PDUs with the same VLAN tag, or all PDUs received at the same switch port.

[0033] As described herein, each computing node 26 executes a corresponding virtual router that implements a provider edge router ( Figure 1PE-X” in the figure), the provider edge router implements multiple virtual routing and forwarding instances (“VRFs”) for corresponding virtual networks within the data center 10 and routes packets to appropriate workloads executing within the operating environment provided by the server. For example, a packet received by the PE1 router of the computing node 26A from the underlying physical network structure may include an outer header to allow the physical network structure to tunnel the payload or “inner packet” to the physical network address of the network interface of the computing node 26 executing the PE1 router. The outer header may include not only the physical network address of the network interface of the server, but also a virtual network identifier, such as a virtual extensible LAN (VXLAN) label or an MPLS label that identifies one of the virtual networks and the corresponding VRF implemented by the PE1 router or interface. That is, the MPLS label can be mapped to a VRF or mapped to an interface. The inner packet includes an inner header with a destination network address that conforms to the virtual network addressing space for the virtual network identified by the virtual network identifier. In some aspects, the PE1 router buffers and aggregates multiple tunnel packets received from the underlying physical network fabric before delivering the packets to the appropriate VRFs for the packets.

[0034] exist Figure 1 In the example of , the controller 32A learns routing and other information (e.g., configuration information) and distributes the routing and other information to all computing nodes in the data center 10. The virtual agent (VA) 36 running inside the computing node typically programs the data forwarding element (virtual router) with the forwarding information when receiving the routing information from the controller 32A. The controller 32A sends the routing and configuration information to the VA 36 using a signaling protocol such as the XMPP protocol. In XMPP, the controller 32 and the agent transmit routes and configurations on the same channel. When receiving the overlay network routes (virtual routes) from the VA 36, the controller 32A acts as a signaling protocol client, and in this case, the VA 36 acts as a signaling protocol server. Conversely, when the controller sends routes (including overlay network routes learned from gateways or other computing nodes) to the VA 36, the controller 32A acts as a message protocol server of the VA 36 (as a message protocol client).

[0035] The control node of controller 32A may generate and encode a route distinguisher for a virtual private network address. In some examples, the route distinguisher may be generated using a physical hardware address of a compute node that hosts a virtual network destination. For example, a virtual network destination may be a virtual network endpoint that is a workload of a compute node and may represent a virtual machine and / or a container. For example, in response to receiving a signaling protocol message specifying a VPN route from compute node 26, the control node of controller 32A sends the VPN route to the virtual network destination to one or more routing protocol peers (such as PE router 8). The VPN route includes, among other fields, a route distinguisher field having a route distinguisher value, which may be represented by Figure 1 The control node in the example is generated. A route distinguisher is an identifier attached to a route that enables a router to distinguish which VPN or Virtual Private LAN Service (VPLS) the route belongs to. RDs allow the same IP address prefixes to be used in different VPNs without them overlapping.

[0036] According to the techniques of the present disclosure, each VRF is not limited to being associated with a single route distinguisher, but can have one or more unique route distinguishers (RDs) associated with it. PEs (PE-1 to PE-X) can advertise the same prefix to different next hops from a single VRF using different RDs. Multiple RDs distinguish the common prefix of the receiving PE and enable the PE to import multiple routes with the same prefix to a common next hop: the advertising PE. The receiving PE can then use these multiple routes to better load balance the traffic towards the CE associated with the prefix.

[0037] Figure 2 is a more detailed description of the technology according to the present disclosure Figure 1 A block diagram of an example implementation of a data center 10 is provided. Figure 2 In the example of , data center 10 includes computing nodes 26A to 26X, which include corresponding virtual routers that function as corresponding provider edge (PE) routers 42A to 42X (collectively, "PE routers 42," sometimes referred to as "vrouters" or "virtual routers"). In response to instructions received from controller 32A, PE router 42 dynamically creates and manages one or more virtual networks (e.g., "VN1, VN0") 46 that can be used for communication between application instances.

[0038] In one example, PE router 42 implements the virtual network as an overlay network, which provides the ability to decouple the virtual address of an application from the physical address (e.g., IP address) of one of the computing nodes 26A to 26X (on which the application is executing) ("computing node 26"). Each virtual network can use its own addressing and security scheme and can be considered orthogonal to the physical network and its addressing scheme. Various techniques can be used to transmit packets within and across virtual networks 46 through the physical network.

[0039] Each PE router 42 may be executed within a hypervisor, a host operating system, a virtual computing instance (such as a virtual machine or a container-based instance), a SmartNIC, or other component of each compute node 26. Each compute node 26 may represent an x86 or other general-purpose or specialized server capable of executing a virtual machine. Figure 2 In the example of , PE router 42A executes within a hypervisor 43, which is also commonly referred to as a virtual machine manager (VMM), which provides a virtualization platform that allows multiple operating systems to run simultaneously on one of the computing nodes 26. Figure 2 In the example of , PE router 42A manages virtual networks 46, each of which provides a network environment for executing one or more customer edge (CE) 48 instances on a virtualization platform provided by a hypervisor 43. Each CE 48 is associated with one of the virtual networks VN0 to VN1 and represents a tenant CE workload running a customer application (such as a network server, a database server, an enterprise application, or a hosted virtualized service for creating a service chain). In some cases, any one or more computing nodes 26 or other computing devices directly host customer applications, that is, not as virtual machines. The workloads referred to herein (e.g., CE 48) and computing nodes 26 or independent computing devices that host customer applications may also be referred to as "hosts."

[0040] Each interface of a CE 48 running on a host is connected to a VRF that contains a forwarding table for the corresponding network, which contains the IP address of the interface. PE routers 42 only have VRFs for networks that have interfaces on the host, including the Fabric VRFs that are connected to the physical interfaces of the host. Virtual networking uses encapsulation tunnels to transfer packets between CEs 48 on different hosts, and encapsulation and decapsulation occur between the Fabric VRFs and VM VRFs.

[0041] In general, each CE 48 may be any type of workload running a software application and is assigned a virtual address for use within a corresponding virtual network 46, where each virtual network may be a different virtual subnet provided by PE1 router 42A. CE 48 may be assigned its own virtual layer 3 (L3) IP address, e.g., for sending and receiving communications, but is unaware of the IP address of the physical computing node 26A (on which the virtual machine is executed). In this manner, a "virtual address" is a different physical address from the underlying, physical computer system (e.g., Figure 2 The virtual address may also be referred to as a "virtual interface" in this document.

[0042] In one implementation, each compute node 26 includes a corresponding one of VR agents 36A-36X that communicates with controller 32A and, in response to communications with controller 32A, directs virtual router 42 to control the overlay of virtual network 46 and coordinate the routing of data packets within compute node 26. Typically, each VR agent 36 communicates with controller 32A, which generates commands to control the routing of packets through data center 10.

[0043] VR agent 36 executes in user space and acts as a proxy for control plane messages between CE 48 and controller 32A. For example, CE 48 may request to send a message via VR agent 36A using its virtual address, and VR agent 36A may in turn send the message and request to receive a message response to the virtual address of CE 48 that originated the first message. In some cases, CE 48 invokes a procedure or function call provided by an application programming interface of VR agent 36A, and VR agent 36A also handles the encapsulation of the message, including addressing.

[0044] In some example implementations, each computing node 26A also includes an orchestration agent ( Figure 2 For example, in response to instructions from orchestration engine 30, the orchestration agent transmits the attributes of a specific CE 48 executed on a corresponding computing node 26, and may create or terminate a single CE.

[0045] In one example, network packets (e.g., layer 3 (L3) IP packets or layer 2 (L2) Ethernet packets) generated or consumed by an application instance executed by a CE 48 within a virtual network domain can be encapsulated in other packets (e.g., other IP or Ethernet packets) transmitted by a physical network. Packets transmitted in a virtual network may be referred to herein as "internal packets," while physical network packets may be referred to herein as "external packets" or "tunnel packets." Encapsulation and / or decapsulation of virtual network packets within physical network packets may be performed within a PE router 42, for example, within a hypervisor or host operating system running on each computing node 26. As another example, the encapsulation and decapsulation functions are performed at the edge of the IP fabric 20 at a first top-of-rack (TOR) switch 24, which is a hop removed from the application instance that initiated the packet. This functionality is referred to herein as a tunnel, and may be used within a data center 10 to create one or more overlay networks. In addition to IP-in-IP, other example tunneling protocols that can be used include IP over GRE, VxLAN, MPLS over GRE, MPLS over UDP, etc.

[0046] As described above, controller 32A provides a logically centralized controller for facilitating the operation of one or more virtual networks within data center 10. For example, controller 32A maintains a routing information base, such as one or more routing tables that store routing information for the physical network of data center 10 and one or more overlay networks. Similarly, PE router 42 maintains routing information (such as one or more routing and / or forwarding tables). In one example implementation, PE router 42A of hypervisor 43 implements a network forwarding table (NFT) 44 for each virtual network 46. Typically, each NFT 44 stores forwarding information for a corresponding virtual network 46 and identifies where a data packet is to be forwarded and whether the packet is to be encapsulated in a tunneling protocol (such as using a tunnel header that may include one or more headers of different layers of the virtual network protocol stack).

[0047] For example, CE1 48 may send an "internal packet" to PE1 router 42A over an internal link. PE1 router 42A uses NFT1 to look up the virtual network destination network address for the packet. NFT1 specifies the outbound interface for PE1 router 42A and the encapsulation for the packet. Virtual router 30A applies the encapsulation to add a tunnel header to generate an outer packet and outputs the outer packet on the outbound interface, in this case, to leaf switch 24A.

[0048] For example, the routing information maps packet key information (e.g., destination IP information and other optional information from the packet header) to one or more specific next hops within the network provided by PE router 42 and IP fabric 20. In some cases, the next hop is a chained next hop that specifies a set of operations to be performed on each packet when forwarding the packet, such as can be used for flooding next hops and multicast replication. Figure 2 As shown, each virtual network 46 provides a communication framework for encapsulated packet communications of the overlay network established through IP fabric 20. In this manner, network packets associated with any virtual machine 48 may be transmitted as encapsulated packet communications via the overlay network.

[0049] Each VR agent 36 may send a message to the controller 32A via an XMPP session that passes the virtual route to the virtual interface (virtual address) of the VM of the computing node 26. The virtual route may also be referred to as an overlay network route herein. For example, the VR agent 36A sends an XMPP message 37A containing a virtual route for the computing node 26A. The controller 32A receives the message and stores the virtual route to overlay the routing information, and then may announce one or more virtual routes received from the first VR agent 36 to the PE router 8 (e.g., via a multi-protocol extension for BGP (MP-BGP)), such as via a route announcement 38A. MP-BGP is an extension of BGP that allows different address families to be distributed. If there is a gateway router between the two clusters, the controller 32A may also announce the virtual route to other control nodes 54 (e.g., the control node of the controller 32B). In some examples, any virtual route may include a prefix, a next-hop address associated with a server of the computing node 26, and a label or other data identifying the virtual route and forwarding instance configured at the next-hop server. A virtual route may also include a route differentiator (RD).

[0050] The route distinguisher is an address qualifier used in the context of an IP-VPN (such as a BGP-MPLS VPN). The route distinguisher is used to distinguish VPNv4 (or "VPN-IPv4") routes. The route distinguisher is an 8-byte field. In addition to the 4-byte IP address, the route distinguisher also forms a 12-byte VPNv4 prefix. The route distinguisher (RD) is an 8-octet value consisting of two main fields, the type field (2 octets) and the value field (6 octets). The type field determines how the value field should be interpreted. As shown in Table 1, the following types are defined:

[0051] Type No. value Type 0 2-byte ASN + 4-byte subfield Type 1 4-byte IP + 2-byte subfield Type 2 4-byte ASN + 2-byte subfield

[0052] Table 1

[0053] For type 2VPN routing, at the control node of the SDN controller, the / 32IP address of the VM started in the virtual node is added to the VRF corresponding to the virtual node (VN). The VRF will have the usual attributes such as the route target (RT) and the route distinguisher (RD). For type 2VPN routing, the control node generates the RD using the IP of the computing node (4-byte IP address and 2-byte virtual network ID). The VN-ID is assigned sequentially by the configuration module and is unique in the cluster for each routing instance. VPNv4 routing is typically advertised using type 1RD. For example, for a computing node with an IP address of 10.204.217.108 and a VRF with a VN ID of 0, the RD generated by the control node will be 10.204.217.108:0. Despite the above description, other schemes can be used to generate RD.

[0054] Each control node of the SDN controller advertises the XMPP routes received from the compute nodes as VPNv4 routes to other BGP speakers, for example, route advertisement 38A. The BGP speakers may include other control nodes 54 as well as external BGP speakers such as SDN gateway routers 8.

[0055] The SDN architecture described in this article supports the separation of control data and management interfaces. It is assumed that the management interface is assigned an IP address that is accessible from the outside and must be unique. However, the control data network comes from a private addressing space and is local to the cluster. This can be reused across multiple independent clusters.

[0056] In response to receiving route advertisement 38A, PE router 8A, a gateway router, stores the VPN route. PE router 8A may then advertise the route to its routing peers (such as other gateway routers, other controller control nodes, and computing nodes). PE router 8A may forward network traffic based on the stored VPN route. For example, PE router 8A may store a virtual route to a virtual routing and forwarding (VRF) instance of a virtual network including a virtual network destination, and forward traffic to computing node 26A based on the virtual route stored by PE router 8A.

[0057] According to the techniques of the present disclosure, each VRF is not limited to being associated with a single route distinguisher, but can have one or more unique route distinguishers (RDs) associated with it. The virtual router of any computing node 26 can implement a PE device (e.g., PE-1 42A to PE-X 42X) that can use different RDs to advertise the same prefix to different next hops from a single VRF. Multiple RDs distinguish the common prefix of the receiving PE and enable it to import multiple routes with the same prefix to a common next hop: the advertising PE. The receiving PE can then use these multiple routes to better load balance the traffic towards the CE associated with the prefix.

[0058] Figure 2 The architecture of the data center 10 shown in FIG. 1 is shown for illustrative purposes only. The techniques described in this disclosure may be used in Figure 2 The present invention may be implemented in the exemplary data center 10 of the present invention, and may also be implemented in other types of data centers not specifically described herein. Nothing in this disclosure should be interpreted as limiting the technology of this disclosure to Figure 2 Example architecture shown.

[0059] Figure 3 is a block diagram of an example network system that illustrates an example in which the techniques described herein may be implemented. In some examples described herein, Figure 3 The configuration of the network system 50 depicted in can be used to improve load balancing of traffic across a VPN to each of a plurality of CE devices. The network 40 can represent one or more layer 3 networks and include a PE router 42 that implements a VPN using a corresponding VRF 300. The network 40 can represent or include one or more service provider networks, the Internet, a data center network, or other types of networks. Local PE1 42A is associated with VRF 300A, local PE2 42B is associated with VRF 300B, and local PE3 42C is associated with VRF 300C. CE11 48A, CE12 48B, and CE13 48C are communicatively coupled to local PE1 42A. PE1 42A stores multiple routes to public address prefixes for CE11 48A, CE12 48B, and CE13 48C, with corresponding next hops for CE11 48A, CE12 48B, and CE13 48C. Likewise, CE2 48D is communicatively coupled to local PE2 42B. Similarly, CE3 48E is communicatively coupled to local PE3 42C. Local PE1 42A, local PE2 42B, and local PE3 42C are communicatively coupled to network 40. Figure 3In the example of FIG. 4 , CE 48A to 48E (collectively referred to as “CE 48”) may be any type of customer edge device, such as a CE router or switch, a workload (such as a reference Figure 2 The CE 48 has or provides reachability to the common prefix. Figure 3 In the example of , CE 48 is assigned a public / 32 IP address 123.123.123.123 / 32. For example, this address can be a virtual IP address and / or an anycast IP address. Traffic destined for this prefix should be forwarded by PE 48 to any one or more of CE 48.

[0060] According to the techniques described herein, routes may be advertised from PEs from the same VRF but using different route distinguishers. More specifically, local PE1 42A, local PE2 42B, and local PE3 42C may each output routes using route advertisements 302 including multiple unique route distinguishers assigned to the VRFs to forward traffic to CE 48. A given prefix advertised using multiple route distinguishers by a PE may be stored in a single VRF of the PE. For example, local PE 42A may advertise a route from VRF 300A to CE11 48A using route distinguisher RD11 and IP address 123.123.123.123 / 32. The local PE 42A may also advertise a route from VRF 300A to CE1 48B using route distinguisher RD12 and IP address 123.123.123.123 / 32; and a route from VRF 300A to CE13 48C using route distinguisher RD13 and IP address 123.123.123.123 / 32. Similarly, the local PE2 42B may advertise a route for VRF 300B via CE2 48D using route distinguisher RD2 and IP address 123.123.123.123 / 32. Similarly, the local PE3 42C may advertise a route for VRF 300C via CE3 48E using route distinguisher RD3 and IP address 123.123.123.123 / 32.

[0061] The routing advertisement 302 is sent over the network 40 and is received at the remote PE 42X. The remote PE 42X is associated with the VRF 300X, and the remote PE 42X is configured to store the routing information base (RIB) 90. RIB 90 may import multiple routes into VRF 300X based on route advertisements 302 from PEs 42A to 42C, such as a route via RD11:123.123.123.123 / 32 of PE1 42A, a route via RD12:123.123.123.123 / 32 of PE1 42A, a route via RD12:123.123.123.123 / 32 of PE1 42A; a route via RD2:123.123.123.123 / 32 of PE2 42B, and a route via R3:123.123.123.123 / 32 of PE3 42C.

[0062] Thus, multiple route distinguishers may be assigned to a single VRF 300A, 300B, or 300C to provide the same destination path diversity in a VPN implemented in the network 40. A local PE (such as local PE1 42A, local PE2 42B, and / or local PE3 42C) may advertise prefixes for multiple CE devices within a VRF using multiple route distinguishers to improve load balancing of traffic to the CE devices across the VPN. For example, local PE1 42A may advertise prefixes within a VRF for multiple CE devices including CE11 48A, CE12 48B, and / or CE13 48C. In some examples, the same prefix with multiple possible next hops (each corresponding to one of the CE devices CE11 42AB, CE12 48B, or CE13 48C) may be configured or imported as a separate route within VRF 300A configured within local PE1 42A. Local PE 42A may, for example, use one or more Multi-Protocol Border Gateway Protocol (MP-BGP) messages to advertise each corresponding prefix as a separate route using a different one of the route distinguishers assigned to VRF 300A. The prefixes are thus differentiated, and each prefix is ​​assigned and advertised with a different service label, e.g., an MPLS label, to be used as a packet label when forwarding from the remote PE that imported the prefix. PE2 42B similarly advertises routes to CE2 48D, and PE3 42C similarly advertises routes to CE3 48E.

[0063] Based on one or more route advertisements 302, remote PE 42X imports multiple routes with different route distinguishers for the advertisement prefix and can thus load balance traffic 51 between paths to multiple CE devices in the VPN (such as CE11 48A, CE12 48B, and CE13 48C reachable via PE1 42A, CE2 48D reachable via PE2 42B, and CE3 48E reachable via PE3 42C), thereby increasing path diversity within the VPN. The various routes imported into VRF 300X are as follows: Figure 3 As shown. PE 42X can form these routes to the common prefix 123.123.123.123 / 32 into equal cost multi-path (ECMP) routes or forwarding entries and load balance between the paths according to a load balancing algorithm. Although packets forwarded by remote PE42X using the prefix and assigned service label can in some cases be forwarded along the same physical path on network 40, the local PE (e.g., PE1 42A) that provides reachability to any CE device (e.g., CE11 48A, CE12 48B and / or CE13 48C) and receives such packets will forward the packet to one of the CEs based on the route entry for the advertised prefix together with the specific route distinguisher and service label received with the packet. In some examples, one or more destinations reachable via a CE in the VPN (or the CE itself) are virtual workloads, such as virtual machines or Pods or other container-based endpoints. Refer to the following Figure 5 Further described is the advertisement of routes with different labels and the use of labels for forwarding at the local PE.

[0064] In some examples, a routing discriminator for a VPN address is generated to provide reusability of an IP address in multiple VRFs. In some examples, one or more routing discriminators include reusable portions of other VRFs that are also mapped to the VPN. In some examples, each of the multiple routing discriminators provides global disambiguation for each of the multiple VRFs in the VPN, including a single VRF and other VRFs. In some examples, one or more virtual network destinations in the VPN are virtual workloads.

[0065] In a further example, the mapping is performed by specifying a range of routing distinguishers for a single VRF. In other further examples, the mapping is performed using network layer reachability information (NLRI). In yet another further example, the CE router initiates the advertisement. In yet another further example, the IP address may include a physical hardware address of a computing node hosting the virtual network destination.

[0066] Each PE 42 includes or is implemented using processing circuitry that has access to a memory storing instructions that cause the processing circuitry to implement the functionality described above with respect to the PE.

[0067] Figure 4 is a block diagram of an example network system equipped with virtual routing and forwarding that illustrates an example in which the techniques described herein may be implemented. In some examples described herein, Figure 4 The configuration of the network system 150 may result in suboptimal or uneven load balancing of traffic across the VPN to each of the multiple CE devices. The VPN may be implemented using an instance of VRF A 41 and Figure 4 41. Local PE1 42A, local PE3 42C, and remote PE2 42B are all part of the network and use corresponding instances of VRF A 41 to implement VPN.

[0068] In some examples described herein, routes stored to VRFs of multiple PEs may be advertised from the PEs using route distinguishers configured for different VRFs. For example, local PE1 42A may advertise routes for its VRF instance using route distinguisher RDAPE1, IP address 123.123.123.123 / 32, and label 100, with local PE1 42A as the next hop. Local PE3 42C may advertise routes using route distinguisher RDAPE2, IP address 123.123.123.123 / 32, and label 100, with local PE3 42C as the next hop. Note that the same label 100 is used in route distinguisher RDAPE1 and route distinguisher RDAPE2.

[0069] The route advertisement 53 is output via the network and received at the remote PE2 42B. The remote PE 42B is configured to store a routing information base (RIB) 90. The RIB 90 may include multiple routes for VRF A 41, such as 123.123.123.123 / 32 via PE1 42A and 123.123.123.123 / 32 via PE3 42C. In this example, the lack of MP-BGP path diversity may result in suboptimal or unbalanced load balancing of traffic. For example, the remote PE2 42B may distribute traffic evenly to PE1 42A and PE3 42C, with 50% directed to the local PE1 42A and 50% directed to PE3 42C. However, local PE1 42A is communicatively coupled to and provides reachability to three CEs, including CE1 48A, CE2 48E, and CE3 48F, which have public addresses 123.123.123.123, while local PE3 is only communicatively coupled to one CE, including CE4 48G, which has public address 123.123.123.123. Therefore, traffic is unevenly directed to the CEs, with 16.67% directed to CE1 48A, 16.67% directed to CE2 48E, 16.67% directed to CE3 48F, and 50% directed to CE4 48G. In some examples, one or more destinations reachable via the CE in the VPN (or the CE itself) are virtual workloads, such as virtual machines or Pods or other container-based endpoints.

[0070] Figure 5 is a block diagram of other example network systems that illustrate examples of techniques described herein. In some examples described herein, Figure 5 The configuration of the network system 250 may be used to improve load balancing of traffic across the VPN to each of the plurality of CE devices. Figure 5 The VRF A 41 is similar to Figure 4 The local PE1 42A and the remote PE2 42B are part of a network and use corresponding instances of VRF A 41 to implement a VPN.

[0071] In some examples described herein, routes within the same VRF may be advertised from a local PE, but using different route distinguishers mapped to the VRF. More specifically, a local PE1 42A within VRF A 41 may advertise routes to a remote PE2 42B via VRF A 41 using route advertisements 153 including a unique route distinguisher. For example, the local PE1 42A may advertise a route via the local PE1 42A using route distinguisher 1.2.3.4:100:192.168.1.0 / 24 and include label 100. The local PE 42A may also advertise a route via the local PE1 42A using route distinguisher 1.2.3.4:101:192.168.1.0 / 24 and include label 200. The labels may be MPLS labels. PE1 42A installs forwarding information that maps each label to a different interface. In this example, label 100 is mapped to the interface of CE1 48A, and label 200 is mapped to CE2 48E. For example, the forwarding information may be stored in a label forwarding information base or an MPLS table.

[0072] The route advertisement 153 is output on the network and received at the remote PE2 42B. The remote PE 42B is configured to store a routing information base (RIB) 90. The RIB 90 may include multiple routes for VRF A 41, such as, for example, 192.168.1.0 / 24 to PE1 42A including label 100 and 192.168.1.0 / 24 via PE1 42A including label 200. Because these routes are advertised by PE1 42A using different route distinguishers for the same prefix, both routes are imported into VRF A of the RIB 90 on PE2 42B. PE2 42B uses the different routes to load balance traffic to CE1 48A and CE2 48E, and forwards packets destined for CE1 48A or CE2 48E to PE1 42A with label 100 or label 200 according to the imported route selected by the load balancing algorithm for the packet (or packet flow). Traffic with label 100 is directed to CE1 48A using label 100 by PE 42A, while traffic with label 200 is directed to CE2 48E using label 200 by PE 42A. PE 42A pops the label and sends it to the appropriate output interface. In this example, these labels (100 and 200) are used to provide MP-BGP path diversity to improve traffic load balancing between CE1 48A and CE2 48E. For example, PE2 42B directs 50% of the traffic to CE1 48A and 50% of the traffic to CE2 48E. In some examples, one or more destinations reachable via a CE in the VPN (or the CE itself) are virtual workloads, such as virtual machines or Pods or other container-based endpoints.

[0073] exist Figure 5 In the example of , multiple route distinguishers are mapped to a single VRF, such as the instance of VRF A 41 for PE 42A. For example, when automatically generating route distinguishers, such configuration may be achieved by providing configuration data in the form of a route distinguisher list (e.g., route-distinguisher-list 123.123.123.123:100, 123.123.123.123:101, ...), a route distinguisher range (e.g., route-distinguisher 123.123.123.123:100–110, i.e., an RD generated from a number in the range of 100 to 110 appended to an IP address), and / or a predefined maximum number of route distinguishers for a VRF (e.g., using a “maximum-per-vrf-route-distinguisher” configuration parameter). As can be seen above, route-distinguisher-list, route-distinguisher, and maximum-per-vrf-route-distinguisher are all example configuration parameters for mapping multiple RDs to a single VRF. The configuration data may be stored in the configuration database 91 for PE1 42A to configure PE1 42A. When advertising routes for a public address prefix, a different corresponding route distinguisher included in each of the multiple advertised routes may be extracted from the multiple route distinguishers specified in the configuration.

[0074] By assigning each next hop (per CE) with a distinct route distinguisher, each prefix of the multipath entry (ECMP) can be derived via MP-BGP. Because there may be a predefined maximum number of route distinguishers for a single VRF, the number of next hops may be greater than the maximum number in some cases. Therefore, a route distinguisher can be used to map to several next hops, for example, using a rotating index. Compared to the previously described add path technique, Figure 5 The method uses a different route discriminator instead of the path id extension. Figure 5 The approach provides a technical advantage over adding paths because no infrastructure changes (such as MP-BGP peer reconfiguration for adding path support) are required.

[0075] Figure 6 is a block diagram illustrating an example routing advertisement for a virtual private network address according to the techniques described herein. Figure 6In the example of FIG. 6 , the BGP update message 600 is a route advertisement in accordance with MP-BGP and includes an MP-REACH-NLRI field 602 that announces that the CE is reachable via the PE. The BGP update message 600 may indicate Figure 2 Routing advertisement 38A or Figure 5 153. For purposes of illustration, BGP update message 600 is illustrated using glyphs rather than packet fields.

[0076] The MP-REACH-NLRI field 602 of the BGP update message 600 specifies an address family identifier (AFI) field 604 (the value of the AFI field 604 in this example is 1) to indicate an IPv4 network address, and specifies a value of a subsequent AFI (SAFI) field 606 (the value of the SAFI field 606 is 128) to identify the virtual route as an L3VPN route. The AFI field 604 and the SAFI field 606 may have different values ​​in some cases, such as values ​​assigned by a private party or by the Internet Assigned Numbers Authority (IANA). In some examples, an IPv6 prefix may be used instead of an IPv4 prefix.

[0077] The network layer reachability information (NLRI) field 608 specifies the IP address identified in the prefix field 612. The length field 610A specifies the length of the prefix value in the prefix field 612. The label field 610B specifies the MPLS label. The prefix field 612 includes a route distinguisher field 614A that specifies a route distinguisher value. The route distinguisher field 614A may optionally include a type field having a value, the value of the type field indicating that the value field of the route distinguisher field 614A is generated based on a plurality of RDs assigned to the VRF from which the IPv4 prefix is ​​advertised / derived. The IPv4 prefix field 614B specifies the value of the IPv4 prefix, in which case 123.123.123.123 / 32 corresponds to the CE described in various examples elsewhere in this disclosure. According to the described techniques, a BGP update message may include multiple instances of the NLRI 608, wherein each NLRI instance specifies the same prefix 614B but a different RD value 614A.

[0078] Figure 7 is a flowchart illustrating an example operation of an apparatus according to the techniques of the present disclosure. Figure 542A stores multiple routes for a public address prefix to a VRF (901). Each of the multiple routes may have a different next hop to a different CE attached to the VRF. The VRF may be a single VRF instance of one or more VRFs configured for a network device of the network. PE1 42A generates each of the multiple routes for the public address prefix and outputs it to PE2 42B (903), the multiple routes having different corresponding route distinguishers. Such a route distinguisher may be selected from multiple route distinguishers assigned, configured, or otherwise mapped to a single VRF of PE1 42A. PE1 42A may send multiple routes with corresponding route distinguishers to PE2 42B as an announcement 153. Each of the multiple routes may also include different labels for packet forwarding.

[0079] PE2 42B receives a plurality of routes and corresponding different route distinguishers (912). PE2 42B generates an ECMP next hop from the plurality of routes (914). Each path of the ECMP next hop may be associated with a different label, which may be included in the corresponding route of the plurality of routes, as described above. PE2 42B forwards the traffic to PE1 42A (916) based on the ECMP next hop using a load balancing algorithm (such as round-robin). In some examples, in order to forward a given packet on a particular path of the ECMP, PE2 42B attaches the label included in the route of the path to the packet and outputs the packet to PE1 42A.

[0080] PE1 42A forwards the traffic to one or more CEs (eg, CE1 48A and / or CE2 48E) based on the packet label (918).

[0081] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuits, and any combination of these components. The term "processor" or "processing circuit" may generally refer to any of the foregoing logic circuits, alone or in combination with other logic circuits, or any other equivalent circuits. A control unit including hardware may also perform one or more techniques of the present disclosure.

[0082] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, processes, or components may be implemented together or separately as discrete but interoperable logical devices. Describing different features as processes or units is intended to emphasize different functional aspects and does not necessarily mean that these processes or units must be implemented by separate hardware or software components. Instead, the functions associated with one or more processes or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.

[0083] The techniques described in the present disclosure may also be implemented or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and temporary communication media. Tangible and non-transitory computer-readable storage media may include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, cassette, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, rather than a signal, carrier wave, or other transient medium.

Claims

1. A computing device for performing computer networking, the computing device comprising: a processing circuit having access to a memory configured with instructions which, when executed, cause the processing circuit to: storing a plurality of routes for a public address prefix of a virtual private network to a single virtual routing and forwarding instance of one or more virtual routing and forwarding instances of a network device configured for the network; as well as Each of the plurality of routes for the common address prefix having a different corresponding route distinguisher is output to a network router.

2. The computing device according to claim 1, wherein: The instructions cause the processing circuit to: configuring a plurality of routing discriminators for the single virtual routing and forwarding instance, Wherein, the different corresponding route distinguisher for each of the plurality of routes for the common address prefix is ​​extracted from the plurality of route distinguishers.

3. The computing device according to claim 2, wherein: To configure a plurality of routing distinguishers for the single virtual routing and forwarding instance, the instructions cause the processing circuit to provide a list including the plurality of routing distinguishers.

4. The computing device according to claim 2, wherein: To configure a plurality of routing distinguishers for the single virtual routing and forwarding instance, the instructions cause the processing circuitry to define a range of values ​​for the plurality of routing distinguishers.

5. The computing device according to claim 2, wherein: To configure a plurality of routing distinguishers for the single virtual routing and forwarding instance, the instructions cause the processing circuitry to specify a maximum number of routing distinguishers for the single virtual routing and forwarding instance.

6. The computing device according to claim 1, wherein: The instructions cause the processing circuit to execute a virtual router that functions as a provider edge device for the network.

7. The computing device according to claim 1, wherein: The computing device functions as a provider edge device for the network.

8. The computing device according to claim 1, wherein: The instructions cause the processing circuit to: receiving a packet forwarded to the computing device according to a first route of the plurality of routes; and The packet is forwarded to a next hop specified by the first route.

9. The computing device according to any one of claims 1 to 8, wherein: The computing device includes one of the network device and a network controller.

10. The computing device according to any one of claims 1 to 8, wherein: Each of the plurality of routes specifies a different next hop for the public address prefix, wherein the next hop is an interface of the computing device.

11. A computer networking method, comprising: storing, by the device, a plurality of routes for a public address prefix for a virtual private network to a single virtual routing and forwarding instance of one or more virtual routing and forwarding instances of a network device configured for the network; as well as Each of the plurality of routes for the common address prefix having a different corresponding route distinguisher is sent by the apparatus to a network router.

12. The computer networking method according to claim 11, further comprising: configuring a plurality of routing discriminators for the single virtual routing and forwarding instance, Wherein, the different corresponding route distinguisher for each of the plurality of routes for the common address prefix is ​​extracted from the plurality of route distinguishers.

13. The computer networking method according to claim 12, wherein: The configuring includes providing a list including the plurality of routing discriminators.

14. The computer networking method according to claim 12, wherein: The configuring includes defining ranges of values ​​for the plurality of routing discriminators.

15. The computer networking method according to claim 12, wherein: The configuring includes providing at least one predefined routing discriminator.

16. The computer networking method according to claim 11, wherein: The apparatus comprises the network device, and wherein the network device functions as a provider edge device for the network.

17. The computer networking method according to claim 11, further comprising: receiving a packet forwarded to the device according to a first route among the plurality of routes; and forwarding the packet to a next hop specified by the first route.

18. The computer networking method according to any one of claims 11 to 17, wherein: The device includes one of the network device and a network controller.

19. The computer networking method according to any one of claims 11 to 17, wherein: Each of the plurality of routes specifies a different next hop for the common address prefix, wherein the next hop is an interface of the device.

20. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to be configured to perform the method according to any one of claims 11 to 19, or to be configured as a computing device according to any one of claims 1 to 10.

Images