neptune-networks / peering Goto Github PK

View Code? Open in Web Editor NEW

25.0 25.0 5.0 75 KB

A YAML to BIRD configuration generator for transit networks.

Home Page: https://neptunenetworks.org/

Ruby 31.48% HTML 67.44% Dockerfile 0.48% Shell 0.60%

bgp bird ixp network-automation peering router-configuration routing

peering's People

Contributors

Stargazers

Watchers

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.

neptune-networks / peering Goto Github PK

peering's People

Contributors

Stargazers

Watchers

Forkers

peering's Issues

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

Disabling white/blacklist prefixes still leaves the functions in place

Core routers shouldn't need to originate prefixes

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

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

	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 ") %>
	];

	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;
	}

	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;
	}