US20100124170A1 - Methods and Apparatus to Detect Border Gateway Protocol Session Failures - Google Patents
Methods and Apparatus to Detect Border Gateway Protocol Session Failures Download PDFInfo
- Publication number
- US20100124170A1 US20100124170A1 US12/275,055 US27505508A US2010124170A1 US 20100124170 A1 US20100124170 A1 US 20100124170A1 US 27505508 A US27505508 A US 27505508A US 2010124170 A1 US2010124170 A1 US 2010124170A1
- Authority
- US
- United States
- Prior art keywords
- route
- list
- provisioned
- bgp
- routes
- 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.)
- Granted
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/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- 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
-
- 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
-
- 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/033—Topology update or discovery by updating distance vector protocols
-
- 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
-
- 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/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
Definitions
- This disclosure relates generally to border gateway protocols (BGPs) and, more particularly, to methods and apparatus to detect BGP session failures.
- BGPs border gateway protocols
- MPLS multiprotocol label switching
- a BGP is traditionally used to route data within a communication network and/or between different communication networks.
- FIG. 1 is a schematic illustration of example communication system constructed in accordance with the teachings of this disclosure.
- FIG. 2 illustrates an example manner of implementing a border gateway protocol (BGP) session monitor for the example communication system of FIG. 1 .
- BGP border gateway protocol
- FIGS. 3-5 are flowcharts representative of example processes that may be carried out to implement the example BGP session monitors of FIGS. 1 and/or 2 .
- FIG. 6 is a schematic illustration of an example processor platform that may be used and/or programmed to carry out the example processes of FIGS. 3-5 and/or to implement any of all of the methods and apparatus disclosed herein.
- a disclosed example apparatus includes a database interface to obtain provisioned configuration information for a provider edge (PE) router, a BGP engine to receive one or more BGP messages from a route reflector, the one or more BGP messages representing a list of active routes for the PE router; and a session analyzer to compare the list of active routes with the provisioned configuration information to determine whether a provisioned route is not present in the list of active routes, and to declare a BGP session failure when the provisioned route is not present in the list of active routes
- PE provider edge
- BGP engine to receive one or more BGP messages from a route reflector, the one or more BGP messages representing a list of active routes for the PE router
- a session analyzer to compare the list of active routes with the provisioned configuration information to determine whether a provisioned route is not present in the list of active routes, and to declare a BGP session failure when the provisioned route is not present in the list of active routes
- a disclosed example method includes obtaining provisioning data for a PE router, receiving one or more BGP messages from a route reflector, the one or more BGP messages representing a list of active routes for the PE router, comparing the list of active routes with the provisioning data to determine whether a provisioned route is not present in the list of active routes, and declaring a BGP session failure when the provisioned route is not present in the list of active routes
- a BGP session failure may be caused by, for example, one or more routes that are down, inoperable and/or flapping, and/or one or more routers and/or network interfaces that are down, inoperable and/or flapping.
- the examples disclosed herein may also be used to detect the cause(s) and/or type(s) of BGP session failure(s) that have and/or are occurring.
- FIG. 1 illustrates the example communication system 100 .
- the example communication system 100 of FIG. 1 includes a multiprotocol label switching (MPLS) based service-provider network 110 . While for ease of illustration and discussion, all of the example CE routers 105 - 108 are associated with a single virtual private network (VPN), the example communication system 100 of FIG. 1 may facilitate communication services for any number of VPNs.
- MPLS multiprotocol label switching
- the example MPLS-based service-provider network 110 of FIG. 1 includes a plurality of PE routers, three of which are designated at reference numerals 115 , 116 , and 117 .
- the example PE routers 115 - 117 of FIG. 1 are communicatively coupled to each other via any number and/or type(s) of communication paths (not shown) that allow any particular PE router 115 - 117 to communicate with at least some, but not necessarily all of, the other PE routers 115 - 117 .
- each of the example PE routers 115 - 117 of FIG. 1 has a corresponding VPN routing and forwarding (VRF) table.
- VRF VPN routing and forwarding
- the PE routers 115 - 117 have a VRF table 120 for the example VPN that communicatively couples the CE routers 105 - 108 .
- the example VRF tables 120 of FIG. 1 are used by the example PE routers 115 - 117 to route and/or forward a packet received at a particular PE router 115 - 117 to and/or toward its final destination.
- the PE router 115 - 117 uses the final destination specified and/or identified in the packet to perform a query of the VRF table 120 associated with that VPN. Based on a result of the query, the PE router 115 - 117 determines how the packet is to be routed or forwarded within the service provider network 110 , and/or delivered to a particular CE router 105 - 108 .
- each of the example PE routers 115 - 117 of FIG. 1 publishes and/or exports information concerning the CE router(s) 105 - 108 that are currently and/or actively communicatively coupled to the PE router 115 - 117 . Isolation between different VPNs is achieved via route targets (RTs), import policies and export policies. Specifically, all routes of a particular VPN are tagged with an RT parameter and/or value associated with the VPN. For example, when the example PE router 116 sends a BGP advertisement containing information regarding the CE router 105 associated with VPN A that is communicatively coupled to the PE router 116 , the BGP advertisement includes the RT A that is associated with VPN A.
- RTs route targets
- the example PE routers 115 - 117 of FIG. 1 build, compile, update, maintain and/or construct a VRF table for each VPN. Specifically, when the example PE routers 115 - 117 receive BGP advertisements tagged with an RT associated with a particular VPN, they import those routes only into the VRF table associated with that VPN, as dictated by the VPN's import policy(-ies).
- the example service provider network 110 of FIG. 1 includes any number of route reflectors, route servers, intelligent route reflectors and/or intelligent route service control points, one of which is designated at reference numeral 125 . Because not all of the example PE routers 115 - 117 are necessarily communicatively coupled in a full mesh topology (for example, when at least one PE router 115 - 117 does not have a direct communication path to another PE router 115 - 117 ), the example route reflector 125 of FIG. 1 forwards BGP advertisements among and/or to the PE routers 115 - 117 .
- the example route reflector 125 By forwarding each received BGP advertisement, the example route reflector 125 enables each of the PE routers 115 - 117 to build, compile and/or construct a VRF table for each VPN that can be used by the PE router 115 - 117 to route data from any CE router 105 - 108 of a particular VPN to any other CE router 105 - 108 of the VPN, even if such routing of data requires use of one or more intervening PE routers 115 - 117 .
- the example PE routers 115 - 117 of FIG. 1 are provisioned and/or configured based on data, information and/or parameters stored in a network and/or VPN configuration database 130 .
- the example configuration database 130 of FIG. 1 defines for each of the example PE routers 115 - 118 and for each VPN supported by the example service-provider network 110 , the set of CE routers 105 - 108 that are supposed to be communicatively coupled to the PE router 115 - 118 .
- a particular PE router 115 - 118 may not be actively and/or currently communicatively coupled and/or coupleable to one or more of the CE routers 115 - 118 despite how the PE routers 115 - 118 and the CE routers 115 - 118 are provisioned.
- Example failures, errors and/or faults include, but are not limited to, network interface faults, router faults, and/or communication path faults.
- the provisioned configuration(s) of the affected PE router(s) 115 - 118 and/or the affected CE router(s) 105 - 108 are likewise updated by the example service-provider network 110 .
- the example service-provider network 110 of FIG. 1 includes a BGP session monitor 135 .
- the example BGP session monitor 135 of FIG. 1 can automatically detect BGP session failures prior to, in some instances, a customer becoming aware of and/or reporting a problem, thereby improving customer satisfaction, improving network reliability and/or avoiding network reachability failures.
- An example manner of implementing the example BGP session monitor 135 of FIG. 1 is described below in connection with FIG. 2 .
- Example processes that may be carried out to implement the example BGP session monitor 135 of FIG. 1 are described below in connection with FIGS. 3-5 .
- the example BGP session monitor 135 of FIG. 1 compares provisioning information and/or data stored in the configuration database 130 with current and/or active route information acquired via received BGP advertisements and/or messages to determine, identify and/or detect routers 105 - 108 , 115 - 117 and/or PE-to-CE routes that have failed, are down, are inoperable, and/or are flapping.
- BGP advertisements and/or messages include, but are not limited to, a BGP message transmitted initial configuration and/or startup to advertise one or more routes, a BGP message transmitted to advertise one or more additional routes, and/or a BGP message transmitted to withdraw one or more routes.
- the term “flapping” refers to a condition characterized by an alternation between two states.
- a flapping network interface alternates between a working state and an inoperative state.
- an example route that is flapping is alternating between an active state and an inactive state.
- the route information acquired via received BGP advertisements is indicative of the currently active and/or currently available routes of the communication system 100 and, as described above, may be different from the provisioned configuration of the communication system 100 .
- the example BGP session monitor 135 of FIG. 1 identifies and/or detects a potential BGP session failure by determining whether a route provisioned in the configuration database 130 is not present in the list of active routes advertised via one or more BGP messages.
- the example BGP session monitor 135 determines the number of times that a provisioned route does not appear as an active route during a sliding window of time to determine whether the route and/or a router or network interface associated with the route is down and/or flapping. For example, if a provisioned route is missing throughout the sliding window interval, the route can be declared as down.
- the example BGP session monitor 135 declares that a network interface of a router shared by all of the missing routes and/or the router itself are down. However, if a provisioned route is only missing for a portion of the sliding window, the provisioned route may instead be flapping between an active state and an inactive state, and may benefit from servicing to avoid a complete failure.
- the example BGP session monitor 135 of FIG. 1 establishes a passive peered BGP communication session with the example route reflector 125 .
- the example route reflector 125 of FIG. 1 sends and/or forwards a copy of each BGP advertisement that it receives to the BGP session monitor 135 via the communication session.
- a service-provider network 110 includes and/or implements more than one route reflector 125 .
- the example BGP session monitor 135 need only establish a passive and/or peering relationship with a representative subset of the route reflectors 125 .
- the BGP session monitor 135 may select a route reflector 125 from each geographic region and/or logical portion of the service-provider network 110 .
- the BGP session monitor 135 of FIG. 1 detects and/or identifies a BGP session failure
- the BGP session monitor 135 automatically generates and/or creates a trouble ticket, and submits the generated trouble ticket to any type of trouble-ticket system 140 .
- the automatically generated trouble ticket includes information useful to effect resolution of the identified problem.
- An example trouble ticket identifies one or more particular routers, network interfaces and/or communication paths that appear to be faulty. That is, the trouble ticket identifies the cause and/or type of the detected and/or identified BGP session failure.
- the example trouble-ticket system 140 of FIG. 1 routes and/or assigns a trouble ticket submitted by the example BGP session monitor 135 to one or more of a customer 150 and/or a work center 155 via any type of interface system 145 .
- the interface system 145 of FIG. 1 can send such notices via pager, text message, email, updated web-based interface display, updated work list, and/or facsimile.
- the example interface system 145 of FIG. 1 implements one or more user interfaces that allow the users 150 and 155 to access the example trouble-ticket system 140 .
- Example user interfaces are web-based interfaces that allow a user to, for example, generate, submit, update, close, forward, route, assign and/or search for trouble tickets.
- While an example communication system has been illustrated in FIG. 1 , one or more of the interfaces, data structures, elements, processes and/or devices illustrated in FIG. 1 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example PE routers 115 - 117 , the example route reflector 125 , the example configuration database 130 , the example BGP session monitor 135 , the example trouble-ticket system 140 , and/or the example interface system 145 of FIG. 1 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware.
- any of the example PE routers 115 - 117 , the example route reflector 125 , the example configuration database 130 , the example BGP session monitor 135 , the example trouble-ticket system 140 , and/or the example interface system 145 may be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc.
- a communication system may include interfaces, data structures, elements, processes and/or devices instead of, or in addition to, those illustrated in FIG. 1 and/or may include more than one of any or all of the illustrated interfaces, data structures, elements, processes and/or devices.
- FIG. 2 illustrates an example manner of implementing the example BGP session monitor 135 of FIG. 1 .
- the example BGP session monitor 135 of FIG. 2 includes any type(s) and/or number of network interfaces, one of which is designated at reference numeral 205 .
- An example network interface 205 is implemented in accordance with any past, present and/or future standard, recommendation and/or specification for Ethernet transceivers.
- the example BGP session monitor 135 of FIG. 2 includes any type of multi-protocol BGP engine 210 .
- the example multi-protocol BGP engine 210 of FIG. 2 stores the routes advertised in the BGP route advertisement in a production route database 215 using, for example, a flat file format.
- the example multi-protocol BGP engine 210 also establishes a passive peered BGP communication session via which BGP advertisements are received from the route reflector 125 .
- the example BGP session monitor 135 of FIG. 2 includes any type of configuration database interface 220 .
- the example configuration database interface 220 allows a BGP session analyzer 225 to obtain data and/or information representative of provisioned routes for the example communication system 100 ( FIG. 1 ).
- the example BGP session monitor 135 of FIG. 2 includes the example BGP session analyzer 225 .
- the example BGP session analyzer 225 of FIG. 2 compares the list of active and/or current routes stored in the production route database 215 with a list of provisioned routes obtained via the configuration database interface 220 to identify provisioned routes that are not currently active and/or available within the communication system 100 ( FIG. 1 ). Such routes may be indicative of down, failed and/or flapping routes, routers and/or network interfaces.
- Example processes that may be carried out to implement the example BGP session analyzer 225 and/or, more generally, the example BGP session monitor 135 are described below in connection with FIGS. 3 and 4 .
- the example BGP session monitor 135 of FIG. 2 includes a missing route analyzer 230 .
- the example missing route analyzer 230 of FIG. 2 determines and/or counts the number of times that the provisioned route has been missing during a time period, and whether other routes associated with the missing provisioned route are also missing. By analyzing the pattern of missing routes, the example missing route analyzer 230 determines whether and/or which router(s), network interface(s) and/or communication path(s) are down, failed and/or flapping.
- An example process that may be carried out to implement the example missing route analyzer 230 and/or, more generally, the example BGP session monitor 135 is described below in connection with FIG. 5 .
- the example BGP session monitor 135 of FIG. 2 includes any type of trouble-ticket system interface 235 .
- the example missing route analyzer 230 identifies one or more routes, network interfaces and/or communication paths that are down, failed and/or flapping
- the example trouble-ticket system interface 235 of FIG. 2 generates and submits one or more corresponding trouble tickets to the example trouble-ticket system 140 ( FIG. 1 ) via the network interface 205 .
- While an example BGP session monitor 135 has been illustrated in FIG. 2 , one or more of the interfaces, data structures, elements, processes and/or devices illustrated in FIG. 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example network interface 205 , the example multi-protocol BGP engine 210 , the example production route database 215 , the example configuration database interface 220 , the example BGP session analyzer 225 , the example missing route analyzer 230 , the example trouble-ticket system interface 235 and/or, more generally, the example BGP session monitor 135 of FIG. 2 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware.
- any or the example network interface 205 , the example multi-protocol BGP engine 210 , the example production route database 215 , the example configuration database interface 220 , the example BGP session analyzer 225 , the example missing route analyzer 230 , the example trouble-ticket system interface 235 and/or, more generally, the example BGP session monitor 135 may be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc.
- ASIC application specific integrated circuit
- PLD programmable logic device
- FPLD field programmable logic device
- a BGP session monitor may include interfaces, data structures, elements, processes and/or devices instead of, or in addition to, those illustrated in FIG. 2 and/or may include more than one of any or all of the illustrated interfaces, data structures, elements, processes and/or devices.
- a BGP session monitor may implement network interfaces for respective ones of the multi-protocol BGP engine 210 , the example configuration database interface 220 and the example trouble-ticket system interface 235 .
- FIGS. 3-5 illustrate flowcharts representative of example processes that may be carried out to implement the example BGP session monitor 135 of FIGS. 1 and/or 2 .
- the example processes of FIGS. 3-5 may be carried out by a processor, a controller and/or any other suitable processing device.
- 3-5 may be embodied in coded instructions stored on any tangible computer-readable medium such as a flash memory, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a read-only memory (ROM), a random-access memory (RAM), a programmable ROM (PROM), an electronically-programmable ROM (EPROM), and/or an electronically-erasable PROM (EEPROM), an optical storage disk, an optical storage device, magnetic storage disk, a magnetic storage device, and/or any other medium which can be used to carry or store program code and/or instructions in the form of machine-accessible instructions or data structures, and which can be accessed by a processor, a general-purpose or special-purpose computer, or other machine with a processor (e.g., the example processor platform P 100 discussed below in connection with FIG.
- a processor e.g., the example processor platform P 100 discussed below in connection with FIG.
- Machine-accessible instructions comprise, for example, instructions and/or data that cause a processor, a general-purpose computer, special-purpose computer, or a special-purpose processing machine to implement one or more particular processes.
- some or all of the example processes of FIGS. 3-5 may be implemented using any combination(s) of ASIC(s), PLD(s), FPLD(s), discrete logic, hardware, firmware, etc.
- some or all of the example processes of FIGS. 3-5 may instead be implemented manually or as any combination of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, many other methods of implementing the example operations of FIGS.
- 3-5 may be employed.
- the order of execution of the blocks may be changed, and/or one or more of the blocks described may be changed, eliminated, sub-divided, or combined.
- any or all of the example processes of FIGS. 3-5 may be carried out sequentially and/or carried out in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc.
- the example process of FIG. 3 begins with the example BGP session monitor 135 ( FIG. 1 ) selecting one or more route reflectors 125 (block 305 ), and the example BGP engine 210 ( FIG. 2 ) establishing passive and/or peered communication sessions with the selected route reflector(s) 125 (block 310 ).
- the BGP session monitor 135 sets a variable t to zero, for each provisioned route sets a variable Cij to zero, and opens a new data file in the production route database 215 to store a list of routes advertised in received BGP messages during an upcoming period of time (block 315 ).
- the BGP engine 210 begins to send keep alive messages to the route reflector 125 and to receive BGP advertisements from the route reflector 125 (block 320 ).
- the BGP engine 210 stores route information contained in received BGP advertisements into the open data file (block 330 ), and updates the variable t (block 335 ). Control then returns to block 320 to continue sending keep alive messages and received BGP advertisements.
- the variable t is implementing using a real-time clock. For instance, the real-time clock can be reset at block 315 and then the output of the real-time clock can be compared with the value T to detect the end of each BGP advertisement collection period. Additionally or alternatively, the value T can represent a future time such that it is not necessary to reset the real-time clock. That is, T can be computed by adding a length of time to the current output of the real-time clock.
- the BGP session monitor 135 closes the current data file (block 340 ), and resets the variable t to zero and opens a new data file (block 345 ).
- the example BGP session analyzer 225 processes the production route list stored in the closed data file (block 350 ) by, for example, carrying out the example processes of FIGS. 4 and 5 . That is, all BGP messages receiving during a particular period of time of length T are saved in a data file.
- the data file is closed (block 340 ) and processed (block 350 ), and another data file is opened for subsequent BGP messages (block 345 ). Control then returns to block 320 to continue sending keep alive messages and received BGP advertisements. While not depicted in FIG. 3 , processing of the previously collected active route information at block 350 continues in parallel with the collection of active route information in the newly opened data file.
- the example process of FIG. 4 can be carried out to compare an active list of routes with a provisioned list of routes to identify missing routes and to identify one or more reasons for the missing route(s).
- the example process of FIG. 4 begins with the example BGP session analyzer 225 of FIG. 2 compiling a list of active routes that were advertised during the previous time period (block 405 ).
- the BGP session analyzer 225 compiles an ordered list of advertised routes and removes duplicate routes.
- the example BGP session analyzer 225 obtains a list of provisioned routes via the example configuration database interface 220 (block 410 ), and compares the list of advertised routes to the list of provisioned routes (block 415 ).
- the BGP session analyzer 225 checks whether the variable Cij associated with the route(i,j) is equal to a variable C that represents the length of a sliding window (block 420 ). When the end of the sliding window for the route(i,j) is reached (block 420 ), the BGP session analyzer 225 resets the variable Cij (block 425 ). The BGP session monitor 225 determines whether the provisioned route(i,j) is missing from the list of advertised routes (block 430 ). If the provisioned route(i,j) is missing (block 430 ), the example missing route analyzer 230 analyzes the missing route by, for example, carrying out the example process of FIG. 5 (block 435 ). If there are more routes to process (block 440 ), control returns to block 420 to process the next route.
- control proceeds to block 440 without further analyzing the route(i,j).
- the BGP session analyzer 225 increments the value of the variable Cij (block 450 ).
- the example process of FIG. 5 can be carried out to analyze a missing provisioned route(i,j) identified by the BGP session analyzer 225 .
- the example process of FIG. 5 can be called from block 435 of the example process of FIG. 4 .
- the example process of FIG. 5 begins with the example missing route analyzer 230 of FIG. 3 comparing the variable Cij to zero (block 505 ). If the variable Cij is zero (block 505 ), the missing route analyzer 230 initializes a variable Mij, which is used to represent the number of times the route(i,j) is missing, to one and initializes the variable Cij to one to start a sliding window time interval for the route(i,j) (block 510 ). Control then returns from the example process of FIG. 5 to, for example, the example process of FIG. 4 at block 435 .
- the missing route analyzer 230 increments the variable Mij to indicate that the route(i,j) was missing another time (block 515 ). If the end of the sliding window for the provisioned route(i,j) has not been reached (block 520 ), control returns from the example process of FIG. 5 to, for example, the example process of FIG. 4 at block 435 .
- the missing route analyzer 230 compares the variable Mij with a threshold M (block 525 ). If the variable Mij is less than the threshold M (block 525 ), control returns from the example process of FIG. 5 to, for example, the example process of FIG. 4 at block 435 without declaring a BGP session failure.
- the value of the threshold M is selected to avoid false BGP session failure declarations when a particular route is not always advertised during each time interval T, where T represents the length of each BGP message collection window.
- the missing route analyzer 230 determines whether the variable Mij is less than a threshold C x .
- the threshold C x is less or equal to C (block 530 ). In some example, the threshold C x is selected to be equal to C. If the variable Mij is less than C x (block 530 ), the provisioned route(i,j) is declared to be flapping (block 535 ). If during the sliding window all routes(all,j) or all routes(i,all) were either flapping or down (block 540 ), the example trouble-ticket system interface 235 of FIG.
- the provisioned route(i,j) is declared to be down (block 555 ). If during the sliding window all routes(all,j) or all routes(i,all) were down (block 560 ), the example trouble-ticket system interface 235 of FIG. 2 creates and submits a trouble ticket indicating that router i or router j is down (block 565 ). Otherwise (block 560 ), the example trouble-ticket system interface 235 creates and submits a trouble ticket indicating that route(i,j) is down (block 570 ). Control returns from the example process of FIG. 5 to, for example, the example process of FIG. 4 at block 435 .
- FIG. 6 is a schematic diagram of an example processor platform P 100 that may be used and/or programmed to implement the example BGP session monitor 135 of FIGS. 1 and/or 2 .
- the processor platform P 100 can be implemented by one or more general-purpose processors, processor cores, microcontrollers, etc.
- the processor platform P 100 of the example of FIG. 6 includes at least one general purpose programmable processor P 105 .
- the processor P 105 executes coded instructions P 110 and/or P 112 present in main memory of the processor P 105 (e.g., within a RAM P 115 and/or a ROM P 120 ).
- the processor P 105 may be any type of processing unit, such as a processor core, a processor and/or a microcontroller.
- the processor P 105 may execute, among other things, the example processes of FIGS. 3-5 to implement the example methods and apparatus described herein.
- the processor P 105 is in communication with the main memory (including a ROM P 120 and/or the RAM P 115 ) via a bus P 125 .
- the RAM P 115 may be implemented by DRAM, SDRAM, and/or any other type of RAM device, and ROM may be implemented by flash memory and/or any other desired type of memory device. Access to the memory P 115 and the memory P 120 may be controlled by a memory controller (not shown).
- One or both of the example memories P 115 and P 120 may be used to implement the example configuration database 130 of FIG. 1 and/or the example production route database 215 of FIG. 2 .
- the processor platform P 100 also includes an interface circuit P 130 .
- the interface circuit P 130 may be implemented by any type of interface standard, such as an external memory interface, serial port, general-purpose input/output, etc.
- One or more input devices P 135 and one or more output devices P 140 are connected to the interface circuit P 130 .
- the input devices P 135 and/or output devices P 140 may be used to, for example, implement the network interface 205 of FIG. 2 .
Abstract
Description
- This disclosure relates generally to border gateway protocols (BGPs) and, more particularly, to methods and apparatus to detect BGP session failures.
- Enterprise customers are increasingly adopting multiprotocol label switching (MPLS) based VPN services to implement a communication network among their respective customer sites via a service provider's network. Such MPLS-based VPNs provide direct any-to-any reachability among an enterprise's customer sites. A BGP is traditionally used to route data within a communication network and/or between different communication networks.
-
FIG. 1 is a schematic illustration of example communication system constructed in accordance with the teachings of this disclosure. -
FIG. 2 illustrates an example manner of implementing a border gateway protocol (BGP) session monitor for the example communication system ofFIG. 1 . -
FIGS. 3-5 are flowcharts representative of example processes that may be carried out to implement the example BGP session monitors ofFIGS. 1 and/or 2. -
FIG. 6 is a schematic illustration of an example processor platform that may be used and/or programmed to carry out the example processes ofFIGS. 3-5 and/or to implement any of all of the methods and apparatus disclosed herein. - Example methods and apparatus to detect border gateway protocol (BGP) session failures are disclosed. A disclosed example apparatus includes a database interface to obtain provisioned configuration information for a provider edge (PE) router, a BGP engine to receive one or more BGP messages from a route reflector, the one or more BGP messages representing a list of active routes for the PE router; and a session analyzer to compare the list of active routes with the provisioned configuration information to determine whether a provisioned route is not present in the list of active routes, and to declare a BGP session failure when the provisioned route is not present in the list of active routes
- A disclosed example method includes obtaining provisioning data for a PE router, receiving one or more BGP messages from a route reflector, the one or more BGP messages representing a list of active routes for the PE router, comparing the list of active routes with the provisioning data to determine whether a provisioned route is not present in the list of active routes, and declaring a BGP session failure when the provisioned route is not present in the list of active routes
- In the interest of brevity and clarity, throughout the following disclosure references will be made to an
example communication system 100 ofFIG. 1 . However, the methods and apparatus described herein to detect BGP session failures are applicable to other types of networks constructed using other network technologies, topologies and/or protocols. As described herein, a BGP session failure may be caused by, for example, one or more routes that are down, inoperable and/or flapping, and/or one or more routers and/or network interfaces that are down, inoperable and/or flapping. The examples disclosed herein may also be used to detect the cause(s) and/or type(s) of BGP session failure(s) that have and/or are occurring. -
FIG. 1 illustrates theexample communication system 100. To facilitate communication services between a plurality of customer edge (CE) routers, four of which are designated atreference numerals example communication system 100 ofFIG. 1 includes a multiprotocol label switching (MPLS) based service-provider network 110. While for ease of illustration and discussion, all of the example CE routers 105-108 are associated with a single virtual private network (VPN), theexample communication system 100 ofFIG. 1 may facilitate communication services for any number of VPNs. - To route and/or transport data between and/or among the example CE routers 105-108, the example MPLS-based service-
provider network 110 ofFIG. 1 includes a plurality of PE routers, three of which are designated atreference numerals FIG. 1 are communicatively coupled to each other via any number and/or type(s) of communication paths (not shown) that allow any particular PE router 115-117 to communicate with at least some, but not necessarily all of, the other PE routers 115-117. - For each VPN implemented by the service-
provider network 110, each of the example PE routers 115-117 ofFIG. 1 has a corresponding VPN routing and forwarding (VRF) table. In the illustrated example ofFIG. 1 , the PE routers 115-117 have a VRF table 120 for the example VPN that communicatively couples the CE routers 105-108. The example VRF tables 120 ofFIG. 1 are used by the example PE routers 115-117 to route and/or forward a packet received at a particular PE router 115-117 to and/or toward its final destination. In general, when a packet is received at a PE router 115-117 from a CE router 105-108 associated with a particular VPN, the PE router 115-117 uses the final destination specified and/or identified in the packet to perform a query of the VRF table 120 associated with that VPN. Based on a result of the query, the PE router 115-117 determines how the packet is to be routed or forwarded within theservice provider network 110, and/or delivered to a particular CE router 105-108. - By sending, for example, BGP route advertisements, each of the example PE routers 115-117 of
FIG. 1 publishes and/or exports information concerning the CE router(s) 105-108 that are currently and/or actively communicatively coupled to the PE router 115-117. Isolation between different VPNs is achieved via route targets (RTs), import policies and export policies. Specifically, all routes of a particular VPN are tagged with an RT parameter and/or value associated with the VPN. For example, when theexample PE router 116 sends a BGP advertisement containing information regarding theCE router 105 associated with VPN A that is communicatively coupled to thePE router 116, the BGP advertisement includes the RT A that is associated with VPN A. Based on received BGP route advertisements, the example PE routers 115-117 ofFIG. 1 build, compile, update, maintain and/or construct a VRF table for each VPN. Specifically, when the example PE routers 115-117 receive BGP advertisements tagged with an RT associated with a particular VPN, they import those routes only into the VRF table associated with that VPN, as dictated by the VPN's import policy(-ies). - To facilitate sharing of routing information among the example PE routers 115-117, the example
service provider network 110 ofFIG. 1 includes any number of route reflectors, route servers, intelligent route reflectors and/or intelligent route service control points, one of which is designated atreference numeral 125. Because not all of the example PE routers 115-117 are necessarily communicatively coupled in a full mesh topology (for example, when at least one PE router 115-117 does not have a direct communication path to another PE router 115-117), theexample route reflector 125 ofFIG. 1 forwards BGP advertisements among and/or to the PE routers 115-117. By forwarding each received BGP advertisement, theexample route reflector 125 enables each of the PE routers 115-117 to build, compile and/or construct a VRF table for each VPN that can be used by the PE router 115-117 to route data from any CE router 105-108 of a particular VPN to any other CE router 105-108 of the VPN, even if such routing of data requires use of one or more intervening PE routers 115-117. - The example PE routers 115-117 of
FIG. 1 are provisioned and/or configured based on data, information and/or parameters stored in a network and/orVPN configuration database 130. Theexample configuration database 130 ofFIG. 1 defines for each of the example PE routers 115-118 and for each VPN supported by the example service-provider network 110, the set of CE routers 105-108 that are supposed to be communicatively coupled to the PE router 115-118. However, due to any number and/or type(s) of failures, errors, and/or faults, a particular PE router 115-118 may not be actively and/or currently communicatively coupled and/or coupleable to one or more of the CE routers 115-118 despite how the PE routers 115-118 and the CE routers 115-118 are provisioned. Example failures, errors and/or faults include, but are not limited to, network interface faults, router faults, and/or communication path faults. When an operator of a particular VPN and/or an operator of the service-provider network 110 updates theexample configuration database 130, the provisioned configuration(s) of the affected PE router(s) 115-118 and/or the affected CE router(s) 105-108 are likewise updated by the example service-provider network 110. - To proactively detect BGP session failures, the example service-
provider network 110 ofFIG. 1 includes aBGP session monitor 135. By monitoring BGP session status information for thecommunication system 100, the exampleBGP session monitor 135 ofFIG. 1 can automatically detect BGP session failures prior to, in some instances, a customer becoming aware of and/or reporting a problem, thereby improving customer satisfaction, improving network reliability and/or avoiding network reachability failures. An example manner of implementing the exampleBGP session monitor 135 ofFIG. 1 is described below in connection withFIG. 2 . Example processes that may be carried out to implement the exampleBGP session monitor 135 ofFIG. 1 are described below in connection withFIGS. 3-5 . - The example
BGP session monitor 135 ofFIG. 1 compares provisioning information and/or data stored in theconfiguration database 130 with current and/or active route information acquired via received BGP advertisements and/or messages to determine, identify and/or detect routers 105-108, 115-117 and/or PE-to-CE routes that have failed, are down, are inoperable, and/or are flapping. BGP advertisements and/or messages include, but are not limited to, a BGP message transmitted initial configuration and/or startup to advertise one or more routes, a BGP message transmitted to advertise one or more additional routes, and/or a BGP message transmitted to withdraw one or more routes. As used herein, the term “flapping” refers to a condition characterized by an alternation between two states. For example, a flapping network interface alternates between a working state and an inoperative state. Likewise, an example route that is flapping is alternating between an active state and an inactive state. The route information acquired via received BGP advertisements is indicative of the currently active and/or currently available routes of thecommunication system 100 and, as described above, may be different from the provisioned configuration of thecommunication system 100. - The example
BGP session monitor 135 ofFIG. 1 identifies and/or detects a potential BGP session failure by determining whether a route provisioned in theconfiguration database 130 is not present in the list of active routes advertised via one or more BGP messages. In examples described herein, the exampleBGP session monitor 135 determines the number of times that a provisioned route does not appear as an active route during a sliding window of time to determine whether the route and/or a router or network interface associated with the route is down and/or flapping. For example, if a provisioned route is missing throughout the sliding window interval, the route can be declared as down. If other routes associated with the down provisioned route are likewise down, the exampleBGP session monitor 135 declares that a network interface of a router shared by all of the missing routes and/or the router itself are down. However, if a provisioned route is only missing for a portion of the sliding window, the provisioned route may instead be flapping between an active state and an inactive state, and may benefit from servicing to avoid a complete failure. - To obtain active and/or current route information, the example
BGP session monitor 135 ofFIG. 1 establishes a passive peered BGP communication session with theexample route reflector 125. Theexample route reflector 125 ofFIG. 1 sends and/or forwards a copy of each BGP advertisement that it receives to theBGP session monitor 135 via the communication session. In many examples, a service-provider network 110 includes and/or implements more than oneroute reflector 125. However, becausesuch route reflectors 125 are implemented, coupled and/or located to distribute BGP advertisements throughout theentire network 110, the exampleBGP session monitor 135 need only establish a passive and/or peering relationship with a representative subset of theroute reflectors 125. For example, the BGPsession monitor 135 may select aroute reflector 125 from each geographic region and/or logical portion of the service-provider network 110. - When the example BGP session monitor 135 of
FIG. 1 detects and/or identifies a BGP session failure, theBGP session monitor 135 automatically generates and/or creates a trouble ticket, and submits the generated trouble ticket to any type of trouble-ticket system 140. In the illustrated example ofFIG. 1 , the automatically generated trouble ticket includes information useful to effect resolution of the identified problem. An example trouble ticket identifies one or more particular routers, network interfaces and/or communication paths that appear to be faulty. That is, the trouble ticket identifies the cause and/or type of the detected and/or identified BGP session failure. - The example trouble-
ticket system 140 ofFIG. 1 routes and/or assigns a trouble ticket submitted by the example BGP session monitor 135 to one or more of acustomer 150 and/or awork center 155 via any type ofinterface system 145. For example, theinterface system 145 ofFIG. 1 can send such notices via pager, text message, email, updated web-based interface display, updated work list, and/or facsimile. Additionally, theexample interface system 145 ofFIG. 1 implements one or more user interfaces that allow theusers ticket system 140. Example user interfaces are web-based interfaces that allow a user to, for example, generate, submit, update, close, forward, route, assign and/or search for trouble tickets. - While an example communication system has been illustrated in
FIG. 1 , one or more of the interfaces, data structures, elements, processes and/or devices illustrated inFIG. 1 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example PE routers 115-117, theexample route reflector 125, theexample configuration database 130, the example BGP session monitor 135, the example trouble-ticket system 140, and/or theexample interface system 145 ofFIG. 1 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example PE routers 115-117, theexample route reflector 125, theexample configuration database 130, the example BGP session monitor 135, the example trouble-ticket system 140, and/or theexample interface system 145 may be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. Further still, a communication system may include interfaces, data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIG. 1 and/or may include more than one of any or all of the illustrated interfaces, data structures, elements, processes and/or devices. -
FIG. 2 illustrates an example manner of implementing the example BGP session monitor 135 ofFIG. 1 . To implement one or more interfaces to theexample route reflector 125, theexample configuration database 130 and/or the example trouble-ticket system 140, the example BGP session monitor 135 ofFIG. 2 includes any type(s) and/or number of network interfaces, one of which is designated atreference numeral 205. Anexample network interface 205 is implemented in accordance with any past, present and/or future standard, recommendation and/or specification for Ethernet transceivers. - To send, receive and process BGP route advertisements, the example BGP session monitor 135 of
FIG. 2 includes any type ofmulti-protocol BGP engine 210. When a BGP route advertisement is received from theexample route reflector 125 via theexample network interface 205, the examplemulti-protocol BGP engine 210 ofFIG. 2 stores the routes advertised in the BGP route advertisement in aproduction route database 215 using, for example, a flat file format. The examplemulti-protocol BGP engine 210 also establishes a passive peered BGP communication session via which BGP advertisements are received from theroute reflector 125. - To obtain provisioning data and/or information, the example BGP session monitor 135 of
FIG. 2 includes any type of configuration database interface 220. Using any number and/or type(s) of method(s) and/or application programming interface(s), the example configuration database interface 220 allows aBGP session analyzer 225 to obtain data and/or information representative of provisioned routes for the example communication system 100 (FIG. 1 ). - To identify missing routes, the example BGP session monitor 135 of
FIG. 2 includes the exampleBGP session analyzer 225. The exampleBGP session analyzer 225 ofFIG. 2 compares the list of active and/or current routes stored in theproduction route database 215 with a list of provisioned routes obtained via the configuration database interface 220 to identify provisioned routes that are not currently active and/or available within the communication system 100 (FIG. 1 ). Such routes may be indicative of down, failed and/or flapping routes, routers and/or network interfaces. Example processes that may be carried out to implement the exampleBGP session analyzer 225 and/or, more generally, the example BGP session monitor 135 are described below in connection withFIGS. 3 and 4 . - To analyze missing routes identified by the example
BGP session analyzer 225, the example BGP session monitor 135 ofFIG. 2 includes a missingroute analyzer 230. For a missing route, the example missingroute analyzer 230 ofFIG. 2 determines and/or counts the number of times that the provisioned route has been missing during a time period, and whether other routes associated with the missing provisioned route are also missing. By analyzing the pattern of missing routes, the example missingroute analyzer 230 determines whether and/or which router(s), network interface(s) and/or communication path(s) are down, failed and/or flapping. An example process that may be carried out to implement the example missingroute analyzer 230 and/or, more generally, the example BGP session monitor 135 is described below in connection withFIG. 5 . - To generate and submit trouble tickets, the example BGP session monitor 135 of
FIG. 2 includes any type of trouble-ticket system interface 235. When the example missingroute analyzer 230 identifies one or more routes, network interfaces and/or communication paths that are down, failed and/or flapping, the example trouble-ticket system interface 235 ofFIG. 2 generates and submits one or more corresponding trouble tickets to the example trouble-ticket system 140 (FIG. 1 ) via thenetwork interface 205. - While an example BGP session monitor 135 has been illustrated in
FIG. 2 , one or more of the interfaces, data structures, elements, processes and/or devices illustrated inFIG. 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, theexample network interface 205, the examplemulti-protocol BGP engine 210, the exampleproduction route database 215, the example configuration database interface 220, the exampleBGP session analyzer 225, the example missingroute analyzer 230, the example trouble-ticket system interface 235 and/or, more generally, the example BGP session monitor 135 ofFIG. 2 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any or theexample network interface 205, the examplemulti-protocol BGP engine 210, the exampleproduction route database 215, the example configuration database interface 220, the exampleBGP session analyzer 225, the example missingroute analyzer 230, the example trouble-ticket system interface 235 and/or, more generally, the example BGP session monitor 135 may be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)), etc. Further still, a BGP session monitor may include interfaces, data structures, elements, processes and/or devices instead of, or in addition to, those illustrated inFIG. 2 and/or may include more than one of any or all of the illustrated interfaces, data structures, elements, processes and/or devices. For example, a BGP session monitor may implement network interfaces for respective ones of themulti-protocol BGP engine 210, the example configuration database interface 220 and the example trouble-ticket system interface 235. -
FIGS. 3-5 illustrate flowcharts representative of example processes that may be carried out to implement the example BGP session monitor 135 ofFIGS. 1 and/or 2. The example processes ofFIGS. 3-5 may be carried out by a processor, a controller and/or any other suitable processing device. For example, the example processes ofFIGS. 3-5 may be embodied in coded instructions stored on any tangible computer-readable medium such as a flash memory, a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a read-only memory (ROM), a random-access memory (RAM), a programmable ROM (PROM), an electronically-programmable ROM (EPROM), and/or an electronically-erasable PROM (EEPROM), an optical storage disk, an optical storage device, magnetic storage disk, a magnetic storage device, and/or any other medium which can be used to carry or store program code and/or instructions in the form of machine-accessible instructions or data structures, and which can be accessed by a processor, a general-purpose or special-purpose computer, or other machine with a processor (e.g., the example processor platform P100 discussed below in connection withFIG. 6 ). Combinations of the above are also included within the scope of computer-readable media. Machine-accessible instructions comprise, for example, instructions and/or data that cause a processor, a general-purpose computer, special-purpose computer, or a special-purpose processing machine to implement one or more particular processes. Alternatively, some or all of the example processes ofFIGS. 3-5 may be implemented using any combination(s) of ASIC(s), PLD(s), FPLD(s), discrete logic, hardware, firmware, etc. Also, some or all of the example processes ofFIGS. 3-5 may instead be implemented manually or as any combination of any of the foregoing techniques, for example, any combination of firmware, software, discrete logic and/or hardware. Further, many other methods of implementing the example operations ofFIGS. 3-5 may be employed. For example, the order of execution of the blocks may be changed, and/or one or more of the blocks described may be changed, eliminated, sub-divided, or combined. Additionally, any or all of the example processes ofFIGS. 3-5 may be carried out sequentially and/or carried out in parallel by, for example, separate processing threads, processors, devices, discrete logic, circuits, etc. - The example process of
FIG. 3 begins with the example BGP session monitor 135 (FIG. 1 ) selecting one or more route reflectors 125 (block 305), and the example BGP engine 210 (FIG. 2 ) establishing passive and/or peered communication sessions with the selected route reflector(s) 125 (block 310). The BGP session monitor 135 sets a variable t to zero, for each provisioned route sets a variable Cij to zero, and opens a new data file in theproduction route database 215 to store a list of routes advertised in received BGP messages during an upcoming period of time (block 315). TheBGP engine 210 begins to send keep alive messages to theroute reflector 125 and to receive BGP advertisements from the route reflector 125 (block 320). Until the variable t equals a length T of the time period (block 325), theBGP engine 210 stores route information contained in received BGP advertisements into the open data file (block 330), and updates the variable t (block 335). Control then returns to block 320 to continue sending keep alive messages and received BGP advertisements. In some examples, the variable t is implementing using a real-time clock. For instance, the real-time clock can be reset atblock 315 and then the output of the real-time clock can be compared with the value T to detect the end of each BGP advertisement collection period. Additionally or alternatively, the value T can represent a future time such that it is not necessary to reset the real-time clock. That is, T can be computed by adding a length of time to the current output of the real-time clock. - At the end of the time period (block 325), the BGP session monitor 135 closes the current data file (block 340), and resets the variable t to zero and opens a new data file (block 345). The example BGP session analyzer 225 (
FIG. 2 ) processes the production route list stored in the closed data file (block 350) by, for example, carrying out the example processes ofFIGS. 4 and 5 . That is, all BGP messages receiving during a particular period of time of length T are saved in a data file. At the end of each period of time (block 325), the data file is closed (block 340) and processed (block 350), and another data file is opened for subsequent BGP messages (block 345). Control then returns to block 320 to continue sending keep alive messages and received BGP advertisements. While not depicted inFIG. 3 , processing of the previously collected active route information atblock 350 continues in parallel with the collection of active route information in the newly opened data file. - The example process of
FIG. 4 can be carried out to compare an active list of routes with a provisioned list of routes to identify missing routes and to identify one or more reasons for the missing route(s). The example process ofFIG. 4 begins with the exampleBGP session analyzer 225 ofFIG. 2 compiling a list of active routes that were advertised during the previous time period (block 405). In some examples, theBGP session analyzer 225 compiles an ordered list of advertised routes and removes duplicate routes. The exampleBGP session analyzer 225 obtains a list of provisioned routes via the example configuration database interface 220 (block 410), and compares the list of advertised routes to the list of provisioned routes (block 415). - For a presently considered provisioned route(i,j), the
BGP session analyzer 225 checks whether the variable Cij associated with the route(i,j) is equal to a variable C that represents the length of a sliding window (block 420). When the end of the sliding window for the route(i,j) is reached (block 420), theBGP session analyzer 225 resets the variable Cij (block 425). The BGP session monitor 225 determines whether the provisioned route(i,j) is missing from the list of advertised routes (block 430). If the provisioned route(i,j) is missing (block 430), the example missingroute analyzer 230 analyzes the missing route by, for example, carrying out the example process ofFIG. 5 (block 435). If there are more routes to process (block 440), control returns to block 420 to process the next route. - Returning to block 430, if the provisioned route(i,j) is not missing (block 430), control proceeds to block 440 without further analyzing the route(i,j).
- Returning to block 420, if the variable Cij is not equal to C (block 420) and the variable Cij is not equal to zero (block 445), the
BGP session analyzer 225 increments the value of the variable Cij (block 450). - The example process of
FIG. 5 can be carried out to analyze a missing provisioned route(i,j) identified by theBGP session analyzer 225. For example, the example process ofFIG. 5 can be called fromblock 435 of the example process ofFIG. 4 . The example process ofFIG. 5 begins with the example missingroute analyzer 230 ofFIG. 3 comparing the variable Cij to zero (block 505). If the variable Cij is zero (block 505), the missingroute analyzer 230 initializes a variable Mij, which is used to represent the number of times the route(i,j) is missing, to one and initializes the variable Cij to one to start a sliding window time interval for the route(i,j) (block 510). Control then returns from the example process ofFIG. 5 to, for example, the example process ofFIG. 4 atblock 435. - If the variable Cij is not zero (block 505), the missing
route analyzer 230 increments the variable Mij to indicate that the route(i,j) was missing another time (block 515). If the end of the sliding window for the provisioned route(i,j) has not been reached (block 520), control returns from the example process ofFIG. 5 to, for example, the example process ofFIG. 4 atblock 435. - If the end of the sliding window for the provisioned route(i,j) has been reached (block 520), the missing
route analyzer 230 compares the variable Mij with a threshold M (block 525). If the variable Mij is less than the threshold M (block 525), control returns from the example process ofFIG. 5 to, for example, the example process ofFIG. 4 atblock 435 without declaring a BGP session failure. The value of the threshold M is selected to avoid false BGP session failure declarations when a particular route is not always advertised during each time interval T, where T represents the length of each BGP message collection window. - Returning to block 525, if the variable Mij is greater than or equal to M (block 525), the missing
route analyzer 230 determines whether the variable Mij is less than a threshold Cx. The threshold Cx is less or equal to C (block 530). In some example, the threshold Cx is selected to be equal to C. If the variable Mij is less than Cx (block 530), the provisioned route(i,j) is declared to be flapping (block 535). If during the sliding window all routes(all,j) or all routes(i,all) were either flapping or down (block 540), the example trouble-ticket system interface 235 ofFIG. 2 creates and submits a trouble ticket indicating that either router i or router j is flapping (block 545). Otherwise (block 540), the example trouble-ticket system interface 235 creates and submits a trouble ticket indicating that route(i,j) is flapping (block 550). Control returns from the example process ofFIG. 5 to, for example, the example process ofFIG. 4 atblock 435. - Returning to block 530, if the variable Mij is not less than the threshold Cx (block 530), the provisioned route(i,j) is declared to be down (block 555). If during the sliding window all routes(all,j) or all routes(i,all) were down (block 560), the example trouble-
ticket system interface 235 ofFIG. 2 creates and submits a trouble ticket indicating that router i or router j is down (block 565). Otherwise (block 560), the example trouble-ticket system interface 235 creates and submits a trouble ticket indicating that route(i,j) is down (block 570). Control returns from the example process ofFIG. 5 to, for example, the example process ofFIG. 4 atblock 435. -
FIG. 6 is a schematic diagram of an example processor platform P100 that may be used and/or programmed to implement the example BGP session monitor 135 ofFIGS. 1 and/or 2. For example, the processor platform P100 can be implemented by one or more general-purpose processors, processor cores, microcontrollers, etc. - The processor platform P100 of the example of
FIG. 6 includes at least one general purpose programmable processor P105. The processor P105 executes coded instructions P110 and/or P112 present in main memory of the processor P105 (e.g., within a RAM P115 and/or a ROM P120). The processor P105 may be any type of processing unit, such as a processor core, a processor and/or a microcontroller. The processor P105 may execute, among other things, the example processes ofFIGS. 3-5 to implement the example methods and apparatus described herein. - The processor P105 is in communication with the main memory (including a ROM P120 and/or the RAM P115) via a bus P125. The RAM P115 may be implemented by DRAM, SDRAM, and/or any other type of RAM device, and ROM may be implemented by flash memory and/or any other desired type of memory device. Access to the memory P115 and the memory P120 may be controlled by a memory controller (not shown). One or both of the example memories P115 and P120 may be used to implement the
example configuration database 130 ofFIG. 1 and/or the exampleproduction route database 215 ofFIG. 2 . - The processor platform P100 also includes an interface circuit P130. The interface circuit P130 may be implemented by any type of interface standard, such as an external memory interface, serial port, general-purpose input/output, etc. One or more input devices P135 and one or more output devices P140 are connected to the interface circuit P130. The input devices P135 and/or output devices P140 may be used to, for example, implement the
network interface 205 ofFIG. 2 . - Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/275,055 US7804781B2 (en) | 2008-11-20 | 2008-11-20 | Methods and apparatus to detect border gateway protocol session failures |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/275,055 US7804781B2 (en) | 2008-11-20 | 2008-11-20 | Methods and apparatus to detect border gateway protocol session failures |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100124170A1 true US20100124170A1 (en) | 2010-05-20 |
US7804781B2 US7804781B2 (en) | 2010-09-28 |
Family
ID=42172007
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/275,055 Expired - Fee Related US7804781B2 (en) | 2008-11-20 | 2008-11-20 | Methods and apparatus to detect border gateway protocol session failures |
Country Status (1)
Country | Link |
---|---|
US (1) | US7804781B2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120030523A1 (en) * | 2010-07-28 | 2012-02-02 | At&T Intellectual Property I, L.P. | Alarm Threshold For BGP Flapping Detection |
CN108134707A (en) * | 2016-12-01 | 2018-06-08 | 华为技术有限公司 | A kind of method and the network equipment for routeing detection |
CN110784401A (en) * | 2019-10-28 | 2020-02-11 | 北京金山云网络技术有限公司 | Communication equipment adaptation method and device and communication equipment |
CN112953744A (en) * | 2019-12-10 | 2021-06-11 | 中盈优创资讯科技有限公司 | Network fault monitoring method, system, computer equipment and readable storage medium |
US20220224638A1 (en) * | 2021-01-08 | 2022-07-14 | Hewlett Packard Enterprise Development Lp | Preventing generation of duplicate network routes in a software defined wide area network |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8675494B2 (en) * | 2009-12-04 | 2014-03-18 | Brocade Communications Systems, Inc. | Conflict identification in label switched services |
US10230603B2 (en) | 2012-05-21 | 2019-03-12 | Thousandeyes, Inc. | Cross-layer troubleshooting of application delivery |
US9729414B1 (en) * | 2012-05-21 | 2017-08-08 | Thousandeyes, Inc. | Monitoring service availability using distributed BGP routing feeds |
US9411787B1 (en) | 2013-03-15 | 2016-08-09 | Thousandeyes, Inc. | Cross-layer troubleshooting of application delivery |
US10671520B1 (en) | 2016-06-15 | 2020-06-02 | Thousandeyes, Inc. | Scheduled tests for endpoint agents |
US10659325B2 (en) | 2016-06-15 | 2020-05-19 | Thousandeyes, Inc. | Monitoring enterprise networks with endpoint agents |
US10848402B1 (en) | 2018-10-24 | 2020-11-24 | Thousandeyes, Inc. | Application aware device monitoring correlation and visualization |
US11032124B1 (en) | 2018-10-24 | 2021-06-08 | Thousandeyes Llc | Application aware device monitoring |
US10567249B1 (en) | 2019-03-18 | 2020-02-18 | Thousandeyes, Inc. | Network path visualization using node grouping and pagination |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
US20020199016A1 (en) * | 2001-06-22 | 2002-12-26 | Freedman Avraham T. | Automated control of outbound transist links in a multi-homed BGP routing environment |
US20040088405A1 (en) * | 2002-11-01 | 2004-05-06 | Vikas Aggarwal | Distributing queries and combining query responses in a fault and performance monitoring system using distributed data gathering and storage |
US20050050176A1 (en) * | 2003-08-29 | 2005-03-03 | Ilnicki Slawomir K. | Non-intrusive method for routing policy discovery |
US20060193252A1 (en) * | 2005-02-25 | 2006-08-31 | Cisco Technology, Inc. | Active-active data center using RHI, BGP, and IGP anycast for disaster recovery and load distribution |
US20070121486A1 (en) * | 2005-11-28 | 2007-05-31 | James Guichard | System and method for PE-node protection |
US20070153763A1 (en) * | 2005-12-29 | 2007-07-05 | Rampolla Richard A | Route change monitor for communication networks |
US7565449B2 (en) * | 2000-05-23 | 2009-07-21 | At&T Corp. | Method for verifying newly provisioned customer network route advertisements |
US20090262660A1 (en) * | 2007-09-26 | 2009-10-22 | Masafumi Watari | Bgp route evaluation method and device therefor |
US20090290498A1 (en) * | 2005-12-02 | 2009-11-26 | Paritosh Bajpay | Automatic problem isolation for multi-layer network failures |
US7664043B1 (en) * | 2004-07-01 | 2010-02-16 | At&T Corp. | Method and apparatus for performing reachability testing within the context of customer virtual private networks |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7369556B1 (en) | 1997-12-23 | 2008-05-06 | Cisco Technology, Inc. | Router for virtual private network employing tag switching |
US20020021675A1 (en) | 1999-10-19 | 2002-02-21 | At&T Corp. | System and method for packet network configuration debugging and database |
US7272643B1 (en) | 2000-09-13 | 2007-09-18 | Fortinet, Inc. | System and method for managing and provisioning virtual routers |
US20040034702A1 (en) | 2002-08-16 | 2004-02-19 | Nortel Networks Limited | Method and apparatus for exchanging intra-domain routing information between VPN sites |
US8036139B2 (en) | 2002-10-28 | 2011-10-11 | Cisco Technology, Inc. | Internal BGP downloader |
US7184942B2 (en) | 2003-05-22 | 2007-02-27 | Hewlett-Packard Development Company, L.P. | Verifying the configuration of a virtual network |
CN100384172C (en) | 2004-01-20 | 2008-04-23 | 华为技术有限公司 | System and its method for guaranteeing service quality in virtual special net based network |
CN100401678C (en) | 2004-05-21 | 2008-07-09 | 华为技术有限公司 | Network management method for VPN |
US9014181B2 (en) | 2004-11-01 | 2015-04-21 | Alcatel Lucent | Softrouter separate control network |
US7535828B2 (en) | 2005-03-18 | 2009-05-19 | Cisco Technology, Inc. | Algorithm for backup PE selection |
US7532631B2 (en) | 2005-04-13 | 2009-05-12 | Cisco Technology, Inc. | Method and apparatus for accelerating border gateway protocol convergence |
US7855953B2 (en) | 2005-10-20 | 2010-12-21 | Cisco Technology, Inc. | Method and apparatus for managing forwarding of data in an autonomous system |
US20070140133A1 (en) | 2005-12-15 | 2007-06-21 | Bellsouth Intellectual Property Corporation | Methods and systems for providing outage notification for private networks |
JP4542045B2 (en) | 2006-01-24 | 2010-09-08 | アラクサラネットワークス株式会社 | Data communication apparatus and method |
US8082340B2 (en) | 2006-01-30 | 2011-12-20 | Cisco Technology, Inc. | Technique for distinguishing between link and node failure using bidirectional forwarding detection (BFD) |
JP4758259B2 (en) | 2006-01-31 | 2011-08-24 | 株式会社クラウド・スコープ・テクノロジーズ | Network monitoring apparatus and method |
US20070226325A1 (en) | 2006-03-23 | 2007-09-27 | Alcatel | Virtual private network service status management |
US7747954B2 (en) | 2006-03-23 | 2010-06-29 | Alcatel Lucent | Method and system for virtual private network connectivity verification |
US7500196B2 (en) | 2006-03-23 | 2009-03-03 | Alcatel Lucent | Method and system for generating route distinguishers and targets for a virtual private network |
-
2008
- 2008-11-20 US US12/275,055 patent/US7804781B2/en not_active Expired - Fee Related
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
US7565449B2 (en) * | 2000-05-23 | 2009-07-21 | At&T Corp. | Method for verifying newly provisioned customer network route advertisements |
US20020199016A1 (en) * | 2001-06-22 | 2002-12-26 | Freedman Avraham T. | Automated control of outbound transist links in a multi-homed BGP routing environment |
US20040088405A1 (en) * | 2002-11-01 | 2004-05-06 | Vikas Aggarwal | Distributing queries and combining query responses in a fault and performance monitoring system using distributed data gathering and storage |
US20050050176A1 (en) * | 2003-08-29 | 2005-03-03 | Ilnicki Slawomir K. | Non-intrusive method for routing policy discovery |
US7664043B1 (en) * | 2004-07-01 | 2010-02-16 | At&T Corp. | Method and apparatus for performing reachability testing within the context of customer virtual private networks |
US20060193252A1 (en) * | 2005-02-25 | 2006-08-31 | Cisco Technology, Inc. | Active-active data center using RHI, BGP, and IGP anycast for disaster recovery and load distribution |
US20070121486A1 (en) * | 2005-11-28 | 2007-05-31 | James Guichard | System and method for PE-node protection |
US20090290498A1 (en) * | 2005-12-02 | 2009-11-26 | Paritosh Bajpay | Automatic problem isolation for multi-layer network failures |
US20070153763A1 (en) * | 2005-12-29 | 2007-07-05 | Rampolla Richard A | Route change monitor for communication networks |
US20090262660A1 (en) * | 2007-09-26 | 2009-10-22 | Masafumi Watari | Bgp route evaluation method and device therefor |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120030523A1 (en) * | 2010-07-28 | 2012-02-02 | At&T Intellectual Property I, L.P. | Alarm Threshold For BGP Flapping Detection |
US8289856B2 (en) * | 2010-07-28 | 2012-10-16 | At&T Intellectual Property I, L.P. | Alarm threshold for BGP flapping detection |
US8559317B2 (en) | 2010-07-28 | 2013-10-15 | At&T Intellectual Property I, L.P. | Alarm threshold for BGP flapping detection |
CN108134707A (en) * | 2016-12-01 | 2018-06-08 | 华为技术有限公司 | A kind of method and the network equipment for routeing detection |
EP3534570A4 (en) * | 2016-12-01 | 2019-09-04 | Huawei Technologies Co., Ltd. | Route detection method and network device |
US10892977B2 (en) * | 2016-12-01 | 2021-01-12 | Huawei Technologies Co., Ltd. | Route detection method in a BGP monitoring protocol session |
CN113114525A (en) * | 2016-12-01 | 2021-07-13 | 华为技术有限公司 | Routing detection method and network equipment |
US11463345B2 (en) * | 2016-12-01 | 2022-10-04 | Huawei Technologies Co., Ltd. | Monitoring BGP routes of a device in a network |
US11855876B2 (en) * | 2016-12-01 | 2023-12-26 | Huawei Technologies Co., Ltd. | BMP route detection method and network device |
CN110784401A (en) * | 2019-10-28 | 2020-02-11 | 北京金山云网络技术有限公司 | Communication equipment adaptation method and device and communication equipment |
CN112953744A (en) * | 2019-12-10 | 2021-06-11 | 中盈优创资讯科技有限公司 | Network fault monitoring method, system, computer equipment and readable storage medium |
US20220224638A1 (en) * | 2021-01-08 | 2022-07-14 | Hewlett Packard Enterprise Development Lp | Preventing generation of duplicate network routes in a software defined wide area network |
Also Published As
Publication number | Publication date |
---|---|
US7804781B2 (en) | 2010-09-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7804781B2 (en) | Methods and apparatus to detect border gateway protocol session failures | |
US10742556B2 (en) | Tactical traffic engineering based on segment routing policies | |
EP3435602B1 (en) | Service level agreement based next-hop selection | |
US9401844B2 (en) | Methods and apparatus to dynamically control connectivity within virtual private networks | |
EP3435599B1 (en) | Service level agreement based next-hop selection | |
US8139475B2 (en) | Method and system for fault and performance recovery in communication networks, related network and computer program product therefor | |
US7954010B2 (en) | Methods and apparatus to detect an error condition in a communication network | |
US9148372B2 (en) | Methods, apparatus and articles of manufacture to manipulate packet routing | |
US9544217B2 (en) | Identification of paths in a network of mixed routing/switching devices | |
US9537760B2 (en) | Executing loops | |
US9559909B2 (en) | Identifying an egress port of a device | |
US9531598B2 (en) | Querying a traffic forwarding table | |
US8630189B2 (en) | Methods, apparatus and articles of manufacture to monitor tunnels within traffic engineering/fast reroute enabled networks | |
US20230261930A1 (en) | Predicting network issues based on historical data | |
US11916779B2 (en) | Peer comparison-based outlier detection for network performance monitoring | |
US7933212B2 (en) | Methods and apparatus to diagnose enhanced interior gateway routing protocol problems in networks | |
US11575596B1 (en) | Identifying an ingress router of a flow in inter-AS VPN option-C networks with visibility in one AS | |
WO2020097760A1 (en) | Methods, network element and computer readable media for monitoring lsp health in a sr enabled network | |
WO2023094867A1 (en) | Method and system for learning and inferencing faults |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AT&T INTELLECTUAL PROPERTY I, L.P., A NEVADA PARTN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:XU, ZHIJIAN;BAJPAY, PARITOSH;HOSSAIN, MONOWAR;AND OTHERS;SIGNING DATES FROM 20081027 TO 20081118;REEL/FRAME:021915/0919 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.) |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |