About BGP Monitoring System
Real-time BGP routing information is an essential resource for both researchers and operation communities in Internet routing. In order to collect large number of data in real time, BGP Monitoring System (BGPmon) is designed to monitor BGP updates and routing tables from BGP routers. It uses modular architecture to scalably monitor many BGP routers by distributed deployment while allowing a consolidated and neat interface to end users. BGPmon uses the Extensible Markup Language (XML) for BGP data. This format can accurately record BGP data without any information loss and it is extendable for possible new features in BGP updates.
-
Real-time access to BGP data
- Bgpmon provides live BGP data stream to clients
-
New Monitoring Related Features
-
Scalability
-
New XML Log Format
-
Human Readable
-
Feeds Into a variety of existing tools
-
Trivial to extend using new tags or attributes
-
Choice of tags allow bit for bit reconstruction of update if desired
-
Unknown attributes simply displayed in hex
-
Can automatically annotate to mark events such duplicate updates, AS path changes, etc
-
-
No route selection, no policy, no forwarding, etc
-
Resulting code is extensible
-
Simple Configuration
- Configuraion is done via a command line interface
- Mimic the CISCO IOS configuration
BGPmon architecture
The BGPmon architecture reflects a real-time monitor capable of scaling up and out. The design makes use of threading to provide real-time support and scales up the number of peers and clients supported by the monitor. BGPmon uses a lightweight thread for each peer and client connection. In addition, there are threads for chains to other instances of BGPmon, and some internal functions, such as labelling and XML conversion. The use of threads takes advantage of the trend towards multicore processors.
- Peer Thread: BGPmon creates a peer thread for each peer router and places all BGP messages (Open, Update, Notification,Keepalive, Route-refresh) in the peer queue to create a single, consolidated stream of events. In addition, all changes in the BGP FSM are placed in the peer queue.
- Label Thread: A label thread processes the events from the peer queue and maintains a RIBIN table which contains unprocessed routing information advertised by peers. This thread determines label information based on the state of the RIBIN tables, and places the event and corresponding label in the label queue.
- Period Thread: The period thread periodically issues status information and injects route tables into the event stream.
- XML Thread: The XML thread processes events in the label queue, converts them to XML then places them into the XML queue.