March 2012 - NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 27 Mar '12

27 Mar '12

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:AS23655 descr: advertised to AS24388 by Snap Internet - AS23655 members: 118.148.0.0/15^15-29, 111.69.0.0/16^16-29, 130.123.0.0/16^16-29, 130.195.0.0/16^16-29, 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 140.200.0.0/16^16-29, 150.206.0.0/16^16-29, 153.111.0.0/16^16-29, 159.117.0.0/16^16-29, 163.7.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 14.1.32.0/19^19-29, 180.189.192.0/19^19-29, 202.124.96.0/19^19-29, 111.65.224.0/20^20-29, 182.54.160.0/20^20-29, 202.49.16.0/20^20-29, 202.56.32.0/20^20-29, 203.86.192.0/20^20-29, 210.7.32.0/20^20-29, 27.110.120.0/21^21-29, 120.136.0.0/21^21-29, 202.49.64.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 103.4.136.0/22^22-29, 103.4.152.0/22^22-29, 103.247.152.0/22^22-29, 110.92.16.0/22^22-29, 113.197.96.0/22^22-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 203.99.132.0/22^22-29, 103.22.234.0/23^23-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.106.0/23^23-29, 202.49.80.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 103.10.233.0/24^24-29, 143.96.13.0/24^24-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.14.217.0/24^24-29, 202.36.141.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.174.0/24^24-29, 202.37.114.0/24^24-29, 202.37.127.0/24^24-29, 202.37.179.0/24^24-29, 202.37.194.0/24^24-29, 202.37.220.0/24^24-29, 202.46.187.0/24^24-29, 202.49.59.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.140.0/24^24-29, 202.49.187.0/24^24-29, 202.50.110.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.50.176.0/24^24-29, 203.92.25.0/24^24-29, 203.96.112.0/24^24-29, 203.174.26.0/24^24-29, 203.191.7.0/24^24-29, 205.233.128.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29, 210.55.110.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: support(a)biz.snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120213 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS23655 descr: advertised to AS24388 by Snap Internet - AS23655 members: 118.148.0.0/15^15-29, 111.69.0.0/16^16-29, 130.123.0.0/16^16-29, 130.195.0.0/16^16-29, 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 140.200.0.0/16^16-29, 150.206.0.0/16^16-29, 153.111.0.0/16^16-29, 159.117.0.0/16^16-29, 163.7.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 14.1.32.0/19^19-29, 49.50.192.0/19^19-29, 180.189.192.0/19^19-29, 202.124.96.0/19^19-29, 111.65.224.0/20^20-29, 182.54.160.0/20^20-29, 202.49.16.0/20^20-29, 202.56.32.0/20^20-29, 203.86.192.0/20^20-29, 210.7.32.0/20^20-29, 27.110.120.0/21^21-29, 49.50.224.0/21^21-29, 120.136.0.0/21^21-29, 202.49.64.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 103.4.136.0/22^22-29, 103.4.152.0/22^22-29, 103.247.152.0/22^22-29, 110.92.16.0/22^22-29, 113.197.96.0/22^22-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 203.99.132.0/22^22-29, 103.22.234.0/23^23-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.106.0/23^23-29, 202.49.80.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 103.10.233.0/24^24-29, 143.96.13.0/24^24-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.14.217.0/24^24-29, 202.36.29.0/24^24-29, 202.36.141.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.174.0/24^24-29, 202.36.245.0/24^24-29, 202.37.114.0/24^24-29, 202.37.127.0/24^24-29, 202.37.179.0/24^24-29, 202.37.194.0/24^24-29, 202.37.220.0/24^24-29, 202.46.187.0/24^24-29, 202.49.59.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.140.0/24^24-29, 202.49.187.0/24^24-29, 202.50.110.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.50.176.0/24^24-29, 203.6.246.0/24^24-29, 203.92.25.0/24^24-29, 203.96.112.0/24^24-29, 203.174.26.0/24^24-29, 203.191.7.0/24^24-29, 205.233.128.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29, 210.55.110.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: support(a)biz.snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120328 source: NZRR ------------------------------------------------------------

1 0

AUI transceivers and Cisco rack kits
by Tim Price 26 Mar '12

26 Mar '12

Hi Guys, Sorry about the off topic post but I'm looking for anyone willing to sell me AUI transceivers and/or Cisco 2500 rack mount kits. I know I can buy AUI transceivers from blackbox but I prefer cheap rather than diamond encrusted. Anyone with info/stock please contact me off list. Kind regards, Tim Price Network Operations Manager DTS Limited

1 0

Three blocks of AS Numbers allocated to the RIPE NCC
by Leo Vegoda 22 Mar '12

22 Mar '12

Hi, The IANA AS Numbers registry has been updated to reflect the allocation of three blocks to the RIPE NCC in March 2012. 59392-60415 Assigned by RIPE NCC 2011-03-21 60416-61439 Assigned by RIPE NCC 2011-03-21 198656-199679 Assigned by RIPE NCC 2011-03-21 You can find the registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda ICANN

1 0

Bittorrent, Starcraft II , and Diablo III
by Lloyd Parkes 20 Mar '12

20 Mar '12

What sort of traffic increases did people see when Starcraft II was released and what are people expecting with Diablo III? I'm wondering how much impact boxed game sales have because I noticed that Rage was 21GB, but Steam installed that off three DVDs if you had bought the boxed game. Digital downloads and P2P may be nice, but to paraphrase Andy Tanenbaum, never underestimate the bandwidth of a courier van full of DVDs. Cheers Lloyd Parkes | Systems Consultant, Open Systems | Inland Revenue T. +64 4 890 2437 | F. +64 4 890 4704 This email and any attachment may contain confidential information. If you have received this email or any attachment in error, please delete the email / attachment, and notify the sender. Please do not copy, disclose or use the email, any attachment, or any information contained in them. Consider the environment before deciding to print: avoid printing if you can, or consider printing double-sided. Visit us online at ird.govt.nz

1 0

NTIA vs ICANN
by Tristram Cheer 18 Mar '12

18 Mar '12

Hey All, Has anyone else seen the NTIA playing chicken with ICANN over the IANA? NTIA came out about 12 hours ago saying that it had not received a proposal that it deemed to fit it's criteria for the IANA RFP, It sounds like they are still annoyed at the new gTLD policies and the .xxx gTLD saga. Does anyone here believe that the IANA contract might move to someone else or is just posturing while waiting for a new CEO at ICANN who might work with NTIA better? From what I can understand the heart of the issue is NTIA want ICANN to prove that any new gTLD is in the best public interest but also be "approved" by the GAC I have to wonder how much longer the rest of the world will tolerate US interference in the DNS system such as the many recent examples of domain takedowns before action is taken, As messy as a "fork" would be of DNS the US government seems to be hell bent on putting any domain anywhere in the world under US law, Which I'm sure most can agree is bad thing. -- Tristram Cheer Network Architect - Most problems are the result of previous solutions... Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 | 53 Port Road, Whangarei tristram.cheer(a)ubergroup.co.nz <mailto:tristram.cheer(a)ubergroup.co.nz> |www.ubergroup.co.nz <http://www.ubergroup.co.nz> <http://ubergroup.co.nz/fb> <https://twitter.com/#!/ubergroupltd>

9 9

traffic shaping
by Jodi 14 Mar '12

14 Mar '12

Hi All Currently we're running a couple of Packeteers (one for each of our upstreams) to give users a fair slice of the pie. However they're starting to wilt under the increased load and it's time to look at replacing. I've been looking around at some of the more popular appliances that I am aware of (Packeteer, Exinda, Netequalizer), however I don't want to buy a lemon. The other thought was to shape directly on the routers - have a couple of Cisco 2821's at our borders. I'm familiar with the shaping process but have never attempted on Cisco kit before so don't want to start down that path if it's the wrong way to go (especially as I would be the only one who could manage it and I like the occasional day off). My main focus to is to shape at the border by IP for different classes based on our plans e.g. burst to 4meg, 2meg dedicated, 2.5 burst to 10, etc Secondary to that is reporting and 3rdly QoS Any and all advice welcome, on and off list Cheers Jodi -- Jodi Thomson Network & Systems Engineer [Description: Description: Wasp New Zealand] Ph +64-6-8355800 Fax +64-6-8355811 Mob +64-21-903712 E-Mail jodi(a)team.waspnet.co.nz www.waspnet.co.nz<http://www.waspnet.co.nz/>

9 17

NZRR Route Registry Update
by NZRR Database Notifications 13 Mar '12

13 Mar '12

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: AS9439:RS-ROUTES:AS2687 descr: advertised to AS9439 by at&t - AS2687 members: 124.248.128.0/20^20-29, 103.5.80.0/22^22-29, 202.27.216.0/22^22-29, 202.36.192.0/22^22-29, 202.169.192.0/22^22-29, 210.79.48.0/22^22-29, 32.114.24.0/23^23-29, 32.234.80.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.27.136.0/23^23-29, 202.36.68.0/23^23-29, 202.37.70.0/23^23-29, 202.169.198.0/23^23-29, 202.169.202.0/23^23-29, 202.169.206.0/23^23-29, 202.169.212.0/23^23-29, 202.175.142.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 192.88.190.0/24^24-29, 192.203.216.0/24^24-29, 194.196.251.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.20.92.0/24^24-29, 202.27.77.0/24^24-29, 202.27.83.0/24^24-29, 202.27.160.0/24^24-29, 202.27.222.0/24^24-29, 202.27.236.0/24^24-29, 202.27.247.0/24^24-29, 202.27.251.0/24^24-29, 202.36.12.0/24^24-29, 202.36.29.0/24^24-29, 202.36.43.0/24^24-29, 202.36.75.0/24^24-29, 202.36.80.0/24^24-29, 202.36.154.0/24^24-29, 202.36.198.0/24^24-29, 202.37.68.0/24^24-29, 202.37.167.0/24^24-29, 202.37.168.0/24^24-29, 202.37.187.0/24^24-29, 202.37.254.0/24^24-29, 202.49.189.0/24^24-29, 202.49.216.0/24^24-29, 202.50.240.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.85.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 202.169.196.0/24^24-29, 202.169.201.0/24^24-29, 202.169.205.0/24^24-29, 202.169.209.0/24^24-29, 202.169.223.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20111213 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS2687 descr: advertised to AS9439 by AT&T - AS2687 members: 103.5.80.0/22^22-29, 202.36.192.0/22^22-29, 32.114.24.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.36.68.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 32.234.81.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.36.29.0/24^24-29, 202.36.80.0/24^24-29, 202.37.254.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120314 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] [Fwd: [OPSAWG]draft-weil-shared-transition-space-request]
by Scott Weeks 13 Mar '12

13 Mar '12

----- brian.e.carpenter(a)gmail.com wrote: ------ From: Brian E Carpenter <brian.e.carpenter(a)gmail.com> In other words, 100.64.0.0/10 is now legalised bogon space and needs to be filtered just like RFC 1918 space. --------------------------------------------------- ------------------- Original Message ------------- Subject: [OPSAWG] raft-weil-shared-transition-space-request/ From: Bradner, Scott <sob(a)harvard.edu> fyi - the address block has been registered see http://whois.arin.net/rest/net/NET-100-64-0-0-1/pft ---------------------------------------------------- I guess this means the "final bogon list" RFC (or whatever the correct name is; I couldn't find it) needs to be updated. scott ----------------------- ------------------ -------------------

2 1

[Fwd: [OPSAWG]draft-weil-shared-transition-space-request]
by Brian E Carpenter 13 Mar '12

13 Mar '12

In other words, 100.64.0.0/10 is now legalised bogon space and needs to be filtered just like RFC 1918 space. Brian (please do not shoot messenger) -------- Original Message -------- Subject: [OPSAWG] raft-weil-shared-transition-space-request/ Date: Wed, 14 Mar 2012 00:38:33 +0000 From: Bradner, Scott <sob(a)harvard.edu> To: opsawg(a)ietf.org <opsawg(a)ietf.org> fyi - the address block has been registered see http://whois.arin.net/rest/net/NET-100-64-0-0-1/pft thanks to all who worked so hard on this Scott _______________________________________________ OPSAWG mailing list OPSAWG(a)ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- Regards Brian Carpenter

1 0

Async Routing across ape to pipe return via vocus & Internode speedtest
by Barry Murphy 12 Mar '12

12 Mar '12

Hey Guys, I just saw Glen Eustace's post which reminded me of an issue we have seen of late with regards to 'my internet seems slow'. Just wondering if anyone else has seen this similar issue since PIPE joined the APE, then again it's not just PIPE, but a mixture of Oz providers accepting traffic over the APE and then returning the transit via international links such as Vocus. I have a few customers that buy dedicated international and dedicated domestic bandwidth. These customers have a stub address that resides in the Domestic VRF & another stub in the International VRF. Since PIPE came on-board we have noticed that customers trying to do a whois (whois.apnic.net) using their router that connects the stubs, that the traffic goes out thinking its Domestic, but then gets no response because it attempts to return in via the International (Transit) VRF to which has no access to stubs in the Domestic VRF. Another issue we see where 'slow' comes into play is internode have recently been added to speedtest.net as a NZ speedtest server in Auckland. While tracing to this node it does appear to go across APE, the return path is via Vocus. When a customer attempts a speed test and they see they are only able to obtain say 30mbps rather than the 100mbps they would expect from a "NZ" server they start thinking something is broken, when actually it's because the server is International and they are in a pool of bandwidth. I've tried to contact internode & so has a colleague of mine but with no luck. We've tried to pre-pend AS's to the vocus communities but again this hasnt helped at all. Just wondering if anyone else has seen issues arise since ASYNC routing between Oz & NZ, to do with either STUBs getting no internet due to VRF nature, or these 'slow' speeds being reported. thanks Barry

10 21