Active BGP sessions

Rotonda
1

We are going to implement limited active BGP sessions that can sent out BGP PDUs based on a external trigger mechanism.

  • External interface probably JSON/HTTPS POST/PUT receiving a (binary) BGP PDU for a specific peer
  • Rotonda will validate the PDU (alignment with the peer’s session) and send it out
2

The first code for this is in the bgp-pdu-out. Very much work-in-progress still, but there is enough to feed a discussion. Make sure to check the limitations and notes at the end of this post.

New HTTP POST JSON endpoints

To announce a v6 or v4 unicast route:

  • api/v1/bgp/announce/peer/$remote_asn/$remote_ip
  • api/v1/bgp/announce/ingress_id/$ingress_id

The $remote_asn+$remote_ip or $ingress_id determine over which BGP session the PDU goes out.

The body of the request is JSON to describe a list of prefixes, the nexthop IP address, and the wireformat path attributes to be attached (base64 encoded):

{
  "prefix": ["2.2.3.0/24", "3.3.3.0/24"],
  "nexthop": "10.1.0.254",
  "raw_attributes": "QAEBAEACBgIBAAD96UADBAoBAgGABAQAAAAF"
}

Example call:

curl --json '{"prefix": ["2.2.3.0/24", 3.3.3.0/24, "raw_attributes": "QAEBAEACBgIBAAD96UADBAoBAgGABAQAAAAF"}' http://localhost:8080/api/v1/bgp/announce/peer/200/10.1.0.2

To withdraw a v6 or v4 unicast route:

  • api/v1/bgp/withdraw/peer/$remote_asn/$remote_ip
  • api/v1/bgp/withdraw/ingress_id/$ingress_id

The body of the request only contains the list of prefixes to withdraw:

{
  "prefix": ["2.2.3.0/24"]
}

Sending full raw UPDATE PDUs

  • api/v1/bgp/raw/peer/$remote_asn/$remote_ip
  • api/v1/bgp/raw/ingress_id/$ingress_id

On these endpoints, the caller takes responsibility for crafting a PDU valid for this session. Rotonda only checks whether it can parse it and recognizes it as being an UPDATE PDU, but will not add or remove anything.

The full PDU, starting with the 16 byte marker, is passed base64 encoded:

{
   "full_pdu": "/////////////////////wBTAgAAADyADh4AAgEQKhA3gQZ3IQAAAAAAAAABAABAIAENuAAAAABAAQEAQAIGAgEAAP3pQAMECgECAYAEBAAAAAU="
}

Limitations / known issues / ongoing work

  • The announce and withdraw endpoints are limited to IPv6 and IPv4 Unicast
    • Currently, everything goes into the MP_(UN)REACH_NLRI capabilities, regardless of what was exchanged in the BGP OPENs for that session.
    • The raw endpoint could technically send out announcements for any AFISAFI, though this is untested as of yet.
  • There is no check whether the AFISAFI was exchanged in the Capabilities. This shouldn’t break anything, but it would be nice to get a proper error message back from the API call.
  • Announced routes are not yet stored in a adj-RIB-out, and thus can not be queried for. see update in 3
  • The PDU should eventually go through a customizable roto function, where one can inspect (and in the future, alter/add/remove) path attributes, do logging, etc.
  • Testing is ongoing but has been very limited so far, expect rough edges.
3

update:

adj-RIB-out functionality

For the announce and withdraw endpoints (so, not the raw endpoint), the announced/withdrawn routes are now maintained in the main store.

Pros:

  • not yet another custom data structure to maintain
  • leverage all current functionality, e.g. HTTP JSON API support with all the searching and filtering.
  • easy to create dedicated views in the web UI for anything announced by Rotonda itself
  • eventually, with the new store (routedb), we get all the goodies such as writing to persistent storage, resuming, serialisation and transfer via rotoro, etc.

Cons:

  • not all the current machinery/naming is fully suited yet. Most notably, information for the adj-RIB-out view is stored in the ingress::Register while it’s not really an ingress.

So far, the pros seem to outweigh the cons, because the latter seem quite fixable.

Querying the adj-RIB-out

We probably should think about dedicated endpoints or enhanced filters, but for now:

  1. Query the ingresses endpoint to find the (newly introduced) bgpOut type, e.g.
$ curl "http://localhost:8080/api/v1/ingresses?filter\[type\]=bgpOut" | jq .

{
  "data": [
    {
      "id": 3,
      "ingress_type": "bgpOut",
      "parent_ingress": 2,
      "remote_addr": "10.1.0.2",
      "remote_asn": 200
    }
  ]
}
  1. use the id to look into all the stored routes:
curl "http://localhost:8080/api/v1/ribs/ipv4unicast/routes?ingressId=3"

Discussion points

  • for the raw endpoints, currently nothing is stored. Part of the challenge is that non-unicast AFISAFIs can not be stored in the current store. As soon as we refactored to use the new routedb, we’ll have options to store the announcements from these raw API calls.
4

New endpoints to send PDUs to all BGP peers:

  • api/v1/bgp/announce/all
  • api/v1/bgp/withdraw/all
  • api/v1/bgp/raw/all

The HTTP POST parameters are the same as for the endpoints described in this previous post.
The response is (in text) the number of PDUs successfully sent out.

To discuss:

  • As with the ‘individual’ endpoints, there is no check yet to verify whether a certain AFISAFI is agreed on for the BGP session.
  • The response from these /all endpoints should probably carry more info describing, in case of errors, what went wrong and for which BGP session(s). Especially once Rotonda supports more than just v6/v4 unicast, these endpoints might start to produce more or more complex errors.