Virtual Network Lab, MongoDB with the BGP Routes Database

I advise that “first viewers” of this technical blog series begin with the initial posting at url:  Portal Automation Introduction

As initially stated:  …..each new post will describe configuring a subsequent step(s) in the (initially stated)agenda. I expect to be adding new posts for this series semi-weekly.
The intent of this virtual lab configuration was:
1.      primarily to configure a portal supporting automation, employing current portal and software tools
2.      secondarily to  create a flexible automated network tool, in this case a black hole route injection tool.
MongoDB, BGP Routes Database and the Idea of Relational
Issues with Mongo
MongoDB collections are not relational. The ease with which MongoDB collections can be set up, searched, accessed, automated and modified lends Mongo as a tempting siren for applications that may not require relational data sets or collections.  However; Mongo has been a reef siren for application developers who (mistakenly) believed that their apps will not require relational data sets. In those instances where Mongo was wrongly selected for development and relational data sets eventually became required; redevelopment (from scratch) with a relational DB became necessary. Refer to: Cautions with MongoDB
Why Mongo is great with BGP
Any level of DB synchronization between speakers is already achievable between BGP routers themselves. It isn’t necessary to configure an external DB to retain full (relational) BGP databases of all established speakers, for the purpose of maintaining a dependable BGP DB of a particular speaker.  So, a Mongo collection for one BGP speaker’s route DB is quite adequate for understanding the Autonomous System world around that speaker.
This argument is a bit lengthy for the simple BGP black hole route DB supporting our route injector, but I felt I should mention Mongo as being an adequate choice for this BGP application regardless of the application’s  simplicity.
MongoDB Schema
The Mongo schema is flexible:
1.       enabling programmers to allow the insertion of any number of key-value pairs
2.       allowing the users to choose to insert only key-value pairs that they desire
Mongo will allow records (documents on Mongo parlance) to contain unequal quantities of key-value pairs. For any document in a Mongo collection, users can insert only the key-value pairs that they choose and any particular document is searchable based on the key-value pairs contained in it. An example of an unformatted  collection generated by my application follows:
> use portalDB
switched to db portalDB
> db.prefixinfo2.find()
{ “_id” : ObjectId(“59e0c09ec39b950cd5d88c6e”), “nexthop” : “100.10.1.1”, “localpref” : “500”, “aspath” : “65411”, “prefix” : “100.100.1.1”, “opnotes” : “affected ACME corp”, “neighbor” : “100.200.1.1” }
{ “_id” : ObjectId(“59e0c10ac39b950cd5d88c6f”), “nexthop” : “100.10.1.1”, “localpref” : “500”, “aspath” : “65411”, “prefix” : “100.100.2.1”, “opnotes” : “DOS source”, “neighbor” : “100.200.1.1” }
{ “_id” : ObjectId(“59e0c177c39b950cd5d88c70”), “nexthop” : “100.10.1.1”, “localpref” : “500”, “aspath” : “65411”, “prefix” : “100.100.3.1”, “opnotes” : “requested by Skynet”, “neighbor” : “100.200.1.1” }
{ “_id” : ObjectId(“59e0c1d8c39b950cd5d88c71”), “nexthop” : “100.10.1.1”, “localpref” : “500”, “aspath” : “65411”, “prefix” : “10.100.4.1”, “opnotes” : “DOS attack  started 10/10/2017”, “neighbor” : “100.200.1.1” }
>
The same collection illustrated as formatted, follows below:
> db.prefixinfo2.find().pretty()
{
           “_id” : ObjectId(“59e0c09ec39b950cd5d88c6e”),
           “nexthop” : “100.10.1.1”,
           “localpref” : “500”,
           “aspath” : “65411”,
           “prefix” : “100.100.1.1”,
           “opnotes” : “affected ACME corp”,
           “neighbor” : “100.200.1.1”
}
{
           “_id” : ObjectId(“59e0c10ac39b950cd5d88c6f”),
           “nexthop” : “100.10.1.1”,
           “localpref” : “500”,
           “aspath” : “65411”,
           “prefix” : “100.100.2.1”,
           “opnotes” : “DOS source”,
           “neighbor” : “100.200.1.1”
}
{
           “_id” : ObjectId(“59e0c177c39b950cd5d88c70”),
           “nexthop” : “100.10.1.1”,
           “localpref” : “500”,
           “aspath” : “65411”,
           “prefix” : “100.100.3.1”,
           “opnotes” : “requested by Skynet”,
           “neighbor” : “100.200.1.1”
}
The portal GUI allowing the insertion of those values is below:
An examination of the key-value pairs; while keeping in mind the purpose of my black hole route insertion application will suggest that any key-values aside from prefix, next-hop and neighbor may be unnecessary. The key-value for op-notes may prove useful for some instances.  Key-values for as-path and local-pref may not be useful in the general sense, but the capability of inserting those key-values may become valuable later.  In essence, the collection tolerates the insertion of different quantities of key-value pairs for different records.
Taking the above into consideration, my portal is an example of the MongoDB  flexible document schema capability.