Minimum peer threshold support

Posted by Andree Toonk - November 17, 2008 - - 2 Comments
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.


  • Frank says:

    Thanks for adding this! This feature could be improved in several ways:
    a) an assessment of the scope could be by the number or percentage of worldwide netblocks represented by the AS that’s advertising the “hijacked” space. If it’s just 1% of all space, perhaps it’s not that relevant to the BGPMon subscriber’s customer base.
    b) the first point could be refined or tweaked by counting the number of ASNs or netblocks that are hijacked per RIR. If it’s hijacked by one in AfriNIC it’s not as critical, but it’s hijacked in ARIN space that’s more relevant to me.

  • […] 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, implemented peer thresholds. […]

Leave a Reply

Your email address will not be published. Required fields are marked *