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 <jwal...@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 <h...@slabnet.com> wrote: > > > > > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess <mysi...@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: h...@slabnet.com > > pgp key: B178313E | also on Signal > > >
