EP3259886B1 - Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire - Google Patents

Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire Download PDF

Info

Publication number
EP3259886B1
EP3259886B1 EP16706723.0A EP16706723A EP3259886B1 EP 3259886 B1 EP3259886 B1 EP 3259886B1 EP 16706723 A EP16706723 A EP 16706723A EP 3259886 B1 EP3259886 B1 EP 3259886B1
Authority
EP
European Patent Office
Prior art keywords
cluster
paths
nodes
best path
cloud
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP16706723.0A
Other languages
German (de)
English (en)
Other versions
EP3259886A1 (fr
Inventor
Keyur Patel
Serpil Bayraktar
Manish Bhardwaj
David D. Ward
Burjiz Pithawala
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Publication of EP3259886A1 publication Critical patent/EP3259886A1/fr
Application granted granted Critical
Publication of EP3259886B1 publication Critical patent/EP3259886B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • This disclosure relates in general to the field of networking, and more particularly, to optimized Border Gateway Protocol (BGP) best path selection for Optimal Route Reflection (ORR) in a network environment.
  • BGP Border Gateway Protocol
  • ORR Optimal Route Reflection
  • Routers may be used in an autonomous system (AS) to determine a node to which network traffic propagating through the autonomous system should be forwarded. Routers communicate with other routers within the autonomous system to determine the best paths through the autonomous system to reach a destination address.
  • AS autonomous system
  • Routers communicate with other routers within the autonomous system to determine the best paths through the autonomous system to reach a destination address.
  • Various protocols may be used including Border Gateway Protocol (BGP), which is used for routing between autonomous systems, and Internal Border Gateway Protocol (iBGP), which is used for routing between routers in the same autonomous system to external destinations.
  • An Interior Gateway Protocol (IGP) is used for routing inside an autonomous system to internal destinations.
  • Hot potato routing packets are not stored (or buffered), but are constantly transferred in an attempt to move the packets to their final destination. Hot potato routing attempts to direct traffic to the closest autonomous system (AS) egress points within a given BGP network.
  • An egress point is an exit point (e.g., a point of presence (POP) or an edge router) of the autonomous system that may be used to reach an external destination node.
  • POP point of presence
  • edge router the choice of an exit point for a route reflector and its clients will be the egress point closest to the route reflector and not necessarily its clients.
  • BGP Optimal Route Reflection (BGP-ORR)" draft-ietf-idr-bgp-optimal-route-reflection-08 by R. Raszuk, C. Cassar, E. Aman, B. Decraene, and S. Litkowski, dated 22 October 2014 , discloses proposals to facilitate the application of closest exit point policy centralised route reflection deployments. This document concerns implementing BGP route reflection by calculating best path routes from the perspective of a client of the route reflector.
  • EP1737168A1 comprises a method of using a Routing Control Platform involving obtaining IGP topology information, determining available BGP routes associated with a routing entity, and sending a customised routing decision to the routing entity.
  • the present disclosure describes an optimized Border Gateway Protocol (BGP) best path selection for optimal route reflection.
  • BGP Border Gateway Protocol
  • a method is provided in one example of the present disclosure and includes configuring, by a cloud-based node, a first cluster of nodes in an autonomous system. The method also includes determining whether any paths for a network address prefix are available in the first cluster of nodes. The method further includes selecting a best path from one or more paths if the one or more paths are determined to be available in the first cluster for the network address prefix. The method yet further includes advertising the best path to one or more nodes in the first cluster.
  • BGP Border Gateway Protocol
  • the cloud-based node may be a route reflector.
  • the one or more paths may be determined to be available in the first cluster based on reachability information received by the cloud-based node from one or more edge nodes in the first cluster. Further specific embodiments can include determining, if no paths for the network address prefix are available in the first cluster, another path for the network address prefix is available in a second cluster of nodes of the autonomous system, and selecting the other path as the best path.
  • the method can include determining, if no paths for the network address prefix are available in the first cluster, two or more other paths for the network address prefix are available in at least a second cluster of nodes of the autonomous system, and selecting the best path from the two or more other paths based, at least in part, on a comparison of metrics for the two or more other paths.
  • the metrics may include one of a cost or a distance of each of the two or more other paths.
  • the method may also include extracting the metrics from one or more protocol messages of an interior gateway protocol (IGP).
  • IGP interior gateway protocol
  • one or more border gateway protocol (BGP) sessions can be used by the cloud-based node to advertise the best path to the one or more nodes in the first cluster of nodes.
  • the cloud-based node may be a virtualized route reflector in a cloud network.
  • the best path may be selected from the one or more paths based on policy if the one or more paths include two or more paths.
  • the best path may not be advertised to any node in the first cluster that advertised, to the cloud-based node, reachability information for the network address prefix.
  • a more specific embodiment can include identifying the nodes of the first cluster as clients of the cloud-based route reflector before the first cluster is configured.
  • Some or all of the elements, operations, and features may be included in respective systems, apparatuses, and devices for performing the described functionality. Furthermore, some or all of the features may be implemented in at least one machine readable storage medium.
  • FIGURE 1 is a simplified block diagram of a network environment 110 including a communication system 100 for providing optimized best path selection for optimal route reflection in an autonomous system AS1.
  • Network environment 110 represents a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through the network.
  • Network environment 110 offers a communicative interface between nodes, and may include any local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), Intranet, Extranet, wide area network (WAN) such as the Internet, cloud network, virtual private network (VPN), or any other appropriate architecture or system that facilitates communications in the network environment.
  • LAN local area network
  • WLAN wireless local area network
  • MAN metropolitan area network
  • Intranet Intranet
  • Extranet wide area network
  • WAN wide area network
  • VPN virtual private network
  • network environment 110 may implement a UDP/IP connection and use a TCP/IP communication language protocol in particular embodiments of the present disclosure.
  • Network environment 110 illustrates distributed nodes 20, 30, and 50 being interconnected via communication links 12.
  • Nodes 50 are provisioned in autonomous system AS1 and node 20 is provisioned in an autonomous system AS2.
  • Autonomous systems AS1 and AS2 may be configured as distinct routing domains.
  • Nodes 50 and 20 are network elements, such as routers, that can offer intra-domain routing for electronic data between end nodes 25 within their respective autonomous systems AS1 and AS2. At least some of nodes 20 and 50 can provide inter-domain routing for electronic data between end nodes 25 in autonomous system AS1 and other end nodes 25 in autonomous system AS2.
  • Node 30 is network element, such as a router, and may be provisioned in cloud network 15 as a cloud-based route reflector for AS1.
  • cloud network 15 may be physically remote from autonomous system AS1 and may be accessible over the Internet or other wide area network.
  • Node 30 may be part of the same routing domain as autonomous system AS1. Node 30 cooperates with nodes 50 to enable cloud-based route reflection with optimized best path selection.
  • End nodes 25 are intended to include devices used to initiate a communication in network environment 110, such as desktops, laptops, servers, appliances, mobile devices, or any other device, component, element, or object capable of initiating voice, audio, video, media, or data exchanges within network environment 110. End nodes can also include any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within network environment 110. It should be noted that FIGURE 1 is a representation of possible elements of a communication system for providing cloud-based optimal route reflection with optimized best path selection in an autonomous system. As such, any number of links 12, nodes 20, 30, and 50, and end nodes 25 may be configured in a communication system. For example, some autonomous systems may contain thousands of nodes 50 and an even greater number of end nodes 25 and links 12.
  • Border Gateway Protocol is an example routing protocol that enables inter-domain routing between autonomous systems.
  • An external BGP (eBGP) session provides routing information for routes that allow an autonomous system to reach other autonomous systems.
  • An internal BGP (iBGP) session provides routing information for routes inside an autonomous system to external destinations.
  • BGP is a well known routing protocol defined in Request for Comments (RFC) 4271, by Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, http://www.rfc-editor.org/info/rfc4271 .
  • a BGP session can be established when BGP neighbor routers (also referred to herein as 'peer nodes') establish a connection in order to 'speak BGP'.
  • This connection is typically established using a connection-oriented protocol such as Transmission Control Protocol (TCP), which ensures delivery of messages between the connected peer nodes.
  • TCP Transmission Control Protocol
  • the connected peer nodes can speak BGP to exchange update messages containing routing information.
  • Update messages are used to update information contained in a routing information base (RIB) of the receiving peer node.
  • An update message can announce a new route or withdraw a previously announced route.
  • Update messages can include various fields such as network layer reachability information (NLRI).
  • NLRI may include Internet Protocol (IP) address prefixes of feasible routes being advertised in the update message.
  • IP Internet Protocol
  • a field for withdrawn routes may include IP address prefixes for routes being withdrawn because they are no longer reachable.
  • a route is a unit of information that pairs a set of destinations with attributes of a path to those destinations.
  • a path can be defined by one or more attributes and is generally intended to mean the route between two points in a network, such as an autonomous system.
  • IP addresses taken from an IPv4 or IPv6 pool can be divided into two parts including a network section and a host section. The network section identifies a set of destinations and is referred to as the prefix.
  • a prefix in a destination address is used by a routing protocol to render a routing decision for the next hop in the path.
  • a prefix may also be referred to as a 'routing prefix'.
  • An autonomous system can use iBGP to advertise reachability information for network address prefixes of destinations (e.g., routers) outside the autonomous system.
  • destinations e.g., routers
  • iBGP To implement iBGP, however, a full mesh is required in which every router within the autonomous system is connected to every other router via a connection such as TCP. This full mesh requirement can severely limit scalability of an autonomous system running iBGP sessions.
  • Route reflection is often desirable because a full mesh implementation can be avoided. Route reflector deployments can result in a significant reduction of the number of iBGP sessions needed in the network. Route reflection is a well-known routing protocol defined in Requests for Comment (RFC) 4456, Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, http://www.rfc-editor.org/info/rfc4457 .
  • RFC 4456 Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, http://www.rfc-editor.org/info/rfc4457 .
  • a route reflector is a network element used in a BGP network to implement route reflection.
  • one or more routers are designated as route reflectors and are allowed to accept and propagate iBGP routes to their clients.
  • the designated route reflectors can be fully meshed with iBGP peering sessions between the route reflectors.
  • Each route reflector can peer with multiple routers, which may be referred to herein as route reflector clients ('RR-clients') or clients.
  • the clients of each route reflector form a cluster of routers to which the route reflector is connected.
  • a cluster of routers can be connected via iBGP through their shared route reflector.
  • a route reflector can propagate the routing information it receives from other route reflectors to its client routers, and can propagate routing information for its client routers to other route reflectors.
  • the number of sessions needed in a BGP network can be greatly reduced.
  • a router In hot potato routing, a router (e.g., route reflector) attempts to render a best path routing decision that directs network traffic to an autonomous system (AS) egress point, within a given BGP network, that is closest to the router rendering the decision.
  • AS autonomous system
  • a route reflector selects the best path based on an interior gateway protocol (IGP) metric computed from its IGP database and announces this path to its client BGP speakers.
  • IGP interior gateway protocol
  • a metric is the quantitative value used to measure the distance to a given network. For hot potato routing, the best path to a network is the path with the lowest metric.
  • a route reflector may be embodied as any type of router, including a border or edge router deployed on the perimeter of an autonomous system or as a distributed router in a cloud network, for example.
  • route reflectors are usually located in the forwarding path within a cluster (e.g., at the point of presence (POP) boundaries) and stay congruent with the actual topology of the network, virtual route reflectors (vRRs) and possibly other route reflectors may be placed outside of clusters.
  • vRRs virtual route reflectors
  • ring topologies make it difficult to form route reflector clusters naturally, and tunneled applications, such as Layer 3 Virtual Private Networks (L3VPNs), do not necessarily need route reflectors to be in the forwarding path.
  • distributed route reflectors may serve as path aggregation points on the network in order to reduce distribution of BGP information to edge routers that may have limited CPU and memory.
  • Route reflectors that are not in an optimal forwarding path, or that are placed in such a way in the network that is not congruent with the topology of the network can lose their ability to advertise a best path to achieve hot potato routing to their clients. Because the choice of an exit point for a route reflector and its clients is the egress point closest to the route reflector, in BGP route reflector deployments where route reflectors are not in a forwarding path, the chosen egress point may not necessarily be the closest egress point to the route reflector clients (RR-clients).
  • route reflectors may not be the best path (e.g., with optimal metrics) to the destination.
  • deployment of route reflectors may be constrained to appropriate cluster boundaries or at an appropriate central location that facilitates optimum hot potato routing.
  • BGP-ORR BGP Optimal Route Reflection
  • BGP-ORR requires route reflectors (RRs) to associate their RR-clients with an optimal route reflector (ORR) root address as part of BGP-ORR functionality.
  • An ORR root address is an address in the network where IGP SPFs (Interior Gateway Protocol Shortest Paths First) are rooted to compute Shortest Path First (SPF) topology.
  • IGP SPFs Interior Gateway Protocol Shortest Paths First
  • SPF Shortest Path First
  • BGP-ORR is a routing protocol defined in Inter-Domain Routing Working Group Internet Draft, by Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S.
  • BGP-ORR BGP Optimal Route Reflection
  • route reflectors may do the following: 1) store an IGP database as if it was rooted on the RR-clients, and 2) run a best path algorithm multiple times, once per each client. Storing the IGP database as if it was rooted on the RR-clients may require significant memory and CPU resources. Running the best path algorithm for each individual client may also utilize significant CPU resources. As a network scales upwardly, this can become even more problematic.
  • At least one embodiment of the present disclosure can resolve aforementioned issues (and more) associated with determining and selecting a best path in autonomous systems that are partitioned into multiple clusters with their own IGP domains.
  • Embodiments in the present disclosure may be provided in a network running BGP-ORR, in which route reflection is implemented in a virtual or physical router in a cloud network.
  • a cloud-based route reflector of the present disclosure can identify clusters within the autonomous system and can run best path computations once per each cluster.
  • IGP metric values can be stored in a cluster/RR-client based storage such as a database or routing information base (RIB) table of the cloud-based route reflector. The best path computations may be performed using the appropriate database or RIB table.
  • RIB routing information base
  • cloud-based route reflectors automatically prefer intra-cluster client paths over inter-cluster paths, which may be represented as eBGP>intracluster>intercluster.
  • inter-cluster paths may be represented as eBGP>intracluster>intercluster.
  • LSAs inter-area link state advertisements
  • ABRs area border routers
  • BGP route advertisement may be configured to advertise to clients in a cluster the best path computed for a given cluster.
  • a cloud-based route reflector that identifies clusters within an autonomous system and computes best paths per cluster.
  • implementation of a route reflector in a cloud facilitates quick deployment.
  • the use of memory and CPU resources on cloud-based route reflectors can be reduced, and the system can be more easily scaled.
  • such a solution avoids the need to alter existing deployments of route reflectors.
  • Existing route reflectors (deployed in the cloud or not) can serve as optimal route reflectors for multiple clusters rather than a single cluster of which it is a member.
  • FIGURE 2 is a simplified block diagram of possible embodiments of node 30 and nodes 50, as shown in FIGURE 1 .
  • Nodes 30 and 50 may include, respectively, multiple network interfaces 35 and 55, at least one memory element 37 and 57, and at least one processor 39 and 59.
  • Processors 39 and 59 may be operably coupled to respective network interfaces 35 and 55, which include suitable transmitting and receiving components for communicating over communication links 12 in network environment 110.
  • nodes 30 and/or 50 may be implemented in physical or virtualized environments or a suitable combination thereof.
  • Border gateway protocol optimized route reflector (BGP-ORR) 60 with optimized best path selection logic 62 can be implemented in node 30.
  • Border gateway protocol (BGP) 65 can be implemented in node 50.
  • Interior gateway protocol (IGP) 70 can be implemented in nodes 30 and 50.
  • BGP communications may be transmitted and received between node 30 and its clients (e.g., node 50) via a transmission protocol such as TCP/IP.
  • BGP-ORR 60 of node 30 also includes optimized best path selection logic 62 for computing best paths through autonomous system AS1 to reach external destinations such as autonomous system AS2.
  • a network connection can be established between node 50 and node 30 to speak BGP and exchange routing information that can be used to route data from internal nodes of autonomous system AS1 to external destinations.
  • Data associated with embodiments described herein may be stored in memory elements 37 and 57 of nodes 30 and 50, respectively, in at least one embodiment.
  • the data may include, but is not limited to, a cluster routing table 80.
  • Cluster routing table 80 can include IGP metrics (e.g., a cost) for each BGP next hop, which can be measured from designated nodes referred to as 'root nodes'.
  • cluster routing table 80 (or some other suitable storage structure) may include reachability information for network address prefixes advertised by clients of node 30.
  • cluster routing table 80 may be implemented as a routing information base (RIB) table, which can include routing information for all routing protocols running in communication system 100.
  • RDB routing information base
  • stored data may include a local routing table 51 that includes routing information to enable node 50 to route network traffic within autonomous system AS1 and possibly to external destinations.
  • local routing table 51 may contain best path information for network address prefixes, after the best paths are selected and advertised by node 30.
  • Contents of local routing table 51 can depend, at least in part, on its location within autonomous system AS1. For example, routing information may vary based on a cluster of routers to which a node is assigned. A best path for a particular prefix stored in a router of one cluster may vary with respect to a best path for the same prefix stored in another router of another cluster in the same autonomous system.
  • FIGURE 3 is a block diagram illustrating a possible configuration of a communication system 300 for providing optimized best path selection for optimal route reflection in an autonomous system.
  • Nodes in the autonomous system are partitioned into two clusters 380 (e.g., cluster A and cluster B).
  • the nodes in cluster A include an area border router 350 (e.g., ABR1) and edge routers 355 (e.g., ER1 and ER2).
  • the nodes in cluster B include another area border router 350 (e.g., ABR2) and other edge routers 355 (e.g., ER3 and ER4).
  • Edge routers 355 may represent autonomous system border routers (ASBRs), customer edge routers (CEs), provider edge routers (PEs), and any other node provisioned at an edge, or perimeter, of the autonomous system that can participate in BGP sessions with cloud-based route reflector 330 (e.g., CBRR) in cloud network 315.
  • ASBRs autonomous system border routers
  • CEs customer edge routers
  • PEs provider edge routers
  • CBRR cloud-based route reflector 330
  • Other nodes may also be provisioned in the clusters.
  • Area border routers ABR1 and ABR2 represent routers located near a border of one or more areas of an Interior Gateway Protocol (IGP).
  • IGPs are routing protocols for exchanging routing information between routers within an autonomous system for internal destinations. Examples of IGP include Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS).
  • OSPF Open Shortest Path First
  • IS-IS Intermediate System-to-Intermediate System
  • each cluster may have its own IGP domain (e.g., an area for OSPF or a level for IS-IS).
  • an area/level of an IGP is a routing group of an autonomous system that can be smaller than the autonomous system.
  • IGP routing groups correspond to clusters of communication system 300. In other implementations, however, clusters may not have one-to-one correspondence with routing groups.
  • ABR1 and ABR2 can each provide an ingress and egress point for network traffic flowing to nodes within their respective routing groups or flowing from their respective routing groups to nodes in other routing groups within the autonomous system.
  • IGP may have a single flat area.
  • clusters A and B correspond to distinct IGP areas.
  • ABR1 and ABR2 can perform data path forwarding between clusters A and B in this example.
  • IGP neighbors may form an adjacency to exchange routing protocol packets.
  • a routing protocol packet communicated by a router can contain the router's local routing topology including, for example, a router ID, the router's IP address, links to other routers within the router's area, and route metrics for each of the links.
  • Link state advertisements (LSAs) and link state packets (LSPs) are routing protocol packets that are used to communicate in OSPF and IS-IS, respectively.
  • embodiments described herein generally refer to 'link state advertisements' (or 'LSAs') and 'areas', which are used in OSPF.
  • routing protocol packets are referred to as 'link state packets' (or 'LSPs'), and routing groups are referred to as 'levels'.
  • each router has its own unique router ID.
  • OSPF can set a router ID by configuring an IP address on a loopback interface of the router.
  • the router ID (or system ID) can be configured by an administrator in various suitable ways (e.g., IP address of loopback interface, Media Access Control (MAC) address, sequential numbering, etc.).
  • MAC Media Access Control
  • Cloud-based route reflector (CBRR) 330 includes route reflection capabilities. Edge routers ER1, ER2, ER3, and ER4 and area border routers ABR1 and ABR2 are clients of CBRR 330. CBRR 330 may be a virtualized or physical router in cloud network 315. CBRR 330 is not in the forwarding path of the autonomous system and therefore, can run BGP-ORR 60 with optimized best path selection logic 62 and be configured to receive and send control plane information only.
  • IGP can advertise router information to CBRR 330 for each node in the autonomous system (e.g., ABR1, ABR2, ER1, ER2, ER3, and ER4).
  • CBRR 330 can identify ER1, ER2, and ABR1 as clients and can group them in cluster A.
  • CBRR 330 can identify ER3, ER4, and ABR2 as clients and can group them in cluster B.
  • Various approaches may be utilized to group the nodes into clusters including, for example, manually configuring the clusters or using information from existing protocols (e.g., BGP, IGP) to identify clients and group the clients into clusters.
  • a cluster identifier which is a BGP attribute, may be used by CBRR 330 to determine which nodes are in the same cluster.
  • clusters can correspond to IGP areas (or levels) and thus, clusters can be configured based on an IGP area membership. In yet further embodiments, clusters may be manually configured.
  • edge routers ER1, ER2, ER3, ER4, and area border routers ABR1 and ABR2 are clients of CBRR 330 and each one can establish a connection or BGP session 316 (e.g., TCP connection) with CBRR 330 in order to speak BGP.
  • BGP sessions 316 edge nodes ER1-ER4 can provide update messages to CBRR 330 to advertise network layer reachability information (NLRI).
  • NLRI advertised by ER1 for example, can include IP prefixes of network addresses to which ER1 can route network traffic it receives.
  • Other routers within clusters A and B that are not edge routers may also establish BGP sessions with CBRR and send update messages. These interior routers, however, may not advertise reachability to any external destinations.
  • multiple edge nodes can advertise routes for the same prefix. In this scenario, CBRR 330 can see multiple paths to the prefix.
  • CBRR 330 selects a best path per cluster in the autonomous system.
  • the selected best paths may vary between clusters.
  • CBRR 3300 can advertise a best path selected for a cluster to clients within that cluster.
  • the clients receiving the advertisement can use the best path information to route traffic toward external destinations associated with the prefix.
  • a best path selected for clients in cluster A to reach network address prefix 1.1.1.1/24 can be advertised by CBRR 330 in BGP sessions established with clients (e.g., ER1, ER2, ABR1) in cluster A.
  • the clients in cluster A can use the best path information to route traffic toward external destinations associated with the 1.1.1.1/24 network address prefix.
  • CBRR 330 when selecting a best path for a particular cluster, can automatically prefer a path within the cluster (i.e., intra-cluster path) over paths associated with other clusters (i.e., inter-cluster path). If more than one intra-cluster path has been advertised, then CBRR 330 can use any suitable tie-breaking policies including, but not limited to selecting a best path based on IGP metric comparisons, selecting a best path associated with a lowest (or highest) edge router identifier (ID), or selecting a best path based on parameters of the edge routers (e.g., CPU load, capacity, etc.).
  • CBRR 330 may compare inter-cluster paths for the prefix, which are advertised by edge nodes in other clusters.
  • CBRR 330 can use IGP metrics (e.g., cost) carried in IGP advertisements for the comparison.
  • IGP metrics e.g., cost
  • a link-state advertisement (LSA) originated by an edge node and sent to CBRR 330 can include the cost of a path being advertised. This cost may be injected in the LSA by an area border router of the cluster before the LSA is forwarded to CBRR 330.
  • the edge node and area border router may be grouped as a different cluster than the particular cluster for which CBRR 330 is attempting to find a best path for the prefix. It should be noted that, in at least some embodiments, a cost of reaching ABRs from CBRR 330 is not considered when comparing the cost of available inter-cluster paths.
  • FIGURE 4 is a simplified block diagram illustrating additional elements and clusters of communication system 300.
  • communication system 300 may further include additional nodes partitioned in a third cluster 380 (e.g., cluster C).
  • Cluster C includes an area border router 350 (e.g., ABR3) and edge routers 355 (e.g., ER5 and ER6).
  • Other nodes (not shown), such as interior routers, may also be provisioned in cluster C.
  • Communication system 300 may further include a node embodied as a router 357 (e.g., R1) between cloud-based route reflector (CBRR) 330 and ABR1.
  • CBRR cloud-based route reflector
  • cluster routing table 395 which can be maintained by CBRR 330.
  • cluster routing table 395 is configured as a routing information base (RIB) and may include routing information associated with prefixes of external network addresses. This routing information can be advertised by edge nodes ER1-ER6 in communication system 300.
  • Cluster routing table 395 can include the routing information per cluster for every cluster in the autonomous system.
  • Routing information in cluster routing table 395 may include, but is not limited to, router IDs and IGP metrics (e.g., cost, distance) that enable optimum path selection for clients (e.g., ER1-ER6) of CBRR 330.
  • the IGP metrics stored in cluster routing table 395 may be measured from a root node of a cluster (e.g., ABR1, ABR2, ABR3) to a client within the cluster (e.g., ER1-ER6).
  • Example IGP costs for each hop between nodes in communication system 300 are indicated at 390.
  • IGP next hop costs 390 are used to calculate IGP costs that are stored in cluster routing table 395.
  • the costs from ABR1 to ER1 and to ER2 is 1 each, because each path traverses one hop having a cost of 1.
  • the costs from ABR1 to ER3 and to ER4 are 2 each, because each path traverses two hops and each hop has a cost of 1.
  • the costs from ABR1 to ER5 and to ER6 are 3 each, because each path traverses two hops, where one hop has a cost of 1 and the other hop has a cost of 2.
  • IGP metrics may be considered in at least some scenarios.
  • a tie-breaking policy that indicates which path to select may be based on IGP metrics.
  • One possible policy could require the path with the lowest IGP metric to be selected.
  • each edge router within a cluster has the same cost.
  • another tie-breaking policy may be used in this scenario (e.g., lowest/highest router ID, parameters of the edge routers, etc.).
  • inter-cluster paths may be compared to determine which path offers the lowest cost. For example, assume ER3 and ER5 advertise the same network address prefix to CBRR 330.
  • a best path computation can include comparing the routes of ER3 and ER5 from the perspective of the root node ABR1 of cluster A. The best path computation can indicate that ER3 has a cost of 2 from ABR1, while E5 has a cost of 3 from ABR1. Accordingly, E3 may be selected as the best path for the network address prefix.
  • FIGURE 5 is a flowchart of a possible flow 500 of operations that may be associated with embodiments described herein.
  • one or more sets of operations correspond to activities of FIGURE 5 .
  • a cloud-based route reflector (e.g., 30, 330, 430) may utilize the one or more sets of operations.
  • the cloud-based route reflector may comprise means, such as at least one processor (e.g., 39), for performing the operations.
  • at least some operations of flow 500 may be performed by optimized best path selection logic (e.g., 62) of a border gateway protocol optimized route reflector (e.g., 60) in the cloud-based route reflector.
  • a cloud-based route reflector receives reachability information from clients (e.g., edge routers, interior routers) in an autonomous system.
  • this reachability information can be received in the form of update messages in BGP sessions established between CBRR and each of the clients.
  • the update messages can advertise Internet Protocol (IP) address prefixes of feasible routes being advertised in the update message.
  • IP Internet Protocol
  • CBRR can identify its clients in the autonomous system including the edge nodes and area border routers, for example.
  • CBRR can group the identified clients into clusters. This cluster grouping may be done manually or automatically based on information received in existing protocols including, for example, a cluster identifier, which is a BGP attribute, and may be used by CBRR 330 to determine which nodes are in the same cluster.
  • Edge nodes and area border routers are both BGP nodes and share the same cluster ID if they are in the same cluster.
  • clusters may correspond to areas (or levels) of IGP.
  • clusters may be manually configured.
  • Subsequent operations shown in FIGURE 5 may be performed for a particular cluster and a particular network address prefix. However, such operations may be repeated to select a best path for each possible network address prefix for each cluster.
  • CBRR determines whether intra-cluster paths for a network address prefix are available in the cluster. To make this determination, reachability information from BGP update messages can be evaluated to determine whether any clients (e.g., edge routers) in the cluster have advertised a path for the network address prefix.
  • CBRR may determine whether inter-cluster paths for the network address prefix are available in other clusters. To make this determination, reachability information from BGP update messages can be evaluated to determine whether any clients (e.g., edge routers) in other clusters have advertised a path for the network address prefix.
  • clients e.g., edge routers
  • CBRR can advertise the best path to each client in the cluster.
  • the advertisement can also include the network address prefix associated with the best path. In at least some embodiments, however, if the selected best path is an intra-cluster path, CBRR may not advertise the selected best path to the client from which it received the path.
  • best paths may be re-evaluated in some scenarios.
  • an update message from a client could include an IP address prefix being withdrawn because a route is deemed no longer reachable.
  • any best path selections for the withdrawn IP address prefix may be recomputed to select a new valid (i.e., available) best path.
  • an update message from a client could include a new IP address prefix because a route is now deemed reachable by the client. If the client is grouped in a cluster that currently uses an inter-cluster path as a best path, then the best path selection for the cluster may be recomputed to select the new intra-cluster path to be used by the nodes in the cluster.
  • FIGURE 6 is a block diagram illustrating another possible configuration of a communication system 600 for optimized best path selection in an autonomous system.
  • Communication system 600 includes cloud-based virtualized route reflectors 630, area border routers 650, and provider edge routers 650. More particularly, communication system 600 includes cloud-based virtualized route reflector 1 (VRR1), a cloud-based virtualized route reflector 2 (VRR2), a provider edge router 1 (PE1), a provider edge router 2 (PE2), a provider edge router 3 (PE3), a provider edge router 4 (Pe4), a provider edge router 5 (PE5), a provider edge router 6 (PE6), an area border router 1 (ABR1), and an area border router 2 (ABR2).
  • VRR1 cloud-based virtualized route reflector 1
  • PE2 cloud-based virtualized route reflector 2
  • PE1 provider edge router 1
  • PE2 provider edge router 2
  • PE3 provider edge router 3
  • Pe4 provider edge router 4
  • PE5 provider edge router 5
  • PE6 provider edge
  • each of the two clusters, cluster 1 and cluster 2 may have its own IGP area.
  • VRR1 includes PE1, PE2, PE3, and ABR1 as its clients.
  • VRR2 includes Pe4, Pe5, Pe6, and ABR2 as its clients.
  • VRR1 and VRR2 run internal Border Gateway Protocol (iBGP) peering between them, without clients.
  • iBGP Border Gateway Protocol
  • VRR1 and VRR2 can be virtual route reflectors running BGP-ORR with optimized best path selection logic, as they are not in the forwarding path.
  • VRR1 and VRR2 may run on a Linux based platform.
  • ABR1 and ABR2 perform actual data path forwarding between clusters 1 and 2.
  • VRR1 may perform several functions in accordance with at least one embodiment.
  • First, VRR1 can identify PE1, PE2, PE3 and ABR1 as its clients and group them under a same policy (e.g., a cluster).
  • the comparison can use the IGP cost of inter-area subnet Link State Advertisements (LSAs) injected by ABRs of respective clusters and ABR1.
  • LSAs inter-area subnet Link State Advertisements
  • VRR1 can decide the best path for its clients based on this comparison.
  • the iBGP VRRs can include VRR2 and any other VRRs in other clusters.
  • the IGP cost of inter-area LSAs may be injected by ABR1 and ABR2.
  • VRR1 can receive an inter-area LSA from ABR1 for PE4, PE5, and PE6.
  • VRR1 can get the metric cost carried within the inter-area LSA (computed by ABR1) as an IGP metric cost (without adding the cost to reach ABR1) of a next hop of an inter-cluster path. Based on this information, VRR1 can decide the best path.
  • the concepts presented herein may be implemented using Open Shortest Path First (OSPF) as an interior gateway protocol (IGP) within clusters.
  • OSPF is an IGP for Internet Protocol (IP) networks based on the shortest path first on link state advertisement (LSA).
  • OSPF peering between VRR1 and ABR1 can also be implemented.
  • An OSPF downbit extension may be enabled, in at least one embodiment depending on the particular needs, to prevent leaking of inter-area LSAs.
  • the concepts presented herein may be implemented using Intermediate System to Intermediate System (IS-IS), or any other suitable interior gateway protocol.
  • IS-IS peering or BGP-Link State (BGP-LS) peering may be used.
  • BGP-LS is a set of simple extensions to advertise topology information.
  • 'network traffic' or 'traffic' Communications in a network environment are referred to herein as 'network traffic' or 'traffic', which may be inclusive of packets.
  • a packet is a formatted unit of data, and can contain both control information (e.g., source and destination addresses, etc.) and data, which is also known as payload.
  • Network traffic can be sent and received according to any suitable communication messaging protocols. Suitable communication messaging protocols can include a multi-layered scheme such as Open Systems Interconnection (OSI) model, or any derivations or variants thereof (e.g., transmission control protocol/IP (TCP/IP), user datagram protocol/IP (UDP/IP), etc.).
  • OSI Open Systems Interconnection
  • 'data' refers to any type of binary, numeric, voice, video, textual, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another in electronic devices and/or networks. Additionally, advertisements, messages, requests, responses, replies, queries, etc. are forms of network traffic, and therefore, may comprise packets.
  • network element is meant to encompass any of the aforementioned elements, as well as routers, switches, wireless access points (WAPs), gateways, bridges, loadbalancers, appliances, firewalls, servers, processors, modules (any of which may be physical or virtually implemented on physical hardware) or any other suitable device, component, element, proprietary appliance, or object that is operable to exchange information in a network environment.
  • a network element may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.
  • nodes with optimized best path selection capabilities include logic to achieve (or to foster) the activities as outlined herein.
  • each of these elements can have an internal structure (e.g., processors, memory elements, network interface cards, etc.) to facilitate some of the operations described herein.
  • these activities for selecting a best path may be executed externally to these elements, or included in some other network element to achieve this intended functionality.
  • these nodes may include logic (or reciprocating logic) that can coordinate with other network elements in order to achieve the operations, as outlined herein.
  • one or several devices may include any suitable algorithms, hardware, firmware, software, components, modules, interfaces, or objects that facilitate the operations thereof.
  • the optimized best path selection functions outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an application specific integrated circuit (ASIC), digital signal processor (DSP) instructions, software (potentially inclusive of object code and source code) to be executed by one or more processors or other similar machine, instructions in software, hardware, firmware, or any combination thereof, etc.).
  • This tangible media may be non-transitory in at least one embodiment.
  • one or more memory elements can store data used for the operations described herein. This includes the memory elements being able to store software, logic, code, and/or processor instructions that are executed to carry out the activities described herein.
  • a processor can execute any type of instructions associated with the data to achieve the operations detailed herein.
  • a processor could transform an element or an article (e.g., data) from one state or thing to another state or thing.
  • the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable ROM (EEPROM)) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof.
  • FPGA field programmable gate array
  • EPROM erasable programmable read only memory
  • EEPROM electrically erasable programmable ROM
  • any of these elements can include memory for storing information to be used in achieving the optimized best path selection features, as outlined herein. Additionally, these network elements may include at least one processor that can execute software, an algorithm, or other instructions to perform the optimized best path selection operations, as disclosed herein. These network elements may further keep information, to be used in achieving the optimized best path selection activities as discussed herein, in any suitable memory element (random access memory (RAM), read only memory (ROM), EPROM, EEPROM, ASIC, etc.), software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs.
  • RAM random access memory
  • ROM read only memory
  • EPROM EPROM
  • EEPROM electrically erasable programmable read only memory
  • ASIC programmable programmable read only memory
  • any of the memory items discussed herein should be construed as being encompassed within the broad term 'memory element.
  • any of the potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term 'processor.
  • Each of the network elements can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.
  • interaction may be described in terms of two, three, or more network elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of network elements. It should be appreciated that the systems described herein are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of the optimized best path selection features as potentially applied to a myriad of other architectures or implementations.
  • 'at least one of' refers to any combination of the named elements, conditions, or activities.
  • X, Y, and Z' is intended to mean any of the following: 1) X, but not Y and not Z; 2) Y, but not X and not Z; 3) Z, but not X and not Y; 4) X and Y, but not Z; 5) X and Z, but not Y; 6) Y and Z, but not X; or 7) X, Y, and Z.
  • the terms 'first', 'second', 'third', etc. are intended to distinguish the particular items (e.g., element, condition, module, activity, operation, etc.) they modify. Unless expressly stated to the contrary, the use of these terms is not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified item. For example, 'first X' and 'second X' are intended to designate two separate X elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements.
  • references to "optimize,” “optimization,” “optimized”, “optimal” and related terms are terms of art that refer to improvements in speed and/or efficiency of a specified outcome and do not purport to indicate that a process for achieving the specified outcome has achieved, or is capable of achieving, a perfectly speedy/perfectly efficient state.
  • Substantial flexibility is provided by nodes with optimized best path selection capabilities in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the present disclosure. Additionally, these activities can be facilitated by various modules and/or components which can be suitably combined in any appropriate manner, or divided in any appropriate manner, and which may be based on particular configuration and/or provisioning needs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Claims (11)

  1. Procédé, comportant les étapes consistant à :
    configurer (506), par un réflecteur de trajet basé sur l'infonuagique (30, 330), un premier groupe (380) de noeuds (50, 350, 355) dans un système autonome (AS1, AS2), dans lequel les noeuds (50, 350, 355) du premier groupe (380) sont des clients du réflecteur de trajet basé sur l'infonuagique (30, 330) ;
    déterminer (508) si des chemins du type intra-groupes pour un préfixe d'adresse de réseau sont disponibles dans le premier groupe (380) de noeuds (50, 350, 355) ;
    sélectionner (518) un meilleur chemin du type intra-groupes parmi un ou plusieurs chemins du type intra-groupes si un ou plusieurs chemins du type intra-groupes sont déterminés comme étant disponibles dans le premier groupe (380) pour le préfixe d'adresse de réseau ;
    déterminer (512), si aucun chemin du type intra-groupes pour le préfixe d'adresse de réseau n'est disponible dans le premier groupe (380), si des chemins du type inter-groupes pour le préfixe d'adresse de réseau sont disponibles dans au moins un deuxième groupe (380) de noeuds (50, 350, 355) du système autonome (AS1, AS2) ;
    sélectionner (522) un meilleur chemin du type inter-groupes parmi un ou plusieurs chemins du type inter-groupes ; et
    annoncer (524) le meilleur chemin jusqu'à un ou plusieurs noeuds (50, 350, 355) dans le premier groupe (380).
  2. Procédé selon la revendication 1, dans lequel lesdits un ou plusieurs chemins sont déterminés comme étant disponibles dans le premier groupe (380) en fonction d'informations se rapportant à l'accessibilité ayant été reçues par le réflecteur de trajet basé sur l'infonuagique (30, 330) parmi un ou plusieurs noeuds périphériques (355) du premier groupe (380).
  3. Procédé selon la revendication 1, dans lequel l'étape consistant à sélectionner le meilleur chemin parmi les chemins disponibles est basée, au moins en partie, sur une comparaison de mesures pour les chemins disponibles.
  4. Procédé selon la revendication 3, dans lequel les mesures comprennent l'un parmi un coût ou une distance de chacun des deux ou plusieurs autres chemins.
  5. Procédé selon la revendication 3, comportant par ailleurs l'étape consistant à :
    extraire les mesures parmi un ou plusieurs messages de protocole d'un IGP (interior gateway protocol - protocole de passerelle intérieure).
  6. Procédé selon la revendication 1, dans lequel une ou plusieurs sessions BGP (border gateway protocol - protocole de passerelle frontière) sont utilisées par le réflecteur de trajet basé sur l'infonuagique (30, 330) pour annoncer le meilleur chemin jusqu'auxdits un ou plusieurs noeuds (50, 350, 355) dans le premier groupe (380) de noeuds.
  7. Procédé selon la revendication 1, dans lequel le réflecteur de trajet basé sur l'infonuagique (30, 330) est un réflecteur de trajet virtualisé dans un réseau en nuage (15, 315) .
  8. Procédé selon la revendication 1, dans lequel le meilleur chemin est sélectionné parmi lesdits un ou plusieurs chemins en fonction d'une politique si lesdits un ou plusieurs chemins comprennent deux chemins ou plus.
  9. Procédé selon la revendication 1, dans lequel le meilleur chemin n'est annoncé à aucun noeud (50, 350, 355) dans le premier groupe (380) qui a annoncé, au réflecteur de trajet basé sur l'infonuagique (30, 330), des informations se rapportant à l'accessibilité pour le préfixe d'adresse de réseau.
  10. Système, comportant :
    un réflecteur de trajet basé sur l'infonuagique (30, 330) comprenant :
    un ou plusieurs processeurs (39) ; et
    une logique optimisée de sélection du meilleur chemin (62) qui, quand elle est exécutée par lesdits un ou plusieurs processeurs (39), effectue un procédé selon l'une quelconque des revendications précédentes.
  11. Au moins un support de stockage lisible par ordinateur comportant des instructions stockées sur celui-ci et, quand elles sont exécutées, amenant un ou plusieurs processeurs (39) à effectuer un procédé selon l'une quelconque des revendications 1 à 10.
EP16706723.0A 2015-02-20 2016-02-12 Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire Active EP3259886B1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562119036P 2015-02-20 2015-02-20
US14/805,300 US10097449B2 (en) 2015-02-20 2015-07-21 Optimized border gateway protocol best path selection for optimal route reflection
PCT/US2016/017786 WO2016133821A1 (fr) 2015-02-20 2016-02-12 Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire

Publications (2)

Publication Number Publication Date
EP3259886A1 EP3259886A1 (fr) 2017-12-27
EP3259886B1 true EP3259886B1 (fr) 2019-07-24

Family

ID=56690077

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16706723.0A Active EP3259886B1 (fr) 2015-02-20 2016-02-12 Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire

Country Status (4)

Country Link
US (1) US10097449B2 (fr)
EP (1) EP3259886B1 (fr)
CN (1) CN107409092B (fr)
WO (1) WO2016133821A1 (fr)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9992161B2 (en) * 2014-06-03 2018-06-05 The Viki Group, Inc. DDOS protection infrastructures using IP sharing across wide area networks
US10015073B2 (en) 2015-02-20 2018-07-03 Cisco Technology, Inc. Automatic optimal route reflector root address assignment to route reflector clients and fast failover in a network environment
US9736059B2 (en) * 2015-04-06 2017-08-15 Verizon Digital Media Services Inc. Purging failover through application controlled transit selection
US9787579B2 (en) 2015-04-06 2017-10-10 Verizon Digital Media Services Inc. Application controlled path selection based on type-of-service
US10033628B2 (en) 2015-04-06 2018-07-24 Verizon Digital Media Services Inc. Application controlled path selection over different transit providers
US10469360B1 (en) * 2015-09-30 2019-11-05 Juniper Networks, Inc. Reverse metric advertisement for border gateway protocol route reflection inhierarchical networks
US10742599B2 (en) * 2017-06-30 2020-08-11 Juniper Networks, Inc. Conflict resolution in segment routing
EP3422645B1 (fr) * 2017-06-30 2020-04-29 Juniper Networks, Inc. Résolution de conflits dans un routage de segments
US10491483B2 (en) * 2017-10-19 2019-11-26 Nicira, Inc. Using application programming interface calls for communication between network functions
US10476779B1 (en) * 2018-03-19 2019-11-12 Juniper Networks, Inc. Configuring a topology of devices to support scaling of an exchange point
US10778563B1 (en) * 2018-03-22 2020-09-15 Amazon Technologies, Inc. Brick identifier attribute for routing in multi-tier computer networks
EP3777327A1 (fr) * 2018-03-29 2021-02-17 GOOEE Limited Système et procédé de gestion et de commande d'un protocole de tunnellisation dynamique dans un réseau maillé
US11398973B2 (en) 2018-09-26 2022-07-26 Hewlett Packard Enterprise Development Lp Route selection using cumulative cost
CN110971522B (zh) * 2018-09-30 2021-09-17 华为技术有限公司 一种确定路由泄露的方法、设备和系统
US10917330B1 (en) * 2019-01-28 2021-02-09 Juniper Networks, Inc. Minimizing or reducing traffic loss when an external border gateway protocol (eBGP) peer goes down
EP3928479A4 (fr) * 2019-03-20 2022-04-13 Huawei Technologies Co., Ltd. Procédé de routage optimal dans un réseau igp srmpl inter-zone, noeuds et système associés
US11153420B2 (en) 2019-10-18 2021-10-19 Arista Networks, Inc. Neighbor equivalence groups
US11121963B2 (en) * 2019-11-04 2021-09-14 Arrcus Inc. Best path computation offload in a network computing environment
US11405308B2 (en) 2019-12-05 2022-08-02 Juniper Networks, Inc. Automatic discovery of route reflection peering end-points
US11329880B2 (en) * 2020-01-09 2022-05-10 Dell Products L.P. Automatic route reflector configuration system
CN111614557B (zh) 2020-04-02 2021-09-24 深圳创维－Rgb电子有限公司 Mesh网络的数据传输方法、装置、网关及存储介质
CN113595901A (zh) * 2020-04-30 2021-11-02 华为技术有限公司 一种基于边界网关协议的路由选择方法及装置
CN111817954B (zh) * 2020-06-19 2022-07-26 聚好看科技股份有限公司 路由反射模式的切换方法及网络架构系统
US11394636B1 (en) * 2020-12-10 2022-07-19 Amazon Technologies, Inc. Network connection path obfuscation using global access points
JP2024505643A (ja) * 2021-02-03 2024-02-07 アルカス インコーポレイテッド ネットワークコンピューティング環境における最適パス計算オフロード
CN115277527A (zh) * 2021-04-30 2022-11-01 华为技术有限公司 一种路由信息的处理方法及装置
US11601336B2 (en) 2021-05-18 2023-03-07 Google Llc Assigning routing paths based on interior gateway protocol metric optimization
CN114143807B (zh) * 2021-10-27 2023-08-08 中盈优创资讯科技有限公司 一种路由注册完整率评价方法及装置
CN114124780B (zh) * 2021-11-15 2023-07-21 迈普通信技术股份有限公司 路由发布方法、装置、电子设备及存储介质
US20230269223A1 (en) * 2022-02-22 2023-08-24 Cisco Technology, Inc. Secured advertisement of autoconfigured internet protocol prefixes in a cloud environment
US11575596B1 (en) * 2022-03-07 2023-02-07 Ciena Corporation Identifying an ingress router of a flow in inter-AS VPN option-C networks with visibility in one AS
EP4262169A1 (fr) * 2022-04-12 2023-10-18 Arista Networks, Inc. Mise en uvre d'une réflexion optimale de route de protocole de passerelle frontière (bgp)
US20240064085A1 (en) * 2022-08-16 2024-02-22 Cisco Technology, Inc. Method to select best path for saas using application and network telemetry

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6148000A (en) * 1996-10-02 2000-11-14 International Business Machines Corporation Merging of data cells at network nodes
US6711152B1 (en) * 1998-07-06 2004-03-23 At&T Corp. Routing over large clouds
DE60024750D1 (de) * 1999-10-01 2006-01-19 Nortel Networks Ltd Aufbau von Verbindungen über ein Kommunikationsnetzwerk
US6954790B2 (en) * 2000-12-05 2005-10-11 Interactive People Unplugged Ab Network-based mobile workgroup system
US7023808B2 (en) * 2003-12-23 2006-04-04 Cisco Technology, Inc. System and method for distributing route selection in an implementation of a routing protocol
US20060029035A1 (en) 2004-03-25 2006-02-09 Chase Christopher J Method and apparatus for selecting routes for distribution within IP networks
US7769886B2 (en) * 2005-02-25 2010-08-03 Cisco Technology, Inc. Application based active-active data center network using route health injection and IGP
US20060291446A1 (en) 2005-06-24 2006-12-28 Donald Caldwell Systems, methods, and devices for managing routing
US20070091794A1 (en) 2005-10-20 2007-04-26 Clarence Filsfils Method of constructing a backup path in an autonomous system
US7660296B2 (en) * 2005-12-30 2010-02-09 Akamai Technologies, Inc. Reliable, high-throughput, high-performance transport and routing mechanism for arbitrary data flows
US7697416B2 (en) 2006-09-08 2010-04-13 Cisco Technolgy, Inc. Constructing a repair path in the event of non-availability of a routing domain
US8549616B2 (en) * 2008-10-31 2013-10-01 At&T Intellectual Property I, L.P. Methods and apparatus to dynamically control access from virtual private networks to network-based shared resources
EP2213933A1 (fr) 2009-01-30 2010-08-04 Energias Renovables del Principado, S.A. Poteaux d'éclairage à énergie solaire photovoltaic avec connexion au réseau
US9036504B1 (en) * 2009-12-07 2015-05-19 Amazon Technologies, Inc. Using virtual networking devices and routing information to associate network addresses with computing nodes
CN102148832B (zh) * 2011-04-07 2013-06-12 清华大学 边界网关路由协议路径鉴定方法
US8537840B1 (en) 2011-07-26 2013-09-17 Cisco Technology, Inc. Angular distance calculation for BGP best path selection
US8452871B2 (en) * 2011-08-27 2013-05-28 At&T Intellectual Property I, L.P. Passive and comprehensive hierarchical anomaly detection system and method
US9450817B1 (en) * 2013-03-15 2016-09-20 Juniper Networks, Inc. Software defined network controller
US10015073B2 (en) 2015-02-20 2018-07-03 Cisco Technology, Inc. Automatic optimal route reflector root address assignment to route reflector clients and fast failover in a network environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
WO2016133821A1 (fr) 2016-08-25
EP3259886A1 (fr) 2017-12-27
CN107409092B (zh) 2021-04-09
CN107409092A (zh) 2017-11-28
US20160248663A1 (en) 2016-08-25
US10097449B2 (en) 2018-10-09

Similar Documents

Publication Publication Date Title
EP3259886B1 (fr) Sélection optimisée de meilleur trajet sous protocole de passerelle frontière pour réflexion optimale d'itinéraire
US10541905B2 (en) Automatic optimal route reflector root address assignment to route reflector clients and fast failover in a network environment
EP3648420B1 (fr) Permission aux routeurs à algorithme non flexible de participer à des protocoles de routage à algorithme flexible
US8537840B1 (en) Angular distance calculation for BGP best path selection
US10021023B2 (en) Packet forwarding method, controller, forwarding device, and network system
US7522603B2 (en) Technique for efficiently routing IP traffic on CE-CE paths across a provider network
US11743166B2 (en) Provisioning non-colored segment routing label switched paths via segment routing policies in border gateway protocol
EP3731471B1 (fr) Procédé et dispositif de distribution d'offset d'identificateur de segment
US20100061227A1 (en) Method to reduce routing convergence at the edge
US9515916B2 (en) Redirection of requests for target addresses
CN112118178B (zh) 网络装置和用于ip网络中基于类别的流量工程的方法
US20130151445A1 (en) Method and System for Survival of Data Plane Through a Total Control Plane Failure
WO2013078776A1 (fr) Établissement d'une relation de voisinage distante dans un protocole de distribution avec étiquette, ldp
US8014318B2 (en) Routing-based proximity for communication networks to routing-based proximity for overlay networks
US7957289B2 (en) Method to reduce IGP routing information
Asher Comprehensive analysis of dynamic routing protocols in computer networks
CN111245716A (zh) 域间路由方法、设备和系统
WO2020227412A1 (fr) Inondation sensible au trajet d'un protocole open shortest path first (ospf)

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170525

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602016017288

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0012717000

Ipc: H04L0012721000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20190214

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/707 20130101ALI20190201BHEP

Ipc: H04L 12/721 20130101AFI20190201BHEP

Ipc: H04L 12/717 20130101ALI20190201BHEP

Ipc: H04L 29/08 20060101ALI20190201BHEP

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: CISCO TECHNOLOGY, INC.

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602016017288

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1159571

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190815

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20190724

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1159571

Country of ref document: AT

Kind code of ref document: T

Effective date: 20190724

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191024

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191024

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191125

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191025

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191124

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200224

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602016017288

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG2D Information on lapse in contracting state deleted

Ref country code: IS

26N No opposition filed

Effective date: 20200603

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20200229

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200212

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200229

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200229

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200212

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200229

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602016017288

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0012721000

Ipc: H04L0045000000

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20190724

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240207

Year of fee payment: 9

Ref country code: GB

Payment date: 20240212

Year of fee payment: 9

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240228

Year of fee payment: 9