US20220278890A1 - Method for Establishing High Resilient Active Recovery for BGP Route Reflectors - Google Patents
Method for Establishing High Resilient Active Recovery for BGP Route Reflectors Download PDFInfo
- Publication number
- US20220278890A1 US20220278890A1 US17/748,735 US202217748735A US2022278890A1 US 20220278890 A1 US20220278890 A1 US 20220278890A1 US 202217748735 A US202217748735 A US 202217748735A US 2022278890 A1 US2022278890 A1 US 2022278890A1
- Authority
- US
- United States
- Prior art keywords
- route reflector
- recovery
- bgp
- establishing
- provider edge
- 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.)
- Abandoned
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/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- 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/58—Association of routers
- H04L45/586—Association of routers of virtual routers
-
- 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/02—Topology update or discovery
- H04L45/026—Details of "hello" or keep-alive messages
-
- 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/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
Definitions
- the present disclosure relates to communicating network routing information. More particularly, the disclosure relates to a method, system, and computer program for establishing high resilient active recovery.
- Border Gateway Protocol is the routing protocol of the Internet. It is used to exchange routing information between Autonomous Systems (AS) and routing traffic across the Internet. Forwarding BGP updates within an AS introduces a couple of challenges.
- BGP requires a BGP router to add its own AS number (ASN) entry to the AS_PATH attribute when forwarding BGP route updates to another AS.
- ASN AS number
- the AS_Path attribute identifies the ASes through which an UPDATE message has passed and lists in reverse order the ASes traversed by a prefix, with the last AS placed at the beginning of the list.
- the primary purpose of AS_PATH is to provide loop-prevention during inter-AS routing.
- BGP drops a route if a BGP router sees its own ASN in the AS_PATH list.
- each BGP edge router will add its own ASN to the AS_PATH list.
- the next hop BGP router which is in the same AS, sees its own ASN in the AS_PATH list, assumes that a loop has occurred and drops the route.
- IGP interior gateway protocol
- BGP internal BGP
- iBGP internal BGP
- a router within an AS does not exchange routing updates to another iBGP router.
- the ASN is added and routes are advertised only when they are being sent to a BGP router in another autonomous system, i.e. to an eBGP router.
- routing updates learned are not advertised to other iBGP peers to prevent loops, route reachability must be achieved by using a full-mesh topology between all the iBGP peers. This means that every device within an AS is logically connected to every other device through a peering relationship.
- iBGP full-mesh topology can cause scalability issues in large networks.
- RR Route Reflector
- An RR is an iBGP feature that eliminates the need for a BGP full-mesh topology and allows iBGP to scale in large networks.
- the RR mechanism allows a iBGP router to act as a RR that advertises (reflects) the routes it learns from one iBGP router to other iBGP peers within the AS.
- the internal peers that connect to an RR are classified as RR client peers.
- An RR along with its client peers form a cluster.
- Each cluster can have multiple RRs which helps avoid a single point of failure and achieve redundancy. It is also possible to have multiple RRs within an AS where each RR is a non-client peer to another RR.
- RRs are critical components in large network functionality to support high scale. Large complex topologies require a large number of RRs to run the network and provide some protection from outage events. Traditionally, RRs were deployed in pairs to support some failover functions however dual-failures would result in service outages. To improve the resiliency more RRs can be deployed but this comes with a higher cost and functional challenge that drives up scale throughout the topology. Additionally, in virtual environment servers are taken out of service for planned maintenance frequently resulting in ongoing states where there is only one RR functioning. This exposes the network to more frequents service interruptions.
- One general aspect includes a method including: establishing a first peer session between a recovery RR and a first RR that has established a first provider edge peer session with a first set of provider edge devices. Establishing a second peer session between the recovery RR and a second RR that has established a second provider edge peer session with a second set of provider edge devices. Monitoring a BGP state between the first RR and the recovery RR and a BGP state between the second RR and the recovery RR. Establishing a peer session between the recovery RR and the first set of provider edge devices when the first RR fails and the first BGP state is idle.
- Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.
- Implementations may include establishing a BGP SET in the recovery RR that manages a first provider edge BGP state between the recovery RR and the first set of provider edge devices.
- the BGP set may be a container that includes all neighbor configuration policies and parameters.
- One general aspect includes a system including: a first RR and a second RR where the first RR has a set of established first provider edge peer sessions with a first set of provider edge devices, and the second RR has a set of established second peer sessions with a second set of provider edge devices.
- the system includes a recovery RR with an established first recovery RR peer session with the first RR and an established second recovery RR peer session with the second RR.
- the recovery RR includes a monitoring module in the that monitors a first BGP state between the first RR and the recovery RR and a second BGP state between the second RR and the recovery RR.
- the recovery RR includes a BGP state establishment module that establishes a peer session between the recovery RR and the first set of provide edge devices when the first BGP state is idle.
- the recovery RR may include a BGP SET that manages a first provider edge BGP state between the recovery RR and the first set of provider edge devices.
- the BGP set may be a container that includes all neighbor configuration policies and parameters.
- One general aspect includes a non-transitory computer readable storage medium storing an information processing program to cause a computer to execute a process including: establishing a first peer session between a recovery RR and a first RR where the first RR has established a first provider edge peer session with a first set of provider edge devices.
- the process executed by the computer further includes establishing a second peer session between the recovery RR and a second RR where the second RR has established a second provide edge peer session with a second set of provider edge devices.
- the process executed by the computer also includes monitoring a first BGP state between the first RR and the recovery RR and a second BGP state the second RR and the recovery RR; and when the first BGP state is idle, establishing a peer session between the recovery RR and the first set of provider edge devices.
- the non-transitory computer readable storage medium where the process executed by the computer may further includes establishing a BGP SET that manages a first provider edge BGP state between the recovery route reflector and the first set of provider edge devices.
- the BGP SET is a container that includes all neighbor configuration policies and parameters.
- FIG. 1 is a block diagram illustrating the network environment of a system 100 for providing active recovery for a RR.
- FIG. 2 is a block diagram illustrating the network environment of a system 100 for providing active recovery for a RR when a primary RR fails.
- FIG. 3 is a flowchart of a method for providing active recovery for a RR.
- FIG. 4 is a Block diagram illustrating the configuration of a recovery RR.
- An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other Unified Modeling Language (UML) models, requirements and design documents) help describe the function, architecture, and design of software.
- UML Unified Modeling Language
- an autonomous system On the Internet, an autonomous system (AS) is the unit of router policy, either a single network or a group of networks that is controlled by a common network administrator (or group of administrators) on behalf of a single administrative entity (such as a university, a business enterprise, or a business division).
- An autonomous system is also sometimes referred to as a routing domain.
- An autonomous system is assigned a globally unique number, sometimes called an Autonomous System Number (ASN).
- ASN Autonomous System Number
- Networks within an autonomous system communicate routing information to each other using an Interior Gateway Protocol (IGP).
- An autonomous system shares routing information with other autonomous systems using the Border Gateway Protocol (BGP).
- IGP Interior Gateway Protocol
- BGP Border Gateway Protocol
- BGP BGP Neighbor Sate.
- BGP forms a TCP session with neighbor routers called peers.
- BGP uses the Finite State Machine (FSM) to maintain a table of all BGP peers and their operational status.
- the BGP session may report in the following states: Idle; Connect; Active; OpenSent; OpenConfirm; Established.
- Idle is the first stage of the BGP finite state machine (FSM0.
- BGP detects a start event, tries to initiate a TCP connection to the BGP peer, and also listens for a new connect from a peer router.
- BGP starts a new three-way TCP handshake. If a connection is established an Open message is sent, the whole timer set for four minutes, and the state moves to open sent.
- the BGP section is established.
- BGP neighbors exchange routes via update messages. As update and keep alive messages are received the whole timer is reset. If the whole timer expires, an error is detected and BGP moves the neighbor back to the idle state
- BGP SET is a new artifact that groups BGP neighbors into a single logical container.
- Border Gateway Protocol BGP (Border Gateway Protocol) is protocol that manages how packets are routed across the internet through the exchange of routing and reachability information between edge routers. BGP directs packets between autonomous systems (AS)—networks managed by a single enterprise or service provider. Traffic that is routed within a single network AS is referred to as internal BGP, or iBGP. More often, BGP is used to connect one AS to other autonomous systems, and it is then referred to as an external BGP, or eBGP.
- iBGP autonomous systems
- a container is an isolated execution environment on a Linux host that behaves much like a full-featured Linux installation with its own users, file system, processes and network stack. Running an application inside of a container isolates it from the host and other containers, meaning that even when the applications inside of them are running as root, they cannot access or modify the files, processes, users, or other resources of the host or other containers.
- Containers have become popular due to the way they simplify the process of installing and running an application on a Linux server. Applications can have a complicated web of dependencies. The newest version of an application may require a newer version of a dependency than is available for the Linux distribution, and upgrading the dependency may break another application running on the server.
- containers are portable and can be shared across platforms. Docker, a popular container engine, has a specific format for containers to be stored in. This allows a developer to package a container with all of its dependencies, post it online and allow users to download and run the container right away.
- a CE router (customer edge router) is a router located on the customer premises that provides an Ethernet interface between the customer's LAN and the provider's core network.
- CE routers, P (provider) routers and PE (provider edge) routers are components in an MPLS (multiprotocol label switching) architecture.
- Provider routers are located in the core of the provider or carrier's network.
- Provider edge routers sit at the edge of the network.
- CE routers connect to PE routers and PE routers connect to other PE routers over P routers.
- a loopback address is a type of IP address that is used to test the communication or transportation medium on a local network card and/or for testing network applications. Data packets sent on a loopback address are re-routed back to the originating node without any alteration or modification.
- PE Router Provider Edge Router
- PE router is a router between one network service provider's area and areas administered by other network providers.
- a route reflector is a network routing component for BGP. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP).
- IBGP internal border gateway protocol
- a RR acts as a focal point for IBGP sessions. The purpose of the RR is concentration.
- Multiple BGP routers can peer with a central point, the RR—acting as a RR server—rather than peer with every other router in a full mesh. All the other IBGP routers become RR clients.
- SABR Service-Aware Border Router
- the SABR protocol is an extension of Contact Graph Routing that seeks to provide a routing solution for a wide range of scenarios that include both scheduled and discovered connectivity.
- SABR uses a ‘contact plan’ provided by network management describing the current connectivity and future connectivity schedule.
- SABR then makes forwarding decisions based on an earliest-arrival-time metric where bundles are routed over the time-varying connectivity graph.
- SABR uses historical contact information and neighbor discovery to address routing over non-scheduled links.
- FIG. 1 is a block diagram illustrating the network environment of a system 100 for providing active recovery for RRs.
- a plurality of primary RRs (RR 1 101 , RR 2 103 and RR 3 105 ) are peered with a plurality of edge devices (PE 1 A 107 , PE 1 B 109 , PE 2 A 111 , PE 2 B 113 , PE 3 A 115 , and PE 3 B 117 ).
- the primary RRs may be virtual RRs. In the example illustrated in FIG. 1 only 3 primary RRs are shown. However, it is contemplated that a plurality of primary RRs (e.g. 5-50) may be used.
- two provider edge devices are illustrated as being peered with each primary RR, but it is contemplated that a plurality of edge devices may be peered with each primary RR.
- Primary RRs (RR 1 101 , RR 2 103 and RR 3 105 ) are also peered with a recovery RR 119 which may be a virtual RR.
- the recovery RR 119 include a recovery subsystem 120 including a monitoring module 121 and an activation module 122 .
- the monitoring module 121 monitors the state of the BGP session to determine whether the state is active/established or idle/inactive.
- the monitoring module 121 checks the BGP session between the recovery RR 119 and the primary RRs periodically (e.g. every 5 seconds) to determine whether the BGP state is established/active or idle/inactive.
- the activation module 122 takes further action (establishes a peer relationship between the recovery RR 119 and the PEs supported by the inactive primary RR.
- the recovery RR 119 must manage a copy of the differences on all primary RRs that it supports. Those differences are captured in a container labeled a BGP SET (e.g. BGP SET- 1 123 , BGP SET- 2 124 and BGP SET- 3 125 ).
- a BGP SET is a new artifact that resides in the recovery RR 119 .
- Each primary RR that is protected places the unique configurations of the primary RR including all clients (PEs) that it supports and the IP addresses of those clients in a BGP SET.
- BGP SET is a new data artifact local to the recover RR 119 .
- the BGP SET does not modify BGP adjacency (the establishment of a session between two BGP neighbors) or attributes distributed over the session.
- the neighbor would be a client of the Route reflector or a PE. So, the SET does not change the adjacency or the session itself between the two neighbors.
- the SET is designed to create a session or adjacency with the neighbors defined in the SET.
- Each BGP SET is a container and group-level session management function. The container includes all neighbor configuration, policies and parameters such as hold/keepalive settings.
- Each BGP SET must include a router ID/loopback address. Clients defined within the BGP SET must establish BGP peering with the BGP SET itself.
- the recovery RR 119 may have any number of BGP SETs (typically anywhere between 5 to 50 BGP SETs). Each SET represents a different primary RR configuration.
- the recovery RR 119 may also access global configurations 126 which are the configurations that are common between the primary RRs (RR 1 101 , RR 2 103 and RR 3 105 ).
- Each BGP SET will inherit all global configurations (e.g. subsequent address family (SAFI, L3VPN, L2VPN), autonomous system number (ASN), interior gateway protocol (IGP) and policies).
- SAFI subsequent address family
- L3VPN L2VPN
- ASN autonomous system number
- IGP interior gateway protocol
- the recovery RR 119 must be classified as one of the above (either intra, inter or SABR).
- the recovery RR 119 must be of the same category of the primary RRs that it services.
- FIGS. 1 and 2 The operation of the system is illustrated in FIGS. 1 and 2 .
- RR 1 101 supports PE 1 A 107 and PE 1 B 109
- RR 2 103 supports PE 2 A 111 and PE 2 B 113
- RR 3 105 supports PE 3 A 115 and PE 3 B 117 .
- the primary RRs are operational the BGP state between the recovery RR 119 and the primary RRs (RR 1 101 , RR 2 103 and RR 3 105 ) are all active, and BGP SET- 1 123 , BGP SET- 2 124 and BGP SET- 3 125 are all inactive. In that case no connections exist between the PEs and the recovery RR 109 .
- FIG. 2 illustrates what happens when a primary RR (e.g. RR 1 101 ) fails.
- the BGP state between the recovery RR 119 and RR 1 101 is idle.
- the change of BGP state is the trigger used by the activation module 122 on the recovery RR 119 to activate a peer relationship with the set of PEs (e.g. PE 1 A 107 and PE 1 B 109 ) associated with the primary RR (RR 1 101 ) that failed.
- the BGP SET of the affected primary RR becomes active and the Loopback address of the affected peer is used to build BGP sessions to each client (PE) defined in the BGP SET.
- PE client
- the activation module 122 will access BGP SET- 1 123 which will become active.
- the BGP SET manages the BGP state for all neighbors defined within the SET, with the BGP state being either up or shutdown.
- the BGP SET container has all the neighbor (PE) configurations contained in it and can define all sessions as either up (sessions are established) or shutdown (none of the sessions are established). Unlike existing BGP sessions where the state is managed on a per session basis the BGP SET is managed for all BGP neighbors within the BGP SET.
- the recovery RR 119 maintains the BGP global configuration 126 which are the common configurations of the primary RRs.
- the recovery RR 119 can manage multiple BGP SETs where each set represents a client (PE) group on a protected primary RR.
- a BGP SET defines the differences in configurations which is limited to the neighbor IP address for BGP session establishment.
- a router may have three BGP SETs.
- the difference between those BGP SETs is essentially the neighbor address of the clients to which those BGP SETs report. So, for example a BGP SET 1 may be a BGP SET for routers 1 - 10 .
- the BGP SET 2 supports routers 11 - 20 with the PE addresses of routers 11 - 20 .
- In BGP SET 3 the BGP SET supports routers 21 - 30 with the PE addresses of routers 21 - 30 .
- the BGP SET also maintains the router-ID/Loopback address for each protected PE. When the failed primary RR returns to an established state the recovery router disables its BGP SET returning to active monitoring mode.
- FIG. 3 Illustrated in FIG. 3 is a flowchart for a method 300 for establishing high resilient active recovery for primary RRs.
- step 301 the method 300 establishes a peer session between a first set of PEs and a first primary RR.
- step 303 the method 300 establishes a peer session between the second set of PEs and a second primary RR.
- step 305 the method 300 establishes a peer session between the first primary RR and a recovery RR.
- step 307 the method 300 establishes a peer session between the second primary RR and the recovery RR.
- step 309 the method 300 establishes a BGP SET in the recovery RR for managing a PE BGP state between the recovery RR and the first set of PEs
- step 311 the method 300 establishes a BGP SET in the recovery RR for managing a PE BGP state between the recovery RR and the second set of PEs
- step 313 the method 300 establishes a global configuration in the recovery RR for managing the common configurations of the first primary RR and the second primary
- step 315 the method 300 monitors a first BGP state between the first primary RR and the recovery RR.
- step 317 the method 300 monitors a second BGP state between the second primary RR and the recovery RR.
- step 319 the method 300 establishes a peer session between the recovery RR in the first set of PEs when the first BGP state is idle as a result of the failure of the first primary RR.
- FIG. 4 illustrates the configuration 300 of the recovery RR 119 .
- the recovery RR 119 includes global configurations 126 which are the configurations that are common between the primary RRs (RR 1 101 , RR 2 103 and RR 3 105 ).
- the common configurations may include Subsequent Address Family Identifiers (SAFIs) associated with a level 2 VPN and a Level 3 VPN; Autonomous system numbers (ASN); interior gateway protocol (IGP) and policies.
- SAFIs Subsequent Address Family Identifiers
- ASN Autonomous system numbers
- IGP interior gateway protocol
- the Recovery RR 119 also include a plurality of containers (BGP SET- 1 121 , BGP SET- 2 123 ; and BGP SET- 3 125 ).
- Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon.
- Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.
- Such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures.
- a network or another communications connection either hardwired, wireless, or combination thereof
- any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.
- Computer-executable instructions include, for example, instructions and data which cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
- Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments.
- program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types.
- Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Abstract
A recovery route reflector with a monitoring module and a BGP state establishment module is peered with a plurality of primary route reflectors. Each of the plurality of primary route reflectors is peered with a set of provider edge devices. The BGP state between the recovery route reflector and the plurality of primary route reflectors is periodically monitored. When a primary route reflector fails the BGP state between the recovery route reflector and the failed primary route reflectors is idle, and the recovery route reflector establishes a peer session with the provider edge devices that had been peered with the failed route reflector.
Description
- This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 16/984,530, filed Aug. 4, 2020, which is a continuation of, and claims priority to, U.S. patent application Ser. No. 16/418,353, filed May 21, 2019, now U.S. Pat. No. 10,764,120, issued Sep. 1, 2020, the entire contents of all of which are hereby incorporated herein by reference.
- The present disclosure relates to communicating network routing information. More particularly, the disclosure relates to a method, system, and computer program for establishing high resilient active recovery.
- Border Gateway Protocol (BGP) is the routing protocol of the Internet. It is used to exchange routing information between Autonomous Systems (AS) and routing traffic across the Internet. Forwarding BGP updates within an AS introduces a couple of challenges. First, BGP requires a BGP router to add its own AS number (ASN) entry to the AS_PATH attribute when forwarding BGP route updates to another AS. The AS_Path attribute identifies the ASes through which an UPDATE message has passed and lists in reverse order the ASes traversed by a prefix, with the last AS placed at the beginning of the list. The primary purpose of AS_PATH is to provide loop-prevention during inter-AS routing. Second, to avoid routing loops, BGP drops a route if a BGP router sees its own ASN in the AS_PATH list. Thus, when forwarding a BGP route advertisement through the routers within an AS, each BGP edge router will add its own ASN to the AS_PATH list. But the next hop BGP router, which is in the same AS, sees its own ASN in the AS_PATH list, assumes that a loop has occurred and drops the route. Although this can be overcome by redistributing all BGP routes into an interior gateway protocol (IGP), and not using BGP, the large number of routes advertised by BGP can cause IGP to crash. To avoid this an internal BGP (iBGP) is used to forward route advertisements received from an external BGP router through the internal network. With iBGP, a router within an AS does not exchange routing updates to another iBGP router. The ASN is added and routes are advertised only when they are being sent to a BGP router in another autonomous system, i.e. to an eBGP router. However, because routing updates learned are not advertised to other iBGP peers to prevent loops, route reachability must be achieved by using a full-mesh topology between all the iBGP peers. This means that every device within an AS is logically connected to every other device through a peering relationship.
- Deploying iBGP full-mesh topology can cause scalability issues in large networks. To exchange routing updates with all the other BGP routers in the full-mesh, each peering router uses up network resources. Additionally, to add new iBGP router network engineers must establish a connection to every other BGP router within the AS. This requires configuration changes on backbone routers, which results in network downtime. These problems may be avoided through the use of a Route Reflector (RR).
- An RR is an iBGP feature that eliminates the need for a BGP full-mesh topology and allows iBGP to scale in large networks. The RR mechanism allows a iBGP router to act as a RR that advertises (reflects) the routes it learns from one iBGP router to other iBGP peers within the AS.
- The internal peers that connect to an RR are classified as RR client peers. An RR along with its client peers form a cluster. Each cluster can have multiple RRs which helps avoid a single point of failure and achieve redundancy. It is also possible to have multiple RRs within an AS where each RR is a non-client peer to another RR.
- RRs are critical components in large network functionality to support high scale. Large complex topologies require a large number of RRs to run the network and provide some protection from outage events. Traditionally, RRs were deployed in pairs to support some failover functions however dual-failures would result in service outages. To improve the resiliency more RRs can be deployed but this comes with a higher cost and functional challenge that drives up scale throughout the topology. Additionally, in virtual environment servers are taken out of service for planned maintenance frequently resulting in ongoing states where there is only one RR functioning. This exposes the network to more frequents service interruptions.
- One general aspect includes a method including: establishing a first peer session between a recovery RR and a first RR that has established a first provider edge peer session with a first set of provider edge devices. Establishing a second peer session between the recovery RR and a second RR that has established a second provider edge peer session with a second set of provider edge devices. Monitoring a BGP state between the first RR and the recovery RR and a BGP state between the second RR and the recovery RR. Establishing a peer session between the recovery RR and the first set of provider edge devices when the first RR fails and the first BGP state is idle. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.
- Implementations may include establishing a BGP SET in the recovery RR that manages a first provider edge BGP state between the recovery RR and the first set of provider edge devices. The BGP set may be a container that includes all neighbor configuration policies and parameters.
- One general aspect includes a system including: a first RR and a second RR where the first RR has a set of established first provider edge peer sessions with a first set of provider edge devices, and the second RR has a set of established second peer sessions with a second set of provider edge devices. The system includes a recovery RR with an established first recovery RR peer session with the first RR and an established second recovery RR peer session with the second RR. The recovery RR includes a monitoring module in the that monitors a first BGP state between the first RR and the recovery RR and a second BGP state between the second RR and the recovery RR. The recovery RR includes a BGP state establishment module that establishes a peer session between the recovery RR and the first set of provide edge devices when the first BGP state is idle.
- The recovery RR may include a BGP SET that manages a first provider edge BGP state between the recovery RR and the first set of provider edge devices. The BGP set may be a container that includes all neighbor configuration policies and parameters.
- One general aspect includes a non-transitory computer readable storage medium storing an information processing program to cause a computer to execute a process including: establishing a first peer session between a recovery RR and a first RR where the first RR has established a first provider edge peer session with a first set of provider edge devices. The process executed by the computer further includes establishing a second peer session between the recovery RR and a second RR where the second RR has established a second provide edge peer session with a second set of provider edge devices. The process executed by the computer also includes monitoring a first BGP state between the first RR and the recovery RR and a second BGP state the second RR and the recovery RR; and when the first BGP state is idle, establishing a peer session between the recovery RR and the first set of provider edge devices.
- In one embodiment, the non-transitory computer readable storage medium where the process executed by the computer may further includes establishing a BGP SET that manages a first provider edge BGP state between the recovery route reflector and the first set of provider edge devices. In an embodiment the BGP SET is a container that includes all neighbor configuration policies and parameters.
-
FIG. 1 is a block diagram illustrating the network environment of asystem 100 for providing active recovery for a RR. -
FIG. 2 is a block diagram illustrating the network environment of asystem 100 for providing active recovery for a RR when a primary RR fails. -
FIG. 3 is a flowchart of a method for providing active recovery for a RR. -
FIG. 4 is a Block diagram illustrating the configuration of a recovery RR. - Artifact. An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other Unified Modeling Language (UML) models, requirements and design documents) help describe the function, architecture, and design of software.
- Autonomous system (AS). On the Internet, an autonomous system (AS) is the unit of router policy, either a single network or a group of networks that is controlled by a common network administrator (or group of administrators) on behalf of a single administrative entity (such as a university, a business enterprise, or a business division). An autonomous system is also sometimes referred to as a routing domain. An autonomous system is assigned a globally unique number, sometimes called an Autonomous System Number (ASN). Networks within an autonomous system communicate routing information to each other using an Interior Gateway Protocol (IGP). An autonomous system shares routing information with other autonomous systems using the Border Gateway Protocol (BGP).
- BGP Neighbor Sate. BGP forms a TCP session with neighbor routers called peers. BGP uses the Finite State Machine (FSM) to maintain a table of all BGP peers and their operational status. The BGP session may report in the following states: Idle; Connect; Active; OpenSent; OpenConfirm; Established. Idle is the first stage of the BGP finite state machine (FSM0. BGP detects a start event, tries to initiate a TCP connection to the BGP peer, and also listens for a new connect from a peer router. In the active state BGP starts a new three-way TCP handshake. If a connection is established an Open message is sent, the whole timer set for four minutes, and the state moves to open sent. In the established state the BGP section is established. BGP neighbors exchange routes via update messages. As update and keep alive messages are received the whole timer is reset. If the whole timer expires, an error is detected and BGP moves the neighbor back to the idle state.
- BGP SET. BGP SET is a new artifact that groups BGP neighbors into a single logical container.
- Border Gateway Protocol (BGP). BGP (Border Gateway Protocol) is protocol that manages how packets are routed across the internet through the exchange of routing and reachability information between edge routers. BGP directs packets between autonomous systems (AS)—networks managed by a single enterprise or service provider. Traffic that is routed within a single network AS is referred to as internal BGP, or iBGP. More often, BGP is used to connect one AS to other autonomous systems, and it is then referred to as an external BGP, or eBGP.
- Container. A container is an isolated execution environment on a Linux host that behaves much like a full-featured Linux installation with its own users, file system, processes and network stack. Running an application inside of a container isolates it from the host and other containers, meaning that even when the applications inside of them are running as root, they cannot access or modify the files, processes, users, or other resources of the host or other containers. Containers have become popular due to the way they simplify the process of installing and running an application on a Linux server. Applications can have a complicated web of dependencies. The newest version of an application may require a newer version of a dependency than is available for the Linux distribution, and upgrading the dependency may break another application running on the server. However, since a container simulates a Linux environment, it becomes possible to install the dependencies in the container without causing any conflicts with the host. In fact, it's possible to run multiple containers at the same time, all with different versions of applications and libraries. Finally, containers are portable and can be shared across platforms. Docker, a popular container engine, has a specific format for containers to be stored in. This allows a developer to package a container with all of its dependencies, post it online and allow users to download and run the container right away.
- Customer Edge Router. A CE router (customer edge router) is a router located on the customer premises that provides an Ethernet interface between the customer's LAN and the provider's core network. CE routers, P (provider) routers and PE (provider edge) routers are components in an MPLS (multiprotocol label switching) architecture. Provider routers are located in the core of the provider or carrier's network. Provider edge routers sit at the edge of the network. CE routers connect to PE routers and PE routers connect to other PE routers over P routers.
- Loopback address. A loopback address is a type of IP address that is used to test the communication or transportation medium on a local network card and/or for testing network applications. Data packets sent on a loopback address are re-routed back to the originating node without any alteration or modification.
- Provider Edge Router (PE Router). A Provider Edge router (PE router) is a router between one network service provider's area and areas administered by other network providers.
- Route Reflector. A route reflector (RR) is a network routing component for BGP. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). A RR acts as a focal point for IBGP sessions. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR—acting as a RR server—rather than peer with every other router in a full mesh. All the other IBGP routers become RR clients.
- Service-Aware Border Router (SABR). The SABR protocol is an extension of Contact Graph Routing that seeks to provide a routing solution for a wide range of scenarios that include both scheduled and discovered connectivity. For the scheduled connectivity regime, SABR uses a ‘contact plan’ provided by network management describing the current connectivity and future connectivity schedule. SABR then makes forwarding decisions based on an earliest-arrival-time metric where bundles are routed over the time-varying connectivity graph. SABR uses historical contact information and neighbor discovery to address routing over non-scheduled links.
-
FIG. 1 is a block diagram illustrating the network environment of asystem 100 for providing active recovery for RRs. A plurality of primary RRs (RR1 101,RR2 103 and RR3 105) are peered with a plurality of edge devices (PE1A 107,PE1B 109,PE2A 111,PE2B 113,PE3A 115, and PE3B 117). The primary RRs may be virtual RRs. In the example illustrated inFIG. 1 only 3 primary RRs are shown. However, it is contemplated that a plurality of primary RRs (e.g. 5-50) may be used. Similarly, two provider edge devices are illustrated as being peered with each primary RR, but it is contemplated that a plurality of edge devices may be peered with each primary RR. - Primary RRs (
RR1 101,RR2 103 and RR3 105) are also peered with arecovery RR 119 which may be a virtual RR. Therecovery RR 119 include arecovery subsystem 120 including amonitoring module 121 and an activation module 122. Themonitoring module 121 monitors the state of the BGP session to determine whether the state is active/established or idle/inactive. Themonitoring module 121 checks the BGP session between therecovery RR 119 and the primary RRs periodically (e.g. every 5 seconds) to determine whether the BGP state is established/active or idle/inactive. When the state goes from established/active to idle/inactive the activation module 122 takes further action (establishes a peer relationship between therecovery RR 119 and the PEs supported by the inactive primary RR. - The
recovery RR 119 must manage a copy of the differences on all primary RRs that it supports. Those differences are captured in a container labeled a BGP SET (e.g. BGP SET-1 123, BGP SET-2 124 and BGP SET-3 125). A BGP SET is a new artifact that resides in therecovery RR 119. Each primary RR that is protected places the unique configurations of the primary RR including all clients (PEs) that it supports and the IP addresses of those clients in a BGP SET. BGP SET is a new data artifact local to the recoverRR 119. The BGP SET does not modify BGP adjacency (the establishment of a session between two BGP neighbors) or attributes distributed over the session. The neighbor would be a client of the Route reflector or a PE. So, the SET does not change the adjacency or the session itself between the two neighbors. The SET is designed to create a session or adjacency with the neighbors defined in the SET. Each BGP SET is a container and group-level session management function. The container includes all neighbor configuration, policies and parameters such as hold/keepalive settings. Each BGP SET must include a router ID/loopback address. Clients defined within the BGP SET must establish BGP peering with the BGP SET itself. Although only three BGP SETs are illustrated inFIG. 1 , therecovery RR 119 may have any number of BGP SETs (typically anywhere between 5 to 50 BGP SETs). Each SET represents a different primary RR configuration. - The
recovery RR 119 may also accessglobal configurations 126 which are the configurations that are common between the primary RRs (RR1 101,RR2 103 and RR3 105). Each BGP SET will inherit all global configurations (e.g. subsequent address family (SAFI, L3VPN, L2VPN), autonomous system number (ASN), interior gateway protocol (IGP) and policies). - There are different categories of RRs—intra, inter and SABR. The
recovery RR 119 must be classified as one of the above (either intra, inter or SABR). Therecovery RR 119 must be of the same category of the primary RRs that it services. - The operation of the system is illustrated in
FIGS. 1 and 2 . As shown inFIG. 1 RR1 101 supports PE1A 107 andPE1B 109,RR2 103 supportsPE2A 111 and PE2B 113 andRR3 105 supportsPE3A 115 andPE3B 117. When the primary RRs are operational the BGP state between therecovery RR 119 and the primary RRs (RR1 101,RR2 103 and RR3 105) are all active, and BGP SET-1 123, BGP SET-2 124 and BGP SET-3 125 are all inactive. In that case no connections exist between the PEs and therecovery RR 109. -
FIG. 2 illustrates what happens when a primary RR (e.g. RR1 101) fails. In that case, the BGP state between therecovery RR 119 andRR1 101 is idle. The change of BGP state is the trigger used by the activation module 122 on therecovery RR 119 to activate a peer relationship with the set of PEs (e.g. PE1A 107 and PE1B 109) associated with the primary RR (RR1 101) that failed. In the event of an outage of a protected RR, the BGP SET of the affected primary RR becomes active and the Loopback address of the affected peer is used to build BGP sessions to each client (PE) defined in the BGP SET. The activation module 122 will access BGP SET-1 123 which will become active. The BGP SET manages the BGP state for all neighbors defined within the SET, with the BGP state being either up or shutdown. The BGP SET container has all the neighbor (PE) configurations contained in it and can define all sessions as either up (sessions are established) or shutdown (none of the sessions are established). Unlike existing BGP sessions where the state is managed on a per session basis the BGP SET is managed for all BGP neighbors within the BGP SET. Therecovery RR 119 maintains the BGPglobal configuration 126 which are the common configurations of the primary RRs. Therecovery RR 119 can manage multiple BGP SETs where each set represents a client (PE) group on a protected primary RR. A BGP SET defines the differences in configurations which is limited to the neighbor IP address for BGP session establishment. On a given router there may be multiple BGT SETs. For example, a router may have three BGP SETs. The difference between those BGP SETs is essentially the neighbor address of the clients to which those BGP SETs report. So, for example aBGP SET 1 may be a BGP SET for routers 1-10. InBGP SET 2, the BGP SET supports routers 11-20 with the PE addresses of routers 11-20. InBGP SET 3 the BGP SET supports routers 21-30 with the PE addresses of routers 21-30. The BGP SET also maintains the router-ID/Loopback address for each protected PE. When the failed primary RR returns to an established state the recovery router disables its BGP SET returning to active monitoring mode. - Illustrated in
FIG. 3 is a flowchart for amethod 300 for establishing high resilient active recovery for primary RRs. - In
step 301, themethod 300 establishes a peer session between a first set of PEs and a first primary RR. - In
step 303, themethod 300 establishes a peer session between the second set of PEs and a second primary RR. - In
step 305, themethod 300 establishes a peer session between the first primary RR and a recovery RR. - In
step 307, themethod 300 establishes a peer session between the second primary RR and the recovery RR. - In
step 309, themethod 300 establishes a BGP SET in the recovery RR for managing a PE BGP state between the recovery RR and the first set of PEs - In
step 311, themethod 300 establishes a BGP SET in the recovery RR for managing a PE BGP state between the recovery RR and the second set of PEs - In
step 313, themethod 300 establishes a global configuration in the recovery RR for managing the common configurations of the first primary RR and the second primary - RR.
- In
step 315, themethod 300 monitors a first BGP state between the first primary RR and the recovery RR. - In step 317, the
method 300 monitors a second BGP state between the second primary RR and the recovery RR. - In step 319, the
method 300 establishes a peer session between the recovery RR in the first set of PEs when the first BGP state is idle as a result of the failure of the first primary RR. -
FIG. 4 illustrates theconfiguration 300 of therecovery RR 119. Therecovery RR 119 includesglobal configurations 126 which are the configurations that are common between the primary RRs (RR1 101,RR2 103 and RR3 105). The common configurations may include Subsequent Address Family Identifiers (SAFIs) associated with alevel 2 VPN and aLevel 3 VPN; Autonomous system numbers (ASN); interior gateway protocol (IGP) and policies. TheRecovery RR 119 also include a plurality of containers (BGP SET-1 121, BGP SET-2 123; and BGP SET-3 125). - Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of the computer-readable media.
- Computer-executable instructions include, for example, instructions and data which cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, objects, components, and data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
- Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.
Claims (20)
1. A method comprising:
establishing, by one or more processors, a first peer session between a recovery route reflector and a first route reflector;
monitoring, by the one or more processors, a routing protocol state between the first route reflector and the recovery route reflector;
based upon a determination that the routing protocol state is not active, establishing, by the one or more processors, a second peer session between the recovery route reflector and a first set of provider edge devices associated with the first route reflector; and
establishing, by the one or more processors, a data artifact relating to the recovery route reflector and the first set of provider edge devices.
2. The method of claim 1 , further comprising establishing, by the one or more processors, a third peer session between the recovery route reflector and a second route reflector, monitoring, by the one or more processors, a second routing protocol state between the second route reflector and the recovery route reflector, and based upon a determination that the second routing protocol state is not active, establishing, by the one or more processors, a fourth peer session between the recovery route reflector and a second set of provider edge devices associated with the second route reflector.
3. The method of claim 1 , wherein the data artifact comprises neighbor configuration policies and parameters.
4. The method of claim 1 , wherein the data artifact comprises a router ID.
5. The method of claim 1 , wherein the data artifact comprises a loopback address.
6. The method of claim 1 , wherein the recovery route reflector comprises a virtual route reflector.
7. The method of claim 1 , wherein the first set of provider edge devices comprises routers.
8. A system comprising:
one or more processors; and
memory coupled with the one or more processors, the memory storing executable instructions that when executed by the one or more processors cause the one or more processors to effectuate operations comprising:
establishing a first peer session between a recovery route reflector and a first route reflector;
monitoring a routing protocol state between the first route reflector and the recovery route reflector;
based upon a determination that the routing protocol state is idle, establishing a second peer session between the recovery route reflector and a first set of provider edge devices associated with the first route reflector; and
establishing an artifact for the recovery route reflector and the first set of provider edge devices.
9. The system of claim 8 , further comprising establishing a third peer session between the recovery route reflector and a second route reflector, monitoring a second routing protocol state between the second route reflector and the recovery route reflector, and based upon a determination that the second routing protocol state is idle, establishing a fourth peer session between the recovery route reflector and a second set of provider edge devices associated with the second route reflector.
10. The system of claim 8 , wherein the artifact comprises neighbor configuration policies and parameters.
11. The system of claim 8 , wherein the artifact comprises a router ID.
12. The system of claim 8 , wherein the artifact comprises a loopback address.
13. The system of claim 8 , wherein the recovery route reflector comprises a virtual route reflector.
14. The system of claim 8 , wherein the first set of provider edge devices comprises routers.
15. A non-transitory computer readable storage medium storing computer executable instructions that when executed by a computing device cause said computing device to effectuate operations comprising:
establishing a first peer session between a recovery route reflector and a first route reflector;
monitoring a routing protocol state between the first route reflector and the recovery route reflector;
when the routing protocol state is idle, establishing a second peer session between the recovery route reflector and a first set of provider edge devices; and
establishing a data artifact for the recovery route reflector and the first set of provider edge devices.
16. The non-transitory computer readable storage medium of claim 15 , further comprising establishing a third peer session between the recovery route reflector and a second route reflector, monitoring a second routing protocol state between the second route reflector and the recovery route reflector, and, when the second routing protocol state is idle, establishing a fourth peer session between the recovery route reflector and a second set of provider edge devices.
17. The non-transitory computer readable storage medium of claim 15 , wherein the data artifact comprises neighbor configuration policies and parameters.
18. The non-transitory computer readable storage medium of claim 15 , wherein the data artifact comprises a router ID.
19. The non-transitory computer readable storage medium of claim 15 , wherein the data artifact comprises a loopback address.
20. The non-transitory computer readable storage medium of claim 15 , wherein the recovery route reflector comprises a virtual route reflector.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/748,735 US20220278890A1 (en) | 2019-05-21 | 2022-05-19 | Method for Establishing High Resilient Active Recovery for BGP Route Reflectors |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/418,353 US10764120B1 (en) | 2019-05-21 | 2019-05-21 | Method for establishing high resilient active recovery for BGP route reflectors |
US16/984,530 US11368355B2 (en) | 2019-05-21 | 2020-08-04 | Method for establishing high resilient active recovery for BGP route reflectors |
US17/748,735 US20220278890A1 (en) | 2019-05-21 | 2022-05-19 | Method for Establishing High Resilient Active Recovery for BGP Route Reflectors |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/984,530 Continuation US11368355B2 (en) | 2019-05-21 | 2020-08-04 | Method for establishing high resilient active recovery for BGP route reflectors |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220278890A1 true US20220278890A1 (en) | 2022-09-01 |
Family
ID=72241608
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/418,353 Active US10764120B1 (en) | 2019-05-21 | 2019-05-21 | Method for establishing high resilient active recovery for BGP route reflectors |
US16/984,530 Active 2039-05-30 US11368355B2 (en) | 2019-05-21 | 2020-08-04 | Method for establishing high resilient active recovery for BGP route reflectors |
US17/748,735 Abandoned US20220278890A1 (en) | 2019-05-21 | 2022-05-19 | Method for Establishing High Resilient Active Recovery for BGP Route Reflectors |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/418,353 Active US10764120B1 (en) | 2019-05-21 | 2019-05-21 | Method for establishing high resilient active recovery for BGP route reflectors |
US16/984,530 Active 2039-05-30 US11368355B2 (en) | 2019-05-21 | 2020-08-04 | Method for establishing high resilient active recovery for BGP route reflectors |
Country Status (1)
Country | Link |
---|---|
US (3) | US10764120B1 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11178047B2 (en) * | 2020-01-14 | 2021-11-16 | Raytheon Company | Tailored contact plan generation |
US20220376998A1 (en) * | 2021-05-24 | 2022-11-24 | Cisco Technology, Inc. | Autonomous system bottleneck detection |
US11652728B2 (en) * | 2021-09-24 | 2023-05-16 | Arista Networks, Inc. | Traffic loss avoidance in a border gateway protocol (BGP) network via flexible session tracking |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120213218A1 (en) * | 2011-02-19 | 2012-08-23 | Selma Yilmaz | Automatically detecting best paths from shadow route reflectors |
US20140198794A1 (en) * | 2013-01-14 | 2014-07-17 | Apurva Mehta | Connecting multiple customer sites over a wide area network using an overlay network |
US20180367388A1 (en) * | 2017-06-19 | 2018-12-20 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040034702A1 (en) * | 2002-08-16 | 2004-02-19 | Nortel Networks Limited | Method and apparatus for exchanging intra-domain routing information between VPN sites |
US7506194B2 (en) * | 2004-03-24 | 2009-03-17 | Cisco Technology, Inc. | Routing system and method for transparently rocovering routing states after a failover or during a software upgrade |
US8228786B2 (en) * | 2005-04-07 | 2012-07-24 | Cisco Technology, Inc. | Dynamic shared risk node group (SRNG) membership discovery |
US7675912B1 (en) * | 2005-07-05 | 2010-03-09 | Cisco Technology, Inc. | Method and apparatus for border gateway protocol (BGP) auto discovery |
US7916729B2 (en) * | 2008-09-30 | 2011-03-29 | Cisco Technology, Inc. | Automatic RD rewrite technique to achieve fast convergence in inter-as networks |
US8169921B2 (en) * | 2008-09-30 | 2012-05-01 | At&T Intellectual Property I, Lp | Methods and apparatus to monitor border gateway protocol sessions |
US8995446B2 (en) * | 2009-12-21 | 2015-03-31 | Cisco Technology, Inc. | Efficient generation of VPN-based BGP updates |
US8537840B1 (en) * | 2011-07-26 | 2013-09-17 | Cisco Technology, Inc. | Angular distance calculation for BGP best path selection |
US9178797B2 (en) * | 2012-06-30 | 2015-11-03 | Juniper Networks, Inc. | Selective BGP graceful restart in redundant router deployments |
US9686381B1 (en) * | 2013-09-30 | 2017-06-20 | Juniper Networks, Inc. | Control word decapsulation in a hybrid BGP-VPLS network |
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 |
US10084685B2 (en) * | 2015-08-17 | 2018-09-25 | Verizon Patent And Licensing Inc. | Route reflector as a service |
WO2018148302A1 (en) * | 2017-02-07 | 2018-08-16 | Level 3 Communications, Llc | System and method for next hop bgp routing in a network |
-
2019
- 2019-05-21 US US16/418,353 patent/US10764120B1/en active Active
-
2020
- 2020-08-04 US US16/984,530 patent/US11368355B2/en active Active
-
2022
- 2022-05-19 US US17/748,735 patent/US20220278890A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120213218A1 (en) * | 2011-02-19 | 2012-08-23 | Selma Yilmaz | Automatically detecting best paths from shadow route reflectors |
US20140198794A1 (en) * | 2013-01-14 | 2014-07-17 | Apurva Mehta | Connecting multiple customer sites over a wide area network using an overlay network |
US20180367388A1 (en) * | 2017-06-19 | 2018-12-20 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
Also Published As
Publication number | Publication date |
---|---|
US10764120B1 (en) | 2020-09-01 |
US20200412601A1 (en) | 2020-12-31 |
US11368355B2 (en) | 2022-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220278890A1 (en) | Method for Establishing High Resilient Active Recovery for BGP Route Reflectors | |
US8189579B1 (en) | Distributed solution for managing periodic communications in a multi-chassis routing system | |
US10574513B2 (en) | Handling controller and node failure scenarios during data collection | |
US10182105B2 (en) | Policy based framework for application management in a network device having multiple packet-processing nodes | |
Cascone et al. | Fast failure detection and recovery in SDN with stateful data plane | |
JP4790376B2 (en) | Separation of SoftRouter protocol | |
US7752024B2 (en) | Systems and methods for constructing multi-layer topological models of computer networks | |
US7310314B1 (en) | Managing periodic communications | |
CN110784400B (en) | N: 1 method, system and standby service gateway for redundancy of stateful application gateway | |
CN1770743B (en) | Softrouter | |
US7835303B2 (en) | Packet-switched network topology tracking method and system | |
CN110535760B (en) | Forwarding detection of aggregated interfaces | |
US7206309B2 (en) | High availability packet forward apparatus and method | |
US8908676B2 (en) | Automatically detecting best paths from shadow route reflectors | |
US20070097974A1 (en) | Distributed border gateway protocol (BGP) route reflector system | |
KR20150048835A (en) | System and method for supporting discovery and routing degraded fat-trees in a middleware machine environment | |
WO2001086844A1 (en) | Systems and methods for constructing multi-layer topological models of computer networks | |
Abhashkumar et al. | Running {BGP} in Data Centers at Scale | |
Alotaibi et al. | Multidomain sdn-based gateways and border gateway protocol | |
US20080059620A1 (en) | Method and apparatus for persisting SNMP MIB integer indexes across multiple network elements | |
Greenberg et al. | Refactoring network control and management: A case for the 4D architecture | |
Nguyen et al. | A MPLS/LDP distributed architecture for next generation routers | |
Sonderegger et al. | Junos High Availability: Best Practices for High Network Uptime | |
US11627062B2 (en) | Designated intermediate system (DIS) priority changing | |
Kamamura et al. | OSPF and BGP state migration for resource-portable IP router |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: AT&T INTELLECTUAL PROPERTY I, L.P., GEORGIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MEANS, ISRAEL;RAMADENU, PRAVEEN;SIGNING DATES FROM 20190409 TO 20190410;REEL/FRAME:060180/0001 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |