1 / 16

bgpmon BGP Monitoring System

bgpmon BGP Monitoring System. Dave Matthews Yan Chen He Yan Dan Massey Colorado State University. BGP Monitoring Objectives. Software Dedicated to BGP Monitoring Establish peering session Receive updates Maintain RIB-IN tables Provide easy real-time access to data

lydia
Download Presentation

bgpmon BGP Monitoring System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. bgpmonBGP Monitoring System Dave Matthews Yan Chen He Yan Dan Massey Colorado State University

  2. BGP Monitoring Objectives • Software Dedicated to BGP Monitoring • Establish peering session • Receive updates • Maintain RIB-IN tables • Provide easy real-time access to data • But this software exists….. • Zebra and Quagga are widely used NANOG40 - bgpmon

  3. So Yet Another BGP Package? • Didn’t Add BGP Complexity To Code • No route selection, no policy, no forwarding, etc. • Resulting code is extensible • Did Add Monitoring Related Features • Periodic route refresh to keep monitor in sync • Objective labels to the data Can peer with very large number of routers • Did Focus on Scaling • Chain bgpmon to monitor 100’s of peers • User interface can still appears as single BGPmon • Can chain bgpmon to provide robust protection against failures • Did Add New XML Log Format NANOG40 - bgpmon

  4. BGPMon Architecture NANOG40 - bgpmon

  5. Chaining Together BGPMons NANOG40 - bgpmon

  6. Scaling Features and Chaining • BGPmon stores one RIB-IN for each peer • Updates are transient and written to logs/clients • RIB-IN dominates memory and limits scaling • BGPmon chains distribute RIB-Ins • Each BGPmon provides update flow from each peer • Each BGPmon appears to provide RIB-IN for each peer • In fact only stores RIB-IN for directly connected peers • When user requests RIB-IN from a BGPmon, it acts as a proxy and fetches the RIB-IN from the appropriate BGPmon in chain NANOG40 - bgpmon

  7. Chaining Together BGPMons No RIB-IN stored here! Can instead focus resources on client requests NANOG40 - bgpmon

  8. Log Format Issues • Started with MRT format • Following RIPE, RouteViews, etc. • But encountered some issues…. • ASCII or Binary? • Binary is compact, but clearly not human readable • MRT->ASCII adds extra step and may lose some information • Hard to extend format • Add flag to indicate if peering session encrypted? • Add some annotations the data to indicate duplicates? • Natively support new attributes? NANOG40 - bgpmon

  9. XML • <?xml version="1.0"?> • <bgp> • <message> • <time>2007-03-22T19:00:07Z</time> • <source> <as>65001<as> <ip afi="1">129.82.138.4</ip> </source> • <destination> <as>65009</as> <ip afi="1">129.82.47.109</ip> </destination> • <update> • <path_attributes> • <origin order="0"> • <transitive/> • <igp value='0'/> • </origin> • <as_path order="1"> • <transitive/> • <as_sequence>65001 14041 3356 22351 </as_sequence> • </as_path> • <next_hop order="2"> • <transitive/> • <ip afi=1>129.82.138.4</ip> • </next_hop> • </path_attributes> • <nlri> • <prefix label="NANN" afi="1" safi="1" length="24">82.206.163</prefix> • </nlri> • </update> • /message> • </bgp> NANOG40 - bgpmon

  10. XML Format • Human Readable • Also Feeds Into Many Applications • Trivial to extend using new tags • Choice of tags allow bit for bit reconstruction of update if desired • Unknown attributes simply displayed in hex. • Can automatically annotate to mark events • BGPmon can mark duplicate updates, AS path changes, etc. • But clearly pay a storage cost • Compact binary message is expanded into ASCII with Tags! NANOG40 - bgpmon

  11. XML Storage Costs NANOG40 - bgpmon

  12. Status • Versions running since December • monitor several routers • serviced 20 simulanteous clients • Got Peers? • Interested in testing with additional feeds • Contact Dan Massey (massey@cs.colostate.edu) • Software release for late summer • Want to complete more testing with larger feeds • http://netsec.colostate.edu • XML Log Format Specification in Progress NANOG40 - bgpmon

  13. Questions? NANOG40 - bgpmon

  14. Key Features • real-time feed for clients • scalability (peers and clients) • XML NANOG40 - bgpmon

  15. bgpmon architecture MessageLog Clients Monitor RIB XML Clients Rib In Tables TableDump NANOG40 - bgpmon

  16. multi-bgpmon architecture bgpmon bgpmon bgpmon bgpmon bgpmon NANOG40 - bgpmon

More Related