Rapid and verifiable network configuration repair

Abstract

Discussed herein is technology for verifiable network configuration repair. A method can include adding a routing adjacency or route redistribution edge to a router of an aETG to generate an enhanced aETG (eaETG), adding, for each dETG of dETGs, static route edges to a destination of the dETG to generate an enhanced dETG (edETG), determining, for each of the edETGs, all simple paths from all sources to the destination of the edETG, determining a set of paths (pathset) over the determined simple paths that satisfies the policies, and translating the edge additions and/or removals in the eaETG and in the edETGs to an addition and/or removal of one or more of a routing adjacency, routing filter, or static route based on the determined pathset.

Description

GOVERNMENT RIGHTS[0001]This invention was made with Government support under government contract FA8750-16-C-0176. The Government has certain rights in this invention.TECHNICAL FIELD[0002]Embodiments pertain to computer architecture and computer security. More specifically, some embodiments regard automatic network configuration repair and verification.BACKGROUND[0003]Network configuration is still largely a manual, time consuming, and error-prone process. In fact, even during steady state operations, a many network outages are due to misconfigurations in the network. The misconfigurations may be due to network complexity. It is very hard for a human to reason about a distributed network configuration due to the complex composition and interaction of the many control and data plane features and mechanisms involved at different layers. The composition and interaction may be on tens, hundreds, or even thousands of devices (e.g., from different vendors), not to mention the complex cros...

AI Technical Summary

Problems solved by technology

Network configuration is still largely a manual, time consuming, and error-prone process.

In fact, even during steady state operations, a many network outages are due to misconfigurations in the network.

The misconfigurations may be due to network complexity.

It is very hard for a human to reason about a distributed network configuration due to the complex composition and interaction of the many control and data plane features and mechanisms involved at different layers.

Additional complexity stems from reasoning about correctness despite failures, since some common outages and configuration backdoors only manifest because of these latent behaviors, such as after a link failure.

The problems of automated verification and repair of distributed network configurations (as opposed to centralized software-defined networks repair) are known to be intractable.

While this approach is promising, it has several limitations.

First, it is slow, and it does not scale to large networks.

Second, the repair does not always produce a correct solution when the intent specifies k-Reachable policies.

Third, a repair model does not support adding new configuration constructs, such as new routing adjacencies or new static routes that did not exist in the original configurations.

Finally, the model has limited expressiveness and cannot support control planes where the route preferences cannot be modeled using global edge weights, as is the case for example with administrative distances, and border gateway patrol (BGP) local preferences.

This is especially true when downtime could lead to loss of business, or even to loss of critical equipment such as with industrial control system networks.

This means either all paths from source to destination are reachable or all of them are blocked.

Embodiments can enforce failure consistency since violating failure consistency is likely due to a misconfiguration.

For example, an ACL on a primary path that is not on a secondary path or vice versa means that the policy will be violated after the primary path fails.

Despite adding new configuration constructs, the repair problem should not be confused with the configuration synthesis problem.

This approach has several limitations.

Encoding the edges for all the tcETGs directly into a constraint solver formulation significantly reduces scalability.

In addition, constraining ACL optimization to edge addition / removal is inconsistent with the optimality objective since the solution ends up with a correct, but unoptimized combination of permits and denies within an ACL.

Second, an important limitation of CPR is that even if the intent specifies a k-Reachable policy for a traffic class, the repair solution does not guarantee this property, unless an additional primary path policy is explicitly defined for the traffic class.

While path-equivalence can be desirable, it is often too strong of a guarantee and is accordingly hard to achieve without a fine-grained model of the control plane, which comes at the cost of scalability.

Fourth, CPR does not support adding new constructs, such as new routing adjacencies and static routes, that did not exist in the original configurations.

Images