bgpmon bgp monitoring system dave matthews yan chen he yan dan massey colorado state university

bgpmon

BGP Monitoring SystemDave Matthews

Yan Chen

He Yan

Dan Massey

Colorado State University

2 5 June 2006 NANOG40 - bgpmon

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


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


BGPMon Architecture

Rib Updater

Updates in BMF(No Label)

Rib Tables in BMF

BMF(BGPMon Format)

XML

Updates in BMF(With Label)

Updates Convertor

(BMF to XML)

Update Logger

Updates in XM

L

Update Logs in

XML

BGP

Rib Logs in

XML

Rib Convertor(BMF to XMl) and Logger

Client

Client

Rib Convertor(BMF to XMl)

Client

BGPMonBGPMon

BGPMonBGPMon

BGP Peer Monitor


Chaining Together BGPMons

BGPMon

BGPMon BGPMon

Logs Logs

Client

ClientClient

XML

BGP


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


Chaining Together BGPMons

BGPMon

BGPMon BGPMon

Logs Logs

Client

ClientClient

XML

BGP No RIB-IN stored here!

Can instead focus resources on client requests


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?


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>


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!


XML Storage Costs

Format Raw (Bytes)

/MRT size Compressed

/MRT size

XML 15,606,616

7.7 243,405 1.46

bgpdump 5,742,039 2.8 243,107 1.46

MRT 2,024,614 1.0 167,050 1.00


Status• Versions running since December

−monitor several routers

−serviced 20 simulanteous clients

• Got Peers?−Interested in testing with additional feeds

−Contact Dan Massey ([email protected])

• Software release for late summer−Want to complete more testing with larger feeds

−http://netsec.colostate.edu

• XML Log Format Specification in Progress


Questions?


Key Features• real-time feed for clients

• scalability (peers and clients)

• XML


Clients

bgpmon architecture

Monitor RIB XML Clients

MessageLog

TableDump

Rib In Tables


multi-bgpmon architecture

bgpmon

bgpmon

bgpmon

bgpmon

bgpmon

bgpmon bgp monitoring system dave matthews yan chen he yan dan massey colorado state university

Documents