summaryrefslogtreecommitdiff
path: root/bgp-logger.org
diff options
context:
space:
mode:
Diffstat (limited to 'bgp-logger.org')
-rw-r--r--bgp-logger.org33
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.