NB: this is neither an endorsement for or against generating policy from databases.
Could somebody that has done this comment on how complicated this is to set up? What steps were involved?
Taking "this" to mean "filter on policy learned from databases," following is a Tcl fragment wrapped around RAToolkit's "peval" that I used to use to query the RADB and build intermediate data from which I would then generate either Cisco prefix lists or Juniper policy statements. The Tcl proc "psort," used to sort a list of prefixes in CIDR notation, is left as an exercise to the reader. proc peval {macro tag allow_incomplete description} { set res [list "$tag\tdescription\t[list $description]"] set incomplete 0 if {[catch {set tmp [exec peval $macro]} why]} { set tmp [lindex [split $why \n] 0] set incomplete 1 } set plist "" if {[regexp {\(\{([^\}]+)\}\)} $tmp junk tmp2]} { set tmp3 [split $tmp2 ,] foreach U [lsort -command psort $tmp3] { lappend res "$tag\tpermit\t[string trim $U]" } } if {[info exists res]} { if {$incomplete && !$allow_incomplete} { return "# [join $res "\n# "]" } else { return "[join $res \n]" } } } The Tcl proc named "peval" takes four arguments: the macro to be evaluated, a tag that I would use later to name the final result, whether an incomplete list of prefixes is permitted, and a description. That third bit, whether an incomplete list of prefixes is permitted, turns out to be an important bit. Some bits of policy refer to other bits of policy, and when bits referenced to not exist peval (the RAToolkit peval, called by Tcl exec) writes them to stderr and causes Tcl to raise an exception. An example (I used to run AS33, and the policy for AS33 doesn't appear to have been changed since I last updated it so I'll take the liberty of picking on it; yes, I know DEC was bought by Compaq and Compaq bought by HP): % source xpeval.tcl % peval as33 33 1 "Digital Equipment Corporation prefixes" 33 description {Digital Equipment Corporation prefixes} 33 permit 16.0.0.0/8 33 permit 128.45.0.0/16 33 permit 130.180.0.0/16 33 permit 198.55.32.0/21 33 permit 198.55.40.0/23 33 permit 199.33.32.0/24 33 permit 199.33.32.0/19 33 permit 199.80.128.0/17 33 permit 204.123.0.0/16 (Goodness, that's a lot of address space, isn't it?) RAToolkit's peval uses rpsl-p.merit.edu as its source of data, and, amusingly, returns data for the macro "AS33," even though the RADB seems to have no AS33 aut-num object. Go figure. Anyways, there was more glue to (a) build vendor-specific configuration language to turn that into a syntactically correct filter for routers (the kind of glue that has to be rewritten every time a new vendor invents a new configuration language), with care taken not to replace a previously-defined filter with no filter should an error be introduced into the RADB, (b) and update the router configs nightly with the new policy. When I ran into the problem of a list of prefixes for one peer being generated that caused the resulting (compressed) configuration to exceed the size of flash memory on my routers, I stopped the cron job and switched all the peers over to "maximum-prefix"-style limits with a standard bogon exclusion filter. It took a couple days to put it together and test it (although I didn't think to test the "list too long" case), and was in production for about a year and a half. The vendors' implementation of maximum prefix limits was not available when I started it, and was available when the "list too long" case cropped up.