diff options
Diffstat (limited to 'bgp-logger.org')
-rw-r--r-- | bgp-logger.org | 33 |
1 files changed, 30 insertions, 3 deletions
diff --git a/bgp-logger.org b/bgp-logger.org index a21a4aa..db20c13 100644 --- a/bgp-logger.org +++ b/bgp-logger.org @@ -1,6 +1,6 @@ host: victoria.tug.nordu.net -telnet localhost 50000 # CLI for the logger software. +telnet localhost 50000 # CLI for the logger software, pw=nordunet nc localhost 50001 # Stream of log data. The product is called [[http://bgpmon.netsec.colostate.edu/][BGPmon]]. There's XFB, an [[http://tools.ietf.org/html/draft-cheng-grow-bgp-xml-00][XML format]] for BGP @@ -28,8 +28,6 @@ so now it does. ** Store in SQL db The data is basically what's in a BGP packet. -Primary key should be the prefix. - We should store everything. We should be able to do this in a single table. @@ -40,3 +38,32 @@ To start the server or sudo -i -u postgres /opt/local/lib/postgresql83/bin/pg_ctl -D /opt/local/var/db/postgresql83/defaultdb -l logfile start +* db layout +<2009-06-24 Wed> Discussions with Fredrik. + +- We should store one entry per prefix that has changed. This means +that one UPDATE message can result in more than one entry. + +- TIMESTAMP isn't enough, there's often more than one message per + second. We'll have to store PRECISION_TIME too. + +- Because of TIMESTAMP (above), we need some other primary key, like + an id with AUTO_INCREMENT. (Can we make postmodern add that?) + Update: It's called [[http://www.postgresql.org/docs/8.3/interactive/datatype-numeric.html#DATATYPE-SERIAL][SERIAL]] in PostgreSQL. Use 'bigserial' if we + anticipate more than 2^31 entries. ':col-type serial' should + probably do it. + +- We've identified, from the perl program output, the following fields + to be of interest: + - TIMESTAMP (int32) + - PRECISION_TIME (int) + - WITHDRAWN (list of prefixes), possibly including label + - NLRI (list of prefixes), possibly including label + - AS_PATH (list of integers) + - NEXT_HOP (int32) + +- I think we care only about UPDATE messages. + +- We also should store OCTETS in OCTET_MSG when TYPE is UPDATE (2). + Just in case we find out that we missed something. This is the + complete BGP message. |