Provide a data to BGPmon

All the BGPMon users can be divided into three main groups. Each group will use BGPMon in a defferent level. We organize the user guide into three sections which each section is for a specifc group. So If you are a potential user of BGPMon, the first thing is to find which user group you are in. After that, you can find the most appropriate user guide to read.

Following are the three user groups of BGPmon:

  1. People who want to use realtime BGP data in XML.

    • Telnet or open a TCP connection to port 50001 to get live stream of BGP updates events.
    • Telnet or open a TCP connection to port 50002 to get live stream of BGP table transfer messages.
    • The format of received XML stream is described in the XML specificaiton.
  2. People who can provide us with peering.

    • BGPMon(release 7.4) is running at machine It is ready to peer with other BGP speakers with or without requesting MD5 authentication.
    • If you are interested in peering with us, please send an email including the IP and AS number of your BGP system.
    • Any questions, please feel free to contact us.
  3. People who want to download BGPMon and run it themselves.

    • System requirements: update gcc to 4.1.1, and make sure libxml and libbz2 are installed in a system.
    • Download the BGPMon source package here.
    • Compile and run: refer to the qucik README and administrator refence manual.

Peering FAQ

  1. Do you support authenticated BGP sessions into the system?
  2.   Yes, we support MD5.

  3. Can you provide details about security configurations that limit risk of routes leaking?
  4.   BGPmon does not implement the full BGP state machine. Hence there is no way for it to advertise routes to it's peers. It only monitors incoming BGP messages.

  5. Who will have access to the actual routing information (not just the stats on the "Live Data" webpage)?
  6.   If someone peers with instances of bgpmon that Colorado State University maintains, then the routing data that, will be collected from his routers will be publicly available. In case though, someone wants to maintain a private bgpmon cluster or node he can setup Access Control Lists that impose restrictions on who can view the data.

  7. Do you want a full BGP table feed or just routes originating in our network?
  8.   Full tables are generally more useful. For example, a researcher exploring a prefix hijack may want to see if the hijacked route became the preferred route in your network. so we would prefer you send a full table. Most (but not all) of peers send full tables. but some data is better than none at all so if full tables are a policy problem, even the routes originiting from your network can be very valuable.