This week it was announced that IANA has allocated 1.0.0.0/8 to APNIC. This prefix must look familiar to many as we see it often in examples and documentation. And let’s be honest haven’t you used 1.1.1.1 on one of your test routers to quickly test something?
Receiving a prefix from this range might result in some issues in regards to duplicate announcements and duplicate address usages.

Duplicate announcements
If multiple networks announce the same prefix it might result in traffic being routed to the wrong network. This problem becomes even worse if someone else starts to announce a more specific of this network. Normally these ‘hijacks’ are not all that common, but with prefixes from this range it might be a bigger issue due to the nature of this prefix.
To try to quantify this I decided to take a look in the BGPmon.net database in which we have a complete collection of bogon announcements since May 2009. Any announcement in the 1.0.0.0/8 range in the last 9 months is recorded in this database.

In this 9 month period we detected 364 unique announcements for in prefix in the 1.0.0.0/8 range. If we group those announcements by origin AS and announced prefix we see 23 unique announcements.

+----------------+----------+-----------------------------------------------------------------------------+
| prefix         | OriginAS | AS_name                                                                     |
+----------------+----------+-----------------------------------------------------------------------------+
| 1.0.0.0/9      | AS24785  | JOINTTRANSIT-AS Open Peering BV trading as Joint Transit                    |
| 1.1.0.0/16     | AS47377  | KPNBE T2 Belgium NV                                                         |
| 1.1.0.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   |
| 1.1.1.0/24     | AS8300   | Test-AS --  Swisscom Ltd                                                    |
| 1.1.1.0/24     | AS30733  | GLOBUS-AS GLOBUS-TELECOM Autonomous System                                  |
| 1.1.1.0/24     | AS6503   | Axtel, S.A.B. de C. V.                                                      |
| 1.1.1.0/24     | AS34695  | E4A-AS E4A Primary AS                                                       |
| 1.1.1.0/24     | AS8218   | NEO-ASN AS Confederation of Neotelecoms, euNetworks AG and Upstreamnet gmbh |
| 1.1.1.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   |
| 1.1.1.0/24     | AS45899  | VNPT-AS-VN VNPT Corp                                                        |
| 1.1.1.0/24     | AS16735  | Companhia de Telecomunicacoes do Brasil Central                             |
| 1.1.1.0/30     | AS38091  | HELLONET-AS-KR CJ-CABLENET                                                  |
| 1.1.1.0/31     | AS8359   | COMSTAR COMSTAR-Direct global network                                       |
| 1.1.1.1/32     | AS45400  | NICNET Korea Telecom-PUBNET                                                 |
| 1.1.1.10/31    | AS8359   | COMSTAR COMSTAR-Direct global network                                       |
| 1.1.2.0/30     | AS3313   | INET-AS I.NET S.p.A.                                                        |
| 1.1.88.0/24    | AS4645   | ASN-HKNET-AP HKNet Co. Ltd                                                  |
| 1.1.88.0/24    | AS39386  | STC-IGW-AS Saudi Telecom Company                                            |
| 1.120.0.0/13   | AS23148  | TERREMARK Terremark                                                         |
| 1.2.3.0/24     | AS19151  | WVFIBER-1 - WV FIBER                                                        |
| 1.20.23.178/32 | AS26592  | Dominio BR Consultoria em Informatica Ltda                                  |
| 1.40.0.0/13    | AS23148  | TERREMARK Terremark                                                         |
| 1.80.0.0/13    | AS23148  | TERREMARK Terremark                                                         |
+----------------+----------+-----------------------------------------------------------------------------+

A complete list of bogon announcements can be found here:
As you can see the 1.1.1.0/24 prefix is the most popular prefix, so we can only hope APNIC won’t allocate this prefix. Except maybe for a nice honeynet project.

Duplicate address usage
Duplicate announcements are not the only thing networks in the 1.0.0.0/8 prefix have to worry about. As it turns out a number of organizations have used this prefix as an alternative for the RFC1918 prefixes. With the reasoning that many people already use 192.168.0.0, 10.0.0.0 or 172.16.0.0 , so chances of collisions are reasonable. So these bright minds came up with the idea of using a unallocated prefix as an alternative, such as for example 1.0.0.0/8

AnoNet
AnoNet is a private friend-to-friend network built using VPNs and software BGP routers. anoNet works by making it difficult to learn the identities of others on the network allowing them to anonymously host content and IPv4 services. Also see http://en.wikipedia.org/wiki/AnoNet
The prefix they use for this network is 1.0.0.0/8.
Apparently AnoNet is planning to do the same for their IPv6 initiative, as according to their website:
“Services are gradually being migrated to dual-stack. It is all in the de00::/8 range”
de00::/8 is a unallocated range, just as 1.0.0.0/8 used to be….

WIANA
Wiana is The Wireless Internet Assigned Numbers Authority, provides IP addresses for wireless devices from the 1.0.0.0/8 prefix.
Ironical WIANA claims to have been formed to meet the that need network policies are upheld.
According to their FAQ the reason for this prefix is that several protocols used already utilize the 10.x.x.x network for unregistered addresses during handshaking. Another class A network was required. Unfortunately for WIANA (and the future legitimate holder of this prefix) soon, the prefix they choose will no longer be unqiue.

Receiving a prefix from the 1/8 range
The role of the RIRS is to make sure prefixes are allocated to one organization only and as a result should be unique. With prefixes from the 1.0.0.0/8 prefixes this can no longer be guaranteed. Not because of multiple allocations by the RIR, but in this case by other organizations that thought it would a smart idea to choose a random unallocated prefix.
In order to prevent issue’s with BGP announcements, looking at the bogon announcements it’s probably a good idea to (at least not yet) allocate prefixes in the 1.1.0.0/16 range as these seem to be leaked the most.

As Alain Durand mentioned on Nanog: “Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing.

Just like many you, I use rancid to track changes in configurations of our routers and switches. This week BGPmon.net released a new feature called ‘routing report’, you can think of this as a Rancid for your BGP routing table. Every day BGPmon compares the announcements by your ASN with those of the day before. Any differences in announcements or reachability will be sent to you in an email.

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.

[Read the rest of this entry...]

Lately I have received quite some questions with regard to connecting BGPmon.net with existing monitoring software. As well as requests for making more data available for developers.
I’m happy to announce that these things should now be possible trough the BGPmon.net Web Services API. This  API  allows you to access your BGPmon.net alert as well as other features from your own program running anywhere on the Internet.
I will use the rest of this Blog to briefly explain how the API works and what it can be used for. More  detailed information regarding the API and how to use this, can be found on the  Web Services API page.

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!

Last week I finally received a new CPU for the BGPmon.net server. This new quad core 2.66GHz CPU replaces a 1.8GHz single core CPU. This upgrades follows the memory upgrade from a few weeks ago when memory was upgraded from 2GB to 8GB.
Over the course of this week I saw significant improvement in execution times and average system load. So with this faster CPU and more memory I’m pretty confident the software should be able to perform as you may expect.

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.

IPv6 slowly seems to become more mainstream, we hear about IPv6 more and more and it seems that at least some Service providers and governments understand that there is a sense of urgency.  Regularly we see the statements of networks that are planning to roll out IPv6 and vendors that are promising to make their products IPv6 ready.

But talk is cheap and the question remains, how far are we actually with rolling out IPv6 deployment?  We tried to answer that question by looking at the Internet Routing tables.

IPv6 deployment ratio.
Each network in the global Internet has a unique Autonomous System (AS) number. An Autonomous System can be an Internet Service Provider (ISP), Enterprise network, content provider or any other sort of network. Each AS number announces one or more prefixes.  By using Geo IP libraries we are able to determine a country for each prefix. This in turn allows us to determine the unique number of networks (AS numbers) per country.   Doing this for both IPv4 as well as IPv6 will result in the IPv4/IPv6 deployment ratio.

Let’s look at for example at Canada. There are 816 Autonomous Systems that originate a prefix registered as in use in Canada.  If we look at the IPv6 routing tables we see that 50 Autonomous Systems announce a Canadian IPv6 prefix.  This results in an IPv6 deployment percentage of 6.1%. Meaning that 6.1% of the networks doing business in Canada are currently actively deploying IPv6.

Results
If we look at the global statistics, i.e. comparing all IPv4 Autonomous Systems with all IPv6 Autonomous Systems we see that the global IPv6/IPv4 deployment ratio is 5.26%. This is slightly higher than the 4.4% we measured in April 2009.

And the winner is
Jersey , a small country between England and France, is the only country scoring a 100% deployment ration.  IPv4 and IPv6 prefixes registered to Jersey are only announced by one provider, AS8681 Jersey Telecom; resulting in a 100% ratio.

Jersey is followed by Cuba (75%), Oman, Monaco, Holy See (Vatican City State) and Fiji all scoring 50%. If we look at the bigger countries, i.e countries with at least a 100 (IPv4) networks we see that Czech Republic (19%), New Zealand(18%), Japan (17%) and The Netherlands (17%) are leading.

Are we on the right track?
Ideally the IPv6 deployment percentage should be around ~100%. Globally today we score a 5% ratio. Although this is one percent higher than half a year ago it’s still very low. Never the less, it’s positive to see that some individual countries such as Tunisia and Uruguay score surprisingly high. And also Europe and parts of Asia seem to be on the right track.

Top 10%
Below an overview of all countries scoring higher than 10%.  A complete list with the results for for all countries can be found here: IPv6 deployment statistics October 2009

Friday morning around 07:22:08 UTC AS9035 (Wind Telecomunicazioni) started to announce approximately 85.000 prefixes with an invalid origin AS. The origin AS was set to AS9035 while these prefixes did not belong to AS9035. The impact was local to a number of Italian providers, all Telecom Italia customers. The incident was resolved in about ~2 minutes after the first announcement.

Many of you have received alert messages for this event, informing you of the ‘possible hijack’.  I would like to take a bit of time explaining how to interpreted these message so it’s easy to determine the impact of such an event.
The first thing to look for is the number of peers that detected this prefix. In this case the event was detected by 2 peers, this gives you an indication that this event did not have a significant widespread impact.
The next thing to do is to login to BGPmon and check the details of this alert, a direct link to this the detailed info page is now included in the email messages.
Here you’ll quickly see again the number of peers that detected this as well as the geographic location of these peers. In this case both peers were located in Italy, indicating that it’s a fairly local event.  The global impact is also visible on the world map, making it easy to determine the geographical impact.

The same detailed info page also shows the BGP messages that are relevant for this alert. This will give you some more detailed information about the exact BGP announcements. In case the alarm is cleared you will see the exact time this happened. An alarm is cleared when the peer that detected this alert saw  a new valid update for this prefix or a withdrawal. It will also display the exact duration of the event per peer.

BGPmon notification time
BGPmon alert messages are normally sent out a few minutes (<5min average) after we received the updates from the RIPE RIS collectors.
Yesterday, some of you, received the alert messages later then usual.  I apologize for this and am currently working on a solution for this in order to prevent the delay in notification in cases of ‘mass hijacks/leaks’ like we saw yesterday.  A significant part of the solution is  to upgrade some of the hardware components of the  BGPmon.net server.   If you or your company would like to support this project, please consider making a donation. For more information please see this page.

Ok, ok… It happens all the time, people leaking private ASN’s. But this one caught my attention. It seems that the US Department of defense (DoD) is leaking a private ASN  65401 for their prefixes 140.21.18.0/23 and 140.21.15.0/24. These prefixes are normally announced by AS5802 but now appear to be originating from the private AS 65401.

The reason that this caught my attention is that although leaks like this happen all the time in general they appear to happen by the less clueful. The DoD I think should not be considered in this category.  However this ‘leak’  has been happening for a few weeks (starting 2009-08-27).  This leads me to believe that the DoD does not monitor their own announcements…. Maybe they should open a BGPmon.net account?

I’m happy to announce that this week a I released the new version of BGPmon.net into production. There are several new features that many of you have asked for. In addition there are some significant changes in the database backend. This is largely to improve the performance of the webinterface and some soon to be announced exciting new features. In this blog post I will describe some of the features that are new in this release. A small screencast describing these new features is also available 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.

The last few weeks I have been working on implementing some more notification options. A number of users have asked for sending out notification email to more than just one email address, as well as being able to send notifications to pagers.
The latest release of BGPmon.net supports these features.  You can find the configuration for these new options in your setting page. In this post I will highlight a few of the new  features.

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!

This morning there was a discussion about a possible prefix hijack by AS13214 on the Nanog list. Cyclops users received a notification email notifying them that AS13214 was announcing their prefix.  I just went trough some of the raw data and this is what I found.
It seems it was picked up by the route-views4 collector only. Non of the RIS peers seem to have seen this.  This is also the reason why BGPmon.net users did not get notified, as BGPmon.net uses the RIS resources for BGP updates.

Looking at the raw BGP data from routeviews4 it seems that:
AS13214 leaked a full table (~266294 prefixes) with 13214  as OriginAS to AS48285 which is a routeviews4 peer. Routeviews4 saw these announcements as:
ASpath 48285 13214.

It seems to  have happened twice:
~ 11:03:45 GMT to 12:16:31 GMT (here AS48285 start announcing a valid path to routeviews again).
then a few seconds later again:
~ 12:16:36 GMT to 12:18:14 GMT
After that AS48285 announced ‘normal’ ASpath to routeviews again.

So looks like it wasn’t a global hijack, it was only seen by one routeview peer.  This is a very similar event as the one we saw in November 2008:  Prefix hijack by AS16735 or (Brazil Leak: If a tree falls in the rainforest).

This again shows that it’s hard to determine if an event is a ‘real’ hijack or not. Some will say it’s irrelevant some want to be notified in all cases. Based on received feedback regarding the November 11 event, BGPmon.net implemented peer thresholds.

Did you ever wonder what the current status of IPv6 deployment is and which country is taking the lead?  A number of sites provide information about IPv6 deployment; each one uses a different way of measuring the usage. From traffics measurements, to the reach ability of popular websites over IPv6, to the growth of the IPv6 routing table such as for example the bgp weathermap. I recently did a different analysis, by comparing the number of ASN’s per country that are announcing IPv6 prefixes as compared to IPv4 prefixes. This will show us how many ASns per country are deploying IPv6.

Methodology
Using Geo IP libraries we are able to determine a country for each prefix. For each country it was determined how many unique Autonomous Systems (ASns) are announcing an IPv4 prefix. The same was done for IPv6 prefixes. Based on these two numbers we came up with a percentage indicating the how many organizations (ASns) have started to deploy IPv6.
Let’s for example take a look at the global statistics, there are currently 31.844 unique  ASns  announcing at least 1 IPv4 prefix.  There are 1.393 unique ASns announcing at least one IPv6 prefix. Resulting in a global deployment percentage of 4.4%.
The same analysis can be done on a per country basis, by only looking at prefixes that are registered to a specific country.  Let’s for example take a look at Canada. There are currently 818 autonomous systems announcing at least 1 Canadian prefix. As compared to IPv6, there are currently 36 unique autonomous systems announcing a Canadian IPv6 prefix, resulting in a deployment percentage of 4.4%.

The results
The analysis as explained above was done for all countries. Ideally each AS currently announcing an IPv4 prefix should eventually also announce a IPv6 prefix. So in a few years from now the IPv6 deployment ratio should be around 100%.
Below you’ll find the countries that had a deployment score higher than 10%. Country’s with more then 10 IPv4 ASN’s are indicated in bold. Results for all countries can be found here: http://bgpmon.net/IPv6_deployment_statistics.txt

One of the first things to notice is that there are quite a few of the smaller (in Internet terms that is) countries that have a high score.  For example The Vatican, has one ASn doing business for them (AS8978), that same ASn is also advertising an IPv6 prefix, hence the restults is 100%.   For the larger countries it’s much harder to get a good score.

Mapping the score

Global IPv6 deployment

If we visualize the score on the world map, it becomes clear that some parts of the world have a much better score then others.  Especially Europe and the East Asia seem to score high.  Another interesting observation is that parts of Africa scored particularly high.

And the winner is…
As could be seen in the result overview, the country with the highest score is  the Vatican. If we look at the (from a networking perspective) bigger countries, with at least 10 ASNs, Uruguay in Latin America is the winner. There are currently 26 ASN’s originating an IPv4 prefix that is used in Uruguay. As compared to 9 ASN that have IPv6 prefixes, resulting in a score of 35%. When we look at both the relative number as well as the absolute number we see that countries such as Japan,  New Zealand, Czech Republic, and The Netherlands are the leaders.

One of the ‘losers’ is the leader in the IPv4 world, The Unites States. The US has the highest number of Origin ASns in the IPv4 world as well as in the IPv6 world. However the percentage (316./ 13280) of 2% is well below the global average.

Are we on the right track?
Considering that the ideal score would be around ~100%,  and the global score is 4%, we still have quite some work to do.  Never the less, it’s promising to see that some individual countries such as Egypt and Uruguay score surprisingly high. And also Europe and parts of Asia seem to be on the right track.

Since NANOG45  I was filled with inspiration for new features in BGPmon.net. Many of you have sent me your feedback and whenever possible I implemented the smaller feature request and bug fixes. Today the newest version went live; this version contains some of bigger changes and improvements.

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

[Read the rest of this entry...]

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?

[Read the rest of this entry...]

You might have experienced it or read about it Monday on the nanog and cisco mailing list. Widespread routing instability caused by a single AS, The beauty of distributed routing system.

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.

[Read the rest of this entry...]

last week I came back from the Dominican republic where I visited the Nanog45 conference. It was quite an interesting conference with lots of interesting people.
I enjoyed many of the presentations and I’m happy to see that the subject of BGP security and especially hijacks are receiving more and more attention from the operators community. Some of the BGP security related presentations were about bgp hijacks of cc-tld’s as well as a lightning talk about the RPKI initiative.

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

Tomorrow I’ll be leaving for Nanog45 in Santo Domingo! It’s my first Nanog conference and I’m looking forward to it! I will also be presenting about BGPmon and Prefix Hijacking during the Hijacking and Tools BOF on Sunday. I look forward to meet others from the Nanog community and some of the BGPmon users!  See you next week in the Dominican Republic.

In order to migrate to IPv6 different methods are available, one of them is using IPv6 in IPv4 tunnels. These tunnels come in different flavors, static tunnel or dynamic tunnels. Dynamic tunneling protocols such as 6to4 and teredo use anycast technology. A number of organizations have employed 6to4 or teredo relays and it’s not always easy for an end user to see which relay you are using because they all have the same IP address.

I’ve created a list of Autonomous systems that are announcing the 6to4 (IPv4 192.88.99.0/24 and IPv6 2002::/16) anycast prefix. The same is done for autonomous systems that announce the teredo relay prefix (2001::/32). This list is dynamically generated by analyzing all BGP announcements and scanning for the relevant tunnel prefixes.  The data available on this website contains data that goes back to 2001 (using RIB snapshots) and will be updated continuously.

So if you’re interested in a list of current or historically autonomous systems that operate a 6to4 routers or teredo relays please take a look here:

• 6to4  Operators   (http://www.bgpmon.net/6to4.php?week=4)

• Teredo relay operators    (http://www.bgpmon.net/teredo.php?week=4)

One last tip, the week interval in the url limits the result to active entries. So in case of week=4, you will only see relays that have been seen in the last 4 weeks. For example, If you would like to go back in time and also see the 6to4 or teredo relays in January 2005 you would use a week interval of 210 http://www.bgpmon.net/6to4.php?week=210

A few months ago BGPmon.net became available for all network operators looking for a tool to monitor there BGP announcements and prefixes.

Now 3 month later I’m looking for feedback from you so that I can get a better understanding of how people are using this, what works and what doesn’t.
Particularly I’m interested in:

1) Real life experiences.
I would like to hear some use cases of how BGPmon.net helped you solve or detect a particular issue?
Did you encounter any real hijacks and how did BGPmon.net help you with this? Or maybe you detected a configuration error in your BGP config, causing you to leak unwanted prefixes? Or any other use cases.

2) New features to improve functionality and user friendliness.
Would you like to see some new features, or checks? Or maybe improvements in the web interface? or additional notification mechanisms? Why and how would you use these?

It would be greatly appreciated if you can provide me any feedback or share your experiences. Just leave it on this Blog or send me an email.
Thanks for you support!

I am happy to announce that BGPmon now has full IPv6 support! This means that you can now monitor your IPv6 prefixes just as you are monitoring your IPv4 prefixes. All the codes, alarm messages etc are they same as for IPv4. It took a while because I had to write a few new libraries myself. These new Perl Libraries are used to do IPv6 prefix matching, Ipv6 to location (Geo_IPv6) and IPv6 bogon detection. Some of the functions used in this library have already made it to a BGPmon service in a earlier stage. Examples are the IPv6 weathermap as well as the IPv6 bogon page.

IPv6 is also fully supported in the auto discovery feature for both prefix discovery as well as the regular expression generator.

I hope you, BGPmon users, are happy with this new functionality and will use it. As always if you have any feedback please let me know

Monitoring IPv6 prefix with BGPmon

.

Last week’s incident triggered a small thread about the different prefix hijack detection tools available  on the Nanog mailing list. The incident was also discussed on a number of blogs [1], [2], [3]. In general the reviews for BGPmon were very good! One suggestion for improvement though was support for a threshold before sending out notifications. I was thinking about this for this for a while already and this weekend I decided to implemented this.
It actually wasn’t that much work because this feature was already in use for the “Notify on withdraw” functionality. This will sent out a notification email if at least 3 peers detected a withdraw for your prefix. In this case the threshold of 3 was hard coded in the software. I rewrote some of the backend software as well as the web interface to add user configurable minimum peer threshold for both updates as well as withdraws.

The minimum peer threshold suggestion came  after a  discussion about a way  to determine the significance of a hijack. In last weeks event the hijack was only seen by 2 peers, indicating that it was a rather local incident and not as relevant for everyone. The use of minimum peer threshold allows you to prevent BGPmon to sent out notifications for events that are only seen by a small number of peers. This threshold can be configured on a per prefix basis, which brings us to the question, what is a good threshold number?

It’s very hard to come up with a good suggestion, the only right answer would be, it depends.  Although a threshold would certainly help to  determine the scale or geographical impact of a hijack it doesn’t help determining if it is relevant (has significant impact) for your network or business. This probably depends on a number of variables, not easy to determine by BGPmon, or any other hijack tool.
That is why the default minimum threshold is set to one, and it’s meaning that it’s up to the network administrator to determine the significance of this event. Of course if you would like to change the threshold you now have the flexibility to do so

I used this opportunity also to improve the user friendliness of the  “My Prefixes”  page.  This is mostly based on feedback I received the last few weeks, thanks for that!
If you have any additional feedback, questions or remarks about this new feature, please leave your comment on this Blog or sent me an email.

Many BGPmon.net users received a notification email regarding a possible prefix hijack.   I just went over the data files manually and verified the leak. For those interested, let me share with you what I saw in the raw data. Between 01:55  UTC  and 02:15  267947 distinct prefixes were originated from AS16735 (Companhia de Telecomunicacoes do Brasil Central), hence a full table ‘leak’.  After that more updates were detected. The last hijack update originated by AS16735 was received at 03:07 UTC. So the ‘hijack’ was there for about 75 minutes As far as I can see the only RIS collector who saw this hijack was the one in Sao Paulo, Brazil (PTTMetro-SP), there it was seen by a few RIS peers.

The reason that you received multiple email is that your prefix was detected as hijacked multiple times in 75 minutes. Multiple alarms in a 5 minutes interval are aggregated in one notification email. If the updates are detected after that 5 minutes another notification email is generated, this email possibly can have multiple  updates as well.  BGPmon tries not to sent to many notification by aggregating notifications, but at the same time we try to be sub-real time, i.e. 5 minutes interval. Hope that explains a bit about more about the notification email interval.

Example email as sent out earlier today:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
http://bgpmon.net/showupdates.php

====================
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix 142.231.0.0/16:
Update details: 2008-11-11 01:58 (UTC)
142.231.0.0/16
Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central)
Transit AS: 22548 (Comite Gestor da Internet no Brasil)
ASpath: 22548 16735
====================


BGPmon is gradually being extended with IPv6 support, the newest IPv6 feature is IPv6 bogon detection comparable to the already existing IPv4 bogon detection page. IPv6 bogons are defined as IPv6 prefixes which are not allocated by the RIRs.  All IPv6 bgp updates are compared to a list of known valid prefixes. If the update does not match this known prefixes list it is considered as a IPv6 bogon. The result can be found here:  http://www.bgpmon.net/showbogons.php?inet=6&global

As you will probably see, there’s quite a few strange IPv6 prefixes out there, looking like: a3c7:8800::/21 and a51e::/16 and many more. I’m not sure what this is, it’s not a bug in the BGPmon.net software as the same updates are seen by RIS (see here).  The announcements are very short, typically an announcement for these prefixes is followed by a withdraw just 1 second later. The (same) bogon prefixes are actually being announced by a number of origin AS’s looking a bit further shows that the one common thing is the rest of the AS path. So it could mean that somewhere in the transit path a faulty router is the cause of this. But that’s all guessing and if we go there we shouldn’t eliminate a bug in the RIS software. If anyone has any information about this, please leave a comment on this blog or sent me an email.

How do I monitor the “non existence” of an AS in the ASpath
Sometimes you have a prefix which is being announced from different AS’s and each of these have different upstream AS’s. Some of these are propagated all over the Internet and some of them are supposed to stay in a certain region or IX. This is typically achieved using the NO-EXPORT feature. A BGPmon.net user emailed me this scenario and would like to get a notification if this prefix is being detected by BGPmon, because this could mean someone might be leaking the prefix.

Let’s look at this example. Suppose  the following prefix 192.0.2.0/24 is originated from AS10 from different places in the world. You (AS20) are one of those sites but are only announcing it at your local Internet Exchange with the NO-Export community set.  Now normally this prefix is not seen as aspath AS20 AS10 in the global routing table, except of course for those at the Exchange point. You want to monitor the global routing table for this prefix & ASpath to make sure non of your peers is leaking this. How would you do that? Well you would add your prefix to BGPmon and use source AS 0. This basically is a wild card, no hard checks will be done on the originAS. Leave the transit AS empty and just use the following regex:

	(?<!20) 10$

It’s called a ‘negative lookbehind assertion’ (Thanks Bas Toonk, for helping me with this) and matches any occurrence of ‘10′ that isn’t following ‘20′.
So basically it should match any aspath that ends with 10, except if 20 is in front of it. In that case (20 10) the ASpath regex does not match and will generate an alarm.
This however does assume that the prefix is always originated by AS 10.  In the real life example this was not the case, the prefix was actually originated by different AS’s and the user wanted to be notified if the prefix was seen if his AS would show up as the transit AS. The regular expression this user is now using is something like this:

	(((?<!20) 10$)|( 30$)|( 40$))

Now the ASpath regular expression will match if:

The aspath ends with * 10 (where *  != 20, i.e. anything except 20)
The aspath ends with 30
The aspath ends with 40
In all other cases it will generate an alarm and you’ll be notified.

The majority of the emails I receive with feedback and questions are things which can be solved with a regex. Today I would like to go over 1 common example:

How do I monitor prefixes that originate from multiple origin AS’s
Some people mailed me with a feature request for the ability to specify multiple ASNs that are allowed to originate a specific prefix. The good news is that is already possible, the bad news is that it wasn’t documented. So how do you allow for multiple origin AS’s? Normally you have to add a source AS when adding a new prefix. This than would be the only AS allowed as origin AS for that particular prefix. However if you use originAS 0 (zero) this field will be ignored.  If you than also leave the transit AS field empty and just use the regex field you have achieved what you wanted to.
So the trick is to use originAS 0 (a wildcard) and catch everything else in a regular expression. A typical regex would look like this:

	(^|\s)(10|20|30)$

This regex allows your prefix to be originated from either AS10, AS20 or AS30. In all other cases BGPmon would generate an alarm and notify you.  I also updated the FAQ with this information.

This is just a heads up, I just deployed a new version of the BGP update analyzer (back-end parser). It has some new functionality (mainly IPv6) related and some bug fixes. The bug fixes have are mainly regarding prefixes which are monitored by multiple users.  It will require some more time to make new IPv6 functionality available in the web frontend. This will be done gradually over the coming weeks.
please let me know if you experience problems with the new analyzer.