Review my BGP configuration

[Hans van Kranenburg]

Hi Andre,

On 03/02/2013 10:40 PM, Andre Nathan wrote:
> 
> I have just put my first bird router up in production. Everything is
> working fine, but I wonder if there are any modifications that I can do
> to my configuration to optimize it and/or adhere best practicess.

Congratulations! :)

> My prefix is, in the configuration bellow, a.b.0.0/23, but I want to
> export it as two separate /24 prefixes, a.b.0.0/24 and a.b.1.0/24.
> 
> [...]
> 
> The part that is bugging me about this configuration is the need for a
> kernel protocol black list filter. Is there a cleaner way to do this?

In this case, you can take advantage of the fact that you can create as
many internal extra routing tables in bird for your own administration
as you like, eliminating the 'bugging' extra filters you need when
putting all in a single table. Using 'pipe' protocols you can
import/export routes between the custom defined tables.

As an example, here's how I'm doing this, adjusted to your config:

    +--------+
    | master |
    +--------+
       ^ |
       | |  p_bgp_to_master
       | v
    +--------+  --->
    | t_bgp  |  <--- iBGP
    +--------+
       ^ |
       | |  p_wzyx_to_bgp
       | v
    +--------+  --->
    | t_wzyx |  <--- eBGP to wzyx
    +--------+
       ^
       |  originate_to_wzyx
       |
    bgp routes we
    want to announce

The extra route tables used here are a table per eBGP peer, in which we
can keep a 'local' administration of what happens to/from this peer, and
a t_bgp table, in which all external learned bgp routes are imported,
and which can be used to export those routes to iBGP peers so they know
where to go outside of our local network.

Here's a diff on your config which implements this:

--- bird-nathan.orig	2013-03-02 23:47:08.963808563 +0100
+++ bird-nathan	2013-03-03 00:12:03.128925412 +0100
@@ -1,36 +1,30 @@
-# Protocol kernel: the black list is so that the routes for
-# the two /24 reject routes from the static protocol are not
-# added to the kernel routing table. This kinda smells fishy.
-# Is there a way around this?
-filter kernel_filter
-prefix set KERNEL_BLACKLIST;
-{
-  KERNEL_BLACKLIST = [
-    a.b.0.0/24,
-    a.b.1.0/24
-  ];
-  if net ~ KERNEL_BLACKLIST then {
-    reject;
-  }
-  accept;
-}
-
 protocol kernel {
   scan time 20;
-  export filter kernel_filter;
+  export all;
 }

 protocol device {
   scan time 10;
 }

-# Prefixes to be exported to BGP, plus a route to the BGP neighbor:
+# A route to the BGP neighbor:
 protocol static mynetwork {
-  route a.b.0.0/24 reject;
-  route a.b.1.0/24 reject;
   route w.z.y.x/32 via w.z.y.1;
 }

+# Use this routing table to gather external routes received via BGP
+# which we want to push to the kernel via our master table and to
+# other routers in our AS via iBGP or even to other routers outside
+# our AS again (transit), which can be connected here or to a router
+# elsewhere on the border of our AS.
+table t_bgp;
+
+protocol pipe p_master_to_bgp {
+  table master;
+  peer table t_bgp;
+  import all;  # default
+  export none;  # default
+}
+
 # The file below contains a single definition: define BGP_MED=200.
 # This is used when, due to failover, the iBGP peer becomes the
 # preferred router. A script is executed changing the MED value to
@@ -72,7 +66,21 @@
 # BGP sessions
 #

+# simply create an extra internal routing table per external peer,
+# which helps keeping the route administration separate from the
+# master table. e.g. injecting routes we want to originate to an eBGP
+# peer happens here
+table t_wzyx;
+
+protocol static originate_to_wzyx {
+  table t_wzyx;
+  import all;  # originate here
+  route a.b.0.0/24 reject;
+  route a.b.1.0/24 reject;
+}
+
 protocol bgp eBGP {
+  table t_wzyx;
+  igp table master;
   description "eBGP";
   local as 1234;
   source address x.y.z.w;
@@ -82,7 +90,18 @@
   export filter ebgp_out;
   import filter ebgp_in;
 }
+
+protocol pipe p_bgp_to_wzyx {
+  table t_bgp;
+  peer table t_wzyx;
+  # put all learned routes into central bgp table
+  import where proto = "eBGP";
+  export none;  # no transit please
+}
+
 protocol bgp iBGP {
+  table t_bgp;
+  igp table master;
   description "iBGP";
   local as 1234;
   source address x.y.z.w;
@@ -90,4 +109,7 @@
   next hop self;
   gateway direct;
   default bgp_local_pref 100;
+  # share all bgp routes with our ibgp peer
+  import all;
+  export all;
 }

This approach is similar to the example of a route server in the bird
examples section, in fact it's where I got the ideas to do this:
https://redmine.labs.nic.cz/projects/bird/wiki/Route_server_with_community_based_filtering_and_multiple_RIBs

Defining transit is as simple as re-exporting routes that were learned
from eBGP peer X from the t_bgp table to the dedicated table for peer y
again. :)

-- 
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenburg at mendix.com | www.mendix.com