The BGP Visibility Scanner now for IPv6 prefixes
Dear all, In November 2012 we have released the *BGP Visibility Scanner*, a tool that checks the visibility of IPv4 prefixes at the interdomain level. We are now happy to further make available the *visibility query for IPv6 prefixes*. Back in February 2013 we have presented the BGP Visibility Scanner at NANOG57. Please find the abstract and slides at the following link: http://www.nanog.org/meetings/abstract?id=2072 The tool is publicly available at *http://visibility.it.uc3m.es/* You can use it to retrieve prefixes injected by a certain origin AS that are not distributed everywhere (i.e., the Limited Visibility Prefixes). The tool has already been proven to be of real help to network operators. In particular, it helped identify and eliminate a large number of unintended IPv4 LVPs (e.g., prefixes leaked because of misconfigurations). We believe the tool is of interest for the ASes already deploying IPv6, enabling the operators to check the visibility status of their IPv6 prefixes and validate their routing policies. We would greatly appreciate your feedback on the limited visibility prefixes that you discover with the tool! For more information about the BGP Visibility Scanner project, we further refer you to the RIPE Labs article: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner For any further questions, do not hesitate to contact us! Thank you, best regards, Andra
Re: /25's prefixes announced into global routing table?
Hi, From public routing data we can see a total of 2,419 /25s prefixes announced from at least one of the monitors active in RIPE RIS and RouteViews. None of the /25s are actually advertised by all these monitors i.e. the /25s reach some but not all the ASes which take part in these projects. The actual distribution of how many unique routing tables sampled contain the /25s is the following: http://visibility.it.uc3m.es/len25_distro.html (out of the approx. 140 collectors that have a full routing table). The top 5 ASes that are originating the most /25s are: AS 11427: 462 /25s AS 4766: 273 /25s AS 45400: 109 /25s AS 14065: 82 /25s AS 3549: 57 /25s If you are interested in limited visibility prefixes, i.e., prefixes that are distributed to some but not all the full routing tables at the interdomain level, you can find more at http://visibility.it.uc3m.es/ and https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner Best regards, Andra On 06/22/2013 12:00 AM, nanog-requ...@nanog.org wrote: Date: Fri, 21 Jun 2013 13:56:02 -0600 From: Michael McConnellmich...@winkstreaming.com To: North American Network Operators Groupnanog@nanog.org Subject: /25's prefixes announced into global routing table? Hello all, As the IPv4 space get smaller and smaller, does anyone think we'll see a time when /25's will be accepted for global BGP prefix announcement. The current smallest size is a /24 and generally ok for most people, but the crunch gets tighter, routers continue to have more and more ram will it always be /24 the smallest size? Cheers, Mike
The BGP Visibility Scanner
Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
Re: The BGP Visibility Scanner
Hi Jason, Thank you for your email! We are glad to hear that you like the work! At the moment, you can only query the webpage and retrieve the LVPs per origin AS. We haven't yet considered giving the option of downloading the complete report. We are now working on a new version of the tool, and we will try to integrate your suggestion, thank you! If you have any other suggestions or requests, don't hesitate to let us know! Best regards, Andra On 05/15/2013 03:00 PM, Jason Hellenthal wrote: Pretty nice. Thanks! I don't suppose there is any straight text version of all this info is there ? /-- / /*Jason Hellenthal*/ IST Services Professional Inbox: /jhellent...@dataix.net mailto:jhellent...@dataix.net/ JJH48-ARIN On May 15, 2013, at 6:22, Andra Lutu andra.l...@imdea.org mailto:andra.l...@imdea.org wrote: Dear all, We have built a tool that checks the visibility of IPv4 prefixes at the interdomain level. The tool is available at *http://visibility.it.uc3m.es/* and you can use it to retrieve the Limited Visibility Prefixes (LVPs) (i.e., prefixes that are not present in all the global routing tables we analyse) injected by a certain originating AS. The query is very simple, it just requires to input the AS number for which you want to retrieve the originated LVPs, if any. After checking the limited-visibility prefixes, we would appreciate any feedback that you can provide on the cause of the limited visibility (we provide a form with a few very short questions which you could fill in and submit). Using a dataset from May 2nd 2013, we generated a list with the ASes which are originating LVPs: *http://visibility.it.uc3m.es/fullASlist.html* We would like to hear from any operator who might find this project interesting, and, in particular, from these large contributors to the LVPs set. Please note that advertising prefixes with limited visibility does not mean that the originating AS is necessarily doing something wrong. The ASes might be generating the LVPs knowingly (e.g., scoped advertisements). However, there might be cases where the origin AS might be unaware that some prefixes are not globally visible (when they should) or that others are leaking as a consequence of mis-configurations/slips. Our purpose is to spread awareness about these latter phenomena, help eliminate the cause of unintended/accidental LVPs and upgrade this tool to an anomaly detection mechanism. For more information on the definition and characteristics of a Limited Visibility prefix, please check the Frequently Asked Questions section of the webpage, available here: *http://visibility.it.uc3m.es/Q_and_A_latest.html* The tool works with publicly available BGP routing data, retrieved from the RIPE NCC RIS and RouteViews Projects. The results are updated on a daily basis. For more information on the methodology we refer you to the slides of the NANOG57 presentation about the BGP Visibility Scanner: http://www.nanog.org/meetings/nanog57/presentations/Wednesday/wed.general.Lutu.BGP_visibility_scanner.19.pdf Also, you can check the RIPE labs article about the BGP Visibility Scanner, available here: https://labs.ripe.net/Members/andra_lutu/the-bgp-visibility-scanner We are looking forward to your feedback! Thank you, best regards, Andra
RIS raw data
Hi all, I am working on getting a better grasp on what data we have in the RIS project from RIPE. To this end, I am checking the export policies of the ASes peering with RIPE AS12654 at different IXPs. I am wondering if anybody knows what these ASes actually announce to the RIPE repositories? Do they dump their entire routing tables (including their internal routes) ? In some cases I saw the export policy ANNOUNCE ANY, is this consistent with a particular AS behaving like the RIPE AS was its customer? Another type of export policy is for example 'to AS12654: ANNOUNCE AS YYY '(where YYY is any AS peering with RIPE in the RIS project). How is this policy different from the previous one from the point of view of the routing feed the RIPE repository receives? Thank you for your help! Best regards, Andra
Re: RIS raw data
Hi Randy, Thank you for your reply. I do, however, have one more question, please find it bellow. In some cases I saw the export policy ANNOUNCE ANY, is this consistent with a particular AS behaving like the RIPE AS was its customer? well, if i was to take that literally, that would include internal prefixes, e.g. some of p2p inter-router links, loopbacks, ... What would be then the difference between this ANNOUNCE ANY policy and this other policy I have found ANNOUNCE AS-YYY (where AS YYY is the AS exporting its routes)? What are the ASes actually exporting in this case? of course, taking anything from the IRR literally is naïve at best. some years back, i asked for a *simple minimal* tagging of announcements to route views, just peer, customer, internal. it got ietfed to utter uselessness, with more crap welded on to it than envisioned in mad max. randy Best regards, Andra
