I’ve been using this feature for a few weeks now and found it very useful.
The things it will report on is differences in announced prefixes, including a breakdown of which prefixes are reachable via which upstream / peer AS. This will help you detect if a prefix is no longer reachable via one or all peers or upstreams.
The routing report will also report on upstream and downstream ASns. At the end of this blog post you’ll find an example report. Please note that each report also contains a summary report of your AS, comparable to the cidr report.

This routing report feature can be enabled/disabled on a per AS basis in the ‘my ASn’ page.
Update January 12, 2010
The routing report feature is disabled by default. If you would like to use this feature you will need to enable it.

New Prefix alert (code60)
If you recently started to announce a new prefix, then you most likely received a BGPmon email with a New Prefix (code60) alert. These notifications are send out as soon as your AS starts to originate a new prefix.
This feature could only be enabled / disabled globally via the settings menu. If you’re using BGPmon.net for multiple ASns chances are that for some ASns you would like to have this feature enabled and for some disabled. As of this week this is possible and you should now be able to configure this on a per ASn basis.

Adding your AS to My ASn
All the ASns your are currently monitoring should have been added to ‘My ASn’ automatically. If you add a new prefix and ASn to my prefixes, remember to also add your AS to ‘My ASn’. Otherwise the ‘routing report’ and ‘New Prefix alert’ will not work, as your ASn needs to be added manually.

As always if you have any questions please leave a comment on this blog or send me an email.

From: BGPmon Alert < info@bgpmon.net >
To: you@gmail.com
Subject: BGPmon Routing report
Date: Sun, 10 Jan 2010 02:53:27 +0100 (CET)

Your routing table report for AS271 (BCNET-AS - BCnet)

================================== Changes: ====================================
RIB file used:
RRC01 -- LINX, London
RRC03 -- AMS-IX / NL-IX / GN-IX, Amsterdam
RRC11 -- NYIIX, New York
RRC12 -- DE-CIX, Frankfurt
RRC13 -- MSK-IX, Moscow
RRC15 -- PTTMetro, Sao Paulo

------ AS Adjacency report ------
New Downstream / Customer AS:
	+ AS25689 (NRCNET-AS - National Research Council of Canada)

------ Prefixes report ------
Lost prefixes for AS271
 - 207.23.245.0/24  	(Sky Research Inc.)
 - 209.87.17.0/24  	(UBC Commercial Client)

------ Prefixes reachable via peers report ------
 + 134.87.113.0/24 via AS6939	(BCNET IPv6 awareness day) now reachable via HURRICANE - Hurricane Electric, Inc.
 + 2607:f8f0:690::/48 via AS6939	(No valid route object!) now reachable via HURRICANE - Hurricane Electric, Inc.

 - 209.87.17.0/24 via AS6509	(UBC Commercial Client) no longer reachable via CANARIE-NTN - Canarie Inc
 - 207.23.245.0/24 via AS6509	(Sky Research Inc.) no longer reachable via CANARIE-NTN - Canarie Inc
 - 209.87.17.0/24 via AS6939	(UBC Commercial Client) no longer reachable via HURRICANE - Hurricane Electric, Inc.
 - 207.23.245.0/24 via AS6939	(Sky Research Inc.) no longer reachable via HURRICANE - Hurricane Electric, Inc.

================ AS271 Summary report 01/09/10 23:59:58: ====================

Upstream Adjacent AS list:
	*AS852  	 ASN852 - Telus Advanced Communications)
	*AS6327  	 SHAW - Shaw Communications Inc.)
	*AS6509  	 CANARIE-NTN - Canarie Inc)
	*AS6939  	 HURRICANE - Hurricane Electric, Inc.)
	*AS13768  	 PEER1 - Peer 1 Network Inc.) 

Downstream Adjacent AS list:
	*AS3633  	 BC-SYSTEMS - Province of British Columbia)
	*AS11105  	 SFU-AS - Simon Fraser University)
	*AS16462  	 UVIC-AS - University of Victoria)
	*AS25689  	 NRCNET-AS - National Research Council of Canada)
	*AS25722  	 GATEWAY-OPERATIONS - Payment Processing Inc.)
	*AS32956  	 ZED-RADIO3 - Canadian Broadcasting Corporation)
	*AS36000  	 NHA-ASN1 - Northern Health Authority)
	*AS36391  	 TRIUMF - TRIUMF (Tri-University Meson Facility))
	*AS25689         NRCNET-AS - National Research Council of Canada

Announced IPv6 prefixes:
	*2607:f8f0:670::/48  	 (No valid route object!)
	*2607:f8f0:680::/48  	 (No valid route object!)
	*2607:f8f0:690::/48  	 (No valid route object!)
	*2607:f8f0::/32  	 (No valid route object!) 

Announced IPv4 prefixes:
	*128.189.0.0/16  	 (BCNet Class B network)
	*128.189.0.0/17  	 (BCNet  network)
	*128.189.128.0/18  	 (UBC RESnet network)
	*128.189.192.0/18  	 (UBC wireless network)
	*128.189.4.0/24  	 (No valid route object!)
	*128.189.64.0/19  	 (No valid route object!)
	*128.189.96.0/19  	 (No valid route object!)
	*134.87.0.0/16  	 (BCNET-2)
	*134.87.112.0/24  	 (BCnet gigapop servers - News,DNS)
	*134.87.113.0/24  	 (BCNET IPv6 awareness day)
	*134.87.114.0/23  	 (BCNET conference 2009 (DUAL stack))
	*134.87.2.0/24  	 (BCnet gigapop C3 interconnect links)
	*134.87.3.0/24  	 (UBC_TRU DR  project)
	*134.87.4.0/24  	 (BC Genome Sequence Centre)
	*134.87.58.0/24  	 (BCnet gigapop C3 interconnect links)
	*137.82.0.0/16  	 (UBC)
	*142.103.0.0/16  	 (University of British Columbia (UBC1))
	*142.207.0.0/16  	 (NET-UNBC)
	*142.231.0.0/16  	 (BCNET3)
	*142.231.1.0/24  	 (BCnet gigapop C3 interconnect links)
	*142.231.110.0/24  	 (BCNET VANTX interconnects)
	*142.231.112.0/24  	 (BCnet gigapop servers - News,IRR)
	*142.231.113.0/24  	 (BCnet gigapop servers - RealServer, Video Server)
	*142.231.142.0/24  	 (BCnet gigapop connections)
	*142.231.2.0/24  	 (No valid route object!)
	*142.231.20.0/24  	 (UBC MedSchool AV Network)
	*142.231.3.0/24  	 (BCIT Internet Engineering Lab)
	*142.231.4.0/24  	 (UBC MedSchool AV Network)
	*142.231.5.0/24  	 (UBC MedSchool AV Network)
	*142.231.64.0/19  	 (University of British Columbia (UBC) Okanagan)
	*142.232.0.0/16  	 (BCITNET2)
	*142.90.0.0/16  	 (TRIUMF)
	*192.139.193.0/24  	 (DPIC)
	*192.146.156.0/24  	 (Thompson Rivers University)
	*192.219.32.0/19  	 (Open Learning Agency)
	*192.68.67.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-67-0-2))
	*192.68.68.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-68-0-1))
	*192.68.69.0/24  	 (British Coulmbia Institute of Technology (NET-192-68-69-0-1))
	*192.68.72.0/24  	 (British Columbia Institute of Technology (BCIT))
	*192.68.73.0/24  	 (BCIT Internet Engineering Lab)
	*192.73.5.0/24  	 (University of British Columbia (CDNnet))
	*198.162.20.0/22  	 (BCNET-AGG-13)
	*198.162.32.0/19  	 (University of British Columbia (UBC-CS))
	*198.162.67.0/24  	 (Forintek)
	*199.175.163.0/24  	 (SPINNAKER)
	*199.60.119.0/24  	 (Emily Carr Institute of Art and Design)
	*199.60.120.0/24  	 (Emily Carr Institute of Art and Design)
	*199.60.226.0/23  	 (Emily Carr Institute of Art and Design)
	*204.239.83.0/24  	 (NETBLK-UNBC-DMZ)
	*206.12.0.0/16  	 (NETBLK-BR-COL-6)
	*206.12.0.0/24  	 (BCNET ORAN interconnect links)
	*206.12.10.0/24  	 (Great Northen Way Digital Arts)
	*206.12.104.0/22  	 (University of British Columbia (UBC) Vancouver BCWARN BC Amateur Radio Network)
	*206.12.11.0/24  	 (E-Learning Conference)
	*206.12.12.0/24  	 (UBC Commercial Clients)
	*206.12.14.0/24  	 (CANFOR)
	*206.12.18.0/24  	 (UBC Commercial Clients)
	*206.12.19.0/24  	 (UBC Commercial Clients Debian Project)
	*206.12.2.0/24  	 (No valid route object!)
	*206.12.24.0/22  	 (WestGrid project)
	*206.12.24.0/24  	 (WestGrid)
	*206.12.28.0/24  	 (UBC Commercial)
	*206.12.52.0/22  	 (UBC eduroam wireless)
	*206.12.8.0/24  	 (WestGrid project inter-router links)
	*206.123.160.0/19        (Thompson Rivers University)
	*206.87.0.0/16  	 (BCNET (Non-portable address space))
	*206.87.0.0/18  	 (University of British Columbia (UBC) Okanagan)
	*206.87.128.0/19  	 (University of British Columbia (UBC) Vancouver wireless)
	*206.87.96.0/19  	 (University of British Columbia (UBC) Vancouver wireless)
	*207.23.0.0/16  	 (BR-COL-8)
	*207.23.128.0/19  	 (BC Childrens and Womens Hospital)
	*207.23.240.0/24  	 (BCnet gigapop interconnects (BCNET-4))
	*207.23.241.0/24  	 (BCNET VICTX interconnects)
	*207.23.242.0/24  	 (BCNET PGTX interconnects)
	*207.23.243.0/24  	 (BC Research - UBC Commercial Client)
	*207.23.249.0/24  	 (UBC Commercial Client)
	*207.23.252.0/24  	 (UBC Commercial Client)
	*207.23.254.0/24  	 (BCNET KELTX interconnects)
	*207.23.255.0/24  	 (BCNET KAMTX interconnects)
	*207.23.78.0/24  	 (UBC Research Enterprises Inc.)
	*207.23.8.0/21  	 (University College of the Cariboo)
	*207.23.94.0/24  	 (BCnet gigapop C3 interconnect links)
	*207.23.95.0/24  	 (BCnet gigapop C3 interconnect links)
	*207.23.96.0/20  	 (Royal Roads University (RRU))
	*209.87.0.0/18  	 (BCNET-5)
	*209.87.18.0/24  	 (Prince George Public Library)
	*65.39.232.0/22  	 (Farleigh Dickinson University Vancouver campus) 

 * The upstream / downstream categorisation in this report is strictly a description relative topology,
 and should not be confused with provider / customer / peer inter-AS relationships.

Web Services
The BGPmon.net API  provide a number of Web services  for developers. It allows you to query our database and let’s you integrate this in your own software.
As we are using SOAP  as the web services protocol. All the web services are described in a WSDL file, which can be found here.
Currently the following functions are available:

1. getIPInfo()
2. GetAlerts()
3. GetAlertDetails()
4. GetASname()
5. GetASPrefixes()
6. GetCountry()

More information about these function can be found here

Integrating BGPmon.net with your software
SOAP is a programming language independent protocol and is supported by all popular languages.  It allows you to access the BGPmon API over HTTP.
Some of the functions are specific for your BGPmon.net account and thus allow you to authenticate, others are currently publicly accessible.

Let’s get started with two examples
On the BGPmon.net API page you will find two examples of SOAP clients that use the the BGPmon.net SOAP API, a perl and a php example.
The examples are for BGPmon.net users to use, as well as to learn from in case you want to write your own application using our API.

Perl Nagios plugin example
The nagios plugin is written in perl and allows you to monitor your prefixes in Nagios by utilizing the BGPmon.net API.
The script expects a number of arguments, these allow you to filter on the type of alerts that will be returned.
The source code for this plugin example can be found here.

PHP RSS feed example
This is an example of utilizing the BGPmon.net SOAP API in PHP. The PHP RSS example retrieves all the alarms and represents the results in a RSS feed.
You will need to edit the PHP script and change the email and password variable to your own BGPmon email and password.
You can then call the php script using your browser or any other RSS reader. Optionally you can change the days, maxalert and active aruguments,
An example using the demo account can be found here:
http://www.bgpmon.net/rssclient.php?days=100&active=0&maxcode=100
The source code can be found here

Developing your own programs
Should you decide that you want to write your own program and you have any questions please leave a comment on this blog.
Also if you have created your own program and are willing to share this, please sent it to me so I can add it the the examples page.

Keep in mind that the Web Services API is a new feature, if you find any bugs please let me know and I will try to solve them asap.
Happy programming!

Now the time has come to release some more new features. Some of these features have been ready for quite a while but I wanted to wait for the new hardware to be installed first. You can expect announcement for these exciting new features soon.

As you can see the the original hardware was very low-end, it was actually bought before BGPmon.net was born. It was never really intended for this purpose. However, with the new hardware I’m confident I can support the ever growing BGPmon.net user base and growing feature set.

Just a final reminder, this project is 100% funded by me. If you would like to support this project and help recover some of the costs, please consider making a donation here.

Improved overview of alerts gui

If you go to the ‘My Alerts’ overview in the BGPmon.net portal, you’ll notice that it looks somewhat different. These differences are mainly to improve the user friendliness and are based on feedback received from many of you the last view months. One of the features many of you asked for is the ability to select many alerts and delete those. The layout of this page has been changed a bit as well, it will now give you a bit more filtering options. Please try the mouse overs where ever you see the (i) information sign, you’ll see that many fields contain extra information. The new gui uses uses a different database table. ‘All’ recent alerts (maximal 1300) alerts have been migrated to this new table. All the alerts in the old database table are also still available using the old interface here.

Map the geographical  impact of an alert
When clicking on an alert you will see more details for this alert. You’ll see a list of all the peers that saw this alert including some of the BGP attributes. In addition it will render a short summary of unique number of peers that saw this alert including the unique number of countries in which those peers reside. These results are also rendered on a world map. This will give you a quick overview of the geographical impact of this alert.

False positive handling
There’s an updated version of the false positive handling interface. Now when marking an alert as a false positive it will allow you to delete all historic alerts related to the false positive. This will help you keep your alert list nice and clean.

Prefix description
If you received a BGPmon email alert in the last few days you might have noticed that there’s a an extra line called description for each alert. This is a description for the prefix you’re monitoring and will help you identify what the prefix is being used for. The prefix description is also shown in the my alerts page. By default BGPmon will use the description of a matching route object. You can change the description in the my prefixes page.

Must match feature
This feature is specifically build for users who would like to monitor small pieces of a large aggregate. The ‘must match’ value can be a prefix or ip address. Now before an alarm is raised an additional check is performed to verify of the announced prefix contains the ‘must match’ value. If this is not the case no alarm is raised. Let’s look at an example of when and how you would use this. For example I have some servers at my hosting provider in the by them to me allocated address space 10.10.0.0/24. This prefix is not visible in the global routing table. In stead my hosting provider, AS10, announces the prefix is 10.0.0.0/8. So I added AS10 & 10.0.0.0/8 to BGPmon and soon I found out that I receive a number of alerts for example 10.200.200.0/24 was announced by AS666, this raised an alert. As this is probably for a different customer and not relevant for me I am not really interested in this. I am however interested in alerts for 10.0.0.0/8 or any more specifics that match my assigned prefix. In this case I add 10.10.0.0/24 as the ‘must match’ value. Now I will only receive alerts that are relevant for me.

Improved cleared alarm detection
Each announcement (or withdrawal) can either raise or clear an alert. All valid announcements or a new invalid announcement can clear any active alert. As the popularity of BGPmon increased and as a result the number of users and open alerts, the clearing algorithm proofed to be inefficient and required a lot of the computing resources. The clearing functionality in this new version has been rewritten and is many times faster and no longer a burden for the systems resources.

Deprecated alarm codes
I decided to deprecate both code 12 and code 23 alarm codes, as I believe that these are confusing and are all ready covered by different alarm codes. The following alerts codes have been deprecated: Code 12, meant a more specific AND different upstream AS. These events will still be detected however from now on just as a code 22, more specific. Code 23 meant withdraw of more specific. This alarm generated quite some alarms. Now that the alarm clearing algorithm is improved there’s no use to generate a separate alert for this. Withdraws for more specifics are still recorded as they are used to mark the previously announced more specific as cleared.

Additional email address
After a number of requests this feature is now available.  The additional email address will be cc’d  on all your notification emails.  This allows you to share these alarms with your colleague or noc.

Pager / SMS notification
This feature is also based on input I received from a number of users who would like to have BGPmon.net notifications sent to their pager or cell phone.  Some of you have email to SMS gateways that takes an email as input and use the content of that email to sent a text message to your pager or cell phone. By adding a pager/sms email address a short messages of maximal 160 characters will be sent to this email address.  This allows you to receive alerts on you pager or cell phone as well.

Conservative notification
For those of you who monitor many prefixes and have dynamic networks (i.e. many new prefixes, upstreams) will receive quite a number of alerts. BGPmon.net used to send out notifications for each suspicious update it detected. If you your filters were not accurate this could result in several hundreds of emails a week or day.
In cases like this less is more. A new feature called ‘conservative mode’ will suppress recurring alarms and only notify you 3 times a day for each unique event.  This is only for recurring alarms and not for new alerts or new prefix & origin combinations.
For example, if you have a new upstream and you did not add this to your upstream list, BGPmon.net will sent out notifications for that each time it sees an update for your prefix containing this upstream. After it sent out 3 notifications for this prefix/upstream event it will ignore this for 24 hours.
Another example: ASx has hijacked your prefix. They are announcing a more specific for one of your prefixes. Conservative notifications do not apply for this kind of alert, as it’s not a recurring alert. In fact it’s a complete new prefix / Origin AS combination.

The conservative notification feature will make BGPmon.net less ‘chatty’. Conservative ignore is enabled by default, you can disable it by setting your notification mode to active. In this case it will notify you for each event over and over. It’s not recommended to run in active mode and in normal circumstances you should not need to do this.

I want to stress that this feature is not needed when you keep your filters up to date. Whenever you see a false alert please click the false positive link in the email so we make sure we don’t sent you notifications for this event again.

New Prefix detection
The last new feature implemented in the latest release is new prefix detection.  When BGPmon.net detects a new prefix for one of your ASns it will sent you a notification (code 60).
This will help you to verify if your new prefix is seen in the global routing table. Or in the case of accidental leaks you’ll be quickly notified.
You will only receive one notification email per prefix & origin AS combination. You can disable this feature in the setting page, in case you do not want BGPmon.net to monitor for new prefixes.

Bug fixes
The new version also contains a few minor bug fixes, regarding IPv6 prefix syntax checking, ignoring more specifics as well as some performance related improvements.

Community feedback
BGPmon.net relies heavily on community feedback. All of the above features are based on input received from BGPmon.net users. If you have a feature request, idea for improvement or found a bug, please let me know.  Together we can continue to improve this project!

In this Blog post I will go over some of the major changes. These changes include the features listed below:

1. Support for multiple Origin ASN’s.
2. Support for multiple upstream ASN’s.
3. Improved BGP Man in the Middle (BGP MITM) attack detection.
4. Ignoring certain prefixes
5. Ignoring certain ASpaths
6. Changed email layout
7. False positive handling

Besides these new features, there are a number of small bug fixes as well as some performance related improvements.  If you have any questions or feedback please sent me an email or leave a comment on this Blog.

Support for multiple Origin ASN’s.

If your prefix is announced by multiple origin ASNs this is the feature you were looking for. It will allow you to specify a list of additional orgin ASns that are allowed to originate this prefix. This feature is for all my anycast friends out there.
In the previous release this was possible by setting your origin AS to 0 (allow all origin AS) and use the regular expression functionality to monitor for allowed orgin ASn. It’s recommended to from now on use the Additional Origin ASN feature.
An auto-detect additional origin ASn feature is available.

Support for multiple Upstream ASN’s.

This feature allows you to specify a list of allowed upstream (transit / peer) ASns, that are allowed as a next hop ASN, i.e upstream ASN.  Previously many users used the regular expression for this. It’s recommended to from now on use the upstream ASN field for this.  An auto-detect upstream ASN feature is available to help you cut and paste all your upstreams.

Support for ignore lists.

This is a feature many of you have asked for since the beginning. A way to ignore certain prefixes or ASpaths. This feature allows you to ignore prefixes as well as specific ASpaths. If you ignore an ASpath you can choose to only do this for a specific prefix or for all your prefixes. The ignore list should help you to receive less irrelevant alarms.

Changed email layout.

Over the last few months I received quite some feedback regarding the notification emails. I hope that the new layout is an improvement. Besides the layout changes there are two other significant changes.
All alarms are now grouped per 5 minutes. This should make your email a bit shorter.  Previously they were grouped per 1 minute, which sometimes meant you would see the same alarms multiple times (one for each minute in that 5 minute interval). This also means that the peer threshold numbers have changed from a per 1 minute threshold to a per 5 minute threshold. So you might want to increase your (withdraw) thresholds.
The second big change: each alarm messages contains a false alert url. By clicking on this url you are able to mark that specific alarm as a false positive.

False positive handling.

In order to help you fine tune your bgpmon.net configuration, there’s now support for marking alarms as false positive. Depending on the kind of alarm it will ask you if you want to add the offending attribute to your configuration or to the ignore list.

Overall this new version includes quite some improvements and new features.  All these features are implemented based on the feedback I received from the community over the last few months.  Please let me know your experiences, so together we can keep improving the system.

Many service providers use an IRR to register their routes and to create BGP filters. These filters define what they will accept from customers or peers.  This is considered a good practice, as it will prevent accidental leaks. However, using an IRR to build your filters is only useful if the registries are complete. You probably have heard people saying that the IRR is incomplete and therefore useless. The question remains, how incomplete is it?

What is an IRR
The Internet route registry allows you to document a number of things about your network in a predefined format called RPSL. Common things to register are, your routing policies, what do you announce to who? And which prefixes are you originating and from which origin AS.

In theory this is a wonderful idea, but as with many things in life ,day-to-day practice is a bit different.  If not everyone registers their routes in an IRR there’s no way of verifying if this is a valid announcement or not. After all it could just be that the origin AS announcing this prefix is not using the IRR the register their routes.

How to use the IRR
Some providers I work with such as Geant and Canarie are very strict in the IRR usage. If you don’t register your route, they will not accept it.  Simple as that!

Since a few months BGPmon.net has support for IRR as well. Examples are the auto detect feature that will automatically detects all the prefixes for your Origin AS and indicates if there’s a valid route object or not. Another example of IRR usage can be found in the hijack detection feature. BGPmon.net will classify each hijack either as a Code10 or Code11 alarm. Depending on whether theirs is a valid route object for this announcement or not. The usefulness of these features is largely depending on the accuracy of the IRR databases.  So I decided to try to quantify the accuracy of the IRR.

How accurate is the IRR
BGPmon retrieves a local copy of “all well known” [1] IRR databases for analyses.  I use this data to determine the accuracy of the IRR data.  For each prefix and origin AS in the global routing table it was checked if a valid route object exist. Meaning, a route object for this prefix and this origin AS.  Let’s take a look at the prefix 142.90.0.0/16. This prefix is announced by AS271. For this IRR check to succeed a route object such as below has to exist

route:        142.90.0.0/16
descr:        Tri-University Meson Facility (TRIUMF)
origin:       AS271
notify:       nmc@BC.net
mnt-by:       BCNET-BC-MNT
changed:      bofh@BC.net 20090102
source:       bcnet

More specifics and aggregates.
During this analysis I checked for both exact matches as well as a possible less specific (aggregate) that covered the prefix.
In my experience, all our upstreams always required all the prefixes we wanted to announce to be explicitly defined as a route object.  More specifics are not accepted unless there’s an exact route object.  I wonder how your upstreams are doing this?

The result

valid route object (exact routes) (Green = high score (good), Red = low score (bad))

As it turns out 46% of all the prefixes in the routing table today have a valid route object. This means that if everybody would use strict IRR filtering, the way it is done by for example Geant and Canarie,  54% of the prefixes on the Internet would be unreachable, that’s 153685 prefixes. If we allow more specific as well, 62 % of all prefixes have a valid route object.

I also distinguished the result on a per country basis, the result can be found below. And in the images. The images represent how many route objects were found for each prefix on a per country basis. Green means good, yellow medium and red means bad.
In this map it’s clearly visible that some countries score better than others. However, it might be that this analysis did not take into account an IRR server [1]  used in that region or country.

valid route object (including aggregates) (Green = high score (good), Red = low score (bad))

Raw data results:
For those interested in a more detailed result, please see these files.

• Per country result (exact matches)
• Per country result (exact or aggregate matches)

Curious how accurate the IRR information for your prefixes are? Just search for your AS in the text files below.

• Prefixes that did not have an exact route object
• Prefixes that not have an exact route object or an aggregate with a correct route object.

What does all this mean?
It means what many already knew, the IRR is incomplete.  In this blog post I tried to quantify this and presented you some numbers, these might be as expected or shocking. The fact however is, that if we ever want to do proper filtering based on route-objects or preferably ROA’s, we have a whole lot of catching up to do.

For those interested in this subject, Renesys did a similar analysis here.

Disclaimer & data sources
The check only examined route-objects. Route objects from the IRR registries below were examined.
RIPE RIS was used as a data source for the rib files. Only IPv4 prefixes were included.
MaxMind geo IP library was used to determine country information.

[1] Used IRR registries:
ripe, altdb, aoltw, apnic, arin, bcnet, bell, deru, digitalrealm,easynet, ebit, epoch, gt, gts,
gw, host, jpirr, level3, mto, nestegg, nttcom, openface, ottix, panix, radb, reach, retina,
rgnet, risq, rogers, savvis, wvfiber

nanog

What happened?

AS47868 (SuproNet) apparently was experimenting with traffic engineering, by using AS path prepending. AS path prepending is a frequently used method to make a certain announcement a bit less preferable by making the AS path longer. It can help network administrators influencing on which peering traffic for certain prefix is preferred. This is done by prepending your own AS one, two or maybe a few times. I guess it’s fair to say that prepends up to let’s say 5 are fairly common, you will see them longer as well but in normal scenario’s that shouldn’t be necessary.

Impact

AS47868 was prepending it’s AS path many times, up to 252 times resulting in a AS path of 256. Although this is an insanely high number, considering that the average AS path length is about 4.3, It should definitely not cause the behavior we observed Monday.
A number of routers that apparently run older software, were not capable to handle these long AS paths and as a result a fair number of BGP sessions started to flap, which caused a wave of updates (many times higher then normal) causing instability. A Good technical explanations can be found at renesys and arbor security.

So what?

The key thing here is that a single AS, announcing a single odd announcement was able to influence many BGP routers, resulting in  world wide instability.
So who do we ‘blame’? Well, I would not blame AS47868 in this case, the real cause are the ASn’s with buggy BGP implementations. A single odd announcement should never be able to impact so many others.

Monitoring for Long AS paths

I added some extra functionality to the BGPmon software. It now collects the longest AS paths seen each day. It will also display the AS path and additional information. Check it out here: http://bgpmon.net/maxASpath.php.

Related incidents

Interestingly we did see a similar issue a few weeks ago as well. BGP sessions started flapping because of invalid data (AS_CONFED_SEQUENCE and AS_CONFED_SET) in the AS4_PATH field. This is actually a feature not a bug, or if you will a bug in the RFC.
The RFC described that a BGP speaker should teardown the session if it sees such an update. This was done to isolate the problem as much as possible and only direct neighbors would be affected. As it turns out in some cases the direct neighbor does not detect this and propagates the update and as a result routers further in the core will start flapping.

The problem here is comparable, a single announcement is able to teardown BGP sessions all over the Internet, so not just its direct neighbors.  This results in lots of BGP updates and global BGP instability.
The above I guess, could be described a BGP denial of service attack.

However it important to realize that in one case the flaw was actually in the RFC and this is being fixed. In the case we saw this week it is  a software bug. As with many of the BGP related events we have seen lately, most are non intentionally. Never the less the impact can be huge.

Same kind of incident last week

Last week one of our upstream providers in Vancouver experienced a similar problem, causing some routing instability for them and all their customers.
According to the Post Mortem we received, one of their peers sent them BGP updates with Malformed AS paths, this is the exact same behavior many people experienced on Monday.
Looking back in some of the BGP data that I collect for BGPmon.net, I notice that at the exact moment that my upstream started to experience these problems an AS path with a length of 257 was detected. In that case AS45307 had prepended it’s AS 251 times.

What’s next?

From a security perspective it’s a real nightmare that things like this can have such a widespread impact. The scary part is, that it’s not hard to imagine the harm someone can do to the stability of the Internet if attacks like these are targeted or by maybe combining one or two of these attacks.
Contrary to what some belief, the issues described in this article will not be solved by secure routing proposals such as SBGP, SoBGP or rpki, it will however be solved by good BGP implementations!

There was a very interesting presentation about a comparison of different BGP hijack detection techniques,   Comparative Analysis of BGP Anomaly Detection and Robustness Algorithms. After hearing that I think BGPmon.net is fairly unique in the way it detects and classifies hijacks by using a combination of user defined information, historical BGP data as well as IRR data.

During the Hijacking and Tools BOF I presented about BGPmon.net. I was very happy with the feedback I received during the presentation as well as the days after.
I talked with many people about this tool and learned about your experiences. I’m now filled with inspiration and ideas again. For those interested, the presentation, I made a screencast of the presentation, check it out here: http://bgpmon.net/screencast.php