RE: Cogent announcing more specific prefixes?
Yeah, I saw the same - saw an extra /22 announced... -Original Message- From: ML [mailto:m...@kenweb.org] Sent: 25 November 2010 22:26 To: nanog@nanog.org Subject: Cogent announcing more specific prefixes? Anyone else get alerts from their BGP monitoring system (In my case Cyclops) saying Cogent briefly announced some more specific prefixes? AS path as reported by Cyclops: 7575 46135 174 174 /20s broken into /23s /23s became /24s Also saw alerts for one to one (/23 announced has /23) All alerts had a timestamp of: 2010-11-25 12:01:12 UTC
Re: Network management software with high detailed traffic report
We are using cisco switches like as 3750, 6500 etc. So there is no fairqueue. On 26 November 2010 09:43, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 26 Nov 2010, Sergey Voropaev wrote: We use a several connections to the financial providers. This connections are low bandwidth (up to 2 Mbps). This connections used by a number of front end services from a nubmer of departments and we could not differentiate its and configure QoS. But from time to time some one produce an extremely high traffic spikes (less than 30 seconds) without congestion avoidance mechanisms. Our task - is to find such applications and report to management and developers a problem. Also if we'll be aware about it we could configure QoS. What kind of queuing are you using? It sounds like configuring fair-queue on the interface (if your platform supports that, usually the ones with 2M interfaces do), it should help with the problem you're describing. If you have CPU to spare, configure fair-queue everywhere you can where you don't have a better QoS-configuration in place. It really solves a lot of the problems people are seeing with FIFO and mixed traffic. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Network management software with high detailed traffic report
There is no problem with *NIX from the point of view qualification. But corporate politic use only Windows servers and no any other OS in the production. On 26 November 2010 15:05, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 26, 2010, at 3:59 PM, Sergey Voropaev wrote: I work on this way too. There ais no problem with netflow-sensor. But I can not find good inexpensive collector for Windows which can collect data and do graphic report. Open-source = free. And you should be using *NIX, anyways. Using it for a simple project like this is a good learning experience. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Network management software with high detailed traffic report
On Nov 26, 2010, at 9:26 PM, Sergey Voropaev wrote: But corporate politic use only Windows servers and no any other OS in the production. They obviously use IOS or JunOS or what-have-you on their routers and other networking gear - classify this server as a piece of infrastructure equipment, and you're golden. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Network management software with high detailed traffic report
Sergey Voropaev serge.devo...@gmail.com wrote: Is it possible to view flows (at least srs and dst addresses) in the NMS or only interface utilization? In OpenNMS? No flow or conversation support built in as of today. Some have successfully integrated with cflowd, jflow, or other similar packages; I'm not familiar with the details of those integrations. -jeff
Re: Network management software with high detailed traffic report
On Fri, Nov 26, 2010 at 07:06:26AM +, Dobbins, Roland wrote: On Nov 26, 2010, at 1:36 PM, Sergey Voropaev wrote: Our task - is to find such applications and report to management and developers a problem. Also if we'll be aware about it we could configure QoS. One place to start would be an open-source NetFlow collector/analyzer like nfdump/nfsen: http://nfdump.sourceforge.net/ http://nfsen.sourceforge.net/ I use these tools with great success and can recommend them for a quick, easy setup and trouble free operation. Combined with a few Linux based internal gateways using fprobe-ulog (http://fprobe.sourceforge.net/) and you can get a good picture of what's happening on your network. This page may provide some guidance: http://mithrandi.net/blog/2010/03/netflow-traffic-monitoring-on-debian-lenny/ --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. LaDerrick
Re: Network management software with high detailed traffic report
On Fri, Nov 26, 2010 at 3:26 PM, Sergey Voropaev serge.devo...@gmail.comwrote: There is no problem with *NIX from the point of view qualification. But corporate politic use only Windows servers and no any other OS in the production. I wonder wether your are allowed to use cygwin on your windows machines; that way you'd might find http://qosient.com/argus/ helpfull; cheers, teemu
RE: Jumbo frame Question
Where would the world be if we weren't stuck at 1500 MTU? I've always kinda thought, what if that was larger from the start We keep getting faster switchports, but the MTU is still 1500 MTU! I'm sure someone has done some testing with a 10/100 switch with jumbo frames enables versus a 10/100/1000 switch using regular 1500 MTU and compared the performance. Subject: RE: Jumbo frame Question Date: Thu, 25 Nov 2010 21:14:02 -0800 From: gbon...@seven.com To: harris@hk1.ibm.com; nanog@nanog.org Hi Does anyone have experience on design / implementing the Jumbo frame enabled network? I am working on a project to better utilize a fiber link across east coast and west coast with the Juniper devices. Based on the default TCP windows in Linux / Windows and the latency between east coast and west coast (~80ms) and the default MTU size 1500, the maximum throughput of a single TCP session is around ~3Mbps but it is too slow for us to backing-up the huge amount of data across 2 sites. There are a lot of stack tweaks you can make but the real answer is larger MTU sizes in addition to those tweaks. Our network is completely 9000 MTU internally. We don't deploy any servers anymore with MTU 1500. MTU 1500 is just plain stupid with any network 100mb ethernet. The following is the topology that we are using right now. Host A NIC (MTU 9000) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9018) J-6350 cluster A (MTU 9018) --- fiber link across site --- (MTU 9018) J-6350 cluster B (MTU 9018) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9000) NIC - Host B I was trying to test the connectivity from Host A to the J-6350 cluster A by using ICMP-Ping with size 8000 and DF bit set but it was failed to ping. Does anyone have experience on it? please advise. Thanks :-) You might have some transport in the path (SONET?) that can't send 8000. I would try starting at 3000 and working up to find where your limit is. Your description of fiber link across site is vague. Who is the vendor, what kind of service?
RE: Jumbo frame Question
On Fri, 26 Nov 2010, Brandon Kim wrote: We keep getting faster switchports, but the MTU is still 1500 MTU! I'm sure someone has done some testing with a 10/100 switch with jumbo frames enables versus a 10/100/1000 switch using regular 1500 MTU and compared the performance. 1500 MTU made sense when network was 10 megabit/s. Now that we have gig and 10GE (and soon general availability of 100GE), I don't understand why 9000 makes people excited, if we're going to do a serious effort towards larger MTU, let's make it 15 then (100x) or at least 64k. 6x size different isn't that much, and it's going to involve a lot of work to make it happen, so if we're going to do that work, do it properly. -- Mikael Abrahamssonemail: swm...@swm.pp.se
need a contact
Is there anyone on the list from facebook? Email me directly please. George Roettger
Free Ping services that test your servers Availability from the Internet
Hey folks, I had a situation recently that our network went down and our Network Monitoring software did not notify us that the network was down because the internet connection went down. We had a problem with our carrier where they messed up on our /23(where our Network Monitoring software resides), when they did a maintenance. What transpired is our /23 was no longer routing to us. Is there a free ping internet service, or something that we can pay a company that just sends a ping to devices? If they fail to respond, then an email is sent to us? Thank you folks. M.A.R Senior Network Engineer
Re: Jumbo frame Question
I have the opposite problem. I use iperf to test WAN and VPN throughput and packet loss, but find that the sending Linux system starts out with the expected MTU / MSS but then ramps up the packet size to way beyond 1500. The result is that network equipment must fragment the packets. On higher bandwidth circuits there are a lot of re-transmits that mask any real packet loss that might exist in the path. I have tried multiple methods to clamp the MTU, but nothing has worked so far. This leads me to wonder how often real bulk transfer applications start using jumbo packets that just end up getting fragmented downstream. The jumbo packets from iperf occur on various versions of the Linux kernel and different distributions. It might only happen on GigE. Suggestions on clamping the MTU are welcome. Thanks, Jon On Thu, Nov 25, 2010 at 7:13 PM, Harris Hui harris@hk1.ibm.com wrote: Hi Does anyone have experience on design / implementing the Jumbo frame enabled network?
Re: Free Ping services that test your servers Availability from the Internet
On Fri, Nov 26, 2010 at 9:14 AM, Michael Ruiz mr...@lstfinancial.comwrote: Hey folks, I had a situation recently that our network went down and our Network Monitoring software did not notify us that the network was down because the internet connection went down. We had a problem with our carrier where they messed up on our /23(where our Network Monitoring software resides), when they did a maintenance. What transpired is our /23 was no longer routing to us. Is there a free ping internet service, or something that we can pay a company that just sends a ping to devices? If they fail to respond, then an email is sent to us? Thank you folks. I generally recommend Pingdom (http://www.pingdom.com/). We used them at my last employer and they caught a few outages that we didn't even know about. -- Justin Rocha Xenith || xen...@xenith.org || http://xenith.org/
RE: Free Ping services that test your servers Availability from the Internet
You could just build a nagios server at your house and use that for free. Not really enterprise-level, but if you're just looking for a last ditch alert it should work just fine. -Richard -Original Message- From: Michael Ruiz [mailto:mr...@lstfinancial.com] Sent: Friday, November 26, 2010 12:15 PM To: nanog@nanog.org Subject: Free Ping services that test your servers Availability from the Internet Hey folks, I had a situation recently that our network went down and our Network Monitoring software did not notify us that the network was down because the internet connection went down. We had a problem with our carrier where they messed up on our /23(where our Network Monitoring software resides), when they did a maintenance. What transpired is our /23 was no longer routing to us. Is there a free ping internet service, or something that we can pay a company that just sends a ping to devices? If they fail to respond, then an email is sent to us? Thank you folks. M.A.R Senior Network Engineer
RE: Jumbo frame Question
Jon, Do you have something blocking MTU Path Discovery? Unless I'm off base on this, shouldn't that be taking care of your issue? -Richard -Original Message- From: Jon Meek [mailto:mee...@gmail.com] Sent: Friday, November 26, 2010 12:17 PM To: nanog@nanog.org Subject: Re: Jumbo frame Question I have the opposite problem. I use iperf to test WAN and VPN throughput and packet loss, but find that the sending Linux system starts out with the expected MTU / MSS but then ramps up the packet size to way beyond 1500. The result is that network equipment must fragment the packets. On higher bandwidth circuits there are a lot of re-transmits that mask any real packet loss that might exist in the path. I have tried multiple methods to clamp the MTU, but nothing has worked so far. This leads me to wonder how often real bulk transfer applications start using jumbo packets that just end up getting fragmented downstream. The jumbo packets from iperf occur on various versions of the Linux kernel and different distributions. It might only happen on GigE. Suggestions on clamping the MTU are welcome. Thanks, Jon On Thu, Nov 25, 2010 at 7:13 PM, Harris Hui harris@hk1.ibm.com wrote: Hi Does anyone have experience on design / implementing the Jumbo frame enabled network?
Re: Jumbo frame Question
On (2010-11-25 21:14 -0800), George Bonser wrote: Hey George, 9000 MTU internally. We don't deploy any servers anymore with MTU 1500. MTU 1500 is just plain stupid with any network 100mb ethernet. I'm big proponent of high MTU, to facilitate user MTU of 1500 while adding say GRE or IPSEC overhead. But calling it plain stupid to run MTU of 1500 is quite the over statement. irb(main):001:0 1460.0/(38+1500) = 0.949284785435631 irb(main):002:0 8960.0/(38+9000) = 0.991369772073468 irb(main):003:0 You are theoretically winning 4.2%, which works only internally in your network, so maybe you'll be able to capitalize on that 4.2% on backup traffic or so. Doesn't seem like that critical win to be honest. -- ++ytti
Re: Jumbo frame Question
On Fri, 26 Nov 2010 19:26:30 +0200, Saku Ytti said: You are theoretically winning 4.2%, which works only internally in your network, so maybe you'll be able to capitalize on that 4.2% on backup traffic or so. Doesn't seem like that critical win to be honest. That's only half the calculation. The *other* half is if you have gear that has a packets-per-second issue - if you go to 9000 MTU, you can move 6 times as much data in the same packets-per-second. Anybody who's ever had to trim a complicated ACL list because it saturated the CPU knows what I mean. pgpMbErXcrZO4.pgp Description: PGP signature
Re: Jumbo frame Question
On (2010-11-26 12:39 -0500), valdis.kletni...@vt.edu wrote: That's only half the calculation. The *other* half is if you have gear that has a packets-per-second issue - if you go to 9000 MTU, you can move 6 times as much data in the same packets-per-second. Anybody who's ever had to trim a complicated ACL list because it saturated the CPU knows what I mean. Academically speaking interesting topic, of course the actual time to copy the packet is not constant, so you are not going to see linear increase in bandwidth. It would be very nice to see graph of say VXR with long enough ACL to cap 1500B rate very low and then see results of different packet sizes of 3000, 6000, 9000. If this is something you regularly need to operationally consider, do you happen to have such numbers and if not would it be too much of work for you to provide the numbers? In my world, we've been running hardware lookup engines since 2003, so we really don't need to care about features affecting lookup speed. -- ++ytti
Re: Free Ping services that test your servers Availability from the Internet
Michael Ruiz wrote: Hey folks, I had a situation recently that our network went down and our Network Monitoring software did not notify us that the network was down because the internet connection went down. We had a problem with our carrier where they messed up on our /23(where our Network Monitoring software resides), when they did a maintenance. What transpired is our /23 was no longer routing to us. Is there a free ping internet service, or something that we can pay a company that just sends a ping to devices? If they fail to respond, then an email is sent to us? Thank you folks. M.A.R Senior Network Engineer Let me ask this question from a different angle. Did you NMS notice the issue? If so, does your software require Internet to notify you? I use just a simple modem(remember those?GRIN), a pots line and qpage to send 'out of band' notifications. Lyle Giese LCR Computer Services, Inc.
Re: Free Ping services that test your servers Availability from the Internet
On 11/26/10 9:58 AM, Lyle Giese wrote: Let me ask this question from a different angle. Did you NMS notice the issue? If so, does your software require Internet to notify you? I use just a simple modem(remember those?GRIN), a pots line and qpage to send 'out of band' notifications. Ah yes, the frequently overlooked internet is required to notify when the internet is broken problem. I use text-to-speech with Asterisk on a POTS line or PRI. Killing landlines is the cool thing to do these days, but if IP breaks that's when a POTS line still wins. ~Seth
Re: Free Ping services that test your servers Availability from the Internet
Webmetrics provides such a service (full disclosure I used to work for these guys)... http://www.webmetrics.com/ Stefan Fouant Sent from my iPad On Nov 26, 2010, at 12:14 PM, Michael Ruiz mr...@lstfinancial.com wrote: Hey folks, I had a situation recently that our network went down and our Network Monitoring software did not notify us that the network was down because the internet connection went down. We had a problem with our carrier where they messed up on our /23(where our Network Monitoring software resides), when they did a maintenance. What transpired is our /23 was no longer routing to us. Is there a free ping internet service, or something that we can pay a company that just sends a ping to devices? If they fail to respond, then an email is sent to us? Thank you folks. M.A.R Senior Network Engineer
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, 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 p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 27 Nov, 2010 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 336618 Prefixes after maximum aggregation: 152156 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 165085 Total ASes present in the Internet Routing Table: 35344 Prefixes per ASN: 9.52 Origin-only ASes present in the Internet Routing Table: 30444 Origin ASes announcing only one prefix: 14895 Transit ASes present in the Internet Routing Table:4900 Transit-only ASes present in the Internet Routing Table:121 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 494 Unregistered ASNs in the Routing Table: 223 Number of 32-bit ASNs allocated by the RIRs:921 Prefixes from 32-bit ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:188 Number of addresses announced to Internet: 2311338848 Equivalent to 137 /8s, 196 /16s and 59 /24s Percentage of available address space announced: 62.4 Percentage of allocated address space announced: 65.6 Percentage of available address space allocated: 95.0 Percentage of address space in use by end-sites: 86.2 Total number of prefixes smaller than registry allocations: 138184 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:83261 Total APNIC prefixes after maximum aggregation: 28210 APNIC Deaggregation factor:2.95 Prefixes being announced from the APNIC address blocks: 80180 Unique aggregates announced from the APNIC address blocks:34447 APNIC Region origin ASes present in the Internet Routing Table:4251 APNIC Prefixes per ASN: 18.86 APNIC Region origin ASes announcing only one prefix: 1194 APNIC Region transit ASes present in the Internet Routing Table:690 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 571809824 Equivalent to 34 /8s, 21 /16s and 32 /24s Percentage of available APNIC address space announced: 77.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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, 133/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, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:136335 Total ARIN prefixes after maximum aggregation:69801 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 107499 Unique aggregates announced from the ARIN address blocks: 43805 ARIN Region origin ASes present in the Internet Routing Table:14036 ARIN Prefixes per ASN: 7.66 ARIN Region origin ASes announcing only one prefix:5381 ARIN Region transit ASes present in the Internet Routing Table:1487 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible:
Re: Jumbo frame Question
1500 MTU made sense when network was 10 megabit/s. Now that we have gig and 10GE (and soon general availability of 100GE), I don't understand why 9000 makes people excited, if we're going to do a serious effort towards larger MTU, let's make it 15 then (100x) or at least 64k. the reason ieee has not allowed upping of the frame size is that the crc is at the prudent limits at 1500. yes, we do another check above the frame (uh, well, udp4 may not), but the ether spec can not count on that. randy
RE: Jumbo frame Question
1500 MTU made sense when network was 10 megabit/s. Now that we have gig and 10GE (and soon general availability of 100GE), I don't understand why 9000 makes people excited, if we're going to do a serious effort towards larger MTU, let's make it 15 then (100x) or at least 64k. the reason ieee has not allowed upping of the frame size is that the crc is at the prudent limits at 1500. yes, we do another check above the frame (uh, well, udp4 may not), but the ether spec can not count on that. randy The CRC loses its effectiveness at around 12K bytes so yeah, 64K bytes would probably require a change to detect all possible double-but errors. But 9K bytes is still within the effective range of the current CRC algorithm. From Dykstra: 'Jumbo frames' extends ethernet to 9000 bytes. Why 9000? First because ethernet uses a 32 bit CRC that loses its effectiveness above about 12000 bytes. And secondly, 9000 was large enough to carry an 8 KB application datagram (e.g. NFS) plus packet header overhead. Is 9000 bytes enough? It's a lot better than 1500, but for pure performance reasons there is little reason to stop there. At 64 KB we reach the limit of an IPv4 datagram, while IPv6 allows for packets up to 4 GB in size. For ethernet however, the 32 bit CRC limit is hard to change, so don't expect to see ethernet frame sizes above 9000 bytes anytime soon. But it actually washes because if you have a larger packet size, you have fewer packets so while you might have a higher false pass rate on the larger packets, since you have fewer packets involved, the actual false pass rate for a given amount of data is virtually unchanged. http://staff.psc.edu/mathis/MTU/arguments.html#crc
Re: Jumbo frame Question
On Fri, 26 Nov 2010, Randy Bush wrote: the reason ieee has not allowed upping of the frame size is that the crc is at the prudent limits at 1500. yes, we do another check above the frame (uh, well, udp4 may not), but the ether spec can not count on that. http://staff.psc.edu/mathis/MTU/arguments.html#crc seems to disagree? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Jumbo frame Question
10/100 switches and NICs pretty much universally do not support jumbos. Joel's widget number 2 On Nov 26, 2010, at 8:02, Brandon Kim brandon@brandontek.com wrote: Where would the world be if we weren't stuck at 1500 MTU? I've always kinda thought, what if that was larger from the start We keep getting faster switchports, but the MTU is still 1500 MTU! I'm sure someone has done some testing with a 10/100 switch with jumbo frames enables versus a 10/100/1000 switch using regular 1500 MTU and compared the performance. Subject: RE: Jumbo frame Question Date: Thu, 25 Nov 2010 21:14:02 -0800 From: gbon...@seven.com To: harris@hk1.ibm.com; nanog@nanog.org Hi Does anyone have experience on design / implementing the Jumbo frame enabled network? I am working on a project to better utilize a fiber link across east coast and west coast with the Juniper devices. Based on the default TCP windows in Linux / Windows and the latency between east coast and west coast (~80ms) and the default MTU size 1500, the maximum throughput of a single TCP session is around ~3Mbps but it is too slow for us to backing-up the huge amount of data across 2 sites. There are a lot of stack tweaks you can make but the real answer is larger MTU sizes in addition to those tweaks. Our network is completely 9000 MTU internally. We don't deploy any servers anymore with MTU 1500. MTU 1500 is just plain stupid with any network 100mb ethernet. The following is the topology that we are using right now. Host A NIC (MTU 9000) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9018) J-6350 cluster A (MTU 9018) --- fiber link across site --- (MTU 9018) J-6350 cluster B (MTU 9018) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9000) NIC - Host B I was trying to test the connectivity from Host A to the J-6350 cluster A by using ICMP-Ping with size 8000 and DF bit set but it was failed to ping. Does anyone have experience on it? please advise. Thanks :-) You might have some transport in the path (SONET?) that can't send 8000. I would try starting at 3000 and working up to find where your limit is. Your description of fiber link across site is vague. Who is the vendor, what kind of service?
BGP Update Report
BGP Update Report Interval: 18-Nov-10 -to- 25-Nov-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS479543590 3.0% 180.1 -- INDOSATM2-ID INDOSATM2 ASN 2 - AS14420 37234 2.5% 64.1 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 3 - AS32528 22924 1.6%7641.3 -- ABBOTT Abbot Labs 4 - AS840222634 1.5% 12.5 -- CORBINA-AS Corbina Telecom 5 - AS476118907 1.3% 187.2 -- INDOSAT-INP-AP INDOSAT Internet Network Provider 6 - AS35931 13901 0.9%4633.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - AS22767 13748 0.9%3437.0 -- NASA-ESDIS-NET - National Aeronautics and Space Administration 8 - AS949813424 0.9% 39.5 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS580011013 0.8% 50.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS15978 10716 0.7%3572.0 -- BOBST Group autonomous system 11 - AS982910594 0.7% 38.2 -- BSNL-NIB National Internet Backbone 12 - AS17974 10514 0.7% 13.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS477110149 0.7% 29.2 -- NZTELECOM Netgate 14 - AS100949106 0.6% 350.2 -- BRUNET-AS BruNet ISP, Telekom Brunei Berhad 15 - AS145229026 0.6% 25.6 -- Satnet 16 - AS369928386 0.6% 13.4 -- ETISALAT-MISR 17 - AS9794 7070 0.5% 124.0 -- DNET-ID-AP PT. Core Mediatech (D-NET) 18 - AS9443 7049 0.5% 4.8 -- INTERNETPRIMUS-AS-AP Primus Telecommunications 19 - AS3816 7017 0.5% 86.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 20 - AS6316 7015 0.5% 259.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS32528 22924 1.6%7641.3 -- ABBOTT Abbot Labs 2 - AS485614710 0.3%4710.0 -- AUTOMIR-AS NP Automir CJSC 3 - AS35931 13901 0.9%4633.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS15978 10716 0.7%3572.0 -- BOBST Group autonomous system 5 - AS22767 13748 0.9%3437.0 -- NASA-ESDIS-NET - National Aeronautics and Space Administration 6 - AS9476 6830 0.5%3415.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 7 - AS479193347 0.2%3347.0 -- UKRGASBANK-AS UKRGASBANK AS 8 - AS360593080 0.2%3080.0 -- MEDMANAGEMENT-LLC - MedManagement, LLC 9 - AS179042883 0.2%2883.0 -- SLTASUL-LK Sri Lankan Airlines 10 - AS370452385 0.2%2385.0 -- tznic 11 - AS496002297 0.2%2297.0 -- LASEDA La Seda de Barcelona, S.A 12 - AS159842129 0.1%2129.0 -- The Joint-Stock Commercial Bank CentroCredit. 13 - AS452933183 0.2%1591.5 -- UT-AS-ID Universitas Terbuka 14 - AS342391424 0.1%1424.0 -- INTERAMERICAN General Insurance Company 15 - AS281752617 0.2%1308.5 -- 16 - AS435343482 0.2%1160.7 -- CREDITCALL CreditCall Ltd 17 - AS26746 685 0.1% 685.0 -- HARVARD-PILGRIM-HEALTH-CARE - Harvard Community Health Plan 18 - AS9929 3298 0.2% 659.6 -- CNCNET-CN China Netcom Corp. 19 - AS36961 586 0.0% 586.0 -- ZIPNET 20 - AS39200 551 0.0% 551.0 -- IRNICANYCAST-AS .ir ccTLD of Iran TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 12488 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 130.36.34.0/2411462 0.7% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/2411461 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 8833 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 216.126.136.0/22 6937 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 192.107.195.128/ 6879 0.4% AS22767 -- NASA-ESDIS-NET - National Aeronautics and Space Administration 7 - 169.154.197.128/ 6857 0.4% AS22767 -- NASA-ESDIS-NET - National Aeronautics and Space Administration 8 - 190.65.228.0/226231 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - 195.2.198.0/23 4710 0.3% AS48561 -- AUTOMIR-AS NP Automir CJSC 10 - 198.140.43.0/244604 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 11 - 195.141.217.0/24 3572 0.2% AS15978 -- BOBST Group autonomous system 12 - 195.95.141.0/243572 0.2% AS15978 -- BOBST Group autonomous system 13 - 195.189.204.0/23 3572 0.2% AS15978 -- BOBST Group autonomous system 15 - 206.184.16.0/243485 0.2% AS174 -- COGENT Cogent/PSI 16 - 91.197.95.0/24 3478 0.2% AS43534 -- CREDITCALL CreditCall Ltd 17 - 91.208.198.0/243347 0.2% AS47919 -- UKRGASBANK-AS UKRGASBANK AS 18 -
The Cidr Report
This report has been generated at Fri Nov 26 21:12:15 2010 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
19-11-10341575 209134
20-11-10341193 209258
21-11-10341071 209274
22-11-10341180 209001
23-11-10341153 208234
24-11-10340623 208371
25-11-10340912 208438
26-11-10340092 208435
AS Summary
36059 Number of ASes in routing system
15393 Number of ASes announcing only one prefix
4549 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
104799488 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').
--- 26Nov10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 340233 208435 13179838.7% All ASes
AS6389 3741 510 323186.4% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4549 1742 280761.7% TWTC - tw telecom holdings,
inc.
AS19262 1838 419 141977.2% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1737 591 114666.0% KIXS-AS-KR Korea Telecom
AS17488 1368 282 108679.4% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS4755 1386 415 97170.1% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS18566 1092 158 93485.5% COVAD - Covad Communications
Co.
AS22773 1254 352 90271.9% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS10620 1335 455 88065.9% Telmex Colombia S.A.
AS6503 1161 285 87675.5% Axtel, S.A.B. de C.V.
AS33363 1580 763 81751.7% BHN-TAMPA - BRIGHT HOUSE
NETWORKS, LLC
AS24560 1030 217 81378.9% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS28573 1174 376 79868.0% NET Servicos de Comunicao S.A.
AS18101 909 155 75482.9% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS7545 1454 736 71849.4% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS8151 1349 710 63947.4% Uninet S.A. de C.V.
AS8452 1122 484 63856.9% TE-AS TE-AS
AS4808 927 297 63068.0% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS17676 641 67 57489.5% GIGAINFRA Softbank BB Corp.
AS7303 827 270 55767.4% Telecom Argentina S.A.
AS22047 564 31 53394.5% VTR BANDA ANCHA S.A.
AS6478 1413 882 53137.6% ATT-INTERNET3 - ATT Services,
Inc.
AS4780 712 211 50170.4% SEEDNET Digital United Inc.
AS7552 636 139 49778.1% VIETEL-AS-AP Vietel
Corporation
AS9443 571 75 49686.9% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS14420 575 86 48985.0% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS1785 1806 1322 48426.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS11492 1260 783 47737.9% CABLEONE - CABLE ONE, INC.
AS4804 544 76 46886.0% MPX-AS Microplex PTY LTD
AS45595 551 83 46884.9% PKTELECOM-AS-PK Pakistan
Telecom Company Limited
Total 39106129722613466.8% Top 30 total
Possible Bogus Routes
RE: Introducing draft-denog-v6ops-addresspartnaming
Cisco's expression of a MAC address is wrong anyway. Correct notation for a MAC address is separating each byte with a colon. Doesn't matter... It's widespread and Cisco isn't the only one to use it. Just for my own edification, who else besides Cisco do you know who uses that notation for MAC addresses? I want some convincing before I'll accept the claim that it's widespread. Windows displays macs as dash separated hexified bytes (ie, 12-34-56-78-90-AB) which is incorrect. Given how widespread and pervasive the Microsoft Windows Virus is, I'd call this widespread and pervasive.
Re: Introducing draft-denog-v6ops-addresspartnaming
On Nov 26, 2010, at 2:11 PM, kmedc...@dessus.com wrote: Cisco's expression of a MAC address is wrong anyway. Correct notation for a MAC address is separating each byte with a colon. Doesn't matter... It's widespread and Cisco isn't the only one to use it. Just for my own edification, who else besides Cisco do you know who uses that notation for MAC addresses? I want some convincing before I'll accept the claim that it's widespread. Windows displays macs as dash separated hexified bytes (ie, 12-34-56-78-90-AB) which is incorrect. Given how widespread and pervasive the Microsoft Windows Virus is, I'd call this widespread and pervasive. Windows is not a virus. Viruses are tight, well written pieces of code with a specific (usually nefarious) purpose. While windows certainly qualifies as nefarious, I doubt anyone would consider it tight or well written code. Owen
Re: Network management software with high detailed traffic report
On 26/11/10 6:51 AM, Dobbins, Roland wrote: On Nov 26, 2010, at 9:26 PM, Sergey Voropaev wrote: But corporate politic use only Windows servers and no any other OS in the production. They obviously use IOS or JunOS or what-have-you on their routers and other networking gear - classify this server as a piece of infrastructure equipment, and you're golden. ; until http://blogs.computerworld.com/17412/now_its_updated jc
