- NZNOG - lists.nznog.org

Re: [nznog] How common is unfiltered BGP?
by Anton Smith 04 Mar '11

04 Mar '11

Message: 2 Date: Tue, 1 Mar 2011 23:56:27 +0000 From: Matthew Moyle-Croft <mmc(a)internode.com.au> To: Cameron Kerr <ckerr(a)cs.otago.ac.nz> Cc: nznog <nznog(a)list.waikato.ac.nz> Subject: Re: [nznog] How common is unfiltered BGP? Message-ID: <5AE909E2-8640-4BDD-ABA4-1D88F9E66B7F(a)internode.com.au> Content-Type: text/plain; charset="us-ascii" Cameron, People filter in different ways and for different reasons: eg. At a small scale people filter based on prefixes. At a larger scale people will filter based from, say, an AS-MACRO which turns into prefixes. At a very large scale it might be ASPATH only as the number of prefixes from a customer might be too hard to deal with (ie. just sheer size of the configs on a router). At a certain size it's just too hard to filter. Some of our peers we can't successfully filter as their AS-MACRO alone is too large to successfully process and place on a router. (These are peers where we see 40k+ prefixes). Then you're down to max-prefix "filtering" which might allow you to stop really dumb things - ie. full table leak, but doesn't stop the insidious things like leaking other people's prefixes where they may only have to send a few prefixes. Some people make a deal out of having "unfiltered" transit - I guess it's okay if you have no systems in place for updating the filters automagically, but typically you can't get advanced features such as remote triggered blackholes unless you are filtered. There are some hybrid approaches people use - eg. they filter customers/peers from sending "largenets" (eg. Tier1 ASes such as 3356, 3549, 1239 etc as well as things like 15169 (Google) and 22822 (Limelight) etc). At a larger scale you might end up with a mishmash of various things: eg. - We have strict filtering on customers and ask them to tell us their prefixes. - We register all our prefixes with a registry (AS-4739 on rr.ntt.net< http://rr.ntt.net> - historical reasons) so our transit is filtered plus we have a good idea of what prefixes we're meant to carry. - We filter by AS-MACRO as much as we can with peers - We filter outbound our own routes against our own internal registry amongst other techniques. But some places are hard: eg. we're at some MLPA based exchanges where there's no useable filter. Some bilateral peers don't register their routes. There are places where ugliness happens. Every now and again we have issues with peers leaking routes - either ours or someone elses and you need to have an operational technique to fix this. My big issue with going for "unfiltered" transit is you can't have remote triggered blackholes, which are a useful technique for protecting you against DDoS by getting your transit to sink the traffic. It's not to hard to figure out a system that allows your own filtered customers to go and announce prefixes to black hole and then back-to-back it with your transit. MMC Matthew, just to check.. Why can't you do remote triggered blackholes without filtered prefixes? Is it because you are worried that they will sink prefixes that don't belong to them? Regards, Anton

2 1

Re: [nznog] [isoc-advisory-council] URGENT UPDATE- Statement relating to today¹s ITU-T SG15 MPLS development decision
by Andy Linton 04 Mar '11

04 Mar '11

I think that we should be very clear in any statements that we make that our view is that the IETF is the arbiter of standards for the Internet and that while we welcome any input that the ITU has to make to that standards process we would be very unhappy to see any steps to see competing standards emerge. The ITU tried that thirty years ago with their support of the OSI protocol stack. It was not useful or successful then and a rerun would be counter productive. I think the statement below gets it pretty well and we should add our support for this: "The Internet is an unprecedented success thanks to open, globally interoperable standards," added Lynn St. Amour, President and CEO of the Internet Society. "This action takes us away from the path of global interoperability. It will have a detrimental effect on the long term health of the Internet, and reduce the benefits to all of us as users. It is imperative that the IETF continues to move forward to develop the MPLS standard in the appropriate way, to ensure the continued health of the Internet as a source of innovation for the future."

7 7

Access to citylink wgtn AT&T
by Barry Murphy (iPhone) 03 Mar '11

03 Mar '11

Can someone with access to citylink AT&T Wellington willing to do me a favor message me offlist, I'm willing to offer a box of beer of your choice in return :) need a cable plugged in, but I'm in Auckland so cant do it myself, simple request Sent from my iPhone

1 0

Vodafone / old ihug static ip ranges on sorbs blocklists?
by Ray Taylor 03 Mar '11

03 Mar '11

Hi Im looking for contact details for someone at vodafone that I can talk to regarding a static ip address or possibly a block they are issuing to customers in their static pool being listed in the sorbs antispam database as a dynamic ip address. This entry dates back to when the ip address was ihugs. It is preventing one of my customers from sending email to recipients behind a sorbs antispam filter / Land Information New Zealand. Im thinking the right person to talk to would subscribe to this mailing list. Thanks, Ray Taylor

1 0

New Zealand Network Operators' Group
by Donald Neal 02 Mar '11

02 Mar '11

The New Zealand Network Operators' Group The NZNOG mailing list exists to facilitate discussion among operators of networks in New Zealand on matters relevant to network operators as described in the list's Acceptable Use Policy. That policy appears later in this posting. The NZNOG Trust is registered as a charitable entity under the Charities Act. The trust exists to provide the legal framework needed to do jobs like operating the bank account which holds the money which allows our annual conferences to happen. Other than the four trustees, the NZNOG does not have a formal membership. The trustees are currently looking to replace some of their number. If you've been active in NZNOG's activities, you may want to think about whether that's for you. Conference NZNOG holds New Zealand's only annual technical networking conference. See http://2011.nznog.org/ to see what you missed. Other Meetings See http://thursdaynightcurry.com/ if you live in or near Auckland or Wellington. Operators' Contact List See http://www.nznog.org/?page_id=6 for operational contact details for most New Zealand ISP's. These are intended for use by other network operators, not by most customers. Internet Exchanges See http://www.nzix.net/ for details of exchanges in operation. About This Mailing List This list has just over 1100 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. You may choose to receive postings as they come in, or just to receive daily "digests". See the bottom of the page http://list.waikato.ac.nz/mailman/listinfo/nznog/ to change the form in which you receive postings. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by employees of APN Online and The University of Waikato and an Unemployed Oaf. Neither of these organisations, nor any administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/pipermail/nznog/ . Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrators remain happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. One way to search the archive is to use google and prefix your search with site:list.waikato.ac.nz . Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins -- Donald Neal | I don't approve of gambling. I'll just | spend my time in the bar. High Performance Computing | - NZNOG 2010 attendee The University of Waikato |

1 0

Re: [nznog] How common is unfiltered BGP?
by Andy Linton 02 Mar '11

02 Mar '11

So what does this say about the potential introduction of rPKI

3 2

How common is unfiltered BGP?
by Cameron Kerr 01 Mar '11

01 Mar '11

Hi everyone, I'm just updating my lecture on exteriour routing for this year, and am wanting to know more about the current state of unfiltered BGP, whereby a customer can advertise a prefix they don't have, their service provider didn't suitably filter the advertisement, and it disrupts other networks in the internet. My previous impression, based on discussions around incidents such as the YouTube/Pakistan incident, lead to me believe "Most people don't filter", and I'm just wanting to see if that is [still] the case now. (Also, thanks to Andy for the NRO nudge) Cheers, Cameron

4 4

[isoc-advisory-council] URGENT UPDATE- Statement relating to today’s ITU-T SG15 MPLS development decision
by jamie baddeley 01 Mar '11

01 Mar '11

what thoughts do folks have on this? > The Internet we know today could > not have come about without open, interoperable, global standards. wise words. jamie > > > ---------- Forwarded message ---------- > From: Drew Dvorshak <dvorshak(a)isoc.org> > Date: 26 February 2011 17:44 > Subject: [isoc-advisory-council] URGENT UPDATE- Statement relating to > today’s ITU-T SG15 MPLS development decision > To: isoc-advisory-council(a)elists.isoc.org > Cc: Russ Housley <housley(a)vigilsec.com> > > > Dear Colleagues, > > Many of you have followed with interest (and some anxiety) ITU Study > Group 15's work and the implications of it has been the subject of > several Advisory Council meeting dialogues for some time. Please read > below ISOCs' response to today's SG15 decision on transport MPLS also > reflecting the views of IETF Chair Russ Housley. This news is indeed > unfortunate and you will note copy to Russ to ensure he is included in > Council dialogue as I am confident your willingness and ability to > focus expertise on issues for problem solving and positive planning > will be useful and appreciated here. > Your communications and media people may link to this release at: > http://isoc.org/wp/newsletter/?p=3287. Please let me know should you > have any questions or comments. > Cheers, > Drew > IETF and Internet Society Statement relating to today’s ITU-T SG15 > decision that will lead to non-interoperability in MPLS development > > Today, the ITU-T Study Group 15 determined a Recommendation that > defines Y.1731 based operations, administration and management (OAM) > for MPLS transport networks. This decision sets the stage for a > divergence in MPLS development; it creates a situation where some > vendors will use the IETF standard for MPLS OAM while other vendors > implement the ITU-T Recommendation for OAM. This situation ensures > that the two product groups will not work together. While the impact > may not be immediate, ongoing evolution along this path will > jeopardize the globally interconnected Internet, which is an > interoperable network of networks. > > Russ Housley, IETF chair, commented; "The Internet we know today could > not have come about without open, interoperable, global standards. > After we have worked so long and so hard together to ensure that MPLS > OAM products from all vendors around the world would be compatible > with each other, I am surprised and disappointed by the action taken > by the ITU-T today, which takes us off the path of global > interoperability for this technology. The decision is all the more > regrettable because the IETF is just completing work on the first > major phase of extensions to MPLS OAM protocols for use in transport > networks.” > > Furthermore, this ITU-T SG15 action represents a serious breach of the > IETF/ ITU-T Joint Working Team (JWT) agreement. This JWT was > commissioned by the ITU-T and IETF to examine the feasibility of a > single, collaborative solution to MPLS transport requirements. The > team unanimously agreed that a single viable solution had been > identified; their report was completed in April 2008 and accepted in > December 2008. This JWT Report states not only that a single solution > was possible but also recommended an approach where protocol > development for MPLS-TP would be undertaken by the IETF. The IETF and > ITU-T independently accepted and endorsed the JWT report. The ITU-T > committed to the IETF that they would abide by the JWT recommendations > and recognized the IETF as the design authority for MPLS. Furthermore, > the JWT confirmed that it was technically feasible to extend the > existing MPLS architecture to meet the requirements of a transport > profile, now called MPLS-TP. Since the acceptance of the JWT Report, > both organizations have worked constructively until now. > > "Resolution 101 represented the clear wishes of the member states of > the ITU, and was agreed at the ITU's Plenipotentiary conference less > than six months ago. That Resolution was agreed at the highest level > of the Union, and yet SG15 has taken action that directly contradicts > it,” said Lynn St. Amour, president and CEO of the Internet Society. > > “The IETF will complete its work on a MPLS OAM specification, and the > IETF leadership is considering the best way to proceed in light of > this surprising development,” added Russ Housley. “At this point, our > goal is to minimize the negative consequences of this unfortunate > situation. The priority is to establish a measured and careful > approach that protects the stability of the Internet while enabling it > to grow to serve the entire world-wide population.” > > Although the ITU-T SG15 decision is disappointing, in an ongoing > pursuit of a globally interoperable solution, the IETF will continue > to gather transport requirements and work to extend IETF MPLS > forwarding, OAM, survivability, network management, and control plane > protocols to meet those requirements through the IETF Standards > Process. > > When two non-interoperable standards are developed, there are only two > possible outcomes: if both technologies are deployed, there will be > confusion, if only one is deployed, the existence of the alternative > is irrelevant. In this instance, there are believed to be commercial > products in development for both proposals, so confusion appears > inevitable. > > Russ Housley concluded, “The IETF leadership continues to believe that > a single OAM solution will better serve the continued growth of > Internet, and we hope that the ITU-T leadership will also come to > recognize the benefits of a single globally interoperable solution.” > > > > > > _______________________________________________ > Isoc-advisory-council mailing list > Isoc-advisory-council(a)elists.isoc.org > https://elists.isoc.org/mailman/listinfo/isoc-advisory-council >

2 1

Re: [nznog] How common is unfiltered BGP?
by Scott Weeks 01 Mar '11

01 Mar '11

--- ckerr(a)cs.otago.ac.nz wrote: From: Cameron Kerr <ckerr(a)cs.otago.ac.nz> Hi everyone, I'm just updating my lecture on exteriour routing for this year, and am wanting to know more about the current state of unfiltered BGP, whereby a customer can advertise a prefix they don't have, their service provider didn't suitably filter the advertisement, and it disrupts other networks in the internet. My previous impression, based on discussions around incidents such as the YouTube/Pakistan incident, lead to me believe "Most people don't filter", and I'm just wanting to see if that is [still] the case now. -------------------------------------------------- I don't know if you mean globally, or just in NZ, but filtering is prevalent in all situations I have been in. This is in the US with higher tier providers, such as Sprint, AT&T and Qwest. Additionally, I filtered downstream customers when I worked at the ILEC here in Hawaii. Thank goodness, too, as some of them really messed it all up: sent me the entire internet, candidate default routes, etc., etc... scott - ----------------- --------------------- ------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 01 Mar '11

01 Mar '11

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS24388:RS-ROUTES:AS9503 descr: advertised to AS24388 by FX Networks - AS9503 members: 130.123.0.0/16^16-29, 130.217.0.0/16^16-29, 131.203.0.0/16^16-29, 139.80.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 203.114.128.0/18^18-29, 119.15.0.0/19^19-29, 121.79.192.0/19^19-29, 202.14.32.0/19^19-29, 112.109.64.0/20^20-29, 114.134.0.0/20^20-29, 114.134.160.0/20^20-29, 116.90.128.0/20^20-29, 116.199.208.0/20^20-29, 119.47.112.0/20^20-29, 120.138.16.0/20^20-29, 121.79.224.0/20^20-29, 124.248.128.0/20^20-29, 202.37.0.0/20^20-29, 202.46.160.0/20^20-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.0/20^20-29, 202.174.160.0/20^20-29, 210.48.160.0/20^20-29, 223.165.64.0/20^20-29, 112.109.80.0/21^21-29, 117.18.80.0/21^21-29, 120.89.80.0/21^21-29, 121.79.240.0/21^21-29, 192.173.16.0/21^21-29, 202.36.96.0/21^21-29, 202.37.32.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.50.208.0/21^21-29, 202.78.240.0/21^21-29, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 27.96.64.0/22^22-29, 27.121.96.0/22^22-29, 49.0.28.0/22^22-29, 49.143.228.0/22^22-29, 110.232.144.0/22^22-29, 113.130.120.0/22^22-29, 113.197.64.0/22^22-29, 117.53.156.0/22^22-29, 140.200.248.0/22^22-29, 175.111.100.0/22^22-29, 182.50.160.0/22^22-29, 192.206.152.0/22^22-29, 202.37.28.0/22^22-29, 202.37.48.0/22^22-29, 202.50.216.0/22^22-29, 202.89.4.0/22^22-29, 203.99.132.0/22^22-29, 223.165.16.0/22^22-29, 140.200.230.0/23^23-29, 192.206.156.0/23^23-29, 202.6.116.0/23^23-29, 202.27.38.0/23^23-29, 202.36.126.0/23^23-29, 202.36.134.0/23^23-29, 202.36.168.0/23^23-29, 202.36.214.0/23^23-29, 202.36.218.0/23^23-29, 202.37.52.0/23^23-29, 202.37.124.0/23^23-29, 202.46.190.0/23^23-29, 202.49.136.0/23^23-29, 202.49.164.0/23^23-29, 202.50.246.0/23^23-29, 202.65.160.0/23^23-29, 203.84.134.0/23^23-29, 203.217.142.0/23^23-29, 192.88.85.0/24^24-29, 192.88.99.0/24^24-29, 192.105.10.0/24^24-29, 192.107.171.0/24^24-29, 192.107.172.0/24^24-29, 192.122.171.0/24^24-29, 192.122.180.0/24^24-29, 192.133.31.0/24^24-29, 192.138.251.0/24^24-29, 192.195.219.0/24^24-29, 192.245.185.0/24^24-29, 202.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.27.239.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.170.0/24^24-29, 202.36.221.0/24^24-29, 202.37.129.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.41.140.0/24^24-29, 202.46.188.0/24^24-29, 202.49.106.0/24^24-29, 202.49.168.0/24^24-29, 202.49.187.0/24^24-29, 202.49.215.0/24^24-29, 202.50.252.0/24^24-29, 202.55.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.74.33.0/24^24-29, 202.74.38.0/24^24-29, 202.89.57.0/24^24-29, 202.129.253.0/24^24-29, 203.89.178.0/24^24-29, 203.89.181.0/24^24-29, 203.89.187.0/24^24-29, 203.92.25.0/24^24-29, 210.7.40.0/24^24-29, 210.7.46.0/24^24-29, 210.48.191.0/24^24-29, 202.89.43.0/25^25-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110222 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS9503 descr: advertised to AS24388 by FX Networks - AS9503 members: 130.123.0.0/16^16-29, 130.217.0.0/16^16-29, 131.203.0.0/16^16-29, 139.80.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 203.114.128.0/18^18-29, 119.15.0.0/19^19-29, 121.79.192.0/19^19-29, 202.14.32.0/19^19-29, 112.109.64.0/20^20-29, 114.134.0.0/20^20-29, 114.134.160.0/20^20-29, 116.90.128.0/20^20-29, 116.199.208.0/20^20-29, 119.47.112.0/20^20-29, 120.138.16.0/20^20-29, 121.79.224.0/20^20-29, 124.248.128.0/20^20-29, 202.37.0.0/20^20-29, 202.46.160.0/20^20-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.0/20^20-29, 202.174.160.0/20^20-29, 210.48.160.0/20^20-29, 223.165.64.0/20^20-29, 112.109.80.0/21^21-29, 117.18.80.0/21^21-29, 120.89.80.0/21^21-29, 121.79.240.0/21^21-29, 192.173.16.0/21^21-29, 202.36.96.0/21^21-29, 202.37.32.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.50.208.0/21^21-29, 202.78.240.0/21^21-29, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 27.96.64.0/22^22-29, 27.121.96.0/22^22-29, 49.0.28.0/22^22-29, 49.143.228.0/22^22-29, 110.232.144.0/22^22-29, 113.130.120.0/22^22-29, 113.197.64.0/22^22-29, 114.31.212.0/22^22-29, 117.53.156.0/22^22-29, 140.200.248.0/22^22-29, 175.111.100.0/22^22-29, 182.50.160.0/22^22-29, 192.206.152.0/22^22-29, 202.37.28.0/22^22-29, 202.37.48.0/22^22-29, 202.50.216.0/22^22-29, 202.89.4.0/22^22-29, 203.99.132.0/22^22-29, 223.165.16.0/22^22-29, 140.200.230.0/23^23-29, 192.206.156.0/23^23-29, 202.6.116.0/23^23-29, 202.27.38.0/23^23-29, 202.36.126.0/23^23-29, 202.36.134.0/23^23-29, 202.36.168.0/23^23-29, 202.36.214.0/23^23-29, 202.36.218.0/23^23-29, 202.37.52.0/23^23-29, 202.37.124.0/23^23-29, 202.46.190.0/23^23-29, 202.49.136.0/23^23-29, 202.49.164.0/23^23-29, 202.50.246.0/23^23-29, 202.65.160.0/23^23-29, 203.84.134.0/23^23-29, 203.217.142.0/23^23-29, 192.88.85.0/24^24-29, 192.88.99.0/24^24-29, 192.105.10.0/24^24-29, 192.107.171.0/24^24-29, 192.107.172.0/24^24-29, 192.122.171.0/24^24-29, 192.122.180.0/24^24-29, 192.133.31.0/24^24-29, 192.138.251.0/24^24-29, 192.195.219.0/24^24-29, 192.245.185.0/24^24-29, 202.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.27.239.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.170.0/24^24-29, 202.36.221.0/24^24-29, 202.37.129.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.41.140.0/24^24-29, 202.46.188.0/24^24-29, 202.49.106.0/24^24-29, 202.49.168.0/24^24-29, 202.49.187.0/24^24-29, 202.49.215.0/24^24-29, 202.50.252.0/24^24-29, 202.55.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.74.33.0/24^24-29, 202.74.38.0/24^24-29, 202.89.57.0/24^24-29, 202.129.253.0/24^24-29, 203.89.178.0/24^24-29, 203.89.181.0/24^24-29, 203.89.187.0/24^24-29, 203.92.25.0/24^24-29, 210.7.40.0/24^24-29, 210.7.46.0/24^24-29, 210.48.191.0/24^24-29, 202.89.43.0/25^25-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110302 source: NZRR ------------------------------------------------------------

1 0