Re: AT&T UVERSE Native IPv6, a HOWTO
On 11/23/2013 1:22 AM, Andrew D Kirch wrote: > Special thanks to Alexander from AT&T's "Tier-2" dept, though my > suspicion is that that is not where he works, as he seems > exceptionally clueful. > Additional thanks to Owen DeLong who finally got me off my ass to > actually do this, I'll see you in the sky! > > Ok, is this core routing? not really, but it's nice to see a major > clue injection over at AT&T Uverse. I'm using this to document the > MASSIVE bureaucratic PITA which is getting native IPv6 on uverse. > You'll start from the default service on a 2wire "modem" (for values > of modem that equate to profanity). If you have the Motorola NVG589, > count yourself lucky and skip most of these steps. > > Abandon all hope ye who enter here > > Step 1: contact AT&T Uverse support and complain that you need IPv6 > (because we all need it, I in fact do for work). > Step 2: general confusion as the level 1 droid doesn't know what IPv6 > is, politely request to be transferred to tier 2 > step 3: you will be told that tier 2 is a paid service, invoke the > almighty FCC and ask to speak with a supervisor, expect a long hold here. > step 4: you arrive at tier 2, mention that IPv6 won't work on your > 2wire and that AT&T has broken your protocol 41 tunnel with tunnel broker here, usually HE> > step 5: you'll need to get your 2wire replaced with a Motorola > NVG589. Again you will be threatened with a cost to upgrade, mine was > waived due to the work requirement. I'd guess some additional > complaining and escalation will get this fee waived. My recollection > was it was $100. The new modem is good news for quite a few reasons, > the 2wire sucks, the Motorola sucks significantly less, and has a > built in battery backup, but mine lacked the battery. > step 6: you'll receive the motorola by mail, or have a tech install > it, they actually had a tech in my area and I had an AT&T tech at my > door in less than 20 minutes from when I got off the phone with tier-2 > (I about died from the shock). > step 7: configure the motorola (192.168.1.254) for passthrough, > DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, > wireless, etc. > Step 8: reboot to push the public IP to your real router. > step 9: head over to the Motorola's home network tab, and in the > status window you'll see: > > >IPv6 > > Status Available > Global IPv6 Address 2602:306:cddd:::1/64 > Link-local IPv6 Address fe80::923e:abff::7e40 > Router Advertisement Prefix 2602:306:cddd:::/64 > IPV6 Delegated LAN Prefix 2602:306:cddd::: > 2602:306:cddd::: > > > In reality additional poking leads me to believe AT&T gives you a > rather generous /60, but how to use it? > step 10: set up dhcpv6, example for mikrotik follows (but should be > easily convertible to nearly any router): > > /ipv6> export > # dec/31/2001 20:26:03 by RouterOS 6.6 > # software id = 5F2Y-X73L > # > /ipv6 address > add address=2602:306:cddd:::1 from-pool=AT&T interface=bridge1 > /ipv6 dhcp-client > add add-default-route=yes interface=ether10 pool-name=AT&T > > I hope that this is of help to someone. > > Andrew > Are you actually getting a /60 in your IPv6 pool in routerOS? I haven't seen it work and Comcast claims a /60 via DHCP-PD is available everywhere now. # nov/23/2013 07:09:08 by RouterOS 6.6 /ipv6 address add address=2601:b:beXX:XXX::1 from-pool=comcastv6-pd interface=ether2-master-local /ipv6 dhcp-client add add-default-route=yes interface=ether1-wan pool-name=comcastv6-pd use-peer-dns=no /ipv6 nd set [ find default=yes ] disabled=yes add hop-limit=64 interface=ether2-master-local reachable-time=5m [admin@MikroTik] /ipv6> pool print Flags: D - dynamic # NAME PREFIX PREFIX-LENGTH EXPIRES-AFTER 0 D comcastv6-pd 2601:b:beXX:XXX::/64 64 3d23h54m48s
Re: AT&T UVERSE Native IPv6, a HOWTO
On 22 November 2013 22:22, Andrew D Kirch wrote: > Status Available > Global IPv6 Address 2602:306:cddd:::1/64 > Link-local IPv6 Address fe80::923e:abff::7e40 > Router Advertisement Prefix 2602:306:cddd:::/64 > IPV6 Delegated LAN Prefix 2602:306:cddd::: > 2602:306:cddd::: I don't believe this is native IPv6; it's probably still their 6rd, which has, in fact, been live since at least February 2012, i.e. for close to two years at this point. http://tu.cnst.su/post/16958139578/at-t-u-verse-6rd-in-santa-clara-county http://www.tunnelbroker.net/forums/index.php?topic=2293.0 And, yes, AT&T is probably still keeping this whole thing a secret. C.
Re: AT&T UVERSE Native IPv6, a HOWTO
Now if Time Warner Cable would get their act together in Ohio (looks at them :) ) On Sat, Nov 23, 2013 at 1:25 AM, Mehmet Akcin wrote: > Yay! Thank you very much. > > You should write up something to their support forums! > > Mehmet > > > On Nov 22, 2013, at 22:22, Andrew D Kirch wrote: > > > > Special thanks to Alexander from AT&T's "Tier-2" dept, though my > suspicion is that that is not where he works, as he seems exceptionally > clueful. > > Additional thanks to Owen DeLong who finally got me off my ass to > actually do this, I'll see you in the sky! > > > > Ok, is this core routing? not really, but it's nice to see a major clue > injection over at AT&T Uverse. I'm using this to document the MASSIVE > bureaucratic PITA which is getting native IPv6 on uverse. You'll start > from the default service on a 2wire "modem" (for values of modem that > equate to profanity). If you have the Motorola NVG589, count yourself > lucky and skip most of these steps. > > > > Abandon all hope ye who enter here > > > > Step 1: contact AT&T Uverse support and complain that you need IPv6 > (because we all need it, I in fact do for work). > > Step 2: general confusion as the level 1 droid doesn't know what IPv6 > is, politely request to be transferred to tier 2 > > step 3: you will be told that tier 2 is a paid service, invoke the > almighty FCC and ask to speak with a supervisor, expect a long hold here. > > step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire > and that AT&T has broken your protocol 41 tunnel with here, usually HE> > > step 5: you'll need to get your 2wire replaced with a Motorola NVG589. > Again you will be threatened with a cost to upgrade, mine was waived due > to the work requirement. I'd guess some additional complaining and > escalation will get this fee waived. My recollection was it was $100. The > new modem is good news for quite a few reasons, the 2wire sucks, the > Motorola sucks significantly less, and has a built in battery backup, but > mine lacked the battery. > > step 6: you'll receive the motorola by mail, or have a tech install it, > they actually had a tech in my area and I had an AT&T tech at my door in > less than 20 minutes from when I got off the phone with tier-2 (I about > died from the shock). > > step 7: configure the motorola (192.168.1.254) for passthrough, > DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, > wireless, etc. > > Step 8: reboot to push the public IP to your real router. > > step 9: head over to the Motorola's home network tab, and in the status > window you'll see: > > > > > > IPv6 > > > > StatusAvailable > > Global IPv6 Address2602:306:cddd:::1/64 > > Link-local IPv6 Addressfe80::923e:abff::7e40 > > Router Advertisement Prefix2602:306:cddd:::/64 > > IPV6 Delegated LAN Prefix2602:306:cddd::: > > 2602:306:cddd::: > > > > > > In reality additional poking leads me to believe AT&T gives you a rather > generous /60, but how to use it? > > step 10: set up dhcpv6, example for mikrotik follows (but should be > easily convertible to nearly any router): > > > > /ipv6> export > > # dec/31/2001 20:26:03 by RouterOS 6.6 > > # software id = 5F2Y-X73L > > # > > /ipv6 address > > add address=2602:306:cddd:::1 from-pool=AT&T interface=bridge1 > > /ipv6 dhcp-client > > add add-default-route=yes interface=ether10 pool-name=AT&T > > > > I hope that this is of help to someone. > > > > Andrew > > > >
Re: AT&T UVERSE Native IPv6, a HOWTO
Yay! Thank you very much. You should write up something to their support forums! Mehmet > On Nov 22, 2013, at 22:22, Andrew D Kirch wrote: > > Special thanks to Alexander from AT&T's "Tier-2" dept, though my suspicion is > that that is not where he works, as he seems exceptionally clueful. > Additional thanks to Owen DeLong who finally got me off my ass to actually do > this, I'll see you in the sky! > > Ok, is this core routing? not really, but it's nice to see a major clue > injection over at AT&T Uverse. I'm using this to document the MASSIVE > bureaucratic PITA which is getting native IPv6 on uverse. You'll start from > the default service on a 2wire "modem" (for values of modem that equate to > profanity). If you have the Motorola NVG589, count yourself lucky and skip > most of these steps. > > Abandon all hope ye who enter here > > Step 1: contact AT&T Uverse support and complain that you need IPv6 (because > we all need it, I in fact do for work). > Step 2: general confusion as the level 1 droid doesn't know what IPv6 is, > politely request to be transferred to tier 2 > step 3: you will be told that tier 2 is a paid service, invoke the almighty > FCC and ask to speak with a supervisor, expect a long hold here. > step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire and > that AT&T has broken your protocol 41 tunnel with usually HE> > step 5: you'll need to get your 2wire replaced with a Motorola NVG589. Again > you will be threatened with a cost to upgrade, mine was waived due to the > work requirement. I'd guess some additional complaining and escalation will > get this fee waived. My recollection was it was $100. The new modem is good > news for quite a few reasons, the 2wire sucks, the Motorola sucks > significantly less, and has a built in battery backup, but mine lacked the > battery. > step 6: you'll receive the motorola by mail, or have a tech install it, they > actually had a tech in my area and I had an AT&T tech at my door in less than > 20 minutes from when I got off the phone with tier-2 (I about died from the > shock). > step 7: configure the motorola (192.168.1.254) for passthrough, > DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, wireless, > etc. > Step 8: reboot to push the public IP to your real router. > step 9: head over to the Motorola's home network tab, and in the status > window you'll see: > > > IPv6 > > StatusAvailable > Global IPv6 Address2602:306:cddd:::1/64 > Link-local IPv6 Addressfe80::923e:abff::7e40 > Router Advertisement Prefix2602:306:cddd:::/64 > IPV6 Delegated LAN Prefix2602:306:cddd::: > 2602:306:cddd::: > > > In reality additional poking leads me to believe AT&T gives you a rather > generous /60, but how to use it? > step 10: set up dhcpv6, example for mikrotik follows (but should be easily > convertible to nearly any router): > > /ipv6> export > # dec/31/2001 20:26:03 by RouterOS 6.6 > # software id = 5F2Y-X73L > # > /ipv6 address > add address=2602:306:cddd:::1 from-pool=AT&T interface=bridge1 > /ipv6 dhcp-client > add add-default-route=yes interface=ether10 pool-name=AT&T > > I hope that this is of help to someone. > > Andrew >
AT&T UVERSE Native IPv6, a HOWTO
Special thanks to Alexander from AT&T's "Tier-2" dept, though my suspicion is that that is not where he works, as he seems exceptionally clueful. Additional thanks to Owen DeLong who finally got me off my ass to actually do this, I'll see you in the sky! Ok, is this core routing? not really, but it's nice to see a major clue injection over at AT&T Uverse. I'm using this to document the MASSIVE bureaucratic PITA which is getting native IPv6 on uverse. You'll start from the default service on a 2wire "modem" (for values of modem that equate to profanity). If you have the Motorola NVG589, count yourself lucky and skip most of these steps. Abandon all hope ye who enter here Step 1: contact AT&T Uverse support and complain that you need IPv6 (because we all need it, I in fact do for work). Step 2: general confusion as the level 1 droid doesn't know what IPv6 is, politely request to be transferred to tier 2 step 3: you will be told that tier 2 is a paid service, invoke the almighty FCC and ask to speak with a supervisor, expect a long hold here. step 4: you arrive at tier 2, mention that IPv6 won't work on your 2wire and that AT&T has broken your protocol 41 tunnel with broker here, usually HE> step 5: you'll need to get your 2wire replaced with a Motorola NVG589. Again you will be threatened with a cost to upgrade, mine was waived due to the work requirement. I'd guess some additional complaining and escalation will get this fee waived. My recollection was it was $100. The new modem is good news for quite a few reasons, the 2wire sucks, the Motorola sucks significantly less, and has a built in battery backup, but mine lacked the battery. step 6: you'll receive the motorola by mail, or have a tech install it, they actually had a tech in my area and I had an AT&T tech at my door in less than 20 minutes from when I got off the phone with tier-2 (I about died from the shock). step 7: configure the motorola (192.168.1.254) for passthrough, DHCPS-dynamic, disable the firewall, the "advanced" firewall, hpna, wireless, etc. Step 8: reboot to push the public IP to your real router. step 9: head over to the Motorola's home network tab, and in the status window you'll see: IPv6 Status Available Global IPv6 Address 2602:306:cddd:::1/64 Link-local IPv6 Address fe80::923e:abff::7e40 Router Advertisement Prefix 2602:306:cddd:::/64 IPV6 Delegated LAN Prefix 2602:306:cddd::: 2602:306:cddd::: In reality additional poking leads me to believe AT&T gives you a rather generous /60, but how to use it? step 10: set up dhcpv6, example for mikrotik follows (but should be easily convertible to nearly any router): /ipv6> export # dec/31/2001 20:26:03 by RouterOS 6.6 # software id = 5F2Y-X73L # /ipv6 address add address=2602:306:cddd:::1 from-pool=AT&T interface=bridge1 /ipv6 dhcp-client add add-default-route=yes interface=ether10 pool-name=AT&T I hope that this is of help to someone. Andrew
RE: NAT64 and matching identities
Someone from Alexa really needs to answer how that list is created because their web site discussion is way too hand-wavy, but given that neither of those appear to be currently valid names, and 1.1.1.1 is on the list at all, there must be some measure of cross link and redirection occurrences. For the entire top-1m, I show today's file has 2815 as dotted-quad. In the top 50,000 there are 1790 with "no IPv4 no IPv6". Clearly they don't bother to prune the list for validity. ~4% of the next 25,000 names are dead (50,000-75,000), and one can only guess that as you get further down the list the percentage of dead names will continue to go up. I have a full 1M run in process, but would not count on it completing before Monday. Just to add a level of 'extra effort' to the process, I increased the number of attempts to 10, and the time between attempts to 10 seconds. With that, dead names in the top 1000: akamaihd.netno IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6 delta-search.comno IPv4 no IPv6 bannersdontwork.com no IPv4 no IPv6 cloudfront.net no IPv4 no IPv6 doorblog.jp no IPv4 no IPv6 uimserv.net no IPv4 no IPv6 linksynergy.com no IPv4 no IPv6 lipixeltrack.comno IPv4 no IPv6 australianbrewingcompany.comno IPv4 no IPv6 searchfun.inno IPv4 no IPv6 greatappsdownload.com no IPv4 no IPv6 klikbca.com no IPv4 no IPv6 jobfindgold.infono IPv4 no IPv6 adnxs.com no IPv4 no IPv6 rakuten.ne.jp no IPv4 no IPv6 sweetpacks-search.com no IPv4 no IPv6 yomiuri.co.jp no IPv4 no IPv6 incredibar-search.com no IPv4 no IPv6 searchgol.com no IPv4 no IPv6 livedoor.bizno IPv4 no IPv6 workercn.cn no IPv4 no IPv6 FWIW: in the top 50,000, I show 1525 "has IPv4 has IPv6" & 0 "no IPv4 has IPv6". In other words, there are more dead names than there are records, and there are not any IPv6-only sites in that group. Tony > -Original Message- > From: Owen DeLong [mailto:o...@delong.com] > Sent: Friday, November 22, 2013 1:48 PM > To: Tony Hain > Cc: joel jaeggli; valdis.kletni...@vt.edu; NANOG List > Subject: Re: NAT64 and matching identities > > So one has to wonder how those names made it into the top 100 list if it's > supposed to be a top 100 web sites, since they are obviously not web sites. > (at least in the case of the two in the top 100) > > Owen > > On Nov 22, 2013, at 1:28 PM, Tony Hain wrote: > > > The only thing it explicitly strips out are dotted-quads, which don't > > occur until # 4255. The code makes five passes at getaddrinfo() for > > IPv4 before giving up, and then it checks for a leading www and if > > that exists it strips it off and does the 5 tries loop again, then > > later the same process for IPv6. For the top 100 run: > > akamaihd.netno IPv4 no IPv6 > > bp.blogspot.com no IPv4 no IPv6 > > > > FWIW ::: > > Dotted-quad's in the top 10,000 > > 4255,92.242.195.24 > > 4665,1.1.1.1 > > 5079,92.242.195.231 > > 6130,1.254.254.254 > > 9518,208.98.30.70 > > > >> whois 92.242.195.24 > > ... > > netname:Respina > > descr: BroadBand IP Pool > > country:IR > > ... > > route: 92.242.195.0/24 > > > > Respina BroadBand IP Pool in the top 100,000 > > 4255,92.242.195.24 > > 5079,92.242.195.231 > > 10059,92.242.195.233 > > 23912,92.242.195.30 > > 31520,92.242.195.111 > > 35867,92.242.195.235 > > 95233,92.242.195.129 > > > > > >> -Original Message- > >> From: Owen DeLong [mailto:o...@delong.com] > >> Sent: Friday, November 22, 2013 12:16 PM > >> To: joel jaeggli > >> Cc: valdis.kletni...@vt.edu; Tony Hain; NANOG List > >> Subject: Re: NAT64 and matching identities > >> > >> It would be way more than 2 if it were CNAME, methinks. > >> > >> Owen > >> > >> On Nov 22, 2013, at 12:12 PM, joel jaeggli wrote: > >> > >>> On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote: > On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: > > > The top 100 websites: records and IPv6 connectivity > > count with A: 98 ( 98.000%) > > count with : 30 ( 30.000%) > > Of the 30 hosts with records, testing connectivity to TCP/80: > >count with IPv6 ok: 30 (100.000%) > > Statistics whoopsie, or are there actually 2 sites in the top100 > that are IPv6-only? > >>> > >>> IN CNAME ? or is that being accounted for. > >>> > >>> > >>>
BGP Update Report
BGP Update Report Interval: 14-Nov-13 -to- 21-Nov-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS754579543 2.7% 37.5 -- TPG-INTERNET-AP TPG Telecom Limited 2 - AS30693 49031 1.7% 91.1 -- SERVERHUB-PHOENIX - Eonix Corporation 3 - AS840240599 1.4% 19.4 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS982939167 1.3% 25.4 -- BSNL-NIB National Internet Backbone 5 - AS453832376 1.1% 59.1 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS702930570 1.0% 7.2 -- WINDSTREAM - Windstream Communications Inc 7 - AS28573 24608 0.8% 7.1 -- NET Serviços de Comunicação S.A. 8 - AS13118 23281 0.8% 529.1 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS29990 22641 0.8% 754.7 -- ASN-APPNEXUS - AppNexus, Inc 10 - AS38457 21312 0.7% 234.2 -- HNS-AS-AP Honesty Net Solution (I) Pvt Ltd 11 - AS36753 19597 0.7%6532.3 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 12 - AS15003 19508 0.7% 22.6 -- NOBIS-TECH - Nobis Technology Group, LLC 13 - AS35873 18792 0.6%1708.4 -- MOVE-NETWORKS - Move Networks, inc. 14 - AS17974 18608 0.6% 6.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS477518460 0.6% 142.0 -- GLOBE-TELECOM-AS Globe Telecoms 16 - AS27738 18250 0.6% 31.7 -- Ecuadortelecom S.A. 17 - AS11976 15374 0.5% 75.4 -- FIDN - Fidelity Communication International Inc. 18 - AS432315282 0.5% 5.1 -- TWTC - tw telecom holdings, inc. 19 - AS36998 14333 0.5% 7.7 -- SDN-MOBITEL 20 - AS3 14294 0.5%3394.0 -- RAFFEL-INTERNET Raffel Internet B.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS36753 19597 0.7%6532.3 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 2 - AS57130 11844 0.4%3948.0 -- SECPRAL-AS Secpral COM SRL 3 - AS624312000 0.1%2000.0 -- NCSC-IE-AS National Cyber Security Centre 4 - AS35873 18792 0.6%1708.4 -- MOVE-NETWORKS - Move Networks, inc. 5 - AS544657528 0.2%1505.6 -- QPM-AS-1 - QuickPlay Media Inc. 6 - AS31269 0.0%3453.0 -- RAFFEL-INTERNET Raffel Internet B.V. 7 - AS6775 7181 0.2%1196.8 -- BACKBONE_EHF_EUROPE Backbone ehf 8 - AS7202 8622 0.3% 862.2 -- FAMU - Florida A & M University 9 - AS49742 827 0.0% 827.0 -- IWT-NETWORK LLC "Iwt" Company 10 - AS57851 771 0.0% 771.0 -- GENESIS-HOUSING-ASSOCIATION-LIMITED Genesis Housing Association Limited 11 - AS29990 22641 0.8% 754.7 -- ASN-APPNEXUS - AppNexus, Inc 12 - AS523551343 0.1% 671.5 -- Jalasoft Corp. 13 - AS37367 667 0.0% 667.0 -- CALLKEY 14 - AS119473186 0.1% 637.2 -- Cablenett Limited 15 - AS57201 578 0.0% 578.0 -- EDF-AS Estonian Defence Forces 16 - AS13118 23281 0.8% 529.1 -- ASN-YARTELECOM OJSC Rostelecom 17 - AS374537206 0.2% 514.7 -- VODACOM-CONGO 18 - AS3 14294 0.5%3394.0 -- RAFFEL-INTERNET Raffel Internet B.V. 19 - AS22688 855 0.0% 427.5 -- DOLGENCORP - Dollar General Corporation 20 - AS503371230 0.0% 410.0 -- TETTAS-AS TETTAS SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 23044 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.220.0/22 22568 0.7% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 3 - 8.20.2.0/24 18763 0.6% AS35873 -- MOVE-NETWORKS - Move Networks, inc. 4 - 194.9.23.0/24 11835 0.4% AS57130 -- SECPRAL-AS Secpral COM SRL 5 - 12.68.46.0/24 9850 0.3% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 6 - 64.240.174.0/249745 0.3% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 9 - 14.202.160.0/228351 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 10 - 67.210.190.0/237834 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 11 - 206.152.15.0/247522 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 12 - 192.58.232.0/247476 0.2% AS6629 -- NOAA-AS - NOAA 13 - 79.134.225.0/247093 0.2% AS6775 -- BACKBONE_EHF_EUROPE Backbone ehf 14 - 38.87.227.0/24 6937 0.2% AS37453 -- VODACOM-CONGO 15 - 220.244.72.0/216858 0.2% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 16 - 67.210.188.0/236746 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 17 - 110.175.88.0/225507 0.2% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 18 - 220.244.0.0/22 5445 0.2% AS7545 -- TPG-INTERNET-AP TPG Telecom
The Cidr Report
This report has been generated at Fri Nov 22 21:13:32 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
15-11-13485585 273250
16-11-13484011 273668
17-11-13483814 273917
18-11-13484111 272263
19-11-13484362 272400
20-11-13484547 272722
21-11-13484317 272975
22-11-13483927 273289
AS Summary
45683 Number of ASes in routing system
18756 Number of ASes announcing only one prefix
4209 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
118835968 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 22Nov13 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 484535 273295 21124043.6% All ASes
AS28573 3392 89 330397.4% NET Serviços de Comunicação
S.A.
AS6389 3042 56 298698.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS17974 2713 173 254093.6% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS7029 4209 1739 247058.7% WINDSTREAM - Windstream
Communications Inc
AS22773 2211 158 205392.9% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2931 949 198267.6% KIXS-AS-KR Korea Telecom
AS18881 1647 31 161698.1% Global Village Telecom
AS36998 1864 375 148979.9% SDN-MOBITEL
AS18566 2054 566 148872.4% MEGAPATH5-US - MegaPath
Corporation
AS4323 2960 1527 143348.4% TWTC - tw telecom holdings,
inc.
AS7303 1729 470 125972.8% Telecom Argentina S.A.
AS1785 2058 836 122259.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1792 582 121067.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS10620 2671 1469 120245.0% Telmex Colombia S.A.
AS7552 1194 139 105588.4% VIETEL-AS-AP Vietel
Corporation
AS22561 1241 221 102082.2% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS9829 1544 659 88557.3% BSNL-NIB National Internet
Backbone
AS35908 913 91 82290.0% VPLSNET - Krypt Technologies
AS7545 2113 1304 80938.3% TPG-INTERNET-AP TPG Telecom
Limited
AS18101 982 180 80281.7% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1144 400 74465.0% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS8151 1365 637 72853.3% Uninet S.A. de C.V.
AS24560 1095 368 72766.4% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS701 1509 786 72347.9% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS6983 1295 580 71555.2% ITCDELTA - ITC^Deltacom
AS13977 853 144 70983.1% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS6147 790 108 68286.3% Telefonica del Peru S.A.A.
AS4780 1018 348 67065.8% SEEDNET Digital United Inc.
AS855725 56 66992.3% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS26615 755
Re: NAT64 and matching identities
So one has to wonder how those names made it into the top 100 list if it’s supposed to be a top 100 web sites, since they are obviously not web sites. (at least in the case of the two in the top 100) Owen On Nov 22, 2013, at 1:28 PM, Tony Hain wrote: > The only thing it explicitly strips out are dotted-quads, which don't occur > until # 4255. The code makes five passes at getaddrinfo() for IPv4 before > giving up, and then it checks for a leading www and if that exists it strips > it off and does the 5 tries loop again, then later the same process for > IPv6. For the top 100 run: > akamaihd.netno IPv4 no IPv6 > bp.blogspot.com no IPv4 no IPv6 > > FWIW ::: > Dotted-quad's in the top 10,000 > 4255,92.242.195.24 > 4665,1.1.1.1 > 5079,92.242.195.231 > 6130,1.254.254.254 > 9518,208.98.30.70 > >> whois 92.242.195.24 > ... > netname:Respina > descr: BroadBand IP Pool > country:IR > ... > route: 92.242.195.0/24 > > Respina BroadBand IP Pool in the top 100,000 > 4255,92.242.195.24 > 5079,92.242.195.231 > 10059,92.242.195.233 > 23912,92.242.195.30 > 31520,92.242.195.111 > 35867,92.242.195.235 > 95233,92.242.195.129 > > >> -Original Message- >> From: Owen DeLong [mailto:o...@delong.com] >> Sent: Friday, November 22, 2013 12:16 PM >> To: joel jaeggli >> Cc: valdis.kletni...@vt.edu; Tony Hain; NANOG List >> Subject: Re: NAT64 and matching identities >> >> It would be way more than 2 if it were CNAME, methinks. >> >> Owen >> >> On Nov 22, 2013, at 12:12 PM, joel jaeggli wrote: >> >>> On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote: On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: > The top 100 websites: records and IPv6 connectivity > count with A: 98 ( 98.000%) > count with : 30 ( 30.000%) > Of the 30 hosts with records, testing connectivity to TCP/80: >count with IPv6 ok: 30 (100.000%) Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only? >>> >>> IN CNAME ? or is that being accounted for. >>> >>> >>>
RE: NAT64 and matching identities
The only thing it explicitly strips out are dotted-quads, which don't occur until # 4255. The code makes five passes at getaddrinfo() for IPv4 before giving up, and then it checks for a leading www and if that exists it strips it off and does the 5 tries loop again, then later the same process for IPv6. For the top 100 run: akamaihd.netno IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6 FWIW ::: Dotted-quad's in the top 10,000 4255,92.242.195.24 4665,1.1.1.1 5079,92.242.195.231 6130,1.254.254.254 9518,208.98.30.70 > whois 92.242.195.24 ... netname:Respina descr: BroadBand IP Pool country:IR ... route: 92.242.195.0/24 Respina BroadBand IP Pool in the top 100,000 4255,92.242.195.24 5079,92.242.195.231 10059,92.242.195.233 23912,92.242.195.30 31520,92.242.195.111 35867,92.242.195.235 95233,92.242.195.129 > -Original Message- > From: Owen DeLong [mailto:o...@delong.com] > Sent: Friday, November 22, 2013 12:16 PM > To: joel jaeggli > Cc: valdis.kletni...@vt.edu; Tony Hain; NANOG List > Subject: Re: NAT64 and matching identities > > It would be way more than 2 if it were CNAME, methinks. > > Owen > > On Nov 22, 2013, at 12:12 PM, joel jaeggli wrote: > > > On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote: > >> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: > >> > >>> The top 100 websites: records and IPv6 connectivity > >>> count with A: 98 ( 98.000%) > >>>count with : 30 ( 30.000%) > >>> Of the 30 hosts with records, testing connectivity to TCP/80: > >>> count with IPv6 ok: 30 (100.000%) > >> > >> Statistics whoopsie, or are there actually 2 sites in the top100 that > >> are IPv6-only? > > > > IN CNAME ? or is that being accounted for. > > > > > >
Re: NAT64 and matching identities
It would be way more than 2 if it were CNAME, methinks. Owen On Nov 22, 2013, at 12:12 PM, joel jaeggli wrote: > On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote: >> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: >> >>> The top 100 websites: records and IPv6 connectivity >>> count with A: 98 ( 98.000%) >>>count with : 30 ( 30.000%) >>> Of the 30 hosts with records, testing connectivity to TCP/80: >>> count with IPv6 ok: 30 (100.000%) >> >> Statistics whoopsie, or are there actually 2 sites in the top100 >> that are IPv6-only? > > IN CNAME ? or is that being accounted for. > > >
Re: NAT64 and matching identities
On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote: > On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: > >> The top 100 websites: records and IPv6 connectivity >>count with A: 98 ( 98.000%) >> count with : 30 ( 30.000%) >> Of the 30 hosts with records, testing connectivity to TCP/80: >> count with IPv6 ok: 30 (100.000%) > > Statistics whoopsie, or are there actually 2 sites in the top100 > that are IPv6-only? IN CNAME ? or is that being accounted for. signature.asc Description: OpenPGP digital signature
Re: NAT64 and matching identities
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said: > The top 100 websites: records and IPv6 connectivity >count with A: 98 ( 98.000%) > count with : 30 ( 30.000%) > Of the 30 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 30 (100.000%) Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only? pgp4FQD9GYm_F.pgp Description: PGP signature
Re: NAT64 and matching identities
I question how one can have a top 100 website without an A record. I am inclined to believe there is a bug in there somewhere. Owen On Nov 22, 2013, at 10:18 AM, Tony Hain wrote: > Lee Howard wrote: > ... > There is obviously a long tail of ip4 destinations, but nearly all > of 500 of the Alexa global 500 have ip6 listeners, Do you have a data source for that? I see no indication of IPv6 listeners on 85% of the top sites. >>> >>> A slightly different metric, 44% of USA content available on IPv6: >>> >>> http://6lab.cisco.com/stats/ >> >> Right, weighted by DNS queries. >> Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us >> and http://www.employees.org/~dwing/-stats/ >> >> Not equivalent to "nearly all of Alexa 500." > > Using a derivative of Dan Wings code from a couple of years back I get: > > The top 5 websites: records and IPv6 connectivity > count with A:5 (100.000%) >count with :4 ( 80.000%) > Of the 4 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok:4 (100.000%) > > The top 10 websites: records and IPv6 connectivity > count with A: 10 (100.000%) >count with :6 ( 60.000%) > Of the 6 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok:6 (100.000%) > > The top 25 websites: records and IPv6 connectivity > count with A: 25 (100.000%) >count with : 10 ( 40.000%) > Of the 10 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 10 (100.000%) > > The top 50 websites: records and IPv6 connectivity > count with A: 50 (100.000%) >count with : 21 ( 42.000%) > Of the 21 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 21 (100.000%) > > The top 100 websites: records and IPv6 connectivity > count with A: 98 ( 98.000%) >count with : 30 ( 30.000%) > Of the 30 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 30 (100.000%) > > The top 250 websites: records and IPv6 connectivity > count with A: 248 ( 99.200%) >count with : 56 ( 22.400%) > Of the 56 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 56 (100.000%) > > The top 500 websites: records and IPv6 connectivity > count with A: 494 ( 98.800%) >count with : 91 ( 18.200%) > Of the 91 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 91 (100.000%) > > The top 1000 websites: records and IPv6 connectivity > count with A: 990 ( 99.000%) >count with : 132 ( 13.200%) > Of the 132 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 132 (100.000%) > > The top 2500 websites: records and IPv6 connectivity > count with A: 2479 ( 99.160%) >count with : 216 ( 8.640%) > Of the 216 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 214 ( 99.074%) > > The top 5000 websites: records and IPv6 connectivity > count with A: 4959 ( 99.220%) >count with : 354 ( 7.083%) > Of the 354 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 347 ( 98.023%) > > The top 1 websites: records and IPv6 connectivity > count with A: 9918 ( 99.230%) >count with : 600 ( 6.003%) > Of the 600 hosts with records, testing connectivity to TCP/80: > count with IPv6 ok: 575 ( 95.833%) > > Original code developed by dw...@employees.org. > manual run by tony on arabian.tndh.net using ./IPv6-check . > on Fri Nov 22 09:48:17 PST 2013 (elapsed: 00:08:33, t: 15). > Top 1 websites based on Alexa top-1m.csv. > >
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Nov, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet Complete listing at http://thyme.rand.apnic.net/current/data-badAS Complete listing at http://thyme.rand.apnic.net/current/data-dsua Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos End of report
RE: NAT64 and matching identities
Lee Howard wrote: ... > >> >There is obviously a long tail of ip4 destinations, but nearly all > >> >of 500 of the Alexa global 500 have ip6 listeners, > >> > >> Do you have a data source for that? I see no indication of IPv6 > >> listeners on 85% of the top sites. > > > >A slightly different metric, 44% of USA content available on IPv6: > > > >http://6lab.cisco.com/stats/ > > Right, weighted by DNS queries. > Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us > and http://www.employees.org/~dwing/-stats/ > > Not equivalent to "nearly all of Alexa 500." Using a derivative of Dan Wings code from a couple of years back I get: The top 5 websites: records and IPv6 connectivity count with A:5 (100.000%) count with :4 ( 80.000%) Of the 4 hosts with records, testing connectivity to TCP/80: count with IPv6 ok:4 (100.000%) The top 10 websites: records and IPv6 connectivity count with A: 10 (100.000%) count with :6 ( 60.000%) Of the 6 hosts with records, testing connectivity to TCP/80: count with IPv6 ok:6 (100.000%) The top 25 websites: records and IPv6 connectivity count with A: 25 (100.000%) count with : 10 ( 40.000%) Of the 10 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 10 (100.000%) The top 50 websites: records and IPv6 connectivity count with A: 50 (100.000%) count with : 21 ( 42.000%) Of the 21 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 21 (100.000%) The top 100 websites: records and IPv6 connectivity count with A: 98 ( 98.000%) count with : 30 ( 30.000%) Of the 30 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%) The top 250 websites: records and IPv6 connectivity count with A: 248 ( 99.200%) count with : 56 ( 22.400%) Of the 56 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 56 (100.000%) The top 500 websites: records and IPv6 connectivity count with A: 494 ( 98.800%) count with : 91 ( 18.200%) Of the 91 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 91 (100.000%) The top 1000 websites: records and IPv6 connectivity count with A: 990 ( 99.000%) count with : 132 ( 13.200%) Of the 132 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 132 (100.000%) The top 2500 websites: records and IPv6 connectivity count with A: 2479 ( 99.160%) count with : 216 ( 8.640%) Of the 216 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 214 ( 99.074%) The top 5000 websites: records and IPv6 connectivity count with A: 4959 ( 99.220%) count with : 354 ( 7.083%) Of the 354 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 347 ( 98.023%) The top 1 websites: records and IPv6 connectivity count with A: 9918 ( 99.230%) count with : 600 ( 6.003%) Of the 600 hosts with records, testing connectivity to TCP/80: count with IPv6 ok: 575 ( 95.833%) Original code developed by dw...@employees.org. manual run by tony on arabian.tndh.net using ./IPv6-check . on Fri Nov 22 09:48:17 PST 2013 (elapsed: 00:08:33, t: 15). Top 1 websites based on Alexa top-1m.csv.
Re: Meraki
Read the unifi forums (I was pretty active there when I was testing unifi controller beta). If that doesn't cure your fanboy feelings, you are doomed. Sent from my Mobile Device. Original message From: Ray Soucy Date: 11/22/2013 3:37 AM (GMT-09:00) To: Seth Mos Cc: NANOG Subject: Re: Meraki FWIW, I picked up a UniFi 3-pack of APs and built up a controller VM using Ubuntu Server LTS and the beta multi-site controller code over the past week. I'm very impressed so far, it doesn't have all the bells and whistles of Cisco setup, sure, but I'm pretty shocked at the level of functionality here and the ease of having APs use an off-site controller (they all phone home over TCP so no VPN or port forwarding is required). I'm interested in UniFi mainly for remote Libraries that don't have any IT staff but need a little more than a router from Best Buy. Also of interest is the EdgeMAX line. I also got the EdgeRouter LITE for testing this past week after finding out it runs a fork of Vyatta (EdgeOS) and is developed by former Vyatta employees. For a sub- $100 device ... very impressive. Pricing just popped up for the new EdgeRouter PRO last night and I was pretty blown away: $360 For a device with 2 SFP ports, and 2M PPS. That is music to my ears since we do a lot of dark fiber around the state even for smaller locations. I'm pretty excited to get one of these and see how they perform. I wish I would have bothered looking at Ubiquiti sooner, really. I'm a little embarrassed to admit I initially wrote them off because the prices were so low, but the more I look into these guys the more I like them. I feel like I'm at the risk for becoming a UBNT fanboy. Does anyone have any qualified horror stories about EdgeMAX or UniFi? Everything I've been able to find has been for nonsense configurations like complaining about trying to to OSPF over WiFi ... Who does that? On Fri, Nov 22, 2013 at 1:34 AM, Seth Mos wrote: > > Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven: > > > - Original Message - > > Anecdote: > > > > My local IHOP finally managed to get Wifi internet access in the > restaurant. > > > > For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*. > > > > That's just as unpleasant as you'd think it would be, And More! > > > > Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis, > > requiring a power cycle, which, generally, they'll only do because I've > > been eating there for 20 years, and they trust me when I ask them to. > > > > I can't say whether this provides any illumination on the rest of their > > product line, but... > > To compound matters, i'd go as far as to say that any wireless solution on > 2.4Ghz isn't really a wireless solution. It's just not feasible anymore in > 2013, there is just *so much* interference from everything using the > unlicensed 2.4Ghz band that it's own success is it's greatest downfall. > > Reliable wireless isn't (to use the famous war quote "friendly fire isn't") > > For whatever reasons, whomever I talk to they all tell me that > sucks, and if I ask further if they are using the wireless thingamabob that > the ISP shipped them, they says yes. So, that's about right then. > > I've been using a PCengines.ch Alix router for years now (AMD Geode, x86, > 256MB ram, CF) with a cable modem in bridge mode with seperate dual band > access points in the places where I need them (living room, attic office) > and I can't say that my experiences with the mesh with theirs. > > Anyhow, if you are going to deploy wireless, make sure to use dual band, > and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet". > You'll see people having a heck of a better time. Social engineering works > :) > > When we chose the Ubiquity wireless kit we could deploy twice as many APs > for the same price of one of the other APs. This effectively means we have > a very dense wireless network that covers the entire building, and lot's of > kit that can actually see and use the 5Ghz band. > > Setup was super easy, I added a unifi DNS name that points to my unifi > controller host and I get a email that a new AP is ready to be put into > service. Having a local management host instead of some cloud was a hard > requirement. I also like that I can just "apt-get update; apt-get upgrade" > the software. By using DNS remote deployment was super easy too, send the > unit off and let them plug it in, it then comes onto the network and > registers itself. > > I believe every current Apple iDevice currently supports the 5Ghz band, > and all the Dell gear we purchase also comes ordered with it. Heck, even my > 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung Galaxy > S3, S4 > > Best regards, > > Seth > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: prefix filtering per IRR - practices
Le 22/11/2013 17:57, Chris Rogers a écrit :
> From my experience, networks that are capable of filtering from IRR objects
> generally filter for exact routes, meaning no "le 24".
Hi,
Are you sure? My experience is, with a small number of exceptions,
that "le 24" ('route' or 'route-set,' sometimes in relation with "is in
AS-set of peer") is an often used policy. Maybe it depends on what
kind of networks one's looking at?
Cheers,
mh
> While I've always
> found networks to be set in their ways, I know some people that have
> managed to get their filters changed to allow longer prefixes without
> needing additional objects.
>
> But ultimately, it does help prevent the leaking of internal routes.
>
> -Chris
>
> On Fri, Nov 22, 2013 at 6:55 AM, Frank Habicht wrote:
>
>> Hi,
>>
>> I have a question regarding what's the most common practice [1]
>> for transit ASs to filter prefixes from their BGP customers
>> when using IRR data. (which of course everyone does...)
>>
>> Would many/most/all/none :
>> a) accept only the prefixes listed in route objects
>> or
>> b) accept these and anything "upto /24" (or "le 24")
>>
>> I was hoping / assuming the latter but I start getting a different
>> impression.
>> Yep, and apart from the current status, the tendency would be of interest.
>>
>> Thanks,
>> Frank
>>
>> [1] after "my network, my rules"
>>
>>
Re: prefix filtering per IRR - practices
>From my experience, networks that are capable of filtering from IRR objects generally filter for exact routes, meaning no "le 24". While I've always found networks to be set in their ways, I know some people that have managed to get their filters changed to allow longer prefixes without needing additional objects. But ultimately, it does help prevent the leaking of internal routes. -Chris On Fri, Nov 22, 2013 at 6:55 AM, Frank Habicht wrote: > Hi, > > I have a question regarding what's the most common practice [1] > for transit ASs to filter prefixes from their BGP customers > when using IRR data. (which of course everyone does...) > > Would many/most/all/none : > a) accept only the prefixes listed in route objects > or > b) accept these and anything "upto /24" (or "le 24") > > I was hoping / assuming the latter but I start getting a different > impression. > Yep, and apart from the current status, the tendency would be of interest. > > Thanks, > Frank > > [1] after "my network, my rules" > >
Re: Meraki
FWIW, I picked up a UniFi 3-pack of APs and built up a controller VM using Ubuntu Server LTS and the beta multi-site controller code over the past week. I'm very impressed so far, it doesn't have all the bells and whistles of Cisco setup, sure, but I'm pretty shocked at the level of functionality here and the ease of having APs use an off-site controller (they all phone home over TCP so no VPN or port forwarding is required). I'm interested in UniFi mainly for remote Libraries that don't have any IT staff but need a little more than a router from Best Buy. Also of interest is the EdgeMAX line. I also got the EdgeRouter LITE for testing this past week after finding out it runs a fork of Vyatta (EdgeOS) and is developed by former Vyatta employees. For a sub- $100 device ... very impressive. Pricing just popped up for the new EdgeRouter PRO last night and I was pretty blown away: $360 For a device with 2 SFP ports, and 2M PPS. That is music to my ears since we do a lot of dark fiber around the state even for smaller locations. I'm pretty excited to get one of these and see how they perform. I wish I would have bothered looking at Ubiquiti sooner, really. I'm a little embarrassed to admit I initially wrote them off because the prices were so low, but the more I look into these guys the more I like them. I feel like I'm at the risk for becoming a UBNT fanboy. Does anyone have any qualified horror stories about EdgeMAX or UniFi? Everything I've been able to find has been for nonsense configurations like complaining about trying to to OSPF over WiFi ... Who does that? On Fri, Nov 22, 2013 at 1:34 AM, Seth Mos wrote: > > Op 22 nov 2013, om 06:37 heeft Jay Ashworth het volgende geschreven: > > > - Original Message - > > Anecdote: > > > > My local IHOP finally managed to get Wifi internet access in the > restaurant. > > > > For reasons unknown to me, it's a Meraki box, backhauled *over T-mobile*. > > > > That's just as unpleasant as you'd think it would be, And More! > > > > Both the wifi and 3G (yes, 3G) boxes lock up on a fairly regular basis, > > requiring a power cycle, which, generally, they'll only do because I've > > been eating there for 20 years, and they trust me when I ask them to. > > > > I can't say whether this provides any illumination on the rest of their > > product line, but... > > To compound matters, i'd go as far as to say that any wireless solution on > 2.4Ghz isn't really a wireless solution. It's just not feasible anymore in > 2013, there is just *so much* interference from everything using the > unlicensed 2.4Ghz band that it's own success is it's greatest downfall. > > Reliable wireless isn't (to use the famous war quote "friendly fire isn't") > > For whatever reasons, whomever I talk to they all tell me that > sucks, and if I ask further if they are using the wireless thingamabob that > the ISP shipped them, they says yes. So, that's about right then. > > I've been using a PCengines.ch Alix router for years now (AMD Geode, x86, > 256MB ram, CF) with a cable modem in bridge mode with seperate dual band > access points in the places where I need them (living room, attic office) > and I can't say that my experiences with the mesh with theirs. > > Anyhow, if you are going to deploy wireless, make sure to use dual band, > and name the 2.4Ghz SSID "internet" and the 5Ghz SSID "faster-internet". > You'll see people having a heck of a better time. Social engineering works > :) > > When we chose the Ubiquity wireless kit we could deploy twice as many APs > for the same price of one of the other APs. This effectively means we have > a very dense wireless network that covers the entire building, and lot's of > kit that can actually see and use the 5Ghz band. > > Setup was super easy, I added a unifi DNS name that points to my unifi > controller host and I get a email that a new AP is ready to be put into > service. Having a local management host instead of some cloud was a hard > requirement. I also like that I can just "apt-get update; apt-get upgrade" > the software. By using DNS remote deployment was super easy too, send the > unit off and let them plug it in, it then comes onto the network and > registers itself. > > I believe every current Apple iDevice currently supports the 5Ghz band, > and all the Dell gear we purchase also comes ordered with it. Heck, even my > 2011 Sony Xperia T has 5Ghz wireless now, as do the current Samsung Galaxy > S3, S4 > > Best regards, > > Seth > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
prefix filtering per IRR - practices
Hi, I have a question regarding what's the most common practice [1] for transit ASs to filter prefixes from their BGP customers when using IRR data. (which of course everyone does...) Would many/most/all/none : a) accept only the prefixes listed in route objects or b) accept these and anything "upto /24" (or "le 24") I was hoping / assuming the latter but I start getting a different impression. Yep, and apart from the current status, the tendency would be of interest. Thanks, Frank [1] after "my network, my rules"
Super Computer 13: GPUs would make terrific network monitors
http://www.networkworld.com/news/2013/112113-sc13-gpus-would-make-terrific-276246.html Super Computer 13: GPUs would make terrific network monitors An off-the-shelf Nvidia GPU is able to easily capture all the traffic of a 10Gbps network, Fermilab research finds By Joab Jackson, IDG News Service November 21, 2013 02:50 PM ET Sponsored by: IDG News Service - A network researcher at the U.S. Department of Energy's Fermi National Accelerator Laboratory has found a potential new use for graphics processing units -- capturing data about network traffic in real time. GPU-based network monitors could be uniquely qualified to keep pace with all the traffic flowing through networks running at 10Gbps (gigabits per second) or more, said Fermilab's Wenji Wu. Wenji presented his work as part of a poster series of new research at the SC 2013 supercomputing conference this week in Denver. Network analysis tools face an extreme challenge in keeping up with all of the traffic of today's larger networks, he said. Adding to the strain, network administrators increasingly expect to inspect operational data in real-time, as it is happening. For processing, today's commercial monitoring appliances typically rely on either standard x86 processors or customer ASICs (application specific integrated circuits). Both architectures have their limitations, Wenji noted. CPUs don't have the memory bandwidth or the compute power to keep pace with the largest networks in real time. As a result, they can drop packets. ASICs can have sufficient memory bandwidth and compute power for the task, but their custom architecture is difficult, and expensive, to program. Nor do they offer the ability to split processing duties into parallel tasks, which is becoming increasingly necessary for watching high-speed networks. GPUs can offer all of these capabilities, Wenji said. They have "a great parallel execution model," he said, noting that they offer high memory bandwidth, easy programmability, and can split the packet capturing process across multiple cores. As their name implies, GPUs were originally designed to render graphics on computer screens. Their architectures, consisting of many processor cores working in tandem, also make them useful as general coprocessors good at inherently parallelizable tasks. In the latest Top500 ranking of the world's most powerful supercomputers, 38 machines used Nvidia GPUs to boost their output. The task of monitoring networks requires reading all the data packets as they cross the network, which "requires a lot of data parallelism," Wenji said. Wenji has built a prototype at Fermilab to demonstrate the feasibility of a GPU-based network monitor, using a Nvidia M2070 GPU and an off-the-shelf NIC (network interface card) to capture network traffic. The system could easily be expanded with additional GPUs, he said. In this setup, Wenji found that packet processing could be considerably accelerated through GPUs. Compared to a single core CPU-based network monitor, the GPU-based system was able to speed performance by as much as 17 times. Compared to a six core CPU, the speed up from using a GPU was threefold. Makers of commercial network appliances could use GPUs to boost their devices' line rates, as well as cut development costs by using pre-existing GPU programming models such as the Nvidia CUDA (Compute Unified Device Architecture) framework, Wenji said. Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab's e-mail address is joab_jack...@idg.com The IDG News Service is a Network World affiliate.
