BaGPipe-BGP¶

Dataplane driver configuration¶

Note well that the dataplane drivers proposed in the sample config file are dummy drivers that will not actually drive any dataplane state. To have traffic really forwarded into IP VPNs or E-VPNs, you need to select real dataplane drivers.

For instance, you can use the ovs dataplane driver for IP VPN, and the linux driver for E-VPN.

Note well that there are specific constraints or dependencies applying to dataplane drivers for IP VPNs:

• the ovs driver can be used on most recent Linux kernels, but requires an OpenVSwitch with suitable MPLS code (OVS 2.4 to 2.6 was tested); this driver can do bare-MPLS or MPLS-over-GRE (but see Caveats for MPLS-over-GRE); for bare MPLS, this driver requires the OVS bridge to be associated with an IP address, and that VRF interfaces be plugged into OVS prior to calling BaGPipe-BGP API to attach them
• the linux driver relies on the native MPLS stack of the Linux kernel, it currently requires a kernel 4.4+ and uses the pyroute2 module that allows defining all states via Netlink rather than by executing ‘ip’ commands

For E-VPN, the linux driver is supported without any particular additional configuration being required, and simply requires a Linux kernel >=3.10 (linux_vxlan.py).

BaGPipe-BGP local service¶

If systemd init scripts are installed (see samples/systemd), bagpipe-bgp is typically started with: systemctl start bagpipe-bgp

It can also be started directly with the bagpipe-bgp command (--help to see what parameters can be used).

By default, it outputs logs on stdin (captured by systemd if run under systemd).

BaGPipe Fake BGP Route Reflector¶

If you choose to use our fake BGP Route Reflector (see BGP Route Reflection), you can start it whether with the bagpipe-fakerr command, or if you have startup scripts installed, with service bagpipe-fakerr start. Note that this tool requires the additional installation of the twisted python package.

There isn’t anything to configure, logs will be in syslog.

This tool is not a BGP implementation and simply plugs together two TCP connections face to face.

REST API tool for interface attachments¶

The bagpipe-rest-attach tool allows to exercise the REST API through the command line to attach and detach interfaces from IP VPN VRFs and E-VPN EVIs.

See bagpipe-rest-attach --help.

ip netns exec test ping 12.11.11.2
PING 12.11.11.2 (12.11.11.2) 56(84) bytes of data.
64 bytes from 12.11.11.2: icmp_req=6 ttl=64 time=1.08 ms
64 bytes from 12.11.11.2: icmp_req=7 ttl=64 time=0.652 ms

ip netns exec test2 ping 12.11.11.2
PING 12.11.11.2 (12.11.11.2) 56(84) bytes of data.
64 bytes from 12.11.11.2: icmp_req=1 ttl=64 time=1.71 ms
64 bytes from 12.11.11.2: icmp_req=2 ttl=64 time=1.06 ms

Looking glass¶

The REST API (default port 8082) provide troubleshooting information, in read-only, through the /looking-glass URL.

It can be accessed with a browser: e.g. http://10.0.0.1:8082/looking-glass or http://127.0.0.1:8082/looking-glass (a browser extension to nicely display JSON data is recommended).

It can also be accessed with the bagpipe-looking-glass utility:

# bagpipe-looking-glass
bgp:  (...)
vpns:  (...)
config:  (...)
logs:  (...)
summary:
  warnings_and_errors: 2
  start_time: 2014-06-11 14:52:32
  local_routes_count: 1
  BGP_established_peers: 0
  vpn_instances_count: 1
  received_routes_count: 0

# bagpipe-looking-glass bgp peers
* 192.168.122.1 (...)
  state: Idle

# bagpipe-looking-glass bgp routes
match:IPv4/mpls-vpn,*:
  * RD:192.168.122.101:1 12.11.11.1/32 MPLS:[129-B]:
      attributes:
        next_hop: 192.168.122.101
        extended_community: target:64512:78
      afi-safi: IPv4/mpls-vpn
      source: VRF 1 (...)
      route_targets:
        * target:64512:78
match:IPv4/rtc,*:
  * RTC<64512>:target:64512:78:
      attributes:
        next_hop: 192.168.122.101
      afi-safi: IPv4/rtc
      source: BGPManager (...)
match:L2VPN/evpn,*: -

Publish/Subscribe design¶

The engine dispatching events related to BGP routes is designed with a publish/subscribe pattern based on the principles in RFC4684. Workers (a worker can be a BGP peer or a local worker responsible for an IP VPN VRF) publish BGP VPN routes with specified Route Targets, and subscribe to the Route Targets that they need to receive. The engine takes care of propagating advertisement and withdrawal events between the workers, based on subscriptions and BGP semantics (e.g. no redistribution between BGP peers sessions).

Best path selection¶

The core engine does not do any BGP best path selection. For routes received from external BGP peers, best path selection happens in the VRF workers. For routes that local workers advertise, no best path selection is done because two distinct workers will never advertise a route of same BGP NLRI.

Multi-threading¶

For implementation convenience, the design choice was made to use Python native threads and python Queues to manage the API, local workers, and BGP peers workloads:

• the engine (RouteTableManager) is running as a single thread
• each local VPN worker has its own thread to process route events
• each BGP peer worker has two threads to process outgoing route events, and receive socket data, plus a few timers.
• VPN port attachment actions are done in the main thread handling initial setup and API calls, these calls are protected by Python locks

Non-persistency of VPN and port attachments¶

The BaGPipe-BGP service, as currently designed, does not persist information on VPNs (VRFs or EVIs) and the ports attached to them. On a restart, the component responsible triggering the attachment of interfaces to VPNs, can detect the restart of the BGP and re-trigger these attachments.

BGP Implementation¶

The BGP protocol implementation reuses BGP code from ExaBGP. BaGPipe-BGP only reuses the low-level classes for message encodings and connection setup.

Non-goals for this BGP implementation:

• full-fledged BGP implementation
• redistribution of routes between BGP peers (hence, no route reflection, no eBGP)
• accepting incoming BGP connections
• scaling to a number of routes beyond the number of routes required to route traffic in/out of VMs hosted on a compute node running BaGPipe-BGP

Dataplanes¶

BaGPipe-BGP was designed to allow for a modular dataplane implementation. For each type of VPN (IP VPN, E-VPN) a dataplane driver is chosen through configuration. A dataplane driver is responsible for setting up forwarding state for incoming and outgoing traffic based on port attachment information and BGP routes.

(see Dataplane driver configuration)