Method and apparatus for remote monitoring of BGP prefixes in a network topology

Abstract

Telemetry monitoring of BGP prefixes in a network topology. The system includes a plurality of input topic streams and a plurality of processors, each of the plurality of processors dedicated to one or more of the plurality of input topic streams. The system includes a plurality of stream stores for storing data, each of the plurality of stream stores dedicated to one or more of the plurality of input topic streams. The system includes a route processor in communication with each of the plurality of stream stores, the route processor determining whether a route for the network topology matches an existing route stored on at least one of the plurality of stream stores.

Description

[Technical Field]

[0001] The present disclosure relates to computing networks, and more particularly to telemetry monitoring of prefixes in a network topology. [Background technology]

[0002] Network computing is a means by which multiple computers, or nodes, cooperate and communicate with each other over a network. These include wide area networks (WANs) and local area networks (LANs). Both wide area networks and local area networks allow computers to connect to each other. Local area networks are typically used for smaller, localized networks, such as homes, businesses, and schools. Wide area networks cover large areas, such as cities, and can even connect computers in different countries. Local area networks are typically faster and more secure than wide area networks, but wide area networks allow for broader connectivity. Local area networks are typically owned, controlled, and managed within the organization in which they are deployed, while wide area networks typically require the connection of two or more constituent local area networks, either via the public Internet or private connections established by a telecommunications provider.

[0003] Local and wide area networks connect computers together and allow the transfer of data and other information. Both local and wide area networks require a means to determine the path along which data should be passed from one computing instance to another. This is also known as routing. Routing is the process of selecting a path for traffic within a network, between networks, or across networks. The routing process typically directs forwarding based on routing tables, which maintain records of routes to various network destinations. Routing tables may be specified by an administrator, learned by monitoring network traffic, or constructed with the assistance of a routing protocol.

[0004] Small networks can use manually configured routing tables to determine how information is transferred from one computer to another. Routing tables can contain a list of "best paths," indicating the most efficient or most desirable paths between a starting computer and a final destination computer. Larger networks, including those connected to the public Internet, can rely on complex topologies that can change rapidly, making manual construction of routing tables impossible. Dynamic routing attempts to solve this problem by automatically constructing routing tables based on information conveyed by routing protocols. Dynamic routing allows networks to operate largely autonomously, avoiding network failures or blockages. Several routing protocols exist that provide rules or instructions for determining the best path between network devices. Examples of dynamic routing protocols and algorithms include the Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), and Border Gateway Protocol (BGP).

[0005] In some implementations, path selection involves applying a routing metric to multiple routes to select or predict an optimal route. Most routing algorithms use only one network path at a time. Multipath routing techniques allow for the use of multiple alternative paths. In computer networks, routing algorithms can be used to predict the optimal path between two computing instances. Routing algorithms may be based on multiple factors such as bandwidth, network delay, hop count, path cost, load, maximum transmission unit, reliability, and communication cost. A routing table stores a list of optimal paths. A topology database can store a list of optimal paths and can also store additional information.

[0006] In some networks, routing is complicated by the fact that there is no single entity responsible for selecting the optimal path. Instead, multiple entities are involved in selecting the optimal path or even portions of a single path. In the context of computer networking on the Internet, the Internet is divided into autonomous systems (AS), such as Internet Service Providers (ISPs). Each AS controls the routes that encompass its network. AS-level paths are selected based on the Border Gateway Protocol (BGP). Each AS-level path contains a set of ASs through which information packets are sent from one computing instance to another. Each AS can have multiple paths from which it can select multiple paths provided by neighboring ASs. Summary of the Invention [Problem to be solved by the invention]

[0007] In many network routing implementations, it is desirable to detect routing events within the network, including the addition, withdrawal, or modification of routes. In some cases, it is important to track specific routes within the network topology in real time. [Means for solving the problem]

[0008] In view of the above, systems, methods, and devices are disclosed herein for automatically tracking prefixes in a network topology based on telemetry data.

[0009] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following figures, in which like reference numerals refer to like parts throughout the figures unless otherwise specified. Advantages of the present disclosure will be more clearly understood by referring to the following description and the accompanying drawings. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic diagram of an exemplary system of network devices communicating over the Internet. [Figure 2] 1 is a schematic diagram of a system for automatically tracking prefixes in a network topology based on telemetry data. [Figure 3A] FIG. 1 is a schematic diagram of a process flow for automatically tracking prefixes in a network topology based on telemetry data. [Figure 3B] This key contains root key information applicable to the steps shown in FIGS. [Figure 4] FIG. 1 is a schematic diagram of a process flow for identifying a route state in a network topology. [Figure 5] FIG. 1 is a schematic diagram of a process flow for identifying path conditions in a network topology. [Figure 6] FIG. 1 is a schematic diagram of a process flow for tracking a path in a network topology. [Figure 7] FIG. 1 is a schematic diagram of a process flow for tracking prefixes and synchronizing prefix tracking data stores associated with a network topology. [Figure 8] FIG. 1 is a schematic flow chart diagram of a method for automatically tracking prefixes in a network topology based on telemetry data. [Figure 9] FIG. 1 is a schematic diagram illustrating components of an exemplary computing device. DETAILED DESCRIPTION OF THE INVENTION

[0011] Disclosed herein are systems, methods, and devices for automatically detecting routing events in a network topology. The described systems, methods, and devices are particularly implemented in networks that route traffic via the Border Gateway Protocol (BGP). As described above, speakers peer with a network visibility and analytics platform via BGP to track routes across the network, or send telemetry data directly to the network visibility and analytics platform. BGP prefixes are tracked by matching route attributes such as communities, extended communities, larger communities, prefixes, and neighbor addresses.

[0012] The BGP prefix tracker system described herein is implemented to track specific events, including route / prefix events and network-wide events. Route / prefix events include, for example, newly added BGP routes, updates to existing BGP routes, and withdrawal or deletion of existing BGP routes. This includes detecting changes to the BGP best path by tracking BGP attributes such as the autonomous system path (AS path), multi-exit discriminator (MED), local preference (LocalPref), weight, origin, next hop, atomic aggregate, aggregator, community, originator identifier, cluster list, DPA, advertiser, multiprotocol reachable NLRI, multiprotocol unreachable NLRI, and extended communities. Network-wide events include, for example, detection of prefix reachability within the network, i.e., whether a prefix is ​​no longer reachable across all nodes in the network, route instability due to tracking of optimal path changes or route flapping, route de-prioritization and hijacking, path cost changes due to tracking of next-hop information, etc. The BGP prefix tracker described herein provides an option to specify the network size to enable tracking at a prefix level by specifying a list of neighbor router identifiers that are part of the tracked network. The BGP prefix tracker described herein also provides an option to filter the nodes to be tracked within the network at a prefix level by specifying a list of neighbor router identifiers that are part of the nodes to be tracked within the network.

[0013] The prefix tracker is a real-time application that implements data streams. The data streams are specifically implemented within a real-time streaming framework such as Kafka Streams, with input and output data stored in an Apache Kafka cluster. Real-time data for all prefixes is provided to the prefix tracker from BGP speakers via local telemetry feeds. The prefix tracker tracks state across all BGP speakers in the network topology, including BGP peers and BGP prefixes and paths. The prefix tracker stores state using a state store, which may include an in-memory hash map provided by the data stream. The state data store is implemented by a stream processing application that stores and queries data. The data stream provides fault tolerance and automatic recovery for the local state store. Each stream task in the prefix tracker application can embed multiple state stores to track network-wide state. State stores include, for example, a device store, a configuration store, a peer store, a route store, and a prefix tracker store. Related input source data received across one or more data streams is stored across different state stores using each source processor.

[0014] The following discussion is provided as further background for the disclosure herein. In a computer network environment, network devices such as switches or routers are utilized to transmit information from one destination to another. In an embodiment, data packages and messages are generated at a first location, such as a computer in a person's home. The data packages and messages are generated by a person interacting with a web browser to provide information to or request information from a remote server accessible over the Internet. In an embodiment, the data packages and messages may be information entered by a person into a form accessible on a web page connected to the Internet. The data packages and messages need to be transmitted to a remote server that is geographically distant from the person's computer. There is likely no direct communication between the router in the person's home and the remote server. Thus, the data packages and messages must "hop" through different network devices before reaching their destination at the remote server. The router in the person's home must determine the route to transmit the data packages and messages through multiple different devices connected to the Internet until the data packages and messages reach their destination at the remote server.

[0015] The process of determining the optimal path from a first location to a destination and forwarding data packages and messages to the next destination is an important function performed by network devices such as switches or routers. The connections between network devices within a network are called network topology. A network topology is the arrangement of elements such as links and nodes within a communication network. A network topology can include wired links, wireless links, or a combination of wired and wireless links between nodes in the network. Some examples of wired links include coaxial cables, telephone lines, power lines, ribbon cables, optical fibers, etc. Some examples of wireless links include satellite, cellular signals, radio signals, free space optical communications, etc. A network topology includes a representation of all nodes (e.g., computers, routers, switches, and other devices) in the network and a representation of the links between the nodes. Disclosed herein are systems, methods, and devices for improving network topology and network routing.

[0016] To further the understanding of this disclosure, some descriptions for a number of network computing devices and protocols are provided.

[0017] A BGP instance is a device for routing information within a network. A BGP instance can take the form of a route reflector appliance. A BGP instance can run on a switch, a router, or a BGP speaker on a switch. At a high level, a BGP instance sends all paths it has learned for a prefix to a best path controller. The best path controller responds with a set of best paths from among these paths. The best path controller is allowed to change the next hop and attributes of any path. Upon receiving the best path, the BGP instance updates its local Routing Information Base (RIB) and advertises the best path to its neighbors.

[0018] Switches (also called switching hubs, bridging hubs, or MAC bridges) create networks. Most internal networks use switches to connect computers, printers, phones, cameras, lights, and servers within a building or campus. Switches act as controllers that allow network devices to communicate with each other efficiently. Switches connect devices on computer networks using packet switching, which allows data to be received, processed, and forwarded to the destination device. A network switch is a multi-port network bridge that uses hardware addresses to process and forward data at the data link layer (Layer 2) of the Open Systems Interconnection (OSI) model. Some switches can also process data at the network layer (Layer 3) by incorporating additional routing functionality. Such switches are commonly called Layer 3 switches or multi-layer switches.

[0019] Routers connect networks. Switches and routers perform similar functions, but they perform different functions on a network. Routers are network devices that forward data packets between computer networks. Routers perform traffic directing functions on the Internet. Data sent over the Internet, such as web pages, email, or other forms of information, is sent in the form of data packets. Packets are typically forwarded from one router to another through the networks that make up an internetwork (e.g., the Internet), until they finally reach their destination node. Routers are connected to two or more data lines from different networks. When a data packet arrives on one of the lines, the router reads the network address information in the packet to determine its ultimate destination. The router then uses information in the router's routing table or routing policy to direct the packet to the next network on its journey. A BGP speaker is a router enabled with the Border Gateway Protocol (BGP).

[0020] A customer edge (CE) router is a router located on a premises that provides the interface between the provider's core network and the customer's LAN. CE routers, provider routers, and provider edge routers are components in a multiprotocol label switching configuration. Provider routers are located in the core of the provider's or carrier's network. Provider edge routers are located at the edge of the network. Customer edge routers connect to provider edge routers, which in turn connect to other provider edge routers.

[0021] A routing table or routing information base (RIB) is a data table stored in a router or network computer that lists routes to specific network destinations. In some cases, routing tables include route metrics such as distance and weight. Routing tables contain information about the topology of the network immediately surrounding the router where the routing table is stored. Building a routing table is the primary goal of a routing protocol. Statistical routes are entries created in a routing table by non-automatic means and are fixed regardless of the outcome of some network topology discovery procedure. A routing table can contain at least three information fields, including network ID, metric, and next hop fields. The network ID is the destination subnet. The metric is the routing metric of the path the packet will take when sent. The route travels toward the gateway with the lowest metric. The next hop is the address of the next station to which the packet will be sent on its way to the destination. A routing table can also include the quality of service associated with the route, a link filtering criteria list associated with the route, the interface for an Ethernet card, etc.

[0022] To illustrate the concept of a routing table, a routing table can be analogized as using a map to route packages. A routing table is like using a map to route packages to their final destination. When a node needs to send data to another node on the network, it first needs to know where to send the data. If the node cannot directly connect to the destination node, it needs to send the data to another node along the proper route to the destination node. Most nodes do not attempt to calculate which route will work. Instead, the node sends IP packets to a gateway in the LAN, which then determines how to route the data to the correct destination. Each gateway needs to keep track of the direction to route various packages of data, and it uses a routing table to do so. A routing table is a database that tracks paths, like a map, and uses these paths to determine the direction in which to forward traffic. Gateways can also share the contents of these routing tables with other nodes that request the information.

[0023] For hop-by-hop routing, each routing table creates a list, for every reachable destination, of the address of the next device along the path to the destination, e.g., the next hop. Assuming the routing tables are consistent, the algorithm that relays packets to the next hop to the destination may deliver the data anywhere in the network. Hop-by-hop routing is a feature of the IP internetwork layer and the Open Systems Interconnection (OSI) model.

[0024] The Open Systems Interconnection (OSI) model is a conceptual model that characterizes and standardizes the communication functions of computer systems, regardless of their underlying internal structure and technology. The goal of the OSI model is interoperability of diverse communication systems with standard communication protocols. The OSI model divides communication systems into abstraction layers. A layer serves the layer above it and serves the layer below it. For example, a layer that provides error-free communication across a network provides the path needed by the application above it and requests the layer below it to receive and transmit the packets that make up that path. Two instances of the same layer are visualized as connected by a horizontal connection within that layer. Communication protocols allow entities in one host to interact with corresponding entities at the same layer in other hosts. Service definitions such as the OSI model abstractly describe the functions provided by (N-1) layers to (N), where N is one of the layers of protocols operating within the local host.

[0025] Route control is a type of network management aimed at improving Internet connectivity, reducing bandwidth costs, and reducing overall activity between networks. Some route control services include a suite of hardware- and software-based products and services that work together to improve overall Internet performance and fine-tune available Internet bandwidth at minimal cost. Route control can be successful in scenarios where a network or autonomous system procures Internet bandwidth from multiple providers. Route control can assist in selecting the optimal path for data transmission.

[0026] Some network communication systems are large, enterprise-level networks with thousands of processing nodes. These thousands of processing nodes share bandwidth from multiple Internet Service Providers (ISPs) and can handle large volumes of Internet traffic. Such systems can be very complex and must be properly configured to achieve acceptable Internet performance. If the system is not properly configured for optimal data transmission, Internet access speeds can be slowed and system bandwidth consumption and traffic can increase. These concerns can be eliminated or mitigated by implementing a set of services, also known as routing control.

[0027] One embodiment of the routing control mechanism is comprised of hardware and software. The routing control mechanism monitors all outgoing traffic through connections with Internet Service Providers (ISPs). The routing control mechanism assists in selecting the optimal path for efficient transmission of data. The routing control mechanism calculates the performance and efficiency of all ISPs and can select only the ISPs that perform optimally in the applicable area. The route control device can be configured according to predefined parameters regarding cost, performance, and bandwidth.

[0028] A well-known algorithm for determining the best path for data transmission is called the Border Gateway Protocol (BGP). BGP is a path-vector protocol that provides routing information for autonomous systems on the Internet. If BGP is not configured correctly, it can cause serious availability and security issues. Furthermore, by modifying BGP route information, an attacker can redirect large blocks of traffic to a specific router before the traffic reaches its intended destination. By implementing the BGP best path algorithm, the best path to install in the Internet Protocol (IP) routing table for traffic forwarding can be determined. BGP routers can be configured to receive multiple paths to the same destination.

[0029] The BGP best path algorithm assigns the first valid path as the current best path. The BGP best path algorithm compares the best path to the next path in the list until BGP reaches the end of the list of valid paths. This list provides the rules used to determine the best path. For example, the list can contain directives such as prefer the path with the highest weight, prefer paths with no local preference, prefer paths locally originated by a network or aggregation BGP, prefer the shortest path, or prefer the path with the smallest multi-exit discriminator. The BGP best path selection process can be customized.

[0030] In the context of BGP routing, each routing domain is called an autonomous system (AS). BGP assists in selecting a path through the Internet to connect two routing domains. BGP selects the route that passes through the fewest number of autonomous systems, commonly referred to as the shortest AS path. In one embodiment, once BGP is enabled, a router pulls a list of Internet routes from its BGP neighbors, which may be ISPs. BGP then traverses the list to find the routes with the shortest AS paths. These routes may be entered into the router's routing table. Typically, the router selects the shortest path to an AS. BGP uses path attributes to determine how to route traffic to a particular network.

[0031] Equal Cost Multipath (ECMP) routing is a routing strategy in which next-hop packets forwarded to a single destination can occur over multiple "best paths." The multiple best paths are equal based on a routing metric calculation. Multipath routing can be used with many routing protocols because routing is a hop-by-hop decision limited to a single router. Multipath routing can substantially increase bandwidth by load balancing traffic over multiple paths. However, ECMP routing has many known problems when the strategy is deployed in practice. Disclosed herein are systems, methods, and devices for improving ECMP routing.

[0032] Clos networks can be deployed in telecommunications. A Clos network is a multi-stage circuit-switched network that represents an idealization of a multi-stage switch system. A Clos network includes three stages: an ingress stage, a middle stage, and an egress stage. Each stage is composed of several crossbar switches. Each request enters an ingress crossbar switch and is routed through any available middle stage crossbar switch to the associated egress crossbar switch. A middle stage crossbar switch is available for a particular new request if both the link connecting the ingress switch to the middle stage switch and the link connecting the middle stage switch to the egress switch are free.

[0033] A leaf-spine network topology can be deployed to connect nodes in a computer network. The leaf-spine topology has two layers: a leaf layer and a spine layer. The leaf layer consists of access switches that connect to devices such as servers, firewalls, load balancers, and edge routers. The spine layer consists of switches that perform routing and form the backbone of the network, with all leaf switches interconnected with each spine switch. In a leaf-spine topology, all devices are located the same number of links away from each other and have a predictable, consistent amount of delay or latency for transmitting information.

[0034] A Virtual Local Area Network (VLAN) is a segmented and isolated broadcast domain within a computer network at the data link layer. VLANs apply tags to network frames and process these tags within the network system, making network traffic function and appear as if it is physically on a single network but separated between separate networks. VLANs allow network applications to remain separate even when connected to the same physical network, without the need to deploy multiple sets of cables and network devices.

[0035] A Switched Virtual Interface (SVI) is a virtual interface and port for a managed switch that transmits untagged VLAN packets. Traditionally, switches only transmit traffic to hosts within the same broadcast domain (a single VLAN), and routers handle traffic between different broadcast domains (different VLANs). In such an implementation, network devices in different broadcast domains cannot communicate without a router. When an SVI is implemented, the switch uses a virtual Layer 3 interface to route traffic to other Layer 3 interfaces, eliminating the need for a physical router. VLANs can reduce the load on the network by dividing a LAN into smaller segments and maintaining local traffic within a VLAN. However, because each VLAN has its own domain, a mechanism is needed for one VLAN to transmit data to another without the data passing through a router. SVI is such a mechanism. SVIs are typically based on switches (e.g., Layer 3 and Layer 2 switches). When an SVI is implemented, the switch can recognize packet destinations that are local to the sending VLAN and can switch packets destined for different VLANs. In an embodiment, there is a one-to-one mapping between a VLAN and an SVI. In such an embodiment, only a single SVI is mapped to a VLAN.

[0036] To promote an understanding of the principles underlying the present disclosure, reference will be made to illustrated embodiments and specific language will be used to describe the same, without intending to limit the scope of the present disclosure. Any changes and further modifications of the features of the present disclosure exemplified herein, and any additional applications of the principles of the present disclosure exemplified herein, will be readily apparent to those skilled in the art based on the present disclosure, and are encompassed by the appended claims.

[0037] Before disclosing and describing the structures, systems, and methods for tracking the lifecycle of objects in a network computing environment, it is to be understood that the present disclosure is not limited to the particular structures, configurations, process steps, and materials disclosed herein, as such structures, configurations, process steps, and materials may vary. Furthermore, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the claims and their equivalents.

[0038] In describing and claiming the subject matter of the present disclosure, the following terminology will be used in accordance with the definitions set out below.

[0039] As used in this specification and claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

[0040] As used herein, the terms "comprise," "have," "include," "featuring," and their grammatical equivalents are non-exclusive or open-ended terms that do not exclude additional, unrecited elements or method steps.

[0041] As used herein, the phrase "consisting of" and its grammatical equivalents excludes any element or step not recited in a claim.

[0042] As used herein, the phrase "consisting essentially of" and its grammatical equivalents limit the scope of a claim to the materials or steps specified, and to materials or steps that do not materially affect the basic and novel properties or characteristics of the claimed disclosure.

[0043] Referring to the drawings, FIG. 1 is a schematic diagram of a system 100 for connecting devices to the Internet. The system 100 includes multiple local area networks 110 connected by a switch 106. Each of the multiple local area networks 110 is connectable to one another via the public Internet by a router 112. The exemplary system 100 shown in FIG. 1 includes two local area networks 110. However, more local area networks 110 may be connected to one another via the public Internet. Each local area network 110 includes multiple computing devices 108 connected to one another via the switch 106. The multiple computing devices 108 may include, for example, desktop computers, laptops, printers, servers, etc. The local area networks 110 can communicate with other networks via the public Internet by a router 112. The router 112 connects the multiple networks to one another. The router 112 is connected to an Internet service provider 102. The Internet service provider 102 is connected to one or more network service providers 104. The network service provider 104 communicates with other local network service providers 104 as shown in FIG.

[0044] The switch 106 connects devices within the local area network 110 using packet switching, allowing data to be received, processed, and forwarded to a destination device. The switch 106 can be configured to receive data from a computer, for example, destined for a printer. The switch 106 can receive the data, process the data, and send the data to the printer. The switch 106 may be a Layer 1 switch, a Layer 2 switch, a Layer 3 switch, a Layer 4 switch, a Layer 7 switch, etc. A Layer 1 network device forwards data but does not manage the traffic passing through the device. An example of a Layer 1 network device is an Ethernet hub. A Layer 2 network device is a multi-port device that processes and forwards data at the data link layer (Layer 2) using hardware addresses. A Layer 3 switch can perform some or all of the functions typically performed by a router. However, some network switches are limited to supporting a single type of physical network, usually Ethernet, while a router may support different types of physical networks on different ports.

[0045] The router 112 is a network device that forwards data packets between computer networks. In the exemplary system 100 shown in FIG. 1, the router 112 forwards data packets between local area networks 110. However, the router 112 does not necessarily need to forward data packets between local area networks 110, but may also be used to forward data packets between wide area networks, etc. The router 112 performs traffic direction functions on the Internet. The router 112 may have interfaces for different types of physical layer connections, such as copper cable, optical fiber, or wireless transmission. The router 112 can support different network layer transmission standards. Each network interface can be used to forward data packets from one transmission system to another. The router 112 may also be used to connect two or more logical groups of computer devices, called subnets, each with a different network prefix. As shown in FIG. 1, the router 112 can provide connectivity within a company, between a company and the Internet, or between Internet service provider networks. Some routers 112 may be configured to interconnect various Internet service providers or may be used within large corporate networks. Smaller routers 112 typically provide connectivity for home and office networks to the Internet. The routers 112 shown in Figure 1 can represent any router suitable for network transmission, such as an edge router, a subscriber edge router, an inter-provider border router, a core router, an Internet backbone, a port forwarding router, a voice / data / fax / video processing router, etc.

[0046] An Internet Service Provider (ISP) 102 is an organization that provides services for access, use, or participation in the Internet. ISPs 102 can be organized in a variety of forms, such as commercial, community-owned, non-profit, or privately owned. Internet services typically provided by ISPs 102 include Internet access, Internet transit, domain name registration, web hosting, Usenet services, and colocation. ISP 102 as shown in FIG. 1 can represent any suitable ISP, such as a hosting ISP, transit ISP, virtual ISP, toll-free ISP, wireless ISP, etc.

[0047] A network service provider (NSP) 104 is an organization that provides bandwidth or network access by providing direct Internet backbone access to Internet service providers. A network service provider may provide access to a network access point (NAP). A network service provider 104 is also called a backbone provider or Internet provider. Network service providers 104 can include telecommunications providers, data carriers, wireless communication providers, Internet service providers, and cable television operators that offer high-speed Internet access. Network service providers 104 can also include information technology providers.

[0048] The system 100 shown in Figure 1 is merely exemplary, and many different configurations and systems can be constructed for transmitting data between networks and computing devices. Because networking is highly customizable, it is desirable to provide greater customizability in determining optimal paths for transmitting data between computers or networks. In light of the above, disclosed herein are systems, methods, and devices for offloading optimal path computation to an external device to provide greater customizability in determining an optimal path algorithm that better suits a particular enterprise or particular grouping of computers.

[0049] 2 is a schematic diagram of a topology 200 for implementing the prefix tracker application described herein. The prefix tracker application is specifically implemented to track events in networks implementing the Border Gateway Protocol (BGP).

[0050] Topology 200 includes multiple input topic streams 202. The input topic streams 202 include, for example, a configuration stream 204, a device stream 206, a peer stream 208, and a route stream 210. Peer stream 208 specifically receives data related to BGP peers. Route stream 210 specifically receives data related to BGP routes. The input topic streams 202 may also include other data streams as needed. The input topic streams 202 are fed into and managed by independent processing resources. For example, configuration stream 204 is fed into configuration processor 205. Similarly, device stream 206 is fed into device processor 207, and peer stream 208 is fed into peer processor 209. The route stream 210 is fed directly into route processor 222.

[0051] In implementation, input topic stream 202 is an input topic stream in a real-time streaming framework such as Kafka. A real-time streaming framework is a client library for building applications and microservices, where input and output data is stored in a cluster. Kafka Streams combines the benefits of server-side cluster technology with the simplicity of writing and deploying standard Java and Scala applications on the client side. A real-time streaming framework is implemented for stateful handling, fault tolerance, and processing guarantees built on top of the functionality provided by the storage and messaging layers.

[0052] Topology 200 includes multiple independent state stores, including, for example, configuration store 212, device store 214, peer store 216, route store 218, and prefix tracker store 220. State stores 212-220 are implemented as persistent hash maps that reside within streams within a real-time streaming framework. Topology 200 includes different state stores 212-220 for different information. State stores 212-220 implement fault tolerance and automatic recovery.

[0053] Data received via configuration stream 204 is processed by configuration processor 205 and then stored in configuration store 212. Similarly, data received via device stream 206 is processed by device processor 207 and then stored in device store 214, and data received via peer stream 208 is processed by peer processor 209 and then stored in peer store 216. Data received via route stream 210 is processed by route processor 222 and then stored in route store 218. Route processor 222 can communicate with each of configuration store 212, device store 214, peer store 216, and route store 218. Route processor 222 can also communicate with prefix tracker store 220, which stores data for a prefix tracker application. Route processor 222 can communicate with alert sink 224, which acts as a notification queue for storing alert messages. Events detected by the prefix tracker are sent to an alert sink 224 where they are stored until consumed by a northbound application for further data processing or transmission as a notification.

[0054] The prefix tracker application performs several different tasks. Each of these tasks is referred to herein as a "stream task." Each stream task is associated with one or more of the stream stores 212-220. Each prefix and / or device in the network topology is assigned to a specific set of stream tasks, including one of each type of stream store 212-220. Telemetry data for network resources, such as devices, routes, peers, and configurations, is partitioned into multiple stream tasks of each type of stream store 212-220 based on device or other partitioning configuration. The prefix tracker is modified as the network topology grows to add additional stream tasks for new routes, devices, or other network resources.

[0055] The state stores 212-220 are implemented as hash maps. The configuration store 212 stores configuration information about different prefix attributes, which are used by the prefix tracker to match prefix attributes to prefixes and then track the prefixes. A path is significant to the prefix tracker if it matches an attribute entry in the configuration store. The device store 214 stores a list of devices in the network, including devices that send the device's prefixes to the prefix tracker. The peer store 216 tracks peering data between BGP speakers in the network. The data in the peer store 216 is used to determine which peers are sending routes. This data is particularly important when determining which devices are affected when prefixes in the network topology are added, updated, or withdrawn. The route store 218 stores all routes for the network topology, including routes that are not currently tracked but will be tracked in the future. The prefix tracker store 220 tracks routes of interest (ie, routes currently being tracked by the prefix tracker application).

[0056] Processors 205, 207, 209, 222 are responsible for taking data from their respective input topic streams 202, converting the data into the correct format, and then storing the data in the correct state stores 212-218. As state stores 212-220 are updated, route processor 222 updates the data in each of the state stores 212-220 and updates alert sink 224. State stores 212-220 are automatically updated via telemetry data received from network devices when the network topology is updated or changed. Route processor 222 processes telemetry route and prefix updates received from network devices. The route processor uses information from the other state stores to update the prefix tracker store and alert sink.

[0057] The prefix tracker application is configured to track different route attributes. In particular, prefix trackers are implemented to track community attributes, extended community attributes, large community attributes, prefix attributes, neighbor address attributes, etc. The prefix tracker is configured to track different events, including route specific events and network events. Route specific events include, for example, an indication that one or more routes in the network topology have been added, an indication that one or more routes in the network topology have been updated, or an indication that one or more routes in the network topology have been withdrawn or deleted.

[0058] Network events include events that monitor network reachability for prefixes, route stability by tracking best path changes and route flapping, route depreciation or hijacking, and next hop tracking. When the best path for a route changes, a best path marker identifies the new path. This information can be tracked after receiving a new update for the route via telemetry. Tracking changes to the best path for a route also tracks other network-wide events such as route stability, whether the route has been depreciated or hijacked, and the next hop for the route.

[0059] The system can track route stability by counting the number of best path changes made to a route over time. If a route changes more than a threshold number of times within a given period, the route is less stable for that period. A prefix tracker can track the number of best path changes or flapping as a function of time to determine if a route is stable. If the prefix tracker determines that a route is unstable, then the prefix tracker can trigger a warning notification indicating that the route is unstable. This information can be tracked throughout the network to indicate areas where routes are unstable and provide insufficient reachability.

[0060] A prefix tracker can track route deprioritization or hijacking. The best path of a route changes when a new path becomes preferable to the old one. This occurs when attributes of the current best path are updated with a lower priority or preference value, or when attributes of the new best path have a higher priority or preference value. The prefix tracker detects and records which attributes of the route have changed and provides the reason why the route was deprioritized. The prefix tracker additionally determines whether a route has been maliciously deprioritized through hijacking.

[0061] A prefix tracker performs next-hop tracking, which provides information about the next-hop IP address used to forward traffic to a particular destination. The next hop provides information about the link a router should use to forward traffic. Sometimes, it is preferable to use a lower-cost next-hop link. In some cases, a particular next-hop IP address is blacklisted via configuration, and the prefix tracker then triggers an alert if a route uses that next hop. Similarly, a prefix tracker can track the IGP metric and / or local preference for the next hop to determine why a route was deprioritized.

[0062] The prefix tracker application can receive configuration instructions via configuration stream 204. These configuration settings are then stored in configuration store 212 and processed by configuration processor 205. Configuration store 212 can store configuration settings in a key-value manner. In this implementation, the keys are tuples of attribute types and the values ​​are attribute values ​​for easy lookup during route processing. Route processor 222 uses configuration store 212 to determine whether a prefix needs to be tracked. The prefix tracker can be configured and reconfigured at any time after initialization. These configuration settings, which also include attribute-value pairs for filtering and tracking prefixes, can be converted to key-value pairs in the configuration store.

[0063] The route processor 222 receives streamed routes from a telemetry data feed. This feed continuously updates data whenever a network path is updated. The route processor 222 identifies path changes. A path change includes one or more of a newly added path, an updated path, or a withdrawn path. The route processor 222 can identify path changes because all prefixes for the network topology are stored in the route store 218. The route processor 222 determines whether a path change is prefix tracker-related based on whether the path contains attributes that match data in the configuration store 212. If a path change is prefix tracker-related, then the changed prefix associated with the path change is stored in the prefix tracker store 220. If the path change triggers an event, then the prefix tracker generates an alert for the event.

[0064] The prefix tracker application processes telemetry updates inline. In some implementations, routes are not post-processed after configuration. Rather, route updates are processed inline and the context / state is stored as route updates arrive. Post-processing creates a window where data is removed from synchronization in the real-time system. This step reduces the complexity of tracking and data synchronization for prefixes that already exist in any BGP speaker. This ensures that the prefix tracker functions as a fully real-time application.

[0065] The prefix tracker processor topology 200 can be scaled by dividing the processor topology into multiple stream tasks. The input data stream can be divided into separate partitions based on attributes such as device identifiers, creating a fixed number of stream tasks based on the input stream partitions. Each of these stream tasks is assigned a list of partitions from the input stream. The assignment of partitions to these tasks does not change, making the stream tasks a fixed unit of parallelism for the prefix tracker. These tasks create their own instance of the processor topology for their assigned partitions and process data independently and in parallel.

[0066] 3A is a schematic diagram of a process flow 300 of the prefix tracker application described herein. Process flow 300 is executed at least upon receiving a route and an operation at step 302. The prefix tracker application is configured to identify route status at step 304, identify path status at step 306, track the path at step 308, and synchronize at step 310.

[0067] FIG. 3B includes keys identifying route key information applicable to process flow 300. As described above, the Route Store (RS) stores all routes received for lookup. The Configuration Store (CS) stores all path-config-keys (PCK) configured by customers for lookup. The Path Configuration Key (PCK) formats the device identifier, BGP path attribute type, and BGP path attribute value. The Path Configuration Key (PCK) is configured by the customer and identifies the BGP prefix to track. The Route Key (r) includes (device, prefix, vrf, af). As described herein, RS(Route Key (r)) is equal to r', where r' includes an old route (Old-Route), which is a route already present in the route store. r includes a new route (New-Route), which is a new route received.

[0068] The prefix tracker application identifies the route state in step 304. This process is further illustrated in Figure 4, which is based on the accompanying route key information table contained in Figure 3B. This identification process involves determining whether an old (existing) route exists and whether the old route matches the new route received in step 302.

[0069] If the operation indicates that a route should be added, then the prefix tracker determines whether the new route exists in the route store 218. If the new route exists in the route store (r in RS = TRUE), then the route state is updated. The route store 218 is updated to reflect the new route (r) and the old route (r'). If the new route does not exist in the route store (r in RS = FALSE), then the new route is added.

[0070] If the operation indicates that the route should be deleted, then the prefix tracker determines whether the new route exists in the route store 218. If the new route exists in the route store (r in RS = TRUE), then the route state is deleted. After the route has been processed by the prefix tracker, the route store 218 is updated to reflect that the new route is invalid. If the new route does not exist in the route store (r in RS = FALSE), then the route store 218 is not updated.

[0071] The prefix tracker application identifies the path states in step 306. This process is further illustrated in Figure 5. The prefix tracker determines which paths have been added, which paths have been withdrawn, and which paths have been updated.

[0072] The prefix tracker compares the old path and the new path. In the embodiment illustrated in FIG. 5, the prefix tracker compares the new path p1 against the old path p1'. If the new path p1 has changed from the old path p1', the prefix tracker determines that the path has been updated. If the old path p1' and the new path p1 are the same, the prefix tracker determines that the path has not changed. Furthermore, for example, if the prefix tracker cannot find an old path equivalent to the new path p2, then the prefix tracker determines that the new path p2 has been added. Furthermore, for example, if the prefix tracker cannot find a new path equivalent to the old path p3', then the prefix tracker determines that the old path p3' has been deleted.

[0073] The prefix tracker application tracks the paths in step 308. This process is further illustrated in FIG. 6. The prefix tracker matches each path with attributes associated with the paths stored in the configuration store 212. The configuration can be received directly from a customer who wants to manage their network topology. The prefix tracker generates a list of path configuration keys (PCKs) based on the new path and each old path, if present, or other old paths that do not have a corresponding new path. The path configuration keys (PCKs) are overlapped with the configuration store 212 to determine if a match exists. If the prefix tracker identifies a match, then the prefix tracker indicates that the path should be tracked. The path configuration key (PCK) is a tuple having the format device ID, BGP path attribute type, and BGP path attribute value.

[0074] In the example shown in FIG. 6, a list of entries configured on the configuration store is shown. Each entry indicates a device and a BGP path attribute type and value. Paths matching the entry are paths of interest to the customer and will be tracked by the prefix tracker. As an example, the first entry in the configuration store implies that all paths within device d1 with an extended community value of "route-target:1:1" should be tracked. This list of configured path configuration keys (PCKs) is overlapped with the list of path configuration keys (PCKs) generated from the old and new paths described in paragraph

[0073] , and if there is a matching entry, the path will be tracked by the prefix tracker. The second entry implies that all paths within device d1 with a community attribute of 100:1 should be tracked. The third entry implies that all prefixes within device d2 with prefix 100.1.1.0 / 24 should be tracked.

[0075] The prefix tracker applications synchronize in step 310. This process is further illustrated in Figure 7. If, when tracking a path in step 308, the prefix tracker application identifies a path of interest, then the prefix tracker application proceeds to synchronize in step 310. If multiple attribute-value pairs are configured to track a prefix, then the prefix tracker ensures that all attributes in the configuration match while identifying the path of interest in this step.

[0076] The synchronization process 310 includes updating the prefix tracker store 220 with existing route data of interest from the route store 218 if an entry does not already exist in the prefix tracker store 220. The synchronization process 310 includes processing the matched paths by processing the tracked paths stored in the prefix tracker store 220, processing the matched path configuration keys, and updating the prefix tracker store 220 accordingly. First, as part of the prefix tracker synchronization process 310, the prefix tracker store synchronizes the route data of interest from the route store if this data does not already exist in the prefix tracker store 220. This operation is performed to maintain / synchronize the route context even if this prefix was not previously tracked or if configuration was recently added to track this prefix. This allows updates to be processed inline. The tracked paths and matched path configuration keys (PCKs) from the last step are then utilized along with the data in the prefix tracker store to detect events.

[0077] The configuration store also indicates subscribed events for configured Path Configuration Key (PCK) entries, including root events or network events as described below. Tracked path notifications are sent to an alert sink for further processing or notification if the matching Path Configuration Key (PCK) in the configuration store subscribes to any root events.

[0078] If the matching Path Configuration Key (PCK) in the configuration store subscribes to any network events, such as a route purge, the network event causes further processing to detect if such an event has occurred. For example, in a network-wide event such as a route purge, when a path is withdrawn, the total number of paths in the prefix tracker store is checked for that route and Path Configuration Key (PCK). When the last path is withdrawn and this number becomes 0, this implies that the prefix is ​​no longer reachable across the network, and therefore a notification for the route purge is sent to the alert sink. If the last path is withdrawn and this number is not 0, no notification is generated.

[0079] 8 is a schematic flow chart diagram of a method 800 for tracking prefixes in a network topology based on telemetry data. Method 800 includes, at step 802, receiving a new route for the network topology. Method 800 includes, at step 804, determining whether the new route matches an existing route stored on a route store. Method 800 includes, at step 806, determining whether any network routing paths have changed between the existing route and the new route in response to determining that at least one network routing path has changed between the existing route and the new route. Method 800 includes, at step 808, generating a path configuration key for each of the at least one network routing path in response to determining that at least one network routing path has changed between the existing route and the new route.

[0080] 9 is a block diagram of an exemplary computing device 900. Computing device 900 can be used to perform various procedures as described herein. In one embodiment, computing device 900 can perform the functions of an asynchronous object manager and can execute one or more application programs. Computing device 900 can be any of a wide variety of computing devices, such as a desktop computer, an in-dash computer, a vehicle control system, a notebook computer, a server computer, a handheld computer, a tablet computer, etc.

[0081] Computing device 900 includes one or more processors 902, one or more memory devices 904, one or more interfaces 906, one or more mass storage devices 908, one or more input / output devices 910, and a display device 930, all connected to a bus 912. Processor 902 includes one or more processors or controllers that execute instructions stored on memory device(s) 904 and / or mass storage device(s) 908. Processor 902 may also include various types of computer-readable media, such as cache memory.

[0082] The memory device 904 includes a variety of computer-readable media, such as volatile memory (e.g., random access memory (RAM) 914) and / or non-volatile memory (e.g., read-only memory (ROM) 916). The memory device 904 may also include re-writable ROM, such as flash memory.

[0083] The mass storage device 908 includes various computer-readable media such as magnetic tape, magnetic disks, optical disks, solid-state memory (e.g., flash memory), etc. As shown in Figure 9, an exemplary mass storage device is a hard disk drive 924. The mass storage device 908 may also include various drives to allow reading from and / or writing to various computer-readable media. The mass storage device 908 includes removable media 926 and / or non-removable media.

[0084] Input / output (I / O) devices 910 include various devices that allow data and / or other information to be input to or retrieved from computing device 900. I / O devices 910 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, etc.

[0085] Display device 930 includes any type of device capable of displaying information to one or more users of computing device 900. Display device 930 may include, for example, a monitor, a display terminal, a video projection device, etc.

[0086] The interface 906 includes various interfaces that allow the computing device 900 to interact with other systems, devices, or computing environments. The interface 906 can include any number of different network interfaces 920, such as interfaces to a local area network (LAN), a wide area network (WAN), a wireless network, and the Internet. Other interfaces include a user interface 918 and a peripheral interface 922. The interface 906 can also include one or more user interface elements 918. Additionally, the interface 906 may include one or more peripheral interfaces, such as an interface for a printer, a pointing device (such as a mouse, trackpad, or any suitable user interface currently known or known to those skilled in the art), a keyboard, etc.

[0087] The bus 912 allows the processor 902, memory device 904, interface 906, mass storage device 908, and I / O device 910 to communicate with each other and with other devices or components connected to the bus 912. The bus 912 may represent one or more of several types of bus structures, such as a system bus, a PCI bus, an IEEE bus, a USB bus, etc.

[0088] Although programs and other executable program components are illustrated herein as separate blocks for purposes of illustration, such programs and components may reside at various times in different storage components of computing device 900 and be executed by processor 902. Alternatively, the systems and procedures described herein may be implemented in hardware or a combination of hardware, software, and / or firmware. For example, one or more application specific integrated circuits (ASICs) may be programmed to perform one or more of the systems and procedures described herein. [Example]

[0089] The following examples relate to further embodiments.

[0090] Example 1 is a method. The method includes receiving a route for a network topology and determining whether the route matches an existing route stored on a route store. The method includes, in response to determining that the route matches the existing route, determining whether any network routing paths have changed between the existing route and the route. The method includes, in response to determining that at least one network routing path has changed between the existing route and the route, generating a path configuration key for each of the at least one network routing path.

[0091] Example 2 is the method as in example 1, wherein receiving routes for the network topology includes receiving updates directly from an input topic stream dedicated to receiving updated route information for the network topology.

[0092] Example 3 is the method as in any of Examples 1 and 2, wherein determining whether the route matches an existing route stored on the route store includes determining based on data associated with the route, the data including one or more of a prefix, a virtual routing and forwarding (VRF) address, or a device.

[0093] Example 4 is the method as in any of Examples 1-3, further including receiving an add or delete operation associated with the route, and the method further including updating the route store according to the add or delete operation.

[0094] Example 5 is the method as in any of Examples 1-4, further including, in response to the route being associated with the add operation and further in response to identifying an existing route on the route store, updating the route store to reflect the existing route, or further in response to determining that there is no existing route stored on the route store that matches the route, updating the route store to add the route.

[0095] Example 6 is the method as in any of Examples 1-5, further including, in response to the route being associated with the delete operation and further in response to identifying an existing route on the route store, updating the route and deleting the existing route, or further in response to determining that there is no existing route stored on the route store that matches the route, terminating processing operations associated with the route.

[0096] Example 7 is the method of any of Examples 1-6, wherein determining whether any network routing paths have changed between the existing route and the route includes determining whether any routing paths not present in the existing route have been added to the route, determining whether any routing paths present in the existing route have been changed in the route, and determining whether any routing paths present in the existing route have been canceled in the route.

[0097] Example 8 is the method as in any of Examples 1-7, wherein the path configuration key includes one or more of a device identifier, a Border Gateway Protocol (BGP) path attribute type, or a BGP path attribute value.

[0098] Example 9 is the method as in any of Examples 1-8, wherein the path configuration key includes an indication of one or more BGP prefixes to be tracked.

[0099] Example 10 is the method as in any of Examples 1-9, wherein generating the path configuration key includes generating a plurality of path configuration keys, each of the plurality of path configuration keys being associated with one network routing path that has been changed between the existing route and the route.

[0100] Example 11 is the method of any of Examples 1-10, further including identifying at least one path configuration key of the plurality of path configuration keys that matches configuration data for the new path, the configuration data being stored in the configuration store.

[0101] Example 12 is the method as in any of Examples 1-11, wherein the configuration store includes attributes associated with the new path, the attributes including one or more of an extended community attribute, a community attribute, or a prefix attribute.

[0102] Example 13 is the method as in any of Examples 1-12, further including determining whether the route needs to be tracked based on user input.

[0103] Example 14 is the method as in any of Examples 1-13, further including, in response to determining that the route needs to be tracked, determining whether the route is already stored on the prefix tracker store, and, in response to determining that the route is not already stored on the prefix tracker store, writing the prefix tracker store to include the route.

[0104] Example 15 is the method of any of Examples 1-14, further including processing a path configuration key for each of the at least one network routing path and writing to a prefix tracker store to include the path configuration key for each of the at least one network routing path.

[0105] Example 16 is the method as in any of examples 1-15, further including detecting a route purge in response to determining that at least one element of the route has been removed from the prefix tracker store.

[0106] Example 17 is the method as in any of Examples 1-16, wherein receiving a route for the network topology includes receiving updates via a stream within a real-time streaming framework.

[0107] Example 18 is the method as in any of Examples 1-17, wherein the root store is a stream store in communication with a root processor, the root processor in communication with a plurality of input topic streams that receive data in real time.

[0108] Example 19 is a method such as any of Examples 1-18, wherein receiving a route for the network topology further includes receiving an operation associated with the route, the operation including one of add or delete.

[0109] Example 20 is a method such as any of Examples 1 to 19, wherein the method is performed by a prefix tracker application running on one or more servers associated with a network platform configured to manage a network topology.

[0110] Example 21 is a system. The system includes a plurality of input topic streams. The system includes a plurality of processors, each of the plurality of processors dedicated to one of the plurality of input topic streams. The system includes a plurality of stream stores for storing data, each of the plurality of stream stores dedicated to one of the plurality of input topic streams. The system includes a route processor in communication with each of the plurality of stream stores. The system is such that the route processor determines whether a route for the network topology matches an existing route stored on at least one of the plurality of stream stores.

[0111] Example 22 is the system as in example 21, wherein the plurality of stream stores includes a configuration store, the configuration store is processed by a dedicated configuration processor, and the dedicated configuration processor communicates with the configuration streams of the plurality of input topic streams.

[0112] Example 23 is a system such as any of Examples 21 and 22, wherein the configuration store includes attribute information for multiple routes of the network topology, and the attribute information includes one or more of community attributes, extended community attributes, or large community attributes.

[0113] Example 24 is a system such as any of Examples 21-23, wherein the multiple stream stores include a device store, the device store is processed by a dedicated device processor, and the dedicated device processor communicates with the device streams of the multiple input topic streams.

[0114] Example 25 is the system as in any of examples 21-24, wherein the device store includes an indication of which devices in the network topology are tracking prefixes for the network topology.

[0115] Example 26 is a system such as any of Examples 21 to 25, wherein the multiple stream stores include a route store, the route store is processed by a route processor, and the route store includes information for multiple routes in the network topology.

[0116] Example 27 is a system as in any of Examples 21 to 26, wherein one or more of the plurality of input topic streams is a stream having a real-time streaming framework.

[0117] Example 28 is a system as in any of Examples 21 to 27, in which one or more of the multiple input topic streams are streams within a real-time streaming framework.

[0118] Example 29 is the system as in any of Examples 21-28, wherein each of the multiple input topic streams receives data pertaining to the network topology in real time.

[0119] Example 30 is a system as in any of Examples 21-29, wherein the route processor is configured to execute instructions to track prefixes in a network topology based on telemetry data.

[0120] Example 31 is a system such as any of Examples 21-30, wherein the instructions include receiving a route for the network topology via a root stream of the plurality of input topic streams, and determining whether the route matches an existing route stored on a root store of the plurality of stream stores.

[0121] Example 32 is the system as in any of examples 21-31, wherein the instructions further include: in response to determining that the route matches an existing route, determining whether any network routing paths have changed between the existing route and the route; and in response to determining that at least one network routing path has changed between the existing route and the route, generating a path configuration key for each of the at least one network routing path.

[0122] Example 33 is a system such as any of Examples 21-32, further including storing a path configuration key for each of the at least one network routing path on a prefix tracker store, wherein the prefix tracker store is not dedicated to the input topic stream but is independent of the multiple input topic streams.

[0123] Example 34 is a system such as any of Examples 21-33, wherein the instructions include determining whether the route matches an existing route stored on the route store based on data associated with the route, the data including one or more of a prefix, a virtual routing and forwarding (VRF) address, or a device.

[0124] Example 35 is the system as in any of examples 21-34, wherein the instructions further include receiving an add or delete operation associated with the route, and the instructions further include updating the route store according to the add or delete operation.

[0125] Example 36 is a system such as any of Examples 21 to 35, wherein the instructions are such that determining whether any network routing paths have changed between the existing route and the route includes determining whether any routing paths not present in the existing route have been added to the route, determining whether any routing paths present in the existing route have been changed in the route, and determining whether any routing paths present in the existing route have been canceled in the route.

[0126] Example 37 is the system as in any of examples 21-36, wherein the path configuration key includes one or more of a device identifier, a Border Gateway Protocol (BGP) path attribute type, or a BGP path attribute value.

[0127] Example 38 is the system as in any of Examples 21-37, wherein the path configuration key includes an indication of one or more BGP prefixes to be tracked.

[0128] Example 39 is a system such as any of Examples 21-38, wherein the instructions are such that generating a path configuration key includes generating a plurality of path configuration keys, each of the plurality of path configuration keys being associated with one network routing path that has been changed between an existing route and a route.

[0129] Example 40 is a system such as any of examples 21-39, wherein the instructions further include identifying at least one path configuration key of the plurality of path configuration keys that matches configuration data for the new path, and the configuration data is stored in the configuration store.

[0130] Example 41 is a system such as any of Examples 21-40, wherein the instructions further include: determining whether the route needs to be tracked based on user input; determining whether the route is already stored on the prefix tracker store in response to determining that the route needs to be tracked; and, in response to determining that the route is not already stored on the prefix tracker store, writing the prefix tracker store to include the route, processing a path configuration key for each of the at least one network routing path, and writing the prefix tracker store to include the path configuration key for each of the at least one network routing path.

[0131] The foregoing description has been presented for purposes of illustration and description. The present disclosure is not limited to the precise forms set forth herein. Many modifications and variations are possible in light of the above teachings. Moreover, any or all of the foregoing variations can be combined in any manner to form further combinations of the present disclosure.

[0132] Moreover, although specific embodiments of the present disclosure have been described and illustrated, the present disclosure is not limited to the specific forms or arrangements of parts so described and illustrated. The scope of the present disclosure is defined by the claims of this application or any future claims, separate applications based on this application, and their equivalents, if any.

[0133] It should be noted that any features of the above-described configurations, examples, and embodiments may be combined in a single embodiment, including any combination of features from any of the configurations, examples, and embodiments disclosed herein.

[0134] The various features disclosed herein provide important advantages and advances in the art, and the following claims are illustrative of some of these features.

[0135] In the foregoing detailed description of the present disclosure, for purposes of streamlining the disclosure, various features of the disclosure are grouped together in a single embodiment. This method of disclosure is not to be interpreted as reflecting an intention that the claimed disclosure requires more features than are expressly recited in each claim. That is, inventive aspects may feature fewer than all features of a single foregoing disclosed embodiment.

[0136] The above-described arrangements are merely illustrative of the application of the principles of the present disclosure. Many modifications and alternative arrangements may be devised by those skilled in the art without departing from the spirit and scope of the present disclosure, and the appended claims are intended to cover all such modifications and arrangements.

[0137] Thus, while the present disclosure has been illustrated in the drawings and described in detail above, it will be apparent to those skilled in the art that numerous modifications, including but not limited to variations in size, material, shape, form, function, operation, assembly, and use, may be made thereto without departing from the principles and concepts described herein.

[0138] Additionally, the functions described herein may be implemented in one or more of hardware, software, firmware, digital components, or analog components, where appropriate. For example, one or more application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) may be programmed to implement one or more of the systems and procedures described herein. Specific terms are used throughout the description and claims to refer to particular system components. Those skilled in the art will recognize that components may be referred to by different names. This document does not intend to distinguish between components that differ in name but function.

[0139] The foregoing description has been presented for purposes of illustration and description. The present disclosure is not limited to the precise forms set forth herein. Many modifications and variations are possible in light of the above teachings. Moreover, any or all of the foregoing variations can be combined in any manner to form further combinations of the present disclosure.

[0140] Moreover, although specific embodiments of the present disclosure have been described and illustrated, the present disclosure is not limited to the specific forms or arrangements of parts so described and illustrated. The scope of the present disclosure is defined by the claims of this application or any future claims, separate applications based on this application, and their equivalents, if any. [Explanation of symbols]

[0141] 100 systems 108 Computing Devices 200 Topology 300 Process Flow 800 ways 900 computing devices 912 Bus

Claims

1. Multiple input topic streams; a plurality of processors, each of said plurality of processors dedicated to one or more of said plurality of input topic streams; a plurality of stream stores for storing data, each of the plurality of stream stores dedicated to one or more of the plurality of input topic streams; a route processor in communication with each of the plurality of stream stores; A system comprising: The system, wherein the route processor determines whether a route for a network topology matches an existing route stored on at least one of the plurality of stream stores.

2. 10. The system of claim 1, wherein the plurality of stream stores includes a configuration store, the configuration store being processed by a dedicated configuration processor.

3. 3. The system of claim 2, wherein the configuration store includes attribute information for multiple routes in the network topology, and the attribute information includes one or more BGP route attributes or prefixes, and the BGP route attributes include one or more of a community attribute, an extended community attribute, or a large community attribute.

4. 10. The system of claim 1, wherein the plurality of stream stores includes a device store, the device store is processed by a dedicated device processor, and the dedicated device processor communicates with device streams of the plurality of input topic streams.

5. 5. The system of claim 4, wherein the device store includes an indication of which devices in the network topology are tracking prefixes for the network topology.

6. 2. The system of claim 1, wherein the plurality of stream stores includes a route store, the route store processed by the route processor, and the route store contains information for a plurality of routes in the network topology.

7. 10. The system of claim 1, wherein one or more of the plurality of input topic streams is a stream within a real-time streaming framework.

8. 10. The system of claim 1, wherein each of the plurality of input topic streams receives data pertaining to the network topology in real time.

9. 10. The system of claim 1, wherein the route processor is configured to execute instructions to track prefixes in the network topology based on telemetry data.

10. The instruction: receiving the route for the network topology via a route stream of the plurality of input topic streams; and determining whether the route matches an existing route stored on a route store of the plurality of stream stores; 10. The system of claim 9, further comprising:

11. The instructions further include: In response to determining that the route matches the existing route, determining whether any network routing paths have changed between the existing route and the route; and generating a path configuration key for each of the at least one network routing path in response to determining that at least one network routing path has changed between the existing route and the route; 11. The system of claim 10, comprising:

12. 12. The system of claim 11, further comprising storing the path configuration key for each of the at least one network routing path on a prefix tracker store, the prefix tracker store being independent of the plurality of input topic streams rather than dedicated to an input topic stream.

13. 13. The system of claim 12, wherein the instructions are such that determining whether the route matches the existing route stored on the route store includes determining based on data associated with the route, the data including one or more of a prefix, a virtual routing and forwarding (VRF) address, or a device.

14. 12. The system of claim 11, wherein the instructions further comprise receiving an add, update, or delete operation associated with the root, and the instructions further comprise updating the root store according to the add, update, or delete operation.

15. The instruction: Determining whether any network routing paths have changed between the existing route and the route includes: determining whether any routing paths not present in the existing route have been added to the route; determining whether any routing paths present in the existing route have been changed within the route; and determining whether any routing paths present in the existing route have been withdrawn within the route; 12. The system of claim 11, wherein the instructions include:

16. 12. The system of claim 11, wherein the path configuration key comprises one or more of a device identifier, a Border Gateway Protocol (BGP) path attribute type, or a BGP path attribute value.

17. 12. The system of claim 11, wherein the path configuration key includes an indication of one or more BGP prefixes to be tracked.

18. 12. The system of claim 11, wherein the instructions are such that generating the path configuration key includes generating a plurality of path configuration keys, each of the plurality of path configuration keys being associated with one network routing path that has been changed between the existing route and the route.

19. The instructions further include: determining whether the route needs to be tracked based on user input; In response to determining that the route needs to be tracked, determining whether the route is already stored on a prefix tracker store; responsive to determining that the route is not already stored on the prefix tracker store, writing to the prefix tracker store to include the route; processing the path configuration key for each of the at least one network routing path; and populating the prefix tracker store to include the path configuration key for each of the at least one network routing path; 12. The system of claim 11, comprising:

Images