[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BGP in a containers

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#BorderGatewayProtocol-BGP-ConfiguringBGPUnnumberedInterfaces

In this case, your container would peer directly with the switch.

--Doug


On Mon, Jun 18, 2018 at 2:13 PM, Jeff Walter <jwalter at 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 at slabnet.com> wrote:
>
> >
> > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess <mysidia at 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 at slabnet.com
> > pgp key: B178313E   | also on Signal
> >
>