nanog mailing list archives

Re: BGP in a containers


From: Jeff Walter <jwalter () weebly com>
Date: Mon, 18 Jun 2018 11:13:29 -0700

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



Current thread: