Re: ISP Filter Policies
Adam Clark said the following on 24/8/07 04:02: > I've noticed that http://www.nanog.org/filter.html is a little out of date, > and I was wondering if anyone knows whether any ISPs currnetly have issues > with /24 BGP advertisements for blocks outside of the traditional Class C > space? My regular analysis report shows 120790 /24s in the BGP table today. So I'd suspect that there are few problems with /24 advertisements; but that's just my BGP view, could be different elsewhere. Before you start your migration, announce one /24 as a trial and see what happens? philip --
Re: 200K prefixes - Weekly Routing Table Report
Patrick W. Gilmore said the following on 14/10/06 04:16: > > On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote: > >> BGP routing table entries examined: 200339 >> Prefixes after maximum aggregation: 108814 > > Shall we all have a moment of silence for 200K prefixes in the global > table. My view actually hit 200k on Wednesday morning, then dipped back under by a few hundred on Thursday. I was kinda hoping that it would hit 200K on Tuesday, then I could have added the announcement to my aggregation recommendations lightning talk! ;-) Bit sad that a 200K table can be aggregated down to 109k prefixes with no loss of path information (in my BGP table view). > Maybe reboot all our routers at once or something? Who wants to go first...? Then again, maybe better not... philip --
Re: Traffic to our customer's address(126.0.0.0/8) seems blocked by packet filter
[EMAIL PROTECTED] said the following on 4/8/05 12:03: > > We aren't going to consolidate to a single /8 announcement. > We are going to continue to announce each individual /16 for incoming traffic > engineering. FWIW, if you don't announce your aggregate, do not be surprised if you experience continued disconnectivity to many parts of the Internet. Some SPs notice that SoftbankBB have received 126/8, so will likely filter as such. Leaking sub-prefixes may be fine for traffic engineering, but this generally only works best if you include a covering aggregate. Try including your /8 announcement and see if this improves reachability for you. Out of curiosity, why pick on a /16 for traffic engineering? Most people tend to analyse traffic flows and pick the appropriate address space size as a subdivision. Or do you have 256 links to upstream ISPs and need that level of fine-tuning? best wishes, philip --
FYI: APRICOT 2006
Hi everyone, Just would like to let you know that the APRICOT 2006 Call for Presentations is now out, as below. APRICOT, for those who don't know, is the Asia Pacific Operations and Technology Conference, very similar in aim and purpose to the NANOG conferences we have here in North America. If you are interested in contributing to the APRICOT programme, and visiting Australia during our summer next year, please read on... philip -- Asia Pacific Regional Internet Conference on Operational Technologies Perth, Western Australia 22nd Feb - 3rd March 2006 The APRICOT 2006 Program Committee is now seeking contributors to the program. This is the main call for Presentations & Tutorials before the final program is fixed. We would like to give people the opportunity to submit their proposals early and to encourage people in the Asia Pacific region who have not previously presented their work to do so. We are looking for people who would like to: * Offer a technical tutorial on an appropriate topic; and/or * Participate in the technical conference sessions as a speaker; and/or * Convene and chair a Birds of a Feather (BOF) session. CONFERENCE MILESTONES: 20 November 2005: Receive all Speaker & Instructor submissions 5 December 2005: Announce Selected Speakers and Tutorials 1 February 2006: All Presentation Materials are received from Speakers & Instructors 22 February to 26 February 2006: Pre-conference Workshops 27 February to 28 February 2006: Tutorials 01 March to 02 March 2006: Conference 03 March 2006: APNIC Meeting PROGRAM MATERIAL TUTORIALS: Tutorials are full-day workshops which focus on a particular subject in-depth. They may be presented by a single Instructor, or a team of instructors working together. Tutorial Instructors are encouraged to also sign up to be a Speaker in the Technical Conference Program as well. You can sign up to give a tutorial and/or conference session presentation by following the instructions at the end of this message for signing up as a speaker or instructor. Tutorial topics that have been successful in the past, or which have been requested for this year, include: * Network security, IPSec, Auditing/Forensics, DDoS Mitigation, VoIP Security * Address planning, conservation, responsibility and migration to IPv6 * High performance IP backbone routing and management * BGP MultiHoming * MPLS * Network planning, management and traffic engineering * Operation experiences and issues in deploying Internet Infrastructure * Internet exchanges, construction, peering and collocation * Operations, NOC, Helpdesk and other support aspects * BIND, DNSSEC, Split Horizon DNS, and Reverse and multilingual DNS * Broadband first/last mile access technologies * Mobile and wireless technologies * Content, Applications, streaming and multimedia infrastructure * VoIP, Unified messaging, scaling e-mail infrastructure, Asterisk, etc. * Hosted Essential Services (mail, DNS, etc), Server scaling, Open source * Training the Trainers Workshops / Educators Track * Quantitative Analysis for Internet Public Policy The program committee will consider proposals for tutorials in any of these areas, and also in new areas. There will be two days of Tutorials. Tutorials last 1/2 day or a full day. If you have an idea for a tutorial subject that is not listed, please feel free to submit it to us. TECHNICAL CONFERENCE SESSIONS: The Main Conference Program for 2006 will be made up of 2 days with 3 tracks each day (Plus the APNIC and other concurrent AP* org Tracks which is managed by various AP* groups independent of APRICOT). Each Track has three 1.5 hour sessions on Wednesday and four 1.5 hour sessions on Thursday. Each session can have 3 - 4 presentations (therefore allowing 20-30 minutes per speaker) or a panel. Sessions are chaired by persons of appropriate expertise in the subject matter of the session, and will include ample time for questions from the audience. If you would like to give a presentation at one or more of the sessions, follow the instructions at the end of this message for signing up as a speaker or instructor. Sessions that are planned are: * Access Networks (Wireless, DSL, Cable, Fibre, etc) * Open Source Tools and Analysis * Broadband Content / Gaming * Peering * Exchange Points Operations * Routing / Backbone Technology & Techniques * IPv6 Operations * DNS * ENUM * VoIP * Network Security Practices * Network Auditing and Forensics * DoS Mitigation Strategies * Anti-SPAM and Net Abuse Please submit presentation proposals that would fit in one of the above sessions. When considering a presentation or tutorial, remember that the APRICOT audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills
Re: Weekly Routing Table Report
Hi Folks, Sorry about that, something seems to have broken when the script was run earlier on today. The table in the view I use was 140k prefixes then, and is now back up to the normal 159k again. philip -- Joe Loiacono said the following on 09/04/2005 06:48: Wha happen? Routing Table Report 04:00 +10GMT Sat 09 Apr, 2005 Analysis Summary BGP routing table entries examined: 139674 >
Re: The Cidr Report
Hannigan, Martin said the following on 14/02/2005 09:32: Is aggregation being covered in the Sunday BoF's? [ hint, hint ] The BGP tutorials I've been doing on Sundays at NANOG all cover aggregation - at least, I seem to end up talking about aggregation in each one. Maybe I need to be more direct? But then again, who am I preaching to? The choir maybe, I don't know. Maybe we need a specific aggregation tutorial for those who don't know how to? Those who have operational and technical reasons not to aggregate have made that decision with prior knowledge. We should try and give everyone else the knowledge, then at least we will know that all de-aggregation is done for a reason. Then it begs the question, is NANOG the conference actually reaching the people who'd most benefit from it? I say this as I'm in transit in Singapore heading back from a hugely successful and enjoyable SANOG (South Asia NOG) in Bangladesh. Similar idea to NANOG, but heavier emphasis on education (workshops & tutorials), and we had ISPs falling over themselves to participate in the first Internet operations meeting held in that country. philip --
Re: The Cidr Report
Hi Stephen, Stephen J. Wilcox said the following on 13/02/2005 00:58: that applies to medium and large providers too reading this list - how often do they actually check what prefixes they are sourcing, from my recent work at a couple of european IXes i had a number of folks email me offlist as they hadnt realised til I sent out an email they had deaggregation and once it was pointed out they just fixed it. I don't think many people have the time to check customers deaggregation - it doesn't obviously help with their company's business/profits therefore isn't on the radar. Or is a job done when they have time. Like you, Hank and I (amongst many others) have spent quite a bit of time pointing out possible leakages to providers - and most have been very polite and appreciative of the advice. I've had a few negative reactions, mostly questioning why this is any of my business. :( so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this? Interesting thought - yes that might help, but then how many providers would be willing to do this? The CIDR report website is available, anyone can pop their ASN into the tool there, and they can figure out what needs to be aggregated. Should the tool be packaged up as something anyone can run from their web page, or a cron job? What would customers think about this if their upstreams do it? Or should some third party do it, like Geoff and I post our respective regional reports and aggregation summaries...? How would this differ from spam - and anyway, how would be get in touch with every ISP on the Internet... etc... philip --
Re: The Cidr Report
I split my Routing Analysis based on registry region so that the constituents of each region know what is going on in their area. As you know registries offer training if their membership ask for it. APNIC and RIPE NCC membership seem to ask for training other than just how to be an LIR. But how to be an LIR doesn't cover every single ASN who is announcing address space. For example, APNIC has an extensive region wide programme, but there is still large deaggregation here in the AP region... So I really don't see what RIR training has to do with this. It helps, but it isn't the complete solution. If the industry is worried, the industry has to do something about it. philip -- Hank Nussbacher said the following on 13/02/2005 04:16: Duh! No suprise there. ARIN just gives IP space and only offers some measly online training: http://www.arin.net/library/training/index.html RIPE on the other hand, has 3-6 course a month, throughout Europe: http://www.ripe.net/training/lir/index.html http://www.ripe.net/cgi-bin/courselist.pl.cgi APNIC also has a number of courses and goes out to where it is needed: http://www.apnic.net/training/schedule.html As long as ARIN just doles out IP space with no education, the routing table will continue to grow. -Hank Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip
Re: The Cidr Report
Neil J. McRae said the following on 12/02/2005 21:06: The issue we see is bad aggregation - the root cause is bad practise and processes that manifest into bad aggregation. I would argue that networks with poor aggregation are also networks that will tend to have more routeing issues and other outages although I have no data to back that claim up. I think it depends on which part of the world you look in. But I've visited enough ISPs in the last 7 years in my part of the world (outside US and Western Europe) to know that this is an accurate statement. Again, no data to back this experience up. Neil J. McRae said the following on 12/02/2005 21:07: > >>Commercial reasons? The traffic goes to the 32x/24 instead of >>the /19. > > If that's the reason why the table is growing so much then we > are all in deep deep trouble. Quite often many service providers are de-aggregating without knowing it. They receive their /20 or whatever from the RIR, but they consider this to be 16 Class Cs - I'm not joking - and announce them as such to the Internet. I spend a lot of time getting these folks to announce aggregates, but it is hard work convincing people that this will even work. Even if the RIR recommends that they announce their address block, they still consider it as Class Cs - even Class Bs for some big allocations. :( Solution is education, but the industry is such in many parts of the world that education is not desired but considered a negative reflection on people's abilities, whether they have the abilities or not. And the lack of educators - there are several of us on the worldwide NOG trail but it's very clear we are not enough. Nor do the NOGs cover the ISP industry, but just those who are interested in participating. We are not enough due to lack of time, lack of supportive employers, more focus on making profit in these leaner times, etc... Where next I don't know... philip --
Re: The Cidr Report
Frotzler, Florian said the following on 11/02/2005 21:31: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ~ +3000 routes in one week? Anyone else frightened by this? Yup. From my own Routing Report (due out in a couple of hours), a quick glance shows that the vast majority of the increase comes from ASNs assigned by ARIN (the ASNs from the other three registry regions show minimal increase in announcements). Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip --
Re: IBGP Question --- Router Reflector or iBGP Mesh
Hi Eric, Eric Kagan said the following on 11/01/2005 11:03: >> Correct, route reflector's main advantage is scalability and if you're thinking to evolve into a larger network with dedicated access and core routers, route reflectors are a far better option than full mesh, though perhaps not from the start. Does anyone have any input on when this does make sense ? We have 3 Main IP pops with upstream BGP at each and 4 internal BGP sessions. I am looking to add 2 new routers so there will be about 7 sessions on each border router. They are 7206VXR all 256MB RAM just acting as border. No customer circuits, etc. Is it time to look at route reflectors at this point ? Any input or guidelines for making a smooth transition from Full mesh ? Well, my preference is to start with route reflectors pretty much from day one. Let's face it, one day you will have to migrate that full mesh iBGP to route reflector. Why do the work of migration when you can start off at the beginning using route reflectors. One less job to do, one less potential network disruption, happy customers,... Many of the ISPs I've worked with around the world have followed this path - and they are quite happy. I really think there is absolutely no need to consider full mesh iBGP any more. I wouldn't go as far as saying it's history, but I find it very hard to make an operational case for deploying full mesh iBGP any more. As for guidelines for transition, check out the BGP tutorials which have been given at the recent NANOGs. It's really very simple to do, and you are lucky as you have relatively few routers to migrate. Hope this helps, philip --
APRICOT 2005 in Kyoto, Japan
Hi everyone, This is to let you know that the registration for APRICOT 2005 in Kyoto, Japan, from 18th to 25th February 2005 is now open. APRICOT is the Asia Pacific region's Internet operations and technology conference, and consists of workshops, tutorials, conference, as well as the 6 monthly APNIC meeting. Full information about APRICOT 2005 can be had at www.2005.apricot.net. Registration and accommodation information is at: www.2005.apricot.net/registration.html www.2005.apricot.net/accommodation.html You are encouraged to register as soon as possible as the early bird registration discount finishes on the 12th of January. Hope to see you in Kyoto early next year! philip --
Re: Any Kine NOGs? Re: European Nanog?
At 10:36 13/09/2004 -1000, Scott Weeks wrote: Anyone got a list of all english language NOG mailing lists? So far I have AFNOG, SwiNOG (apparently some in english) and SANOG. My little list includes: NANOG, AfNOG, SANOG, JANOG, EOF, APOPS, SGNOG, NZNOG, NordNOG, SwiNOG, PACNOG So, North America, Africa, South Asia, Japan, Europe, Asia Pacific, Singapore, New Zealand, Nordic Countries, Switzerland, Pacific. There are bound to be others lurking out there... philip --
Re: APNIC returning 223/8 to IANA
At 01:31 17/03/2003 -0500, Jared Mauch wrote: You're missing the issue that when you are assigned space, if part of it is already reserved that should be clearly spelled out. When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. Jared, you hit the nail on the head. Anyone who was at the APNIC Policy SIG meeting during APRICOT 2003 last month will have heard the fairly lengthy discussion around 223/8. While I don't agree that the block should be handed back as it makes a fairly substantial mountain out of what is a tiny molehill, several pointed out the above issue, that 223/8 is not fully usable, and that there is no documentation stating that 223.255.255.0/24 is actually usable. Or not usable. RFC3330 (informational) states what it used to be for, but the actual paragraph discussing 223.255.255.0/24 contradicts itself, and is of no help. My disappointment was that everyone who could solve, or at least take ownership of the problem was in the room at the time. That they chose not to was sad, much to the bewilderment of the attendees I spoke to afterwards. Had the problem been solved there and then, it would have demonstrated clear progress in improving RIR/IETF cooperation. And so the address space has been returned. :-( philip --
Re: FYI New IPv4 allocation ot APNIC
At 17:26 12/02/2003 -0800, David Conrad wrote: Any parties planned for finishing off the class C space? :-) 197/8 and 201/8 are still available. So hold off on that party for a while. ;-) philip -- Rgds, -drc
FYI: South Asia Network Operators Group (SANOG)
This is an FYI only... The first meeting of the South Asia Network Operators Group (SANOG) will take place alongside ITConference2003 (http://www.itconference.org.np/) in Kathmandu, Nepal on 23rd-27th January 2003. Its aimed at ISPs and Network Operators in the South Asia region, basically encompassing the Indian subcontinent and neighbouring countries. SANOG doesn't quite yet have a website, but hopefully this isn't too far off. This is the first attempt to create such an operators group in this part of Asia; if anyone is interested in supporting this new NOG, please feel free to contact Gaurab Raj Upadhaya <[EMAIL PROTECTED]> who is organising the event. philip --
FYI: CIDR Report changes
Hi, As most of you know, the CIDR Report was conceived by Tony Bates in 1995 as a means to monitor and inform the community about the amount of CIDRisation activities being carried out by Internet Service Providers. The CIDR Report has been highly successful, much referred to and well respected snapshot of the growth in the Routing Table, as well as providing information on the level of aggregation being carried out in our community. In recent years it has become more of a challenge to maintain the software to keep up with the rapid growth in the Internet. Philip Smith, who has produced a widely published Routing Table Report since late 1998, has helped to keep the Report up to date with current allocation and assignment information. But with the large number of views of the routing table, and with the numerous requests many individuals and organisations have been making for enhancements to the CIDR Report, we have agreed that the future of the CIDR Report now rests alongside the very comprehensive BGP Table Analysis which Geoff Huston has been running for the last year. This Friday's CIDR Report (23rd August) was the last one posted from Tony's original system. As from the coming Friday (30th August), the CIDR Report will come from Geoff Huston's new implementation. The e-mail will go to the same operations mailing lists, will look very similar in layout, and will have greatly updated information compared with the original. Furthermore, the routing table view will be the summary from the RouteViews project. The supporting website for the CIDR Report has been vastly improved, with greater detail, the ability to search on aggregation effort per AS, and so on. A snapshot of Geoff's implementation can be found at http://bgp.potaroo.net/cidr/. Regular users of the information contained in the CIDR Report should check out the website and the new features in the report. As ever, comments and feedback are most welcome; these should be sent to <[EMAIL PROTECTED]>. Tony Bates, Geoff Huston, Philip Smith
Re: ASN registry?
Ralph, ARIN only handles the ASNs for North and South America, and the southern half of Africa. And has the records for most of the historical stuff from when before APNIC and RIPE NCC existed. Simple rule, if it isn't at ARIN, check APNIC and RIPE NCC databases. Telstra is in Australia, Australia is in the AP region, therefore not finding the entry in ARIN's db would sort of suggest to check APNIC next. Note that the delegation records for some of the ASNs assigned before APNIC and the RIPE NCC existed have been moved to the latter databases. Telstra is but one example. (I agree it might be more helpful if a query on whois.arin.net displayed a message saying "go look at whois.apnic.net" rather than saying "No match".) philip -- At 15:24 19/08/2002 -0400, Ralph Doncaster wrote: >I've always used whois.arin.net to check ASN registrations, and until now >it's always had information on those that I've checked. >It doesn't have anything for 1221, which according to >route-views.oregon-ix.net is Telstra. Is there a single complete database >that has ASN assignment info? > >Ralph Doncaster >principal, IStop.com
Re: AS number inconsistencies
Hi Marwan, At 09:55 08/07/2002 -0400, Marwan Fayed wrote: >I am a CS PhD student trying to track ASes (for reasons I'm happy to >discuss offline). There is a grave inconsistency I have come across and >can't explain. Simply, there seems to be many AS numbers in the >non-private range that come into use at some point in time and advertise a >range of IPs, but these AS numbers are not allocated until much later. Can you give examples? Both the CIDR-Report, posted to this list, and my own Routing Report (which I spare NANOG of, but is "inflicted" on ARIN's rtma, RIPE's routing-wg, and APOPS :), look up every single AS which is present in the BGP table - any AS which is announced and is unregistered in any of the three registry databases is flagged in the report. And there are only two ASes which appear, and are not registered anywhere - one is intermittent, the other, AS5757, has been there since I started this over 3 years ago. >Does any one have any explanations? Are network operators "notified" of >their new AS number well in advance of the actual receipt of that number >on paper, for example? Any help is appreciated (and hopefully this >occurence is of interest to nanog). That tends to happen, but in my experience APNIC, ARIN and the RIPE NCC will put the entry in their database before they inform their customer of the allocation. So, examples would be good - send to me privately if you wish and I can cross reference with my own routing table views. philip --
BGP Tutorial update...
Hi, An update on the AS3257 community slide I included at the end of the BGP Tutorial - it was pointed out that www.as3257.net/html/communities.htm no longer existed as I had on the presentation. And there seem to be no links to it on the Tiscali website either... It's still at www.archive.org under http://web.archive.org/web/20011004092913/http://www.as3257.net/html/communities.htm so anyone who is interested in the full copy of that website should grab a copy from there. I'll try find out what has happened to the original site... philip --
Re: Asian exchange points
Richard, There are several exchange points, but their functions tend to be slightly different from what is understood in the US. IXes such as SOX (Singapore), HKIX (Hong Kong), JPIX & NSP-IXP2 (Japan) and KIX & KINX (Korea) tend to be the more oft quoted IXes in Asia and are familiar in design and function. The others are either very much in-country exchanges offering neutral traffic exchange, or being run by one operator as a for profit transit service provider. (Consider in the latter cases the use of the word exchange as a "marketing" term... ;-) As others have pointed out, www.ep.net has the list of all the known ones. Hope this helps. philip -- At 12:43 11/05/2002 -0400, Richard A Steenbergen wrote: >I know this isn't quote North American, but does anyone know what major >exchange points exist in Asia? The largest one I've found so far is JPIX, >which seems to move a fair amount of traffic >(http://www.jpix.co.jp/en/techncal/traffic.html). Any other major ones? > >-- >Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras >PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
