These days I think the idea is to use unnumbered or dynamic neighbors so most of the configuration complexity goes away: https://docs.cumulusnetworks.com/display/DOCS/Border+Gateway+Protocol+-+BGP#... In this case, your container would peer directly with the switch. --Doug On Mon, Jun 18, 2018 at 2:13 PM, Jeff Walter <jwalter@weebly.com> wrote:
Years back I ran ExaBGP inside a Docker container (when it wasn't "production ready") to anycast a contained service both within a datacenter and across them. To make routing work correctly I had to also run another BGP daemon on the Docker host machine; I can't remember if I used bird for this, but it seems like what I'd use since I didn't need programmatic control of prefixes.
Would I do it that way today? Not a chance. How would I do it? That would really depend on two things: what I'm trying to accomplish with BGP and what the service is. If you just want portability of a service (not redundancy/balancing via anycast) is BGP really the best option? I'd make a strong case for OSPF due to it needing far less config. The same need for a routing instance on the Docker host would apply, but you wouldn't need to manage configuration for neighbors as containers come up and go down (since the IP will likely change). Sure, you could just add neighbor config for every IP Docker might use, however-- ouch.
Jeff Walter
On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert <hugo@slabnet.com> wrote:
On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess <mysidia@gmail.com> wrote:
Running the BGP application in a container on a shared storage system managed by a host cluster would also make it easier to start the service up on a different host when the first host fails or requires maintenance.
On the other hand, running directly on a host, suggests that individual hosts need to be backed up again, and some sort of manual restore of local files from the lost host will be required to copy the non-containerized application to a new
host.
Even if the BGP speaker is running right on the host, the shared storage or backups thing doesn't click for me. What about your BGP speaker will need persistent storage? At least in our environment, everything unique about the BGP speaker is config injected at startup or can be derived at startup. This might be based on differences in how we're using them (BGP daemon per container host in our case, rather than "I need X number of BGP speakers; schedule them somewhere"), I guess.
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal