Search

US-12627594-B2 - Intelligent route distribution to avoid routing asymmetry during graceful restart in software-defined networks

US12627594B2US 12627594 B2US12627594 B2US 12627594B2US-12627594-B2

Abstract

Techniques for ensuring symmetric forwarding between disparate networks are described herein. In active/standby hub architectures, hub nodes may be configured to convert a preference order (e.g., indicating a preferred hub node), specified by an endpoint on a wide-area network (WAN)-side of a network, into a local-area network (LAN)-side-routing-metric that is distributed to datacenter router(s) on the LAN-side of the network. When an active hub node loses connection to all of the available routing controllers, the active hub may automatically manipulate the LAN-side-routing-metric to make the metric worse than the standby hub to indicate that the routes being advertised by the active hub are “stale,” such that the datacenter routers prefer the standby hub, avoiding traffic asymmetry as a result of the lost connection.

Inventors

  • Satish Kumar Mahadevan
  • Balaji Sundararajan
  • Basavaraju Halappa
  • Sourav Sen

Assignees

  • CISCO TECHNOLOGY, INC.

Dates

Publication Date
20260512
Application Date
20240423

Claims (20)

  1. 1 . A method comprising: receiving, at a first hub node that facilitates communications between a first network and a second network, a preference order associated with a route advertised by an edge node associated with the first network; determining, by the first hub node and based at least in part on the preference order, that the first hub node is a more preferred hub for the route than a second hub node that facilitates communications between the first network and the second network; converting, by the first hub node, the preference order into a first metric associated with an internet protocol (IP) routing protocol that is in use in the second network; distributing, by the first hub node, the route including the first metric to the second network such that the first hub node is the more preferred hub for return traffic of the route; determining, by the first hub node, that a connection between the first hub node and a network controller associated with the first hub node has been lost; adjusting, by the first hub node and based at least in part on determining that the connection between the first hub node and the network controller has been lost, the first metric to a second metric such that that the second hub node is preferred over the first hub node for return traffic of the route; and distributing, by the first hub node, the route including the second metric to the second network.
  2. 2 . The method of claim 1 , further comprising storing, by the hub node, an indication that the first hub node is the more preferred hub for the route, the indication stored by the first hub node as a protocol-independent cost metric in a routing information base (RIB).
  3. 3 . The method of claim 1 , further comprising: determining, by the first hub node, that the connection between the first hub node and the network controller has been reestablished; adjusting, by the first hub node and based at least in part on determining that the connection between the first hub node and the network controller has been reestablished, the second metric to the first metric such that the first hub node is preferred over the second hub node for return traffic of the route; and distributing, by the first hub node, the route including the first metric to the second network.
  4. 4 . The method of claim 1 , further comprising determining, by the first hub node, a preference number associated with the first hub node, wherein determining that the first hub node is the more preferred hub is further based at least in part on the preference number associated with the first hub node.
  5. 5 . The method of claim 4 , wherein determining that the first hub node is the more preferred hub comprises determining, by the first hub node, that the preference number associated with the first hub node ranks higher in the preference order than another preference number associated with the second hub node.
  6. 6 . The method of claim 1 , wherein the first network is a wide area network (WAN) and the second network is a local area network (LAN).
  7. 7 . The method of claim 1 , wherein the route and the preference order associated with the route is received from the network controller.
  8. 8 . A system associated with a hub node that facilitates communications between a first network and a second network, the system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the hub node to perform operations comprising: receiving a preference order associated with a route advertised by an edge node associated with the first network; determining, based at least in part on the preference order, that the hub node is a more preferred hub for the route than an additional hub node that facilitates communications between the first network and the second network; converting the preference order into a first metric associated with an internet protocol (IP) routing protocol that is in use in the second network; distributing the route including the first metric to the second network such that the hub node is the more preferred hub for return traffic of the route; determining that a connection between the hub node and a network controller associated with the first hub node has been lost; adjusting, by the hub node and based at least in part on determining that the connection between the hub node and the network controller has been lost, the first metric to a second metric such that that the additional hub node is preferred over the hub node for return traffic of the route; and distributing, by the hub node, the route including the second metric to the second network.
  9. 9 . The system of claim 8 , the operations further comprising storing an indication that the hub node is the more preferred hub for the route, the indication stored by the hub node as a protocol-independent cost metric in a routing information base (RIB).
  10. 10 . The system of claim 8 , wherein the IP routing protocol that is in use in the second network comprises at least one of External Border Gateway Protocol (EBGP), Internal Border Gateway Protocol (IBGP), or Open Shortest Path First (OSPF).
  11. 11 . The system of claim 8 , the operations further comprising determining a preference number associated with the hub node, wherein determining that the hub node is the more preferred hub is further based at least in part on the preference number associated with the hub node.
  12. 12 . The system of claim 11 , wherein determining that the hub node is the more preferred hub comprises determining that the preference number associated with the hub node ranks higher in the preference order than another preference number associated with the additional hub node.
  13. 13 . The system of claim 8 , wherein the first network is a wide area network (WAN) and the second network is a local area network (LAN).
  14. 14 . The system of claim 8 , the operations further comprising: determining, by the hub node, that the connection between the hub node and the network controller has been reestablished; adjusting, by the hub node and based at least in part on determining that the connection between the hub node and the network controller has been reestablished, the second metric to the first metric such that the hub node is preferred over the additional hub node for return traffic of the route; and distributing, by the hub node, the route including the first metric to the second network.
  15. 15 . One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations comprising: receiving, at a first hub node that facilitates communications between a first network and a second network, a preference order associated with a route advertised by an edge node associated with the first network; determining, by the first hub node and based at least in part on the preference order, that the first hub node is a more preferred hub for the route than a second hub node that facilitates communications between the first network and the second network; converting, by the first hub node, the preference order into a first metric associated with an internet protocol (IP) routing protocol that is in use in the second network; distributing, by the first hub node, the route including the first metric to the second network such that the first hub node is the more preferred hub for return traffic of the route; determining, by the first hub node, that a connection between the first hub node and a network controller associated with the first hub node has been lost; adjusting, by the first hub node and based at least in part on determining that the connection between the first hub node and the network controller has been lost, the first metric to a second metric such that that the second hub node is preferred over the first hub node for return traffic of the route; and distributing, by the first hub node, the route including the second metric to the second network.
  16. 16 . The one or more non-transitory computer-readable media of claim 15 , the operations further comprising storing an indication that the first hub node is the more preferred hub for the route, the indication stored as a protocol-independent cost metric in a routing information base (RIB).
  17. 17 . The one or more non-transitory computer-readable media of claim 15 , the operations further comprising determining a preference number associated with the first hub node, wherein determining that the first hub node is the more preferred hub is further based at least in part on the preference number associated with the first hub node.
  18. 18 . The one or more non-transitory computer-readable media of claim 17 , wherein determining that the first hub node is the more preferred hub comprises determining that the preference number associated with the first hub node ranks higher in the preference order than another preference number associated with the second hub node.
  19. 19 . The one or more non-transitory computer-readable media of claim 17 , wherein the first network is a wide area network (WAN) and the second network is a local area network (LAN).
  20. 20 . The one or more non-transitory computer-readable media of claim 17 , wherein the IP routing protocol that is in use in the second network comprises at least one of External Border Gateway Protocol (EBGP), Internal Border Gateway Protocol (IBGP), or Open Shortest Path First (OSPF).

Description

TECHNICAL FIELD The present disclosure relates generally to, among other things, techniques for resolving traffic asymmetry resulting from instable connection(s) between network devices and routing controllers. BACKGROUND In software-defined networks (SDNs), on-device stateful features such as Network Based Application Recognition, Security, Application Quality of Experience, and Network Address Translation require symmetric forwarding. Additionally, externally hosted services like firewalls and intrusion prevention/detection systems in the cloud, in private datacenters, or in point of presence locations can require symmetric forwarding. As such, symmetric forwarding solutions need to work in a wide variety of SDN scenarios/topologies. However, given the wide variety of use cases, the solutions that are currently utilized for symmetric forwarding have some disadvantages and may fall into an asymmetric routing pattern should a connection issue arise. For instance, an active hub and/or a standby hub may be leveraged to facilitate communications between two separate networks, where both networks prefer the active hub over the standby hub to maintain symmetric forwarding. Network controllers may be leveraged to advertise a first network's preferred hub to a second network to allow for symmetric forwarding. However, if the active hub loses connection to the network controller, the active hub may continue to advertise routes as the preferred hub, causing return traffic to be forwarded asymmetrical to the original traffic. This creates problems when stateful services, like firewalls, are deployed on the hubs and results in significant traffic loss creating an outage in the network. BRIEF DESCRIPTION OF THE DRAWINGS The detailed description is set forth below with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items. The systems depicted in the accompanying figures are not to scale and components within the figures may be depicted not to scale with each other. FIG. 1A illustrates a system-architecture diagram of an example environment and flow for performing the symmetric forwarding techniques disclosed herein in an example active/standby hub architecture. FIG. 1B illustrates another system-architecture diagram of an example environment and flow for performing the symmetric forwarding techniques disclosed herein in an example active/standby hub architecture. FIG. 1C illustrates another system-architecture diagram of an example environment and flow for performing the symmetric forwarding techniques disclosed herein in an example active/standby hub architecture. FIG. 2 illustrates a flow diagram of an example method for performing the symmetric forwarding techniques disclosed herein. FIG. 3 illustrates a block diagram illustrating an example packet switching system that can be utilized to implement various aspects of the technologies disclosed herein. FIG. 4 illustrates a block diagram illustrating certain components of an example node that can be utilized to implement various aspects of the technologies disclosed herein. FIG. 5 illustrates a computing system diagram illustrating a configuration for a data center that can be utilized to implement aspects of the technologies disclosed herein. FIG. 6 is a computer architecture diagram showing an illustrative computer hardware architecture for implementing a server device that can be utilized to implement aspects of the various technologies presented herein. DESCRIPTION OF EXAMPLE EMBODIMENTS Overview This disclosure describes method(s) to resolve traffic asymmetry resulting from instable connection(s) between network devices and routing controllers. The method may include receiving, at a first hub node that facilitates communications between a first network and a second network, a preference order associated with a route advertised by an edge node associated with the first network. Additionally, or alternatively, the method may include determining, by the first hub node and based at least in part on the preference order, that the first hub node is a more preferred hub for the route than a second hub node that facilitates communications between the first network and the second network. Additionally, or alternatively, the method may include converting, by the first hub node, the preference order into a first metric associated with an internet protocol (IP) routing protocol that is in use in the second network. Additionally, or alternatively, the method may include distributing, by the first hub node, the route including the first metric to the second network such that the first hub node is the more preferred hub for return traffic of the route. Additionally, or alternatively, the method may include determining, by the first hub node, that a connection between the f