US-12621235-B2 - Network traffic transmission based on next-next-hop indication

Abstract

In some implementations, a network device may receive an indication of a next-next-hop of the network device and link quality information of the next-next-hop. The network device may transmit network traffic based on the indication of the next-next-hop and the link quality information of the next-next-hop.

Inventors

• Kevin Wang
• Manish Gupta

Assignees

• JUNIPER NETWORKS, INC.

Dates

Publication Date

20260505

Application Date

20231208

Claims (20)

1. 1 . A method, comprising: receiving, by a network device of a network, data including an indication of a next-next-hop of the network device and link quality information of the next-next-hop, wherein the received data does not include information associated with one or more hops that are beyond the next-next-hop, and wherein the next-next hop is associated with a hop of the network device after a next-hop of the network device; processing, by the network device, information related to the indication of the next-next-hop; transmitting, by the network device, network traffic based on the indication of the next-next-hop and the link quality information of the next-next-hop; refraining from, by the network device and based on processing the information related to the indication of the next-next-hop, propagating the indication of the next-next-hop to one or more other nodes of the network; and transmitting, by the network device and to one or more direct neighbor devices, another indication of another next-next-hop associated with the one or more direct neighbor devices, wherein there are no intervening nodes between the one or more direct neighbor devices and the network device.
2. 2 . The method of claim 1 , wherein receiving the indication of the next-next-hop includes receiving the indication of the next-next-hop via a non-link-state protocol.
3. 3 . The method of claim 2 , wherein the non-link-state protocol is a border gateway protocol (BGP).
4. 4 . The method of claim 3 , wherein the data is associated with a BGP update message that comprises the indication of the next-next-hop.
5. 5 . The method of claim 4 , wherein the indication of the next-next-hop is a BGP identifier in a next-next-hop nodes capability of the BGP update message.
6. 6 . The method of claim 4 , wherein the indication of the next-next-hop is an autonomous system (AS) number in an AS path attribute of the BGP update message.
7. 7 . The method of claim 1 , wherein the network device is in a Clos network.
8. 8 . The method of claim 1 , further comprising: determining the other indication of the other next-next-hop based on using a next-next-hop nodes (NNHN) capability in a next hop dependent capabilities attribute (NHC), wherein the other indication of the other next-next-hop is encoded as a capability type-length-value (TLV) in a next-hop dependent capabilities attribute (NHC).
9. 9 . A network device of a network, comprising: one or more memories; and one or more processors to: receive a border gateway protocol (BGP) update message that comprises an indication of a next-next-hop of the network device, wherein the BGP update message does not include information associated with one or more hops that are beyond the next-next hop, and wherein the next-next hop is associated with a hop of the network device after a next-hop of the network device; process information related to the indication of the next-next-hop; transmit network traffic based on the indication of the next-next-hop; refrain from, based on processing the information related to the indication of the next-next-hop, propagating the indication of the next-next-hop to one or more other nodes of the network; and transmit, to one or more direct neighbor devices that have no intervening nodes between the one or more direct neighbor devices and the network device, another indication of another next-next-hop associated with the one or more direct neighbor devices.
10. 10 . The network device of claim 9 , wherein the indication of the next-next-hop is a BGP identifier in a next-next-hop nodes capability of the BGP update message.
11. 11 . The network device of claim 10 , wherein the BGP update message is associated with an exterior BGP (eBGP) session.
12. 12 . The network device of claim 10 , wherein the next-next-hop nodes capability includes a plurality of BGP identifiers including the BGP identifier, and wherein the plurality of BGP identifiers correspond to a plurality of next-next-hops, including the next-next-hop, of the network device.
13. 13 . The network device of claim 10 , wherein the BGP update message further comprises an indication of the next-hop that is associated with the next-next-hop, and wherein the one or more processors, to transmit the network traffic, are to transmit the network traffic based on the next-hop being associated with the next-next-hop.
14. 14 . The network device of claim 9 , wherein the indication of the next-next-hop is an autonomous system (AS) number in an AS path attribute of the BGP update message.
15. 15 . The network device of claim 9 , wherein the information related to the indication of the next-next-hop is encoded as a capability type-length-value (TLV) in a next-hop dependent capabilities attribute (NHC).
16. 16 . The network device of claim 14 , wherein the network device is one of a plurality of network devices in a Clos network, and wherein each network device, of the plurality of network devices, is associated with an AS number that is unique within the Clos network.
17. 17 . A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a network device in a Clos network, cause the network device to: receive data including an indication of a next-next-hop of the network device and link quality information of the next-next-hop, wherein the received data does not include information associated with one or more hops that are beyond the next-next-hop, and wherein the next-next hop is associated with a hop of the network device after a next-hop of the network device; process information related to the indication of the next-next-hop; transmit network traffic based on the indication of the next-next-hop and the link quality information of the next-next-hop; refrain from, based on processing the information related to the indication of the next-next-hop, propagating the indication of the next-next-hop to one or more other nodes of the Clos network; and transmit, to one or more direct neighbor devices that have no intervening nodes between the one or more direct neighbor devices and the network device, another indication of another next-next-hop associated with the one or more direct neighbor devices.
18. 18 . The non-transitory computer-readable medium of claim 17 , wherein the one or more instructions, that cause the network device to receive the indication of the next-next-hop, cause the network device to: receive the indication of the next-next-hop via a non-link-state protocol.
19. 19 . The non-transitory computer-readable medium of claim 18 , wherein the non-link-state protocol is border gateway protocol (BGP).
20. 20 . The non-transitory computer-readable medium of claim 19 , wherein the one or more instructions, that cause the network device to receive the indication of the next-next-hop, cause the network device to: receive a BGP update message that includes the indication of the next-next-hop.

Description

CROSS-REFERENCE TO RELATED APPLICATION This Patent application claims priority to U.S. Provisional Patent Application No. 63/594,202, filed on Oct. 30, 2023, and entitled “BORDER GATEWAY PROTOCOL TOPOLOGY DISCOVERY FOR CLOS NETWORK GLOBAL LOAD BALANCING.” The disclosure of the prior Application is considered part of and is incorporated by reference into this Patent Application. BACKGROUND Network devices, such as routers, relay packets through a network from a source to a destination. When the network experiences congestion, the network devices may drop the packets, which may alleviate the congestion. Dropped packets are not received by the destination. SUMMARY Some implementations described herein relate to a method. The method may include receiving, by a network device, an indication of a next-next-hop of the network device and link quality information of the next-next-hop. The method may include transmitting, by the network device, network traffic based on the indication of the next-next-hop and the link quality information of the next-next-hop. Some implementations described herein relate to a network device. The network device may include one or more memories and one or more processors. The one or more processors may be to receive a border gateway protocol (BGP) update message that contains an indication of a next-next-hop of the network device. The one or more processors may be to transmit network traffic based on the indication of the next-next-hop. Some implementations described herein relate to a non-transitory computer-readable medium that stores a set of instructions. The set of instructions, when executed by one or more processors of a network device in a Clos network, may cause the network device in the Clos network to receive an indication of a next-next-hop of the network device and link quality information of the next-next-hop. The set of instructions, when executed by one or more processors of the network device in the Clos network, may cause the network device in the Clos network to transmit network traffic based on the indication of the next-next-hop and the link quality information of the next-next-hop. BRIEF DESCRIPTION OF THE DRAWINGS FIGS. 1A-1B are diagrams of an example implementation associated with network traffic transmission based on a next-next-hop indication. FIG. 2 is a diagram of an example implementation associated with a next-next-hop nodes (NNHN) capability of a BGP update message. FIG. 3 is a diagram of an example environment in which systems and/or methods described herein may be implemented. FIG. 4 is a diagram of example components of a device associated with network traffic transmission based on next-next-hop indication. FIG. 5 is a diagram of example components of a device associated with network traffic transmission based on next-next-hop indication. FIG. 6 is a flowchart of an example process associated with network traffic transmission based on next-next-hop indication. DETAILED DESCRIPTION The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Network devices (e.g., routers, switches, or the like) can forward packets along a route having multiple next-hops by hashing packet flows to the next-hops for load balancing purposes. For example, a network device can hash packet flows into different equal-cost multi-path (ECMP) links of a route. In datacenter (DC) fabric underlay routing, network devices can use exterior border gateway protocol (EBGP) hop-by-hop routing to route packet flows. For example, network devices can use hop-by-hop EBGP underlay routing in Clos networks. Congestion can increase packet loss and latency. For example, congestion can impact artificial intelligence (AI)/machine learning (ML) traffic, which may have strict loss and latency requirements (e.g., in accordance with service level agreements (SLAs) in a wide area network (WAN)). Uneven flow hashing can create congestion anywhere in a network fabric. For example, uneven flow hashing can create congestion in a Clos fabric, which may employ a spine-leaf architecture. If a link becomes congested due to uneven hashing, the network device for which the link is a next-hop link can use dynamic load balancing to adjust the hashing and thereby divert the packet flow(s) away from the link, which can mitigate the congestion. For example, in response to detecting congestion on a local ECMP link from a leaf node to a spine node, a leaf node may use dynamic load balancing to hash packet flows to alternate ECMP links on the leaf node, which may mitigate the congestion. In this example, the congestion is local to the leaf node because the congestion is on a next-hop link of the leaf node. Many instances of link congestions cannot be addressed using dynamic load balancing. For example, if all of the next-hop link(s) of a network device are congested, then dynamic load balanci