New summer release of BGPmon.net
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.