Active BGP sessions

Rotonda
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.