Patent Description:
The present technology pertains to detecting last-mile outages using IP-route clustering.

Most organizations require reliable Internet access. When an outage occurs, it can be time consuming to track down the cause of the issue. This is especially true when infrastructure causing the outage is outside of the control of the organization experiencing the problem. Large Internet outages at the scale of a city or an entire Internet service provider (ISP) may be detected. However, these large-scale outages are rare. Much more common are outages that impact a neighborhood or particular Internet route. These smaller-scale outages are difficult to detect.

<CIT> describes, according to its abstract, a system which may determine receiver identifiers to identify affected receivers, where each of affected receivers failed to receive a packet identified within a packet stream. A loss signature may identify the packet. Each of the affected receivers may be identified by a corresponding one of the receiver identifiers. The system may also determine a packet loss location of the packet from a network topology tree. The network topology tree may include a model of a logical network over which the packet stream was transmitted from a stream source to the affected receivers. The packet loss location may correspond to a lowest common ancestor node of at least two of the affected receivers.

<CIT> describes, according to its abstract, systems, methods, and computer-readable media for OAM in overlay networks. In response to receiving a packet associated with an OAM operation from a device in an overlay network, the system generates an OAM packet. The system can be coupled with the overlay network and can include a tunnel endpoint interface associated with an underlay address and a virtual interface associated with an overlay address. The overlay address can be an anycast address assigned to the system and another device in the overlay network. Next, the system determines that a destination address associated with the packet is not reachable through the virtual interface, the destination address corresponding to a destination node in the overlay network. The system also determines that the destination address is reachable through the tunnel endpoint interface. The system then provides the underlay address associated with the tunnel endpoint interface as a source address in the OAM packet.

In order to describe the manner in which the various advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings.

Various embodiments of the disclosure are discussed in detail below.

Disclosed herein are systems, methods, and computer-readable media for outage detection in networking environments.

Most organizations require reliable Internet access. As discussed above, smaller-scale outages are more common and more difficult to detect compared to large-scale outages, such as city-wide or entire Internet service provider (ISP) outages. For example, outages that impact a neighborhood or a particular Internet route may include a particular device being misconfigured, a network closet losing power, or some other local issue. These occur with more frequency and existing systems are not equipped to detect these types of outages. Furthermore, existing systems are likely inadequate to identify these issues in an IPv6 world because an IPv6 environment includes far more available IP addresses, many of which may not be utilized. In other words, active probing of an IPv6 environment will not work because IP addresses are less densely utilized compared to IPv4 environments. Thus, sending packets to each IP address and waiting for a response would be incredibly compute intensive and inefficient. Furthermore, ISPs frequently reassign IP addresses, which causes further inefficiencies.

Accordingly, the disclosed technology provides systems, methods, and computer-readable media for detecting smaller-scale outages that will work for both IPv4 and IPv6 environments. Additionally, the disclosed technology is useful for identifying outages in the last mile of telecommunications networks. The last mile is the final leg of the telecommunications network that delivers telecommunication services (e.g., Internet) to end-users (e.g., customers). For example, an outage that impacts a neighborhood or particular Internet route may occur because a particular device is misconfigured, a network closet loses power, or some other local issue. These outages can be classified as last mile outages and be difficult for existing technologies to detect. The disclosed technology can detect and character outages for last mile outages in an adaptive manner.

The present technology will be described in the subsequent disclosure as follows. The discussion begins with a description of example ISP networks having various network nodes (e.g. routers, switches, client endpoints), as illustrated in <FIG>. A description of example methods for determining network structure is provided, as illustrated in <FIG>. A description of example methods for detecting and identifying smaller-scale outages (e.g. last-mile outages) is provided, as illustrated in <FIG>. The discussion concludes with a description of an example network device, as illustrated in <FIG>, and an example computing device architecture including example hardware components suitable providing outage detection in networking environments, as illustrated in <FIG>. The disclosure now turns to <FIG>.

<FIG> illustrates an example network environment <NUM> having an Internet service provider (ISP) core network <NUM>. ISP core network <NUM> communicates with various network nodes <NUM>-<NUM> - <NUM>-<NUM> (collectively <NUM>). Communication between ISP core network <NUM> and across network nodes <NUM> can utilize a Border Gateway Protocol (BGP), including both exterior BGP (EBGP) and interior BGP (IBGP), or an interior gateway protocol (IGP). Furthermore, network nodes <NUM> can communicate amongst other network nodes by utilizing tunneling technologies.

ISP core network <NUM> can provide Internet access to one or more network nodes <NUM> by sending, receiving, maintaining, and monitoring data packets to and from network nodes <NUM>. In some implementations, ISP core network <NUM> has a network appliance <NUM> configured to manage data packets within network environment <NUM>. Furthermore, network appliance <NUM> can analyze data packets to create a network model and determine when network node <NUM> disconnects from network environment <NUM>. For example, network appliance <NUM> can receive network data packets that include routes between network nodes. Network appliance <NUM> can then generate a network model based on connected nodes (e.g. routes between network nodes).

It is further contemplated that network appliance <NUM> need not be a part of ISP core network <NUM>. For example, a third party application or service can similarly send, receive, maintain, and monitor data packets to and from network nodes <NUM>. Additionally, a third party application or service can utilize the network data packets to generate the network model.

Network nodes <NUM> can connect to ISP core network <NUM>. Network nodes <NUM> can be any type of network node including, but not limited to a router, an access point, a server, a hub, an antenna, a network interface card (NIC), a module, a cable, a firewall, a repeater, a sensor, a client end point, private networks, etc. Furthermore, network nodes <NUM> are configured to send and receive data packets to allow connected users to access the Internet. Additionally, network nodes <NUM> are configured to utilize wired protocols, wireless protocols, or any other protocols including, but not limited to TCP/IP, OSI (Open Systems Interconnection) protocols (e.g. L1-L7 protocols), routing protocols (e.g. RIP, IGP, BGP, STP, ARP, OSPF, EIGRP, NAT), or any other protocols (e.g. HTTP, SSH, SSL, RTP, FTP, SMTP, POP, PPP, NNTP, IMAP, Telnet, SSL, SFTP, WIFI, Bluetooth, VTP, ISL, IEEE <NUM> standards, L2TP, IPSec, etc.). It is also understood that network nodes <NUM> can receive and utilize one or more policies, configurations, services, settings, and/or capabilities (e.g. security policies, subnetting and routing schemes, forwarding schemes, NAT settings, VPN settings, IP mappings, port number, security information, network administration services, backup services, disaster recovery services, bandwidth or performance services, intrusion detection services, network monitoring services, content filtering services, application control, WAN optimization, firewall services, gateway service, storage services, protocol configuration services, wireless deployment services, etc.).

Moreover, network nodes <NUM> are configured to send, receive, and/or update or modify network data packets. Network data packets can be associated with a route between a first network node and a second network node. Furthermore, the network data packet can associate the first network node as a source node and the second network node as a destination node, such that the first network node can send the network data packet to the second network node through network environment <NUM>. In some cases, the network data packet may traverse through a third network node to ultimately arrive at the second network node. In these cases, the third network node can be configured to update and/or modify the route of the network data packet to associate the third network node as a traversal node. Thus, when the second network node receives the network data packet, the network data packet identifies the source node of the network data packet and any traversal nodes in the route to the destination node. Additionally, network data packets can include IP addresses of any and/or all network nodes <NUM> that have interacted with the network data packets (e.g. sending node, receiving node, intermediate nodes). In some implementations, network nodes <NUM> can implement a traceroute function, multiple traceroute functions, multitraceroute functions (e.g. Dublin Traceroute), etc..

Traceroute functions, as used herein, can include computer network diagnostics commands to generate and display possible routes and measure delays of packets across an Internet Protocol (IP) network. Furthermore, the history of the route can be recorded as roundtrip times of the packets received from each network node <NUM> in the route.

Network appliance <NUM> can utilize the information gathered by the traceroute functions (e.g., the network data packets) to generate a network topology. In some embodiments, the network appliance may convert the one or more routes identified through tracerouting into a graph (e.g., a directed acyclical graph) of connections between network nodes <NUM> in the plurality of network nodes <NUM>. The graph can then be transformed and/or used to generate a network model (e.g., a tree data structure) based on nodes in the graph.

Furthermore, the network topology generated by network appliance <NUM> can identify communications between specific network nodes <NUM> and ISP core network <NUM>. More specifically, network appliance can identify that communications from ISP core network <NUM> to, towards, and/or through a specific network node <NUM> is a downstream communication, while communications from a network node <NUM> to or towards core network <NUM> is an upstream communication. It is to be understood, however, that a communication need not traverse through ISP core network <NUM>. For example, a communication from network node <NUM>-<NUM> to network node <NUM>-<NUM> would be an upstream communication, while a communication from network node <NUM>-<NUM> to network node <NUM>-<NUM> would be a downstream communication.

<FIG> illustrates an example method <NUM> for generating a network model. The method <NUM> shown in <FIG> is provided by way of example, as there are a variety of ways to carry out the method. Additionally, while the example method is illustrated with a particular order of steps, those of ordinary skill in the art will appreciate that <FIG> and the modules shown therein can be executed in any order and can include fewer or more modules than illustrated. Further, each module shown in <FIG> represents one or more steps, processes, methods, or routines in the method.

At block <NUM>, the method <NUM> can send, for example by a first network node, a network data packet to a second network node. The network data packet can include a route associating the first network node as a source node and the second network node as a destination node.

At block <NUM>, the method <NUM> can update, by a third network node, the route in the network data packet when the network data packet traverses through the third network node.

At block <NUM>, the method <NUM> receives, by the second network node, the network data packet with the updated route indicating that the network data packet has traversed through the third network node.

At block <NUM>, the method <NUM> sends, by the second network node, the network data packet to a network appliance with the updated route.

At block <NUM>, the method <NUM> generates, by the network appliance, a network model based on the route of the network data packet. In some cases, multiple network data packets may have been sent and received by various other nodes. In these cases, the network appliance can generate and/or update the network model. As discussed above, it is further contemplated that the network appliance can be an appliance outside of the ISP. In other words, a network appliance outside of the ISP can also generate the network model based on the route of the network data packet.

Furthermore, in some cases, multiple routes are available between network nodes. Thus, in these cases, the network model can include multiple routes between these network nodes. For example, a Dublin Traceroute function can identify a superset of possible paths between network nodes. Thus, the network appliance can use the multiple routes between network nodes to generate the network model having multiple routes between network nodes. Accordingly, the network model reflects a current state of infrastructure and topology of a given network environment and can be used to efficiently answer common ancestor (e.g. connected network nodes closer to ISP core network <NUM>) related queries. One of ordinary skill in the art will also understand that new network nodes can be added to the network model when added to the network environment.

<FIG> illustrates an example tree data structure <NUM> generated and/or transformed from a network environment (e.g., network environment <NUM>). More specifically, network appliance <NUM> can generate and/or transform a tree data structure <NUM> from network environment <NUM>. A tree data structure is an undirected graph in which any two nodes are connected by exactly one path. As shown, tree data structure <NUM> contains network nodes <NUM> from network environment <NUM> in a different structure. To generate tree data structure <NUM>, network appliance <NUM> can apply an algorithm (e.g., method <NUM> below) to compute tree data structure <NUM>. Tree data structure <NUM> provides a structure that accurately reflects a state of network environment <NUM>, while also providing a data structure that is efficient in answering common ancestor related queries. More specifically, tree data structure <NUM> identifies (fuzzy) common ancestors for each network node <NUM>. The tree data structure <NUM> can then be used as a network model for answering common ancestor related queries (e.g., for identifying a single point of failure for an outage of one or more network nodes <NUM>).

<FIG> illustrates an example method <NUM> for generating, converting, or transforming network topology to a tree data structure (e.g., tree data structure <NUM>). The method <NUM> shown in <FIG> is provided by way of example, as there are a variety of ways to carry out the method. Additionally, while the example method is illustrated with a particular order of steps, those of ordinary skill in the art will appreciate that <FIG> and the modules shown therein can be executed in any order and can include fewer or more modules than illustrated. Further, each module shown in <FIG> represents one or more steps, processes, methods, or routines in the method.

At block <NUM>, a network controller receives a network topology (e.g., data packets reflecting network environment <NUM> and/or a directed acyclical graph of network environment <NUM>).

At block <NUM>, the network appliance can determine a plurality of nodes (e.g., network nodes <NUM>) in the network topology.

At block <NUM>, the network appliance can determine a lowest single common ancestor for each of the plurality of nodes. The lowest single common ancestor can be a first ancestor node upstream of a particular node of the plurality of nodes in the network model (e.g., tree data structure <NUM>).

At block <NUM>, the network appliance can generate a tree data structure based on the plurality of nodes and each of the lowest single common ancestors. The tree can be configured to have redundant paths (e.g., multiple paths or routes between nodes) in a graph removed and a node can be directly connected to the lowest single common ancestor. For example, in <FIG>, network node <NUM>-<NUM> has multiple routes from ISP core network <NUM>. Thus, network node <NUM>-<NUM> is shown in <FIG> to have a single common ancestor at ISP core network <NUM>. As another example, in <FIG>, network node <NUM>-<NUM> only has one route through network node <NUM>-<NUM>. Thus, network node <NUM>-<NUM> is shown to have a single common ancestor at network node <NUM>-<NUM> in <FIG>.

<FIG> and <FIG> illustrates an example network environments 500a, 500b having an ISP core network <NUM> and network nodes <NUM>-<NUM> - <NUM>-<NUM> (collectively network nodes <NUM>). Network environments 500a, 500b are reflective of the same network environment (collectively network environment <NUM>). More specifically, <FIG> illustrates network environment 500a in an acyclical graph format, while <FIG> illustrates network environment 500b in a tree data structure format. As discussed above, the tree data structure of environment 500b provides lowest single common ancestor nodes for each network node <NUM>. Additionally, network environment <NUM> has detected that some network nodes are now disconnected network nodes <NUM>-<NUM> - <NUM>-<NUM> (collectively disconnected network nodes <NUM>').

As discussed above, ISP core network <NUM> can include a network appliance <NUM>. Network appliance <NUM> can be configured to detect when a network node <NUM> has become a disconnected network node <NUM>'. For example, network nodes <NUM> can be configured to periodically send data packets to indicate that network nodes <NUM> are still connected to ISP core network <NUM> and network appliance <NUM> can be configured to receive and monitor the data packets. Thus, when network appliance <NUM> does not receive a data packet from disconnected network nodes <NUM>', network appliance <NUM> can determine that disconnected network nodes <NUM>' are disconnected from ISP core network <NUM>.

Additionally, network appliance <NUM> can be configured to identify a source of failure causing network nodes <NUM> to become disconnected network nodes <NUM>'. More specifically, based on the network model generated by network appliance <NUM>, network appliance <NUM> can identify common links and alternative routes between network nodes <NUM> generally. Thus, by searching for common network nodes for disconnected network nodes <NUM>', network appliance <NUM> can identify the source of failure. For example, in <FIG> network nodes <NUM>-<NUM>', <NUM>-<NUM>' have network node <NUM>-<NUM> as a common connected network node <NUM>. However, if network node <NUM>-<NUM> was the source of failure, disconnected network node <NUM>-<NUM>' would not be disconnected due to possible routing across network nodes <NUM>-<NUM>, <NUM>-<NUM>. Thus, network node <NUM>-<NUM> is likely to be the source of failure. In other words, the result of analysis by network appliance <NUM> is a node in the network model highlighting a potential single point of failure and delimiting an area currently experiencing an outage. With this approach, network appliance <NUM> can pick up and characterize failures (e.g. outages) at not only a smaller scale, but also in an adaptive manner. Accordingly, network appliance <NUM> can detect, identify, and present outages from a hyper local outage (e.g. an outage of a customer's router) to large, wide-scale ISP outages (e.g. an outage affecting an entire city) and middle scale outages in between (e.g. a power outage in a district or neighborhood).

This can be further streamlined by utilizing the tree data structure of <FIG>. Continuing the example above, network nodes <NUM>-<NUM>', <NUM>-<NUM>' are not shown to have network node <NUM>-<NUM> as a common connected network node <NUM>. Instead, the tree data structure identifies network node <NUM>-<NUM> as the lowest common ancestor. Thus, by pre-computing the tree data structure and utilizing the tree data structure for queries, common ancestor related queries can be answered with increased efficiency.

<FIG> illustrates an example method <NUM> for identifying a source of failure in a network environment (e.g. a last-mile outage). The method <NUM> shown in <FIG> is provided by way of example, as there are a variety of ways to carry out the method. Additionally, while the example method is illustrated with a particular order of steps, those of ordinary skill in the art will appreciate that <FIG> and the modules shown therein can be executed in any order and can include fewer or more modules than illustrated. Further, each module shown in <FIG> represents one or more steps, processes, methods, or routines in the method.

At block <NUM>, the method <NUM> can monitor, by a network appliance of a network, a plurality of network nodes in real-time. The network nodes can be monitored through an applicable technique for detecting outages at a node-level, e.g. in real-time. For example, the network appliance can be configured to receive data packets from the plurality of network nodes in scheduled intervals. As discussed above, the network appliance can be separate from the ISP. In other words, the network appliance can be an application, service, and/or device that can perform the same.

At block <NUM>, the method <NUM> can detect, by the network appliance, at least one network node of the plurality of network nodes has disconnected from the network. In monitoring network nodes and detecting disconnection of network nodes, an IP address of a node that is a subject of an outage can be identified. For example, the network appliance can detect that a network node has disconnected from the network when the network appliance fails to receive a data packet from the network node at a predetermined time or within a set amount of time.

In monitoring network nodes and identifying disconnected nodes, streams of device disconnections, e.g. resulting from the aggregation of M-tunnel status, can be monitored. Further, an applicable outage detection scheme can be applied to identify potential internet outages. An applied outage detection scheme can be defined by an outage model, which can be based on a burst model, e.g. a Kleinberg burst model, or a binomial mode, e.g. based on elementary binomial testing. Further, a set of potentially disrupted IP addresses can be identified as an outage occurs.

At block <NUM>, the method <NUM> can overlay, by the network appliance, the at least one network node over a network model generated by the network appliance. For example, the network model may be the network model generated by the network appliance at block <NUM> in <FIG>. A model overlay is then generated from the at least one network node overlaid onto the network model. The model overlay can identify and/or show the disconnected node (e.g., the at least one network node) in the scheme of the network model. For example, <FIG> and <FIG> show the model overlay overlaid on the network model to identify and demonstrate the at least one network node that has disconnected (e.g., network nodes <NUM>-<NUM>' and <NUM>-<NUM>').

At block <NUM>, the method <NUM> can determine, by the network appliance, an outage source for the at least one network node by identifying a lowest common ancestor node of the at least one network node. More specifically, the lowest common ancestor node can be a closest upstream node to the network node in the network that provides a single point of failure for either or both upstream communication from the network node and downstream communication to the network node. In situations where two or more network nodes experience an outage, the lowest common ancestor node of the two or more network nodes can be a closest shared upstream node to the network node in the network that provides a single point of failure for either or both upstream communications from the two or more network nodes and downstream communication to the two or more network nodes.

The disclosure now turns to <FIG> and <FIG>, which illustrate example network devices and computing devices, such as switches, routers, nodes, servers, client devices, orchestrators, and so forth.

<FIG> illustrates an example network device <NUM> (e.g. network nodes <NUM>) suitable for performing switching, routing, load balancing, and other networking operations. Network device <NUM> includes a central processing unit (CPU) <NUM>, interfaces <NUM>, and a bus <NUM> (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU <NUM> is responsible for executing packet management, error detection, and/or routing functions. The CPU <NUM> preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU <NUM> may include one or more processors <NUM>, such as a processor from the INTEL X86 family of microprocessors. In some cases, processor <NUM> can be specially designed hardware for controlling the operations of network device <NUM>. In some cases, a memory <NUM> (e.g., non-volatile RAM, ROM, etc.) also forms part of CPU <NUM>. However, there are many different ways in which memory could be coupled to the system.

The interfaces <NUM> are typically provided as modular interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device <NUM>. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, WIFI interfaces, <NUM>/<NUM>/<NUM> cellular interfaces, CAN BUS, LoRA, and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control, signal processing, crypto processing, and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master CPU (e.g., <NUM>) to efficiently perform routing computations, network diagnostics, security functions, etc..

Although the system shown in <FIG> is one specific network device of the present disclosure, it is by no means the only network device architecture on which the present disclosure can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc., is often used. Further, other types of interfaces and media could also be used with the network device <NUM>.

The network device <NUM> can also include an application-specific integrated circuit (ASIC), which can be configured to perform routing and/or switching operations. The ASIC can communicate with other components in the network device <NUM> via the bus <NUM>, to exchange data and signals and coordinate various types of operations by the network device <NUM>, such as routing, switching, and/or data storage operations, for example.

<FIG> illustrates an example computing system architecture of a system <NUM> (e.g. network appliance <NUM>) which can be used to process FaaS operations and requests, deploying execution environments, loading code associated with FaaS functions, and perform any other computing operations described herein. In this example, the components of the system <NUM> are in electrical communication with each other using a connection <NUM>, such as a bus. The system <NUM> includes a processing unit (CPU or processor) <NUM> and a connection <NUM> that couples various system components including a memory <NUM>, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, to the processor <NUM>.

The system <NUM> can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor <NUM>. The system <NUM> can copy data from the memory <NUM> and/or the storage device <NUM> to cache <NUM> for quick access by the processor <NUM>. In this way, the cache can provide a performance boost that avoids processor <NUM> delays while waiting for data. These and other modules can control or be configured to control the processor <NUM> to perform various actions. Other memory <NUM> may be available for use as well. The memory <NUM> can include multiple different types of memory with different performance characteristics. The processor <NUM> can include any general purpose processor and a hardware or software service, such as service <NUM><NUM>, service <NUM><NUM>, and service <NUM><NUM> stored in storage device <NUM>, configured to control the processor <NUM> as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor <NUM> may be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing system <NUM>, an input device <NUM> can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device <NUM> can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing system <NUM>. The communications interface <NUM> can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

The storage device <NUM> can include services <NUM>, <NUM>, <NUM> for controlling the processor <NUM>. Other hardware or software modules are contemplated. The storage device <NUM> can be connected to the connection <NUM>. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor <NUM>, connection <NUM>, output device <NUM>, and so forth, to carry out the function.

Claim 1:
A computer-implemented method (<NUM>) comprising:
monitoring (<NUM>), by a network appliance (<NUM>) associated with a network (<NUM>), a plurality of network nodes (<NUM>);
detecting (<NUM>), by the network appliance, that a network node (<NUM>') of the plurality of network nodes in a last mile of the network has disconnected from the network, wherein the last mile of the network is a final leg of the network that delivers telecommunication services to end-users;
overlaying (<NUM>), by the network appliance, the disconnected network node over a network model (<NUM>, <NUM>) for at least a portion of the network including the disconnected network node to generate a model overlay (500a, 500b), wherein the model overlay identifies and/or shows the disconnected network node in the scheme of the network model; and
determining (<NUM>), by the network appliance, a last mile outage source associated with a disconnection of the network node by identifying a lowest common ancestor node (<NUM>-<NUM>) of the network node from the model overlay, wherein the lowest common ancestor node is a closest upstream node to the network node in the network that provides a single point of failure for either or both upstream communication from the network node and downstream communication to the network node.