Code Monkey home page Code Monkey logo

peering's Introduction

Neptune Networks Peering Config

This used to be the pipeline to build Neptune Networks' BGP peering configuration. At the time when this was in use, Neptune used BIRD 2.0.7 for its core customer routers and border routers. We relied on this pipeline to take templates and YAML and turn them into a BIRD configuration.

This BGP configuration has been built to be agnostic to Neptune Networks and should work for you as well. An example configuration file can be seen in config/router.fqdn.example.yml. Simply create a similar file with the relevant options to your network and execute the generation steps at the bottom of this README.

The YAML files in config/ go through a transformation step in which they turn into bird.conf, peers.conf, and static.conf files in the out/ directory.

BGP Community Support

The BIRD configuration in this repostiory uses BGP large communities inspired by RFC8195.

Informational

Informational BGP communities offer insight into Neptune's routing policies.

Origin

Community Description
YOUR_ASN:101:1 Originated by you
YOUR_ASN:101:2 Learned from IX
YOUR_ASN:101:3 Learned from private peer
YOUR_ASN:101:4 Learned from transit provider
YOUR_ASN:101:5 Learned from customer

Region

Octets in the function field are the numeric country identifier defined by ISO 3166-1.

Community Description
YOUR_ASN:102:840 Learned in U.S.

Site

Community Description
YOUR_ASN:103:1 Learned at NY1

Actionable

BGP communities which manipulate the routing policy.

Prepends

Community Description
YOUR_ASN:900:1 Prepend YOUR_ASN once on export to all AS's
YOUR_ASN:900:2 Prepend YOUR_ASN twice on export to all AS's
YOUR_ASN:900:3 Prepend YOUR_ASN thrice on export to all AS's
YOUR_ASN:991:xxxxx Prepend YOUR_ASN once on export to AS xxxxx
YOUR_ASN:992:xxxxx Prepend YOUR_ASN once on export to AS xxxxx
YOUR_ASN:993:xxxxx Prepend YOUR_ASN once on export to AS xxxxx

NO_EXPORT

Community Description
YOUR_ASN:600:xxxxx Do not export to AS xxxxx
YOUR_ASN:601:2 Do not export to IX peers
YOUR_ASN:601:3 Do not export to private peers
YOUR_ASN:601:4 Do not export to transit providers
YOUR_ASN:601:5 Do not export to customers
YOUR_ASN:602:840 Do not export in U.S.
YOUR_ASN:603:1 Do not export in NY1

Usage

Start by creating a new .yml file in config/ with all of the configurations you'll need. You can use config/router.fqdn.example.yml as a reference.

Once you've tuned your configuration file to your liking, build the docker image locally:

script/build

And then generate the configuration:

script/generate

This will create a file for each of the templates defined in /templates without the .erb suffix in the out/ directory.

If you find that you need to make any adjustments to the templates, simply do so and then re-run the generator.

Staying up to date

If you use this as a GitHub Repository template, you will occassionally want to sync your version of the repository with the master one located at neptune-networks/peering. To do this, you can run the following commands:

git remote add upstream https://github.com/neptune-networks/peering.git
git fetch upstream
git merge upstream/master --allow-unrelated-histories

Roadmap

  • Community-based local pref
  • PeeringDB max prefix support
  • Blackhole support

peering's People

Contributors

bswinnerton avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar

Forkers

bonzi airgapper idaniellaw as202427 adamvallee

peering's Issues

undefined method `join' for nil:NilClass when missing originations in config

I tried to run it with the following config:

# The public Autonomous System Number of the border router that this
# configuration is running on.
asn: 213021

# A unique identifer of this router, known as the "router ID". This is often an
# IP address of the border router, as it's thought to be unique.
router_id: '91.221.66.72'

# The ISO 3166-1 country code of where the border router is operating. This is
# used for BGP community support.
region_id: 246  # Finland

# A unique identifer of which physical site of the ASN the border router is
# operating in. This is used for BGP community support.
site_id: 2

# The preferred source address of prefixes learned on export from the Kernel.
# Used in source address selection for outgoing packets. Has to be one of the IP
# addresses of the router. More information can be found in:
# https://bird.network.cz/?get_doc&v=20&f=bird-6.html
preferred_source:
  v4: '91.221.66.72'
  v6: '2a0e:8f02:201a::1'

# The prefixes being originated by this router
originations:
  v6:
    - '2a0e:8f02:201a::/48'
    - '2a0e:8f02:201b::/48'

# The RPKI RTR address and port for dropping RPKI invalids.
rpki:
  host: 'rpki.fqdn.example'
  port: 8282

bgp:
  # Upstreams are BGP sessions that give you a full table and you want to
  # announce your own originations and customer prefixes to.
  upstreams:
    sessions:
      - description: 'Creanova'
        asn: 51765
        local:
          v6: '2a0c:f040:0:5326::2'
        # If the upstream has multiple addresses, you can add many items to the
        # `v4` and `v6` options here.
        remote:
          v6: '2a0c:f040:0:5326::1'
  # A core router session is just an iBGP session (a BGP session where both
  # peers share the same ASN).
  cores:
    sessions:
      - description: 'Turku core'
        asn: 213021
        alias: 'turku-core'
        route_reflector: true
        local:
          v6: 'fd00:169:254:253::1'
        remote:
          v6: 'fd00:169:254:253::2'

I'm aware that not all of the values are correct, but I get an error when running sudo script/generate:

Traceback (most recent call last):
        10: from script/ruby-generate:7:in `<main>'
         9: from script/ruby-generate:7:in `chdir'
         8: from script/ruby-generate:8:in `block in <main>'
         7: from script/ruby-generate:8:in `each'
         6: from script/ruby-generate:11:in `block (2 levels) in <main>'
         5: from script/ruby-generate:11:in `each'
         4: from script/ruby-generate:20:in `block (3 levels) in <main>'
         3: from /peering/lib/generator.rb:15:in `render'
         2: from /usr/local/lib/ruby/2.7.0/erb.rb:905:in `result'
         1: from /usr/local/lib/ruby/2.7.0/erb.rb:905:in `eval'
(erb):8:in `block in render': undefined method `join' for nil:NilClass (NoMethodError)

Disabling white/blacklist prefixes still leaves the functions in place

Hi.

For my current setup, we require no whitelist/blacklisted prefixes, so they have been removed from the YAML file. This removed the declaration of the variables that store the prefixes, but not the functions that rely on them.

This seems like a large oversight as the code seems to understand not to implement the prefixes if not defined, but hasn't also cleaned up the filter functions that require those variables.

Thanks

Core routers shouldn't need to originate prefixes

Ideally we'd be able to leave out the originations key in the configurations of Core routers:

peering/config/router.fqdn.example.yml

Lines 67 to 72 in 0befb58

# The prefixes being originated by this router
originations:
v4:
- '198.51.100.0/24'
v6:
- '2001:db8::/32'

But they are currently powering things like:

peering/templates/bird.conf.erb

Lines 7 to 21 in 0befb58

define ORIGINATED_PREFIXES_4 = [
<%= config.originations.v4.join(",\n ") %>
];
define ORIGINATED_PREFIXES_6 = [
<%= config.originations.v6.join(",\n ") %>
];
define OUR_INTERNAL_PREFIXES_4 = [
<%= config.originations.v4.map { |p| "#{p}+" }.join(",\n ") %>
];
define OUR_INTERNAL_PREFIXES_6 = [
<%= config.originations.v6.map { |p| "#{p}+" }.join(",\n ") %>
];

Which are later used in:

peering/templates/bird.conf.erb

Lines 194 to 210 in 0befb58

function is_own_prefix() {
if net.type = NET_IP4 then {
if net ~ ORIGINATED_PREFIXES_4 then {
bgp_large_community.add((OUR_AS, 101, 1));
return true;
}
}
if net.type = NET_IP6 then {
if net ~ ORIGINATED_PREFIXES_6 then {
bgp_large_community.add((OUR_AS, 101, 1));
return true;
}
}
return false;
}

And:

peering/templates/bird.conf.erb

Lines 212 to 218 in 0befb58

function is_own_internal_prefix() {
if net.type = NET_IP4 then
if net ~ OUR_INTERNAL_PREFIXES_4 then return true;
if net.type = NET_IP6 then
if net ~ OUR_INTERNAL_PREFIXES_6 then return true;
return false;
}

Perhaps we can separate the idea of "originations" from "IPs that are ours". The main goal here being that we are able to filter out any prefixes by customers who peer with core routers that may accidentally announce our own prefixes.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.