BGP in a containers
ray at oneunified.net
Fri Jun 15 08:18:05 UTC 2018
On 06/14/2018 09:22 PM, Michael Thomas wrote:
> So I have to ask, why is it advantageous to put this in a container
> rather than just run it directly
> on the container's host?
Most any host now-a-days has quite a bit of horse power to run services.
All those services could be run natively all in one namespace on the
same host, or ...
I tend to gravitate towards running services individually in LXC
containers. This creates a bit more overhead than running chroot style
environments, but less than running full fledged kvm style
virtualization for each service.
I typically automate the provisioning and the spool up of the container
and its service. This makes it easy to
up-keep/rebuild/update/upgrade/load-balance services individually and
enmasse across hosts.
By running BGP within each container, as someone else mentioned, BGP can
be used to advertise the loopback address of the service. I go one step
further: for certain services I will anycast some addresses into bgp.
This provides an easy way to load balance and provide resiliency of like
service instances across hosts,
Therefore, by running BGP within the container, and on the host, routes
can be distributed across a network with all the policies available
within the bgp protocol. I use Free Range Routing, which is a fork of
Quagga, to do this. I use the eBGP variant for the hosts and
containers, which allows for the elimination of OSPF or similar internal
Stepping away a bit, this means that BGP is used in tiered scenario.
There is the regular eBGP with the public ASN for handling DFZ style
public traffic. For internal traffic, private eBGP ASNs are used for
routing traffic between and within hosts and containers.
With recent improvements to Free Range Routing and the Linux Kernel,
various combinations of MPLS, VxLAN, EVPN, and VRF configurations can be
used to further segment and compartmentalize traffic within a host, and
between containers. It is now very easy to run vlan-less between hosts
through various easy to configure encapsulation mechanisms. To be
explicit, this relies on a resilient layer 3 network between hosts, and
eliminates the bothersome layer 2 redundancy headaches.
That was a very long winded way to say: keep a very basic host
configuration running a minimal set of functional services, and
re-factor the functionality and split it across multiple containers to
provide easy access to and maintenance of individual services like dns,
smtp, database, dashboards, public routing, private routing,
firewalling, monitoring, management, ...
There is a higher up-front configuration cost, but over the longer term,
if configured via automation tools like Salt or similar, maintenance and
security is improved.
It does require a different level of sophistication with operational staff.
> On 06/14/2018 05:03 PM, Richard Hicks wrote:
>> I'm happy with GoBGP in a docker container for my BGP
>> Dashboard/LookingGlass project.
>> Its just piping RIB updates, as JSON, to script to feed into MongoDB
>> At work we also looked at GoBGP as a route-server for a small IXP type of
>> setup, but ran into few issues that we didn't have the time to fully
>> debug. So we switched to BIRD for that project.
>> We are happy with both.
>> On Thu, Jun 14, 2018 at 11:56 AM, james jones <james.voip at gmail.com>
>>> I am working on an personal experiment and was wondering what is the
>>> option for running BGP in a docker base container. I have seen a lot
>>> and docs referencing Quagga. I just want to make sure I am not over
>>> any other options before I dive in. Any thoughts or suggestions?
ray at oneunified.net
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the NANOG