Virtual Network Lab BGP Operation

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.
As stated in the previous blog entry:
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.
The capability of Linux to operate with BGP was an advantage for a virtual lab.  BGP processes are available for Linux enabling full Linux BGP speakers and Linux BGP route injectors.
The diagram illustrated in blog entry Lab Topology is replicated below:
The exaBGP speaker virtual machine announces or withdraws prefixes introduced via the portal to the (full BGP speaking) quagga BGP virtual machines.
Quagga BGP
The quagga BGP configuration is simple. The essential documentation url is at:  http://www.nongnu.org/quagga/docs/docs-multi
QuickStart quagga BGP configuration examples are also available via the Internet.
The BGP process can run in the background on ubuntu, turning an Ubuntu VM into a BGP router. Telnetting to localhost:<quagga router port> connects the user to a Cisco cli similar user interface, allowing BGP router configuration.
Each quagga BGP speaker 1) announces loopbacks that have been included in the BGP configuration and 2) listens to BGP announcements.
ExaBGP
ExaBGP is the heart of the tool operation.  An ExaBGP VM is only a prefix announcer (or withdrawal) speaker and maintains no internal prefix database or table. The prefix DB is maintained separately by a MongoDB collection.  The ExaBGP .ini  file establishes the BGP configuration and initiates the Python/Flask file that will launch the portal and direct DB operations.
The method via which an ExaBGP speaker knows of prefixes in which to advertise or withdraw is that the ExaBGP process launches a child Python process, which after receiving user portal input will send prefix changes back to the parent ExaBGP process via stdout writes. The parent ExaBGP process will receive the prefix change requests and advertise or withdraw the prefixes towards the quagga BGP speakers.
The ExaBGP process launches a BGP session as follows (ExaBGP is much more capable than the simple use in this application).
group init {                         
    router-id 10.132.1.248;
   
    neighbor 10.132.3.72  {
        local-address 10.132.1.248;
        local-as 7674;
        peer-as 7674;
    }
    process add-routes {
        run /home/mpate/BGP-Portal/pythonenv/bin/python /home/mpate/BGP-Portal/Portal_App_2/app5.py;
    }
}
The Python code in app5.py
​1) launches the initial portal View,
2) and in turn receives references to execute Python/Flask url code segnments  which cause
    a) prefix announce/withdrawal (stdout) commands to the ExaBGP process
    b) direct Mongo prefix DB operations