as702 looking glass?
Folks, Does anyone know if Verizon (AS702) has a publicly accessable looking glass? -- Serg Shubenkov
Re: draft-iana-ipv4-examples
Ron Bonica wrote:
In addition, some authors have used 128.66.0.0/16 (TEST-B) for example
purposes. There is no RFC that talks about this block, but my
understanding is that IANA/ARIN have marked it as reserved. If you
search the Internet you will find at least some number of examples and
firewall rule sets that use this block, but I have no good idea about
how widespread such usage is.
The only examples that I've found are firewall rule sets that block
many ranges now allocated. Such as NANOG 2002 email:
http://www.merit.edu/mail.archives/nanog/2002-12/msg00127.html
It's no different from net 69 et alia. A couple of larger examples,
widely propagated:
NoRouteIPs={127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8, 10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8,
31.0.0.0/8, 69.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5, 82.0.0.0/7, 84.0.0.0/6,
88.0.0.0/5, 96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16, 128.66.0.0/16,
169.254.0.0/16, 172.16.0.0/12, 191.255.0.0/16, 192.0.0.0/19,
192.0.48.0/20, 192.0.64.0/18, 192.0.128.0/17}
block in log quick on external from 0.0.0.0/7 to any
block in log quick on external from 2.0.0.0/8 to any
block in log quick on external from 5.0.0.0/8 to any
block in log quick on external from 10.0.0.0/8 to any
block in log quick on external from 23.0.0.0/8 to any
block in log quick on external from 27.0.0.0/8 to any
block in log quick on external from 31.0.0.0/8 to any
block in log quick on external from 69.0.0.0/8 to any
block in log quick on external from 70.0.0.0/7 to any
block in log quick on external from 72.0.0.0/5 to any
block in log quick on external from 82.0.0.0/7 to any
block in log quick on external from 84.0.0.0/6 to any
block in log quick on external from 88.0.0.0/5 to any
block in log quick on external from 96.0.0.0/3 to any
block in log quick on external from 127.0.0.0/8 to any
block in log quick on external from 128.0.0.0/16 to any
block in log quick on external from 128.66.0.0/16 to any
block in log quick on external from 169.254.0.0/16 to any
block in log quick on external from 172.16.0.0/12 to any
block in log quick on external from 191.255.0.0/16 to any
block in log quick on external from 192.0.0.0/19 to any
block in log quick on external from 192.0.48.0/20 to any
block in log quick on external from 192.0.64.0/18 to any
block in log quick on external from 192.0.128.0/17 to any
block in log quick on external from 192.168.0.0/16 to any
block in log quick on external from 197.0.0.0/8 to any
block in log quick on external from 201.0.0.0/8 to any
block in log quick on external from 204.152.64.0/23 to any
block in log quick on external from 224.0.0.0/3 to any
What should we do about this block? Some of the potential answers
include documenting its role, marking it as reserved but deprecating its
use in examples, and returning it to the free pool immediately (with a
warning sign about possible filtering problems).
Return to the free pool immediately. Allocate it to *IXen, who might
appreciate it being blocked from view by random outsiders.
Re: Single router for P/PE functions
Hi dave, Our setup was a dual ring with two devices common to both rings. It used a full mesh of LSP's but the majority of traffic was L3VPN. There were some VPLS connections as well, maybe a total of 30 VLAN's. LSP's were set up with static path's the short way around the ring and a standby active secondary path the long way around. Convergence time for a failure on either ring was barely noticable. I am no longer with that organization so I can't get access to the gear anymore :( From my experience, you are probably just asking the EX4200 to do more than it was made to do. That is a lot of CCC circuits to reallocate on the fly, especially for a smaller device. You may me able to reduce convergence time by making your LSP's static with a standby secondary so the path is preconfigured when a failover occurs, the only problem with this is the scalability gets poor quickly as you start to add devices. Erik On Fri, Sep 4, 2009 at 8:39 AM, daveb sp...@zitomedia.net wrote: Hi, I saw your response on NANOG and have a couple questions for you if you don't mind. I'm doing a similar design with MPLS (OSPF/RSVP) on EX4200s in a 10GE ring, mainly for 'ccc' circuits and IP connectivity. The EX4200 serves both the P and PE functions and some of my rings may be as large as 30 devices. In my informal lab test with just 4 EXs in a ring, the convergence time (optomized with FRR, path protection and 50ms BDF) for 1 ccc circuit was 300ms and with 200 ccc circuits it was several seconds, and 800 kills the box. I can't imaging what it would be like with 20 or 30 device in the ring. I was just wondering if you've doen similar testing with the MX as far as scaling. I'm assuming the EX4200 just isn't up to the task but I'm also concerned that ring topologies are problematic for re-routing LSPs. I can test to find the optimum/maximum number of allowable ccc circuits with 4 devices in the ring but I have no way or testing with 20 or 30 so I'm really trying to determine how much worse convergence is with more devices vs number of LSPs. Thanks, Dave Bernardi At 12:00 AM 9/4/2009, Erik Schmersal wrote: Not only can they, it's done quite frequently. I just completed a deployment of seven Juniper MX series routers in a dual ring configuration, all acting as combination P/PE devices for a state government WAN backbone. Works like a charm. Erik On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour sergevaut...@yahoo.ca wrote: Hello, I'm pretty confident that a router can be used to perform P PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. Thanks, Serge __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com.
RE: Single router for P/PE functions
Hi All Any one is using PWE solutions? Any good/bad experience with this technology? Thanks Uri
Re: Single router for P/PE functions
We're trying to save on Transport links. Instead of multi-homing each PE to 2 Ps, we're considering building a ring: P-PE-PE-PE-P. This ring follows the transport ring. Each link would be engineering to make sure it can handle all of the traffic from all 3PEs in case of a failure. As the network grows, we could get individual transport links from PE-P. Apart from bandwidth, I was curious if there were other problems I related to doing this that I wasn't thinking of. Thanks for all the replies. Much appreciated. Serge From: William McCall william.mcc...@gmail.com To: Serge Vautour se...@nbnet.nb.ca Cc: nanog@nanog.org Sent: Friday, September 4, 2009 1:07:40 AM Subject: Re: Single router for P/PE functions Kinda depends on what you're doing exactly, but like Erik said, it certainly possible and depending on your particular needs, it might not be much of an issue at all. Can you describe your scenario a bit more? --WM On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour sergevaut...@yahoo.ca wrote: Hello, I'm pretty confident that a router can be used to perform P PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. Thanks, Serge __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- William McCall, CCIE #25044 __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com
Re: Single router for P/PE functions
What if there is a problem from software, filter, mis-configuration from one of the routers ? It will affect whole ring network, not just that problem router. Also if there is routing protocol bounce because of link flapping, it will be propagate through the ring forever. Alex Serge Vautour wrote: We're trying to save on Transport links. Instead of multi-homing each PE to 2 Ps, we're considering building a ring: P-PE-PE-PE-P. This ring follows the transport ring. Each link would be engineering to make sure it can handle all of the traffic from all 3PEs in case of a failure. As the network grows, we could get individual transport links from PE-P. Apart from bandwidth, I was curious if there were other problems I related to doing this that I wasn't thinking of. Thanks for all the replies. Much appreciated. Serge From: William McCall william.mcc...@gmail.com To: Serge Vautour se...@nbnet.nb.ca Cc: nanog@nanog.org Sent: Friday, September 4, 2009 1:07:40 AM Subject: Re: Single router for P/PE functions Kinda depends on what you're doing exactly, but like Erik said, it certainly possible and depending on your particular needs, it might not be much of an issue at all. Can you describe your scenario a bit more? --WM On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour sergevaut...@yahoo.ca wrote: Hello, I'm pretty confident that a router can be used to perform P PE functions simultaneously. What about from a best practice perspective? Is this something that should be completely avoided? Why? We're considering doing this as a temporary workaround but we all know temporary usually lasts a long time. I'd like to know what kind of mess awaits if we let this one go. Thanks, Serge __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com.
Route table prefix monitoring
Howdy all, I've done a bit of digging through the Google machine and the MarkMail archive of NANOG (Which is a great resource I cannot plug enough - http://nanog.markmail.org) and have a few vague answers, but would like some deeper thought so I'm putting this out to the list. We recently had an event where, unbeknownst to us, a circuit went down and a /16 prefix inside our core routing table was withdrawn as a consequence of adjacency disappearing with that downed circuit (the fact that it went down without us knowing is being worked already). This caused a severe breakage for a legacy system that hasn't been touched in years, and tribal knowledge couldn't explain why we were seeing that legacy system going to a subnet that nobody knew anything about (again, documentation is something that's being worked already as a consequence of this). What I'm left thinking is that it would have been great if we'd had a snapshot of our core routing table as it stood hours or even days prior to this event occurring, so that I could compare it with our current broken state, so the team could have seen that subnet in the core table and what the next hop was for the prefix. Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, or to pull the routing table as a whole at regular intervals for storage/comparison purposes? It looks like there's a plugin for NAGIOS, but I'm looking for suggestions on any other tools (commercial, open source, home grown) that we might take a look at. For reference, we are running Cisco as well as Juniper kit. Feel free to drop me your thoughts off-list. Thank you for any insight ahead of time, -Jason Feren Olsen
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. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 05 Sep, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 294331 Prefixes after maximum aggregation: 139398 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 147041 Total ASes present in the Internet Routing Table: 32126 Prefixes per ASN: 9.16 Origin-only ASes present in the Internet Routing Table: 27940 Origin ASes announcing only one prefix: 13641 Transit ASes present in the Internet Routing Table:4186 Transit-only ASes present in the Internet Routing Table:104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 407 Unregistered ASNs in the Routing Table: 114 Number of 32-bit ASNs allocated by the RIRs:260 Prefixes from 32-bit ASNs in the Routing Table: 105 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:319 Number of addresses announced to Internet: 2101706432 Equivalent to 125 /8s, 69 /16s and 126 /24s Percentage of available address space announced: 56.7 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.8 Total number of prefixes smaller than registry allocations: 140659 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:70157 Total APNIC prefixes after maximum aggregation: 24968 APNIC Deaggregation factor:2.81 Prefixes being announced from the APNIC address blocks: 69597 Unique aggregates announced from the APNIC address blocks:31670 APNIC Region origin ASes present in the Internet Routing Table:3774 APNIC Prefixes per ASN: 18.44 APNIC Region origin ASes announcing only one prefix: 1035 APNIC Region transit ASes present in the Internet Routing Table:580 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 493030848 Equivalent to 29 /8s, 99 /16s and 13 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:124764 Total ARIN prefixes after maximum aggregation:66482 ARIN Deaggregation factor: 1.88 Prefixes being announced from the ARIN address blocks: 125341 Unique aggregates announced from the ARIN address blocks: 52721 ARIN Region origin ASes present in the Internet Routing Table:13211 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix:5107 ARIN Region transit ASes present in the Internet Routing Table:1297 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1013346368 Equivalent to 60 /8s, 102 /16s and 112 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046,
Re: as702 looking glass?
On Fri, 4 Sep 2009 13:38:56 +0400 (MSD), Serg Shubenkov wrote Folks, Does anyone know if Verizon (AS702) has a publicly accessable looking glass? -- Serg Shubenkov it's been 2 years since I last inquired, but the answer then was: Date: Fri, 17 Aug 2007 17:37:09 + (GMT) From: hel...@verizonbusiness.com Subject: (2007081704481) BGP routes Hi there, I am afraid we do not have a public looking glass...
OT: 2009 Infrastructure Security Survey
Folks, We're in the process of collecting feedback for this years infrastructure security report, the fifth edition of the report. The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: https://www.tcb.net/survey/index.php?sid=98557lang=en I've again added many questions this time from past participants of the survey, this should be evidenced throughout. Feedback collection will end as soon as we've reached the desired number of respondents (ideally, 70+). We hope to make the results available by November 2009 at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2008 edition of the survey is available here: http://www.tcb.net/ISR2008_US.pdf Or on the Arbor web site (reg required): http://www.arbornetworks.com/report Thanks in advance for your participation! -danny
Re: Route table prefix monitoring
2009/9/4 Olsen, Jason jol...@devry.com: Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, Could you use something like BGPMon? http://bgpmon.com/ Matthew Walster
Re: Route table prefix monitoring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walstermatt...@walster.org wrote: 2009/9/4 Olsen, Jason jol...@devry.com: Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, Could you use something like BGPMon? http://bgpmon.com/ There's also: MyASN: http://www.ripe.net/info/faq/projects/myasn.html PHAS: http://phas.netsec.colostate.edu/stat.html - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFKoX+Oq1pz9mNUZTMRAto+AJ9hn3ZlScq2Tv3TLUCAJCCzPWqmEwCcDImX lsmccRqdMpbWeoT6wkukuO8= =Mtdy -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Route table prefix monitoring
On Fri, Sep 4, 2009 at 4:59 PM, Paul Fergusonfergdawgs...@gmail.com wrote: On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walstermatt...@walster.org wrote: 2009/9/4 Olsen, Jason jol...@devry.com: Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, Could you use something like BGPMon? http://bgpmon.com/ There's also: MyASN: http://www.ripe.net/info/faq/projects/myasn.html PHAS: http://phas.netsec.colostate.edu/stat.html I think the OP wanted something for 'internal route monitoring' ... since he's from DeVry I suspect it's to monitor things on DeVry's internal WAN which probably don't show in the global table. That said, you COULD have rancid (or abuse rancid) pull rib-dumps each 'period' and index those into something that alerted on large diff's (or alerted if some critical bits were missing). Or have a quagga box peer with some number of internal devices, log update messages, alert on withdrawal of critical bits. -chris (I don't know of any COTS tools that do this, sorry)
Re: Route table prefix monitoring
Hi Jason, .-- My secret spy satellite informs me that at Fri, 04 Sep 2009, Olsen, Jason wrote: What I'm left thinking is that it would have been great if we'd had a snapshot of our core routing table as it stood hours or even days prior to this event occurring, so that I could compare it with our current broken state, so the team could have seen that subnet in the core table and what the next hop was for the prefix. Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, or to pull the routing table as a whole at regular intervals for storage/comparison purposes? As already mentioned BGPmon.net can probably do what you're looking for. It will sent you a notification in cases of interesting path changes, possible hijacks, new adjacencies and new prefixes. It will also notify you when 'many' peers see a withdrawal of your prefix. This last feature might be useful for you. I'm currently also testing a new feature that basically compares yesterday's routing table with todays table. If there are any 'interesting' changes they will be emailed to you. You can think of this as a rancid for routing tables changes. I can include you in testing if you want to. All of this does assume that your prefixes are globally visible though. Cheers, Andree
RE: Route table prefix monitoring
-Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Friday, September 04, 2009 5:07 PM To: Paul Ferguson Cc: nanog@nanog.org Subject: Re: Route table prefix monitoring On Fri, Sep 4, 2009 at 4:59 PM, Paul Fergusonfergdawgs...@gmail.com wrote: On Fri, Sep 4, 2009 at 1:48 PM, Matthew Walstermatt...@walster.org wrote: 2009/9/4 Olsen, Jason jol...@devry.com: Are there any tools that people are using to track when/what prefixes are added/withdrawn from their routing tables, Could you use something like BGPMon? http://bgpmon.com/ There's also: MyASN: http://www.ripe.net/info/faq/projects/myasn.html PHAS: http://phas.netsec.colostate.edu/stat.html I think the OP wanted something for 'internal route monitoring' ... since he's from DeVry I suspect it's to monitor things on DeVry's internal WAN which probably don't show in the global table. That said, you COULD have rancid (or abuse rancid) pull rib-dumps each 'period' and index those into something that alerted on large diff's (or alerted if some critical bits were missing). Or have a quagga box peer with some number of internal devices, log update messages, alert on withdrawal of critical bits. -chris (I don't know of any COTS tools that do this, sorry) Tools such as Arbor Peakflow SP have a lot of cool traffic and routing analysis bits for internal monitoring of this sort, but it might be a bit out of your price range. Having said that, I second Chris's approach above utilizing some quagga box/low-end router (make sure you have enough memory!) and simply reflect routes from your production routers in conjunction with update message logging. If you're looking for tools that perform analysis from an exterior point-of-view, there is also BGPlay which has some cool widgetry to see particular prefixes within a user-specific time interval. Again it's using the operators route-servers so might not be of much value to you http://bgplay.routeviews.org/bgplay/ Stefan Fouant Neustar, Inc. / Principal Engineer 46000 Center Oak Plaza Sterling, VA 20166 Office: +1.571.434.5656 ▫ Mobile: +1.202.210.2075 ▫ GPG ID: 0xB5E3803D ▫ stefan.fou...@neustar.biz
BGP Update Report
BGP Update Report Interval: 27-Aug-09 -to- 03-Sep-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS9198 103193 5.5% 280.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - AS30890 88214 4.7% 181.1 -- EVOLVA Evolva Telecom / iLink Telecom 3 - AS33783 22610 1.2% 147.8 -- EEPAD 4 - AS845214795 0.8% 14.7 -- TEDATA TEDATA 5 - AS270814017 0.8% 128.6 -- Universidad de Guanajuato 6 - AS35805 10774 0.6% 28.0 -- UTG-AS United Telecom AS 7 - AS24863 10450 0.6% 11.1 -- LINKdotNET-AS 8 - AS982910214 0.6% 10.2 -- BSNL-NIB National Internet Backbone 9 - AS237009792 0.5% 27.3 -- BM-AS-ID PT. Broadband Multimedia, Tbk 10 - AS5668 9676 0.5% 9.4 -- AS-5668 - CenturyTel Internet Holdings, Inc. 11 - AS201159123 0.5% 6.2 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS3464 8771 0.5% 23.1 -- ASC-NET - Alabama Supercomputer Network 13 - AS250198719 0.5% 134.1 -- SAUDINETSTC-AS Autonomus System Number for SaudiNet 14 - AS8151 8514 0.5% 5.7 -- Uninet S.A. de C.V. 15 - AS4618 8080 0.4% 136.9 -- INET-TH-AS Internet Thailand Company Limited 16 - AS4323 7833 0.4% 3.8 -- TWTC - tw telecom holdings, inc. 17 - AS124797679 0.4% 16.1 -- UNI2-AS Uni2 Autonomous System 18 - AS4249 7546 0.4% 41.5 -- LILLY-AS - Eli Lilly and Company 19 - AS117697518 0.4% 375.9 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 20 - AS5800 7170 0.4% 52.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS171361765 0.1%1765.0 -- SPANGROUP-UTI - Span Manufacturing Ltd. 2 - AS44194 641 0.0% 641.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 3 - AS42969 590 0.0% 590.0 -- G4SCASH G4S Cash Services (CZ), a.s. 4 - AS26414 495 0.0% 495.0 -- LVCINT - LVC International, LLC 5 - AS49517 889 0.1% 444.5 -- TEIKHOS-AS Teikhos 6 - AS476401282 0.1% 427.3 -- TRICOMPAS Tricomp Sp. z. o. o. 7 - AS8668 2718 0.1% 388.3 -- TELONE-AS TelOne Zimbabwe P/L 8 - AS5050 6118 0.3% 382.4 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS303411141 0.1% 380.3 -- SCTA-ASN - South Central Telephone Association 10 - AS19398 754 0.0% 377.0 -- INDENET - Indenet.net 11 - AS117697518 0.4% 375.9 -- MOBILENETICS-LA-GW1 - Mobilenetics Corporation 12 - AS309695308 0.3% 353.9 -- TAN-NET TransAfrica Networks 13 - AS29544 690 0.0% 345.0 -- MAURITEL-AS 14 - AS17301 315 0.0% 315.0 -- FASTENAL - Fastenal Company 15 - AS42182 306 0.0% 306.0 -- KFMC-ASN AS Number for King Fahd Medical City 16 - AS400602533 0.1% 281.4 -- AAAWI - AAA Wireless, Inc. 17 - AS9198 103193 5.5% 280.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 18 - AS47361 277 0.0% 277.0 -- SYSDESIGN-NET-AS System Design LLC 19 - AS350483181 0.2% 265.1 -- NETZONE-AS SC Power Netzone SRL 20 - AS432401050 0.1% 262.5 -- GLINNET GLINNET's AS Number TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.218.218.0/23 11017 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 2 - 89.218.220.0/23 11016 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 3 - 92.46.244.0/2311014 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 4 - 95.59.2.0/23 11002 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 5 - 95.59.8.0/23 11000 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 6 - 95.59.4.0/22 11000 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - 95.59.3.0/24 10997 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - 88.204.221.0/24 10723 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 9 - 95.59.1.0/24 10687 0.6% AS9198 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - 72.23.246.0/24 6032 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - 207.157.105.64/2 5239 0.3% AS3464 -- ASC-NET - Alabama Supercomputer Network 12 - 84.1.45.0/24 5187 0.3% AS41313 -- NOVATEL-AS Novatel Bulgaria 13 - 203.129.254.0/24 3948 0.2% AS7633 --
The Cidr Report
This report has been generated at Fri Sep 4 21:11:40 2009 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
28-08-09301511 186429
29-08-09301248 186322
30-08-09301138 186464
31-08-09301665 186538
01-09-09301637 186574
02-09-09301706 184566
03-09-09301747 184730
04-09-09301651 184941
AS Summary
32261 Number of ASes in routing system
13742 Number of ASes announcing only one prefix
4311 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
89478400 Largest address span announced by an AS (/32s)
AS27064: DNIC-ASBLK-27032-27159 - DoD Network Information Center
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').
--- 04Sep09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 301649 184909 11674038.7% All ASes
AS6389 4178 327 385192.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4311 1761 255059.2% TWTC - tw telecom holdings,
inc.
AS4766 1836 544 129270.4% KIXS-AS-KR Korea Telecom
AS17488 1553 291 126281.3% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4755 1232 144 108888.3% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS18566 1062 10 105299.1% COVAD - Covad Communications
Co.
AS22773 1095 70 102593.6% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS8151 1477 563 91461.9% Uninet S.A. de C.V.
AS10620 1009 134 87586.7% TV Cable S.A.
AS18101 952 85 86791.1% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS19262 1043 236 80777.4% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1396 644 75253.9% ATT-INTERNET3 - ATT WorldNet
Services
AS8452 989 287 70271.0% TEDATA TEDATA
AS3356 1220 592 62851.5% LEVEL3 Level 3 Communications
AS1785 1736 1115 62135.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4804 686 68 61890.1% MPX-AS Microplex PTY LTD
AS4808 767 213 55472.2% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS11492 1120 566 55449.5% CABLEONE - CABLE ONE, INC.
AS7303 635 94 54185.2% Telecom Argentina S.A.
AS9498 634 103 53183.8% BBIL-AP BHARTI Airtel Ltd.
AS22047 542 16 52697.0% VTR BANDA ANCHA S.A.
AS4134 1001 534 46746.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS17676 564 127 43777.5% GIGAINFRA Softbank BB Corp.
AS7018 1497 1061 43629.1% ATT-INTERNET4 - ATT WorldNet
Services
AS7011 1015 590 42541.9% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS4780 566 146 42074.2% SEEDNET Digital United Inc.
AS5668 787 367 42053.4% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS7545 841 429 41249.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4668 695 285 41059.0% LGNET-AS-KR LG CNS
AS7738 419 29 39093.1% Telecomunicacoes da Bahia S.A.
Total 36858114312542769.0% Top 30 total
Possible Bogus Routes
24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC.
41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service
41.223.176.0/22
Reach.com folks need email assistance?
Perhaps someone from REACH NOC can send me a private email? It seems your IRR POC email is non-functional. -Chris - The following addresses had permanent fatal errors - i...@net.reach.com - Transcript of session follows - i...@net.reach.com... Deferred: postoffice.net.reach.com.: No route to host Message could not be delivered for 3 days Message will be deleted from queue Final-Recipient: RFC822; i...@net.reach.com Action: failed Status: 4.4.7 Remote-MTA: DNS; postoffice.net.reach.com Last-Attempt-Date: Sat, 5 Sep 2009 05:05:22 +0100
Re: Reach.com folks need email assistance?
hey! sam from the reach noc reached out to me :) Thanks! -chris On Sat, Sep 5, 2009 at 12:14 AM, Christopher Morrowmorrowc.li...@gmail.com wrote: Perhaps someone from REACH NOC can send me a private email? It seems your IRR POC email is non-functional. -Chris - The following addresses had permanent fatal errors - i...@net.reach.com - Transcript of session follows - i...@net.reach.com... Deferred: postoffice.net.reach.com.: No route to host Message could not be delivered for 3 days Message will be deleted from queue Final-Recipient: RFC822; i...@net.reach.com Action: failed Status: 4.4.7 Remote-MTA: DNS; postoffice.net.reach.com Last-Attempt-Date: Sat, 5 Sep 2009 05:05:22 +0100
