Design Pattern: Looking Glasses

It’s probably safe to say that service provider networking is pretty unique.

One particular design pattern - Looking Glasses - is extremely useful for complex dynamically routed networks.

I’d really like to shift the gatekeeping needle here - networks that are complex enough to benefit from a looking glass should move to:

• 100 Routing table entries globally

• Some vague preference towards reliability
• Dynamic Routing (BGP is preferred)

In any small to medium enterprise, I’d posit that the only thing truly preventing benefits, in this case, is the lack of dynamic routing adoption, primarily because pre-packaged offerings in this range don’t have an “easy button” for implementing them. This lack of accessibility causes a real problem with SMB networking, as reliability features stay out of their reach.

Design Pattern: Looking Glass

A Network “Looking Glass” is a type of web server that responds to user requests, providing externalized (without userspace access to network equipment) to an authenticated or unauthenticated client. This allows clients to view BGP meta-data, routing tables to ensure outbound advertisements between Service Providers have propagated.

Here’s my starting point for this design pattern.

History (non-inclusive)

Note: I don’t have everything here. It seems most Looking Glasses were stood up silently by telecommunications companies. They’re searchable, but I can’t find any citable data on when they started out.

• Looking Glass software has been publicly available since 2000, with the MRLG package reaching public availability
• The University of Oregon set up a public route visibility project called Route Views to expand public visibility to Looking Glasses as early as 1999, with numerous citations in academic research driving the majority of network reliability knowledge we use today.
• BGPView.io starts up in 2016
• BGP Hijacking, whether malicious or not, is causing many more outages than it used to as the internet grows in scope.

Form

• Least (Zero) Privilege Access to a network services routing table, searchable via API and/or GUI

Forces

• Few Network Operating Systems (NOS) have a read-only permission set that also allows access to the RIB/FIB/Routing Table
• Multi-tenancy should be addressed in a scalable, easy-to-manage manner
• This shouldn’t take the network down

Of these forces, #1 is probably the biggest. Since we cannot force all of the networking industry titans (yet) to provide a permission set that will facilitate this use - I’d propose the following approach:

In this solution, I’m proposing some additional safeguards/scale-guards to make sure that the approach will not be harmful to a “host” network. In addition to implementing the looking glass, I’d propose the deployment of a series of Virtual Network Functions (VNFs) scaled out with monitored routing tables. This is where the collectors would interact - if the physical network doesn’t allow any inbound prefixes from the VNF, it’s easy enough to build a solution to safely collect from it. There are tons of VNF options here - as we only need BGP capability and a collection method.