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.
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.
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.
Originally published at https://blog.engyak.net.
