Error in assignments....?

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

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

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
33 permit
33 permit
33 permit
33 permit
33 permit
33 permit
33 permit
33 permit

(Goodness, that's a lot of address space, isn't it?)

RAToolkit's peval uses 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.

peval uses the !gas<as#> query to return the prefixes.
This will return all registered route: objects for all databases
that are being used to respond to queries.

These currently seem to be: