Re: [Nanog-futures] Conference Network Experiment policy
Its pretty easy to assign a Creative Commons license to the work and share it, for example. What could the possible objections be? Best, Marty On 4/9/09, Joel Jaeggli joe...@bogus.com wrote: Martin Hannigan wrote: On Wed, Apr 8, 2009 at 5:14 PM, Joe Provo nanog-...@rsuc.gweep.net mailto:nanog-...@rsuc.gweep.net wrote: Thanks for the feedback - please do keep it coming! We'll pop out an updated draft to reflect the concensus when some equilibrium is reached, but just to comment on some of the questions and points raised so far (both on-list and off): - Costs were intended to be covered under the Have finite and well-defined requirements for support [...] (WRT static/sunk costs of labour, etc) and a statement regarding resources the proposer is committing to supply (WRT money or specific equipment needed for the experiment). The draft will be updated to make both more explict. - It would be interesting to suggest that a copy of all raw data collected to be provided back to the community so that they too could share in the research or create derivatives from it (with proper attribution for all work product of course). As a goal that's exactly the opposite of how we've done it in the past. not sure that it's necessarily a bad idea, just saying. Best, Martin -- Martin Hannigan mar...@theicelandguy.com mailto:mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Conference Network Experiment policy
On Fri, Apr 10, 2009 at 4:34 PM, Joel Jaeggli joe...@bogus.com wrote: So, in the distant past we (there are several we's in this case) experimentally deployed IDSes and or inline sniffers with the permission of merit staff under the requirement that all the data collected be destroyed when the meeting was over. Some of these experiments resulted in the announcement of results, some were simply to get an understanding of dense wireless network deployments, deal with rogue systems, or evaluate the technology. Like I said, I could see alternatives and circumstances were other approaches would be appropriate, But I would probably not avail myself of an experiment where the result to be for example a published set of flow data or catch-all packet traces from the meeting. That's the beauty of full disclosure? :-) Seems like history warrants this as well. I have been lucky enough to not have had my password captured (as far as I am aware) during these experiments and then have it broadcast during the meeting. :-) I'm thinking opt-in with data required to be under CC licensing and shared with attribution seems responsible and valuable to the community. Thanks for the follow-up! Best, Martin -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
Not to turn this into an ethical typ discussion but this arguement would have to assume you could sue the telco not the 'vandal' due to a loss of life if it occured, and that, that dollar amt would be greater then 'securing' all cables. The cost to fix all pintos' gas tanks was only $11 per car unit and it was gambled, though they lost it was cheeper then the lawsuits, I'm betting the while fewer units, its order of magnatitudes more then 11$ per unit to 'secure' access points with a lot less certain negative lawsuit outcomes. Sent from my BlackBerry device on the Rogers Wireless Network -Original Message- From: Ravi Pina r...@cow.org Date: Fri, 10 Apr 2009 01:51:16 To: JC Dilljcdill.li...@gmail.com Cc: nanog@nanog.orgnanog@nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: Ravi Pina wrote: That said one would *hope* vault access is not trivial and there are mechanisms in place to alert of unauthorized, unlawful entry. I regularly drove on these roads when these lines were being put in up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile or so that provide access to this fiber. Do the math. Multiply by the number of miles of fiber runs across the world, and the number of access points per mile on each run. Exactly how do you plan to make vault access non-trivial and yet make the access as easy as it needs to be for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. My guess is that it is probably less expensive in the long run to leave them unprotected and just fix the problems when they occur than to try to secure the vaults and deal with the costs and extended outage delays when access it secured and it takes longer to get into a vault to fix things. I wasn't thinking Exodus/CW/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? -r
Fwd: Outside plant protection, fiber cuts, interwebz down oh noes!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've really got ask if this thread has run it's course. Given the nature of earlier discussions of off-topic issues, I think we've pretty much jumped the shark with people's personal anecdotes of how to disable fiber connectivity. - - ferg - -- Forwarded message -- From: Ravi Pina r...@cow.org Date: Thu, Apr 9, 2009 at 10:51 PM Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! To: JC Dill jcdill.li...@gmail.com Cc: nanog@nanog.org nanog@nanog.org On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: Ravi Pina wrote: That said one would *hope* vault access is not trivial and there are mechanisms in place to alert of unauthorized, unlawful entry. I regularly drove on these roads when these lines were being put in up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile or so that provide access to this fiber. Do the math. Multiply by the number of miles of fiber runs across the world, and the number of access points per mile on each run. Exactly how do you plan to make vault access non-trivial and yet make the access as easy as it needs to be for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. My guess is that it is probably less expensive in the long run to leave them unprotected and just fix the problems when they occur than to try to secure the vaults and deal with the costs and extended outage delays when access it secured and it takes longer to get into a vault to fix things. I wasn't thinking Exodus/CW/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? - -r -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ3uJ/q1pz9mNUZTMRAoRhAJ9m7GTv719RlXUrR6vuGigwpuhJSwCg+sc5 KLrSxYR/cRu1IJOjjM4Go0c= =x059 -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: Outside plant protection, fiber cuts, interwebz down oh noes!
Ravi Pina wrote: Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? Remember the exploding Ford Pinto? http://www.calbaptist.edu/dskubik/pinto.htm
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
deles...@gmail.com wrote: Not to turn this into an ethical typ discussion but this arguement would have to assume you could sue the telco not the 'vandal' due to a loss of life if it occured, and that, that dollar amt would be greater then 'securing' all cables. Internet lawyering is a different mailing list... joel The cost to fix all pintos' gas tanks was only $11 per car unit and it was gambled, though they lost it was cheeper then the lawsuits, I'm betting the while fewer units, its order of magnatitudes more then 11$ per unit to 'secure' access points with a lot less certain negative lawsuit outcomes. Sent from my BlackBerry device on the Rogers Wireless Network -Original Message- From: Ravi Pina r...@cow.org Date: Fri, 10 Apr 2009 01:51:16 To: JC Dilljcdill.li...@gmail.com Cc: nanog@nanog.orgnanog@nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Thu, Apr 09, 2009 at 10:22:41PM -0700, JC Dill wrote: Ravi Pina wrote: That said one would *hope* vault access is not trivial and there are mechanisms in place to alert of unauthorized, unlawful entry. I regularly drove on these roads when these lines were being put in up-and-down the SF Peninsula. There are 4 manhole covers every 1/4 mile or so that provide access to this fiber. Do the math. Multiply by the number of miles of fiber runs across the world, and the number of access points per mile on each run. Exactly how do you plan to make vault access non-trivial and yet make the access as easy as it needs to be for routine maintenance and repair? Having never been in a vault or know how to get in one other than apparently lifting a manhole cover I can't possible answer that with anything more than guessing. My guess is that it is probably less expensive in the long run to leave them unprotected and just fix the problems when they occur than to try to secure the vaults and deal with the costs and extended outage delays when access it secured and it takes longer to get into a vault to fix things. I wasn't thinking Exodus/CW/SAVVIS/Whoever level security, but considering communications cables traverse such sites it is hardly unreasonable to think they could implement some alarm that is centrally monitored by a NOC. I'm guessing *anything* is better than what appears to be the *nothing* that is in place now. Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? -r
Vandalism Likely In Big South Bay Phone Outage [Was: Re: Outside plant protection, fiber cuts, interwebz down oh noes!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 More on this: [snip] SAN JOSE (CBS 5 / KCBS / AP / BCN) -- Vandals severed multiple fiber optic cables on Thursday, leaving thousands of people in Santa Clara, Santa Cruz and San Benito counties without cell phone, Internet and landline service, police said. Crews were making repairs, but estimated that it would likely be sometime Thursday night before all service was restored. The outage which began about 2 a.m. affected both landlines and cellular phones for various ATT, Verizon, Sprint and T-Mobile customers. San Jose Police Sgt. Ronnie Lopez, when asked whether the severed fiber optic cables were the work of vandals, said, that's a pretty good premise. No arrests had yet been made, but police joined repair crews at the scene of the first four severed cables -- located ten feet down a manhole on Monterey Highway, north of Blossom Hill Road in San Jose. Authorities also found two other locations where fiber optic cables were similarly cut -- near Hayes Avenue and Cottle Road in San Jose, and in the 1700 block of Old County Road in San Carlos. Officials said the incidents were related and the police indicated all three locations were being treated as crime scenes. The FBI said while the sabotage acts were criminal, there was no evidence of terrorrism. [snip] More: http://cbs5.com/local/phone.internet.outage.2.980578.html - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj4DBQFJ3qPYq1pz9mNUZTMRAiMlAJ4ztuWURVpURUAbhfzweS/h/nyVCQCVFr+s a+KKWjnze77eqjkrbEB0kg== =+hA8 -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/
SIP - perhaps botnet? anyone else seeing this?
Hi All, Over the past couple of days we have been seeing an exponential increase (about 200-fold) in the amount of UDP SIP Control traffic in our netflow data. The past 24 hours, for example, has shown a total of nearly 300 GB of this traffic incoming and over 400 GB outgoing -- this despite the fact that we do not host any SIP services ourselves, and currently to my knowledge, we have no hosting customers running any kind of SIP services. (Total RTP traffic for 24 hours is only in the region of 150 Kb -- so a vast inbalance between control and RTP) The local sources/destinations of the traffic are within our hosting space, but are spread across a wide range of hosts (i.e. nothing really related to a single or handful of hosts). Additionally over the past couple of days we have seen an increase of mails to our abuse desk for brute force attempts against a number of SIP services... possibly directly related to this traffic. Is anyone aware of a new variant or modus-operandi of botnets in circulation in the past couple of days which attempt to exploit SIP services? Has anyone else notice a significant increase in this kind of traffic? Thanks Leland
Re: SIP - perhaps botnet? anyone else seeing this?
Legally speaking, we can't grab packets in this sense without a specific validated complaint, court orders, and that kind of thing... So all we can do in the the absence of a specific complaint is in the context of our day to day traffic analysis from the netflow data to identify anomalies.. hence this one... (We have already taken action on a handful of known and identified cases of SIP brute-force attacks in recent days). Having said that, we have seen a vast increase in the amount of abuse complaints about SIP authentication brute force attacks in the past couple of days, which would tally with the traffic in general as being actual SIP-Control. The absence of associated RTP, however, leads me to believe that it's either scanning, exploits, or botnets, rather than legitimate SIP traffic. Based on what I've seen in the past couple of days, I am sure that it's as you mentioned, a SIP DDoS or brute-force attacks on SIP services... (circumstantial evidence that it's actually SIP related rather than something else on the same ports -- given the number of abuse complaints) I was simply wondering if this was an overall trend globally, or if it's simply a handful of bozos making life fun for the rest of us ;) Thanks Leland On Fri, 10 Apr 2009, Roland Dobbins wrote: On Apr 10, 2009, at 4:45 PM, Leland E. Vandervort wrote: UDP SIP Control traffic in our netflow data. Have you grabbed some packets in order to ensure it's actually SIP, vs. something else on the same ports? If it really is SIP-related, this could be caused by botted hosts launching a SIP DDoS, or brute-forcing said SIP services in order to steal service for resale, DoS someone else via the service at layer-7 (i.e., call avallanche), sent VoIP spam, et. al. You may have botted hosts in your hosting space, as well as hosts being scanned as potential targets for exploitation. A quick search-engine query should reveal that this sort of thing has been going on for quite some time; I believe there were some convictions in NJ or somewhere else in the northeastern US within the last year or so. --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott
Re: SIP - perhaps botnet? anyone else seeing this?
On Apr 10, 2009, at 4:45 PM, Leland E. Vandervort wrote: UDP SIP Control traffic in our netflow data. Have you grabbed some packets in order to ensure it's actually SIP, vs. something else on the same ports? If it really is SIP-related, this could be caused by botted hosts launching a SIP DDoS, or brute-forcing said SIP services in order to steal service for resale, DoS someone else via the service at layer-7 (i.e., call avallanche), sent VoIP spam, et. al. You may have botted hosts in your hosting space, as well as hosts being scanned as potential targets for exploitation. A quick search-engine query should reveal that this sort of thing has been going on for quite some time; I believe there were some convictions in NJ or somewhere else in the northeastern US within the last year or so. --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott
Re: SIP - perhaps botnet? anyone else seeing this?
On Apr 10, 2009, at 5:32 PM, Leland E. Vandervort wrote: legally speaking, we can't grab packets in this sense without a specific validated complaint, court orders, and that kind of thing... IANAL, but I suggest you check again with your legal department - I doubt this is actually the case (your jurisdiction may vary, but in most Western nations, you can grab packets for diagnostic/ troubleshooting/forensics purposes). Obviously, follow your legal counsel's advice. That being said, I've heard various SPs in various jurisdictions around the world state that they were prohibited from capturing packets, when in fact this wasn't true at all, they'd been misinformed. So, you may wish to check in order to be sure of your position. So all we can do in the the absence of a specific complaint But you said you *had* specific complaints, did you not? ; --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile Our dreams are still big; it's just the future that got small. -- Jason Scott
Re: SIP - perhaps botnet? anyone else seeing this?
On Fri, 10 Apr 2009, Roland Dobbins wrote: IANAL, but I suggest you check again with your legal department - I doubt this is actually the case (your jurisdiction may vary, but in most Western nations, you can grab packets for diagnostic/ troubleshooting/forensics purposes). Already did check... we can't grab packets except in response to judicial order or specific abuse case with a valid ID of the end-user, or of course for general technical diagnostics -- if for diagnostics, we cannot use such collected data in the context of only a suspicion of abuse at all as it would constitute an infringement on the individual's privacy. So in short, we can do it REACTIVELY in response to a complaint.. but if we do it PROACTIVELY, then it cannot be used and is of educational value only (with caveats surrounding confidentiality, non-disclosure, and destruction,, etc.) So all we can do in the the absence of a specific complaint But you said you *had* specific complaints, did you not? yes.. *specific* and action was taken on those *specific* cases... (didn't actually have to grab traffic though...) L.
Re: SIP - perhaps botnet? anyone else seeing this?
to answer your question, as opposed to telling you how to run your business, yes. we are seeing a low level, distributed source, sip probing across a wide swath of target space. it goes back a long time. randy
Re: attacks on MPLS?
* Christopher Morrow: On Thu, Apr 9, 2009 at 12:56 PM, Steven M. Bellovin s...@cs.columbia.edu wrote: http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 This is different from ATM or FRAME or Private lines how? In the end, MPLS is just a transport layer for the private network, if you don't secure your data over a transport, shocker, people can see it!!! People generally believe that MPLS VPNs are encrypted because all VPNs are encrypted in their world. 8-/
BGP Update Report
BGP Update Report Interval: 09-Mar-09 -to- 09-Apr-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS6389 331960 4.2% 75.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS238690353 1.1% 69.7 -- INS-AS - ATT Data Communications Services 3 - AS647873160 0.9% 54.5 -- ATT-INTERNET3 - ATT WorldNet Services 4 - AS949859078 0.8% 83.8 -- BBIL-AP BHARTI Airtel Ltd. 5 - AS845258903 0.7% 44.2 -- TEDATA TEDATA 6 - AS11492 56546 0.7% 46.5 -- CABLEONE - CABLE ONE, INC. 7 - AS10796 52245 0.7% 53.5 -- SCRR-10796 - Road Runner HoldCo LLC 8 - AS19262 50741 0.6% 51.8 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 9 - AS29049 50095 0.6% 151.8 -- DELTA-TELECOM-AS Delta Telecom LTD. 10 - AS701848986 0.6% 33.2 -- ATT-INTERNET4 - ATT WorldNet Services 11 - AS982942463 0.5% 64.9 -- BSNL-NIB National Internet Backbone 12 - AS662942017 0.5% 646.4 -- NOAA-AS - NOAA 13 - AS958339186 0.5% 34.6 -- SIFY-AS-IN Sify Limited 14 - AS17488 38583 0.5% 24.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS754536340 0.5% 44.1 -- TPG-INTERNET-AP TPG Internet Pty Ltd 16 - AS35805 35581 0.5% 111.5 -- UTG-AS United Telecom AS 17 - AS432334580 0.4% 8.0 -- TWTC - tw telecom holdings, inc. 18 - AS20115 34481 0.4% 21.0 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS645832735 0.4% 82.5 -- Telgua 20 - AS443431405 0.4% 805.3 -- ERX-RADNET1-AS PT Rahajasa Media Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS46653 16762 0.2%5587.3 -- FREDRIKSON---BYRON - Fredrikson Byron, P.A. 2 - AS190173599 0.1%3599.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 3 - AS771717553 0.2%3510.6 -- OPENIXP-AS-ID-AP OpenIXP ASN 4 - AS6312 3286 0.0%3286.0 -- WESTWORLD-AS - WestWorld Media, LLC 5 - AS142236091 0.1%3045.5 -- NYSDOH - New York State Department of Health 6 - AS46328 20074 0.2%2230.4 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 7 - AS32398 16047 0.2%2005.9 -- REALNET-ASN-1 8 - AS505024671 0.3%1897.8 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS422916868 0.1%1717.0 -- ISTRANET-AS Istranet LLC 10 - AS305205761 0.1%1440.2 -- NUANCE-SOMERVILLE - NUANCE COMMUNICATIONS, INC 11 - AS403441400 0.0%1400.0 -- PROSK-1 - Pro Sky Wireless 12 - AS209254062 0.1%1354.0 -- RESEAU-DANZAS DANZAS Autonomous System 13 - AS13683 854 0.0% 854.0 -- AUTO-WARES-ASN - Auto-Wares Inc 14 - AS303063335 0.0% 833.8 -- AfOL-Sz-AS 15 - AS45417 821 0.0% 821.0 -- CFLINDIA-NET-IN 1-2-10, S P ROAD 16 - AS569110547 0.1% 811.3 -- MITRE-AS-5 - The MITRE Corporation 17 - AS443431405 0.4% 805.3 -- ERX-RADNET1-AS PT Rahajasa Media Internet 18 - AS476402327 0.0% 775.7 -- TRICOMPAS Tricomp Sp. z. o. o. 19 - AS5839 7266 0.1% 726.6 -- DDN-ASNBLK - DoD Network Information Center 20 - AS262763584 0.1% 716.8 -- TIMKEN-USA - The Timken Company TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/2424558 0.3% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 121.101.184.0/24 17553 0.2% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 3 - 199.45.13.0/2416742 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson Byron, P.A. 4 - 41.204.2.0/24 15863 0.2% AS32398 -- REALNET-ASN-1 5 - 192.35.129.0/24 13961 0.2% AS6629 -- NOAA-AS - NOAA 6 - 198.77.177.0/24 13869 0.2% AS6629 -- NOAA-AS - NOAA 7 - 192.102.88.0/24 13850 0.2% AS6629 -- NOAA-AS - NOAA 8 - 222.255.51.64/26 10738 0.1% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 9 - 192.12.120.0/24 10428 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 202.92.235.0/248314 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 11 - 202.154.57.0/246642 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 12 - 202.154.60.0/226493 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa Media Internet 13 - 192.135.176.0/24 6081 0.1% AS14223 -- NYSDOH - New York State Department of Health 14 - 205.104.240.0/20 5572 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 15 - 202.154.60.0/245543 0.1% AS4434 -- ERX-RADNET1-AS PT Rahajasa
The Cidr Report
This report has been generated at Fri Apr 10 21:13:42 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
03-04-09291003 181969
04-04-09291185 181943
05-04-09291168 182047
06-04-09291172 182195
07-04-09291218 182276
08-04-09291339 182214
09-04-09291312 181932
10-04-09291172 182240
AS Summary
31092 Number of ASes in routing system
13200 Number of ASes announcing only one prefix
4304 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
89679104 Largest address span announced by an AS (/32s)
AS27064: DDN-ASNBLK1 - 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').
--- 10Apr09 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 291607 182306 10930137.5% All ASes
AS6389 4304 359 394591.7% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4253 1679 257460.5% TWTC - tw telecom holdings,
inc.
AS209 2645 1160 148556.1% ASN-QWEST - Qwest
Communications Corporation
AS4766 1797 512 128571.5% KIXS-AS-KR Korea Telecom
AS17488 1537 322 121579.1% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS22773 1022 65 95793.6% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1180 279 90176.4% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS8151 1442 589 85359.2% Uninet S.A. de C.V.
AS8452 1193 354 83970.3% TEDATA TEDATA
AS1785 1745 925 82047.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS19262 974 244 73074.9% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6478 1317 725 59245.0% ATT-INTERNET3 - ATT WorldNet
Services
AS855646 71 57589.0% CANET-ASN-4 - Bell Aliant
AS11492 1210 648 56246.4% CABLEONE - CABLE ONE, INC.
AS18101 756 215 54171.6% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS3356 1193 662 53144.5% LEVEL3 Level 3 Communications
AS2706 543 32 51194.1% HKSUPER-HK-AP Pacific Internet
(Hong Kong) Limited
AS17908 606 118 48880.5% TCISL Tata Communications
AS22047 604 116 48880.8% VTR BANDA ANCHA S.A.
AS6517 744 259 48565.2% RELIANCEGLOBALCOM - Reliance
Globalcom Services, Inc
AS7545 805 330 47559.0% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS4808 619 164 45573.5% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS24560 681 247 43463.7% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS4804 494 64 43087.0% MPX-AS Microplex PTY LTD
AS7018 1446 1020 42629.5% ATT-INTERNET4 - ATT WorldNet
Services
AS17676 561 137 42475.6% GIGAINFRA BB TECHNOLOGY Corp.
AS18566 1060 638 42239.8% COVAD - Covad Communications
Co.
AS4668 697 284 41359.3% LGNET-AS-KR LG CNS
AS7011 956 550 40642.5% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS16814 589 187 40268.3% NSS S.A.
Total 37619129552466465.6% Top 30
Re: On a lighter note..
On Thu, 9 Apr 2009 20:07:05 -0500 jamie rishaw j...@arpa.com wrote: It's amusing to see the media's (misdirected) focus on the event. Expected : MULTIPLE COORDINATED FIBER CUTS TAKE OUT 911, PHONE, CELL, INTERNET TO TENS OF THOUSANDS Google News: ATT uses Twitter ... (link)http://news.cnet.com/8301-1035_3-10216712-94.html *shakes head* I liked the commenter on sfgate.com who suggested that this showed the necessity of implenting RFCs 1149 and 2549. (At http://www.sfgate.com/cgi-bin/article/comments/view?f=/c/a/2009/04/09/BAP816VTE6.DTLo=25 I believe.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: attacks on MPLS?
Steven M. Bellovin wrote: http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 So 2001 (*), slide 46+ here: http://www.securite.org/presentations/secip/BHUS-IPBackboneSecurity.pdf (*) this slide deck is from a talk we've given in 2002 (and contains more details than the 2001 one). Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(n...@securite.org) w:http://www.securite.org/nico/
Re: attacks on MPLS?
Modification to VPN labels in MPLS is interesting however it assumes that providers have exposed their core network to customers. Traffic can be injected into different MPLS VPNs by modifying vpn labels but this is not a trivial attack scenario. For one thing, it would mean the attacker has a view of existing traffic, an understanding of which VPNs are using specific labels, and a path that is inline to modify/ inject traffic. By this same token, attacks on route target membership associations to vpnv4 prefixes would also be a valid attack method. It's all feasible, but it's not trivial. Truman On 10/04/2009, at 4:28 AM, Christian Koch wrote: They presented on the same topic at shmoocon, not sure if the info is any more updated for BH EUROPE, but here is the pres they did in Feb09 http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf On Thu, Apr 9, 2009 at 10:15 AM, Hector Herrera hectorherr...@gmail.com wrote: On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin s...@cs.columbia.edu wrote: http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 --Steve Bellovin, http://www.cs.columbia.edu/~smbhttp://www.cs.columbia.edu/%7Esmb I'll wait to read their full presentation, but according to the article it appears to me that if they have gained access to a Network Management station or a Router, that the entire network has been compromised, not just MPLS. -- Hector Herrera President Pier Programming Services Ltd.
Re: Vandalism Likely In Big South Bay Phone Outage
Sounds to me like an ongoing dispute may be close to the bottom of this. http://blogs.barrons.com/techtraderdaily/2009/04/06/att-union-contract-expires-threat-to-cap-ex/ ATT's answer is to place a $100k bounty on the vandals. The other Bob
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Fri, 10 Apr 2009 01:51:16 EDT, Ravi Pina said: Also not to get sensationalist, but less expensive than a life that could be lost if an emergency call can't be put through? The alarm that goes off saying the lid got opened is only 2 minutes before the big red alarm that says you just lost 5 OC-768s. So the link is *still* going to drop even as you're on the 911 call to try to explain to them where your manhole is, the cops *still* won't catch anybody (the perps may be gone before you hang up on the 911 call), and you're taking 2 minutes off a 10-hour outage. A lot of expense for not a lot of improvement. pgpcngmmZlZAP.pgp Description: PGP signature
Forward Erasure Correction (FEC) and network performance
Hello; I work with FEC in various ways, mostly to protect video streams against packet loss, including as co-chair of the IETF FECFRAME WG and in the Video Services Forum. Most FEC is driven by congestion in the edge, RF issues on wireless LANs, etc., but there is always the chance of loss in transit over the wider network. In many important cases, in fact, (e.g., transfer of video from a content creator to an IPTV service provider or Enterprise to Enterprise video conferencing) the loss at the edges can be controlled, leaving only network transit to worry about. This question has thus come up from time to time, and I was hoping that the assembled NANOG might be able to either answer it or provide pointers to the literature : What level of packet loss would trigger response from network operators ? How bad does a sustained packet loss need to be before it is viewed as a problem to be fixed ? Conversely, what is a typical packet loss fraction during periods of good network performance ? If there is some consensus around this, it would effectively set an upper bound for the need for FEC in network transit. I would be glad to accept replies in confidence off list if people don't want their networks to be identified. (To be clear, I am aware that many ISPs offer some sort of MPLS service with a packet loss SLA for video carriage. I am really asking about Internet transport here, although I would be pleased to learn of MPLS statistics if anyone wants to provide them.) Regards Marshall Eubanks
Re: Forward Erasure Correction (FEC) and network performance
On Apr 10, 2009, at 11:03 AM, Marshall Eubanks wrote: I work with FEC in various ways, mostly to protect video streams against packet loss, including as co-chair of the IETF FECFRAME WG and in the Video Services Forum. Most FEC is driven by congestion in the edge, RF issues on wireless LANs, etc., but there is always the chance of loss in transit over the wider network. In many important cases, in fact, (e.g., transfer of video from a content creator to an IPTV service provider or Enterprise to Enterprise video conferencing) the loss at the edges can be controlled, leaving only network transit to worry about. This question has thus come up from time to time, and I was hoping that the assembled NANOG might be able to either answer it or provide pointers to the literature : What level of packet loss would trigger response from network operators ? How bad does a sustained packet loss need to be before it is viewed as a problem to be fixed ? Conversely, what is a typical packet loss fraction during periods of good network performance ? If there is some consensus around this, it would effectively set an upper bound for the need for FEC in network transit. There will be two consensuses (consensai?). People who _use_ the network will tell you that a network provider will fix a network when they complain, and never before. You have 50% packet loss? Trying to shove 40 Gbps down a GigE? Provider doesn't care, or notice. People who _run_ the network will tell you: No packet loss is acceptable! They'll explain how they constantly monitor their network, have SLAs, give you a tour of their show-NOC, etc. But when you read the SLA, you realize they are measuring packet loss between their core routers in city pairs. And frequently they don't even notice when those hit 2 or 3% packet loss. If you try to send a packet anywhere other than those cities and those router, say down your own transit link, or to a peer, or another customer, well, that's not monitored. And packet loss on those links are not covered by the SLA in many cases. Even if it is covered, it will only be covered from the time you open a ticket. (See point about provider not caring until you complain.) There are a few networks who try harder than others, but no network is perfect. And although you did not say it, I gather than you are not planning to use one of the better networks, you need to use them all. In Summary: How much packet loss is typical? Truthfully, 0% most (i.e. 50%) of the time. The rest of the time, it varies between a fraction of a percent and double-digit percentages. Good luck on figuring out a global average. -- TTFN, patrick
Re: Forward Erasure Correction (FEC) and network performance
On Fri, 10 Apr 2009, Marshall Eubanks wrote: What level of packet loss would trigger response from network operators ? How bad does a sustained packet loss need to be before it is viewed as a problem to be fixed ? Conversely, what is a typical packet loss fraction during periods of good network performance ? My personal opinion is that 10^-12 BER per-link requirement in ethernet sets an upper bound to what can be required of ISPs. Given that a full sized ethernet packet is ~10kbits, that gives us 10^-7 packet loss upper bound. Let's say your average packet traverses 10 links, that gives you 10^-6 (one in a million) packet loss when the network is behaving as per standard requirements (I'm aware that most networks behave much better than this when they're behaving optimally). Personally, I'd start investigating bit error rates somewhere around 10^-5 and worse. This is definitely a network problem, whatever is causing it. A well designed non-congesting core network should easily much be better than 10^-5 packet loss. Now, considering your video case. I think most problems in the core are not caused by actual link BER, but other events, such as re-routes, congested links etc, where you don't have single packet drops here and there in the video stream, instead you'll see very bursty loss. Now, I've been in a lot of SLA discussions with customers who asked why 10^-3 packet loss SLA wasn't good enough, they wanted to raise it to 10^-4 or 10^-5. The question to ask then is when is the network so bad so you want us to tear it to pieces (bringing the packet loss to 100% if needed) to fix the problem. That quickly brings the figures back to 10^-3 or even worse, because most applications will still be bearable at those levels. If you're going to design video codec to handle packet loss, I'd say it should behave without serious visual impairment (ie the huge blocky artefacts travelling across the screen for 300ms) even if there are two packets in a row being lost, and if the jitter is hundreds of ms). It should also be able to handle re-ordering (this is not common, but it happens, especially in a re-route case with microloops). Look at skype, they're able to adapt to all kinds of network impairments and still deliver service, they degrade nicely. They don't have the classic telco we need 0 packet loss and less than 40ms jitter, because that's how we designed it because we're used to SDH/SONET. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
Its all risk and cost. You possibly couldn't have spent enough to stop this event. The outside plant wasn't at fault, highly motivated and informed individuals were. Pretty much a non issue, IMHO. Best, Martin On 4/9/09, Charles Wyble char...@thewybles.com wrote: Seriously though I want to start some discussion around outside plant protection. This isn't the middle of the ocean or desert after all. There were multiple fiber cuts in a major metropolitan area, resulting in the loss of critical infrastructure necessary to many peoples daily lives (though twitter stayed up so it's all good). :) It would appear that this was a deliberate act by one or more individuals, who seemed to have a very good idea of where to strike which resulted in a low cost, low effort attack that yielded significant results. So allow me to think out loud for a minute 1) Why wasn't the fiber protected by some sort of hardened/locked conduit? Is this possible? Does it add extensive cost or hamper normal operation? 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Re: Vandalism Likely In Big South Bay Phone Outage
The reward is effective and the one of the best uses of their funds in responding to this event. More outside plant spending is not effective when you are dealing with motivated individuals. I'd like to reemphasize that you can't spend enough on outside or inside plant to stop this type of thing. It is much more cost effective to stalk the executors with rewards and prosecution as a detterent. Best, Martin On 4/10/09, Bob Bradlee b...@bradlee.org wrote: Sounds to me like an ongoing dispute may be close to the bottom of this. http://blogs.barrons.com/techtraderdaily/2009/04/06/att-union-contract-expires-threat-to-cap-ex/ ATT's answer is to place a $100k bounty on the vandals. The other Bob -- Martin Hannigan mar...@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ?
Roland Dobbins wrote: On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote: Please share your thought and thanks in advance :) No, IMHO. Most broadband operators don't insert firewalls inline in front of their subscribers, and wireless broadband is no different. Some operators put firewalls to NAT their subscribers into smaller IP address pools (I have put some for a particular one). The infrastructure itself must be protected via iACLs, the various vendor-specific control-plane protection mechanisms, and so forth, but inserting additional state in the middle of everything doesn't buy anything, and introduces additional constraints and concerns. Yes.
[SPAM] Re: Forward Erasure Correction (FEC) and network performance
Le 11 avr. 09 à 00:03, Marshall Eubanks a écrit : What level of packet loss would trigger response from network operators ? How bad does a sustained packet loss need to be before it is viewed as a problem to be fixed ? Conversely, what is a typical packet loss fraction during periods of good network performance ? It really depend on a lot of parameters and it's why I think this approach is not relevent at all since IP centric solutions. In past, some peoples said that if you loose less than 0,1% of packet, all is good. Now, you can loose 1% of packet and acheive something that work for the end user with Flash 10 technology and ... despite all you can loose 0,01% packet and see a lot of defaults because HD / 8 Mbps / H264 encoding. (we've presented that with Cisco last year at IBC Amsterdam) Fortunatly if you thing about IP centric solution, you can install enough intelligence in the Set Top Box, for exemple or on a PC client side in order to : - re-ask paquets - and / or repair missing one (fec) Booth of this solution are in operation today and permit a really not too bad IPTV with DSL long lines in many operators that I know. (To be clear, I am aware that many ISPs offer some sort of MPLS service with a packet loss SLA for video carriage. I am really asking about Internet transport here, although I would be pleased to learn of MPLS statistics if anyone wants to provide them.) You can ask what you want to yours ISP but the magic is : all can happen and loss packet and jitter are not relevent at all ! Then solution is not to ask 100% SLA to ISP (except if you find some crazy man to offer you this with good penalty) but to take care about your service, with a real end to end monitoring. There is no more correlation between backbone artefacts and human artefacts. Best way is a user centric monitoring, top down approach that can understand if all is good at service / application / usage level, in order to control principal real artefacts (blockiness, jerkiness, bluriness and availability of image and sound). That's exist, you can believe me ;-) -- Jean-Michel Planche www.jmp.net www.twitter.com/jmplanche 2.0 j...@witbe.net www.witbe.net 1.0 www.internetforeveryone.fr 0.0
Re: Vandalism Likely ...
at least this year its been changed from Terrorists to Vandals. (when most likley, its over-aggressive metals recyclers who have run out of catalitic converters to steal...) --bill
Re: Vandalism Likely ...
On Apr 10, 2009, at 12:57 PM, bmann...@vacation.karoshi.com wrote: at least this year its been changed from Terrorists to Vandals. (when most likley, its over-aggressive metals recyclers who have run out of catalitic converters to steal...) I didn't see a smiley. And I seriously doubt metal recyclers are going 10 feet down into man holes, breaking into locked cabinets, cutting _fiber_optic_ cables (not copper), and doing it in exactly the right points to cause the most damage. But what do I know? -- TTFN, patrick
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. And, yes, you can get lockable manhole covers. They aren't cheap. McGuard make a popular one. (Yes, yes...why would I possibly know any of this.I'm a fire marshal in a small town as a part time gig, so I have to deal with this kind of thing on a reasonably regular basis) Daryl
Re: Forward Erasure Correction (FEC) and network performance
Marshall Eubanks wrote: If there is some consensus around this, it would effectively set an upper bound for the need for FEC in network transit. The bit error rate of copper is better than 1 error in 10^9 bits. The bit error rate of fiber is better than 1 error in 10^12 bits. So the packet loss rate of the transport media is approximately zero.* Thus any packet loss you see is congestion. If you see packet loss, you should SLOW DOWN, not just keep sending and using more and more FEC to get recoverable video out the far end. (And by SLOW DOWN I mean in a way that is TCP-friendly, as anything less will starve out TCP flows unfairly and anything more will itself find that it is starved out by TCP) Matthew Kaufman * The bit error rate of RF-based connections like Wi-Fi is higher *but* because they need to transport TCP, and TCP interprets loss as congestion, they implement link-level ARQ in order to emulate the bit-error-rate performance of wire as best they can.
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Apr 10, 2009, at 12:37 PM, Daryl G. Jurbala wrote: 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. Agreed. Manhole covers are very simple to remove. I don't even need any tools. I've removed countless manhole covers to retrieve balls, frisbees, etc., with nothing more than my bare hands. It's a pretty trivial task. Think about it. All anyone would need to do is pull up to the manhole, set a few orange cones around it, put on an orange vest and a hard hat, and crawl on in with your wire cutters and bolt cutter. Guaranteed NO ONE will even question it. -Andy
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
Charles Wyble wrote: So allow me to think out loud for a minute 1) Why wasn't the fiber protected by some sort of hardened/locked conduit? Is this possible? Does it add extensive cost or hamper normal operation? Cost, both in implementing (what are likely to be easily-circumvented) physical protection mechanisms and the cost of dealing with those when on-site doing installation and maintenance. 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? An alarm did go off, the moment the fiber was cut. In the old days, the alarm was gas pressure reduction on the coax followed by loss of signal... now it is loss of the optical carrier. It turns out that the absolute minimum in false alarms is to ignore things bumping into the manhole or falling into the vault and to alarm immediately if the fiber is tampered with, which is exactly what happened. A little semi-automated OTDR and you could tell which manhole it is without driving down to the CO, too. 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? I see individuals raising manhole covers and going down to do maintenance on their own all the time. Glass is cheap enough that the right solution to this problem is route diversity. An alarm goes off when one path is cut, but you have another path that is still running. Now it takes twice as many people to do the cutting. And if you really care, you can back that path up with other technology like microwave radio. But it all comes down to cost. ADSL and POTS subscribers in Santa Cruz County are willing to pay ATT money for service that doesn't have sufficient route diversity along Monterey Highway. As long as it is more profitable to run the network that way, that's how it will be run. And people who care, *can* back this up. My home ADSL was down but my 90 Mbps home microwave link was running fine, and my VoIP was unaffected as well. My bank couldn't process transactions (Frame Relay was down) but the gas station next door could (VSAT was up). A few years ago it was the other way around when Galaxy 4 went belly-up. Either one of those *could* pay a few extra dollars a month and have both... and if that becomes financially worthwhile, maybe they will. But they can't expect their race-to-the-cheapest telco or ISP to do it for them without specific contractual agreements to that effect, and frankly a 14-hour outage just isn't enough lost business to pay for it. (If it was, I'd have a lot easier time signing people up as customers of my south SF bay area/north monterey bay area wireless ISP) Matthew Kaufman
Re: Vandalism Likely ...
On Fri, Apr 10, 2009 at 1:15 PM, Patrick W. Gilmore patr...@ianai.netwrote: I didn't see a smiley. And I seriously doubt metal recyclers are going 10 feet down into man holes, breaking into locked cabinets, cutting _fiber_optic_ cables (not copper), and doing it in exactly the right points to cause the most damage. But what do I know? The average copper thief normally isn't intelligent enough to know the difference between black PVC clad copper and black PVC clad fiber until they cut it. In this area, thousands of feet of fiber has been stolen along with copper, or left at the scene when the thieves realized it was not copper they had cut out. Copper thieves will climb into power substations, risking electrocution, to steal copper from power companies. So why would they not go down 10 feet into a manhole to get copper? -Steve
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Fri, Apr 10, 2009 at 2:02 AM, deles...@gmail.com wrote: Not to turn this into an ethical typ discussion but this Maybe it's an ethical issue, with an ethical solution. Random news article from google: Workers are seeking to preserve the health care benefit packages, said Libby Sayre, area director for District 9 of the union, which covers California, Nevada and Hawaii. Union leaders say members' health care costs would more than triple under ATT's current proposal. Sayre said ATT posted a $12.9 billion profit last year and added there are few indications the company will be hit hard by the recession. She added its chief executive officer, Randall Stephenson, earns more than $10 million a year. The article goes further to explain that there are 90,000 workers affected. The arithmetic here is pretty easy. So the operational plan is to try harder not to screw over your employees, could be. -Randy Fischer
Re: Vandalism Likely ...
On Apr 10, 2009, at 2:00 PM, Steven M. Callahan wrote: On Fri, Apr 10, 2009 at 1:15 PM, Patrick W. Gilmore patr...@ianai.netwrote: I didn't see a smiley. And I seriously doubt metal recyclers are going 10 feet down into man holes, breaking into locked cabinets, cutting _fiber_optic_ cables (not copper), and doing it in exactly the right points to cause the most damage. But what do I know? The average copper thief normally isn't intelligent enough to know the difference between black PVC clad copper and black PVC clad fiber until they cut it. In this area, thousands of feet of fiber has been stolen along with copper, or left at the scene when the thieves realized it was not copper they had cut out. Copper thieves will climb into power substations, risking electrocution, to steal copper from power companies. So why would they not go down 10 feet into a manhole to get copper? Because it's too easy to get copper elsewhere. At least in the SF bay area. Much, much easier places to get much, much more fiber. If they stole 1000s of feet of fiber, maybe we could say they were dumb. -- TTFN, patrick
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 11 Apr, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 284772 Prefixes after maximum aggregation: 134860 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 140279 Total ASes present in the Internet Routing Table: 30988 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 26974 Origin ASes announcing only one prefix: 13104 Transit ASes present in the Internet Routing Table:4014 Transit-only ASes present in the Internet Routing Table: 96 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (12445) 18 Prefixes from unregistered ASNs in the Routing Table: 466 Unregistered ASNs in the Routing Table: 154 Number of 32-bit ASNs allocated by the RIRs:141 Prefixes from 32-bit ASNs in the Routing Table: 21 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:216 Number of addresses announced to Internet: 2028311744 Equivalent to 120 /8s, 229 /16s and 148 /24s Percentage of available address space announced: 54.7 Percentage of allocated address space announced: 64.0 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.3 Total number of prefixes smaller than registry allocations: 140014 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:66071 Total APNIC prefixes after maximum aggregation: 23545 APNIC Deaggregation factor:2.81 Prefixes being announced from the APNIC address blocks: 62831 Unique aggregates announced from the APNIC address blocks:28740 APNIC Region origin ASes present in the Internet Routing Table:3599 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix:972 APNIC Region transit ASes present in the Internet Routing Table:552 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 410009632 Equivalent to 24 /8s, 112 /16s and 64 /24s Percentage of available APNIC address space announced: 81.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks58/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, 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:124382 Total ARIN prefixes after maximum aggregation:65792 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks:93794 Unique aggregates announced from the ARIN address blocks: 36496 ARIN Region origin ASes present in the Internet Routing Table:12905 ARIN Prefixes per ASN: 7.27 ARIN Region origin ASes announcing only one prefix:4975 ARIN Region transit ASes present in the Internet Routing Table:1248 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 423891200 Equivalent to 25 /8s, 68 /16s and 17 /24s Percentage of available ARIN address space announced: 81.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772,
Re: [outages] fibre cut near 200 Paul, San Francisco
On 10/04/09 03:32, John Martinez wrote: BT Americas? Oh dear, and just after BT suffered a big cut in London. Who needs vandals when there's contractors about? http://www.theregister.co.uk/2009/04/08/bt_hole_hits_vodafone/ http://www.flickr.com/photos/23919...@n00/3426407496/
Re: Forward Erasure Correction (FEC) and network performance
On Friday 10 April 2009 13:43:26 Matthew Kaufman wrote: The bit error rate of copper is better than 1 error in 10^9 bits. The bit error rate of fiber is better than 1 error in 10^12 bits. So the packet loss rate of the transport media is approximately zero.* This sounds pretty good, until you realize that it means you can expect 36 errors in 10 hours on a 100% utilized gigabit fiber link.
Re: Vandalism Likely ...
On Fri, 10 Apr 2009 14:00:38 EDT, Steven M. Callahan said: The average copper thief normally isn't intelligent enough to know the difference between black PVC clad copper and black PVC clad fiber until they cut it. I wish I still had the link to the pictures - one company in Europe was laying fiber that had 'NO COPPER INSIDE' written on the PVC every few feet, in 5 different languages. It helped, but not 100%, IIRC. pgpy7TOfazjVb.pgp Description: PGP signature
Re: Forward Erasure Correction (FEC) and network performance
Lamar Owen wrote: On Friday 10 April 2009 13:43:26 Matthew Kaufman wrote: The bit error rate of copper is better than 1 error in 10^9 bits. The bit error rate of fiber is better than 1 error in 10^12 bits. So the packet loss rate of the transport media is approximately zero.* This sounds pretty good, until you realize that it means you can expect 36 errors in 10 hours on a 100% utilized gigabit fiber link. That *still* sounds good to me. There's a reason reliable transport protocols work the way they do... and integrity protection better than simple checksums is well-understood these days as well. Matthew Kaufman
Re: Forward Erasure Correction (FEC) and network performance
On Fri, 10 Apr 2009, Lamar Owen wrote: This sounds pretty good, until you realize that it means you can expect 36 errors in 10 hours on a 100% utilized gigabit fiber link. Well, it means this is still ok according to standard. In real life, if you engineer your network to be within the optical levels they should be, you get GigE links that at the highest, have single digit CRC errors per month, at the lowest, have 0 CRC errors month after month even with a lot of traffic. BER starts happening very steeply when you approch the optical limit, it might go from 10^-20 to 10^-14 in just a few dB of optical level change. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Outside plant protection, fiber cuts, interwebz down oh noes!
Your right about having the right tools whats a manhole hook cost $50 -carlos -Original Message- From: Daryl G. Jurbala [mailto:da...@introspect.net] Sent: Friday, April 10, 2009 10:37 AM To: Charles Wyble Cc: nanog@nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. And, yes, you can get lockable manhole covers. They aren't cheap. McGuard make a popular one. (Yes, yes...why would I possibly know any of this.I'm a fire marshal in a small town as a part time gig, so I have to deal with this kind of thing on a reasonably regular basis) Daryl
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
I've had pretty good luck when necessary using a large screwdriver, a claw hammer, or a small crow-bar. I know others who claim it can be done with a spade, pick-axe, etc. although I have not tested those implements. Owen On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: Your right about having the right tools whats a manhole hook cost $50 -carlos -Original Message- From: Daryl G. Jurbala [mailto:da...@introspect.net] Sent: Friday, April 10, 2009 10:37 AM To: Charles Wyble Cc: nanog@nanog.org Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! On Apr 9, 2009, at 6:04 PM, Charles Wyble wrote: 3) From what I understand it's not trivial to raise a manhole cover. Most likely can't be done by one person. Can they be locked? Or were the carriers simply relying on obscurity/barrier to entry? Your understanding is incorrect. I'm an average sized guy and I can pull a manhole cover with one hand on the right tool. It might take 2 hands if it hasn't been opened recently and has lots of pebbles and dirt jammed in around it. It's like everything else: if you know how to do it, and you have the right tool, it's simple. And, yes, you can get lockable manhole covers. They aren't cheap. McGuard make a popular one. (Yes, yes...why would I possibly know any of this.I'm a fire marshal in a small town as a part time gig, so I have to deal with this kind of thing on a reasonably regular basis) Daryl
Re: Fiber cut in SF area
George William Herbert wrote: Scott Doty wrote: (Personally, I can think of a MAE-Clueless episode that was worse than this, but that was in the 90's...) The gas main strike out front of the building in Santa Clara? Or something else? -george william herbert gherb...@retro.com Hi George, No, it was when an AS took their full bgp feed fed it into their igp (which used RIP, iirc), which generated (de-aggregated) routes into /24's, which they then announced back into bgp... iirc, part of the chaos than ensued was due to a router bug, so that the routes stuck around in global views, even after the AS killed their announcements, and even after physically disconnecting from their provider. We told our customers the Internet is broken, please try again later...which was acceptable back then. (But I doubt we would get away with just that nowadays... ;-) ) -Scott
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
- Original Message - From: Ravi Pina r...@cow.org To: Charles Wyble char...@thewybles.com Cc: nanog@nanog.org Sent: Thursday, April 09, 2009 5:41 PM Subject: Re: Outside plant protection, fiber cuts, interwebz down oh noes! 2) Why didn't an alarm go off that someone had entered the area? It was after business hours, presumably not in response to a trouble ticket, and as such a highly suspicious action. Does it make sense for these access portals to have some sort of alarm? I mean there is fiber running through and as such it could carry the signaling. Would this be a massive cost addition during construction? I can comment on this, I live three blocks from the scene of the cut. The manholes themselves sit along railroad tracks and an overpass. At 2am, it's a very dark area, and there is very little traffic at that time. It would be an ideal area to perform this type of vandalism. On a side note, when I was passing the area this morning at around 10am PDT, there were two fiber-trailers working in two separate manholes. My company (AS4307) fell off the map from about 2am until roughly 10:42pm when one of our upstreams (AS20115) finally came back. Our primary (AS174) came back about 11:30pm. Of course during the majority of the outage, we also had no land-lines or cell-phones, so were effectively isolated. Bobby Glover Director of Information Services South Valley Internet
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On a side note, when I was passing the area this morning at around 10am PDT, there were two fiber-trailers working in two separate manholes. This is probably the result of having to splice in a new section of fiber, since it would probably have been difficult to splice the ends of the cut section back together.
BGP FlowSpec support on provider networks
Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz
Re: Fiber cut in SF area
On Apr 10, 2009, at 3:41 PM, Scott Doty wrote: George William Herbert wrote: Scott Doty wrote: (Personally, I can think of a MAE-Clueless episode that was worse than this, but that was in the 90's...) The gas main strike out front of the building in Santa Clara? Or something else? -george william herbert gherb...@retro.com No, it was when an AS took their full bgp feed fed it into their igp (which used RIP, iirc), which generated (de-aggregated) routes into /24's, which they then announced back into bgp... That was Vinny Bono of FLIX, the Fat man Little man Internet eXchange, as7007. Happened in 1997, IIRC. He used a Bay Networks router to redistribute BGP on one card into RIPv1 on another card, stripping the CIDR notations off each prefix, making them classful, and stripping the AS Path. This means, for instance, 96.0.0.0 was a /8, not a /24. It also means He then re-redistributed RIP into BGP on a third card, which then originated each route from as7007. I have it on most excellent authority (the Fat man himself) that this was not possible on ciscos. Wonder if it is now ... ? Anyway, I did not know people were calling this the MAE-Clueless incident. I've always called it the 7007 incident. In fact, some people still have as7007 filtered. iirc, part of the chaos than ensued was due to a router bug, so that the routes stuck around in global views, even after the AS killed their announcements, and even after physically disconnecting from their provider. That was Sprint, as7007's transit provider. Sprint only did AS Path filtering, and as every single prefix was ^7007$, they all passed the filter. Vinny literally unplugged the router, no power, no fiber, no copper, but the prefixes were still bouncing around the 'Net for hours. Sprint kept the routes around for a long time as their routers would not honor withdrawals - or so the rumors said. The rumors also claimed the IOS version was named $FOO-sean. Sean Doran was CTO of Sprint's Internet company at the time, and he supposedly specifically asked for the 'feature' of ignoring withdrawals to lower CPU on their AGS+s. I have absolutely no way of confirming this as I haven't spoken to Sean in years years, and wouldn't even know where to find him any more. The most interesting rumor I heard is that Sprint had to shut down every single router simultaneously to clear the routes out of their network. Personally I think that's probably a bit exaggerated, but who knows? We told our customers the Internet is broken, please try again later...which was acceptable back then. (But I doubt we would get away with just that nowadays... ;-) ) Really? That's what some broadband providers say nearly daily. -- TTFN, patrick
Re: BGP FlowSpec support on provider networks
Fouant, Stefan wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Just FYI, but when you hit reply and change the subject, your message still shows up under the Fiber cut in SF area thread. Anyone who's ignoring that thread will not see your message. ~Seth
BGP FlowSpec support on provider networks
Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Sorry for the repost but wanted to make sure this got it's own thread. Thanks, Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz
Re: BGP FlowSpec support on provider networks
Fouant, Stefan wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... See ipv6 :)
Re: BGP FlowSpec support on provider networks
On Apr 10, 2009, at 4:27 PM, Fouant, Stefan stefan.fou...@neustar.biz wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Can you name 3 major vendors who support it? I suspect more providers would offer it if there was vendor support. Last I checked, at least one vendor was fighting mad over the thought of supporting it.
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: Your right about having the right tools whats a manhole hook cost $50 Less than half that. http://www.toolup.com/condux/08023000.html -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
Re: Outside plant protection, fiber cuts, interwebz down oh noes!
On Apr 10, 2009, at 12:05 PM, Carlos Alcantar wrote: Your right about having the right tools whats a manhole hook cost $50 Less than half that. http://www.toolup.com/condux/08023000.html And maybe even less than half *that*. You don't actually need the tool in many cases. A good bit of rebar (trivially found at many construction sites), a prybar, a heavy screwdriver, threaded rod, the trick is just to get the thing out of its rim. Specialized tools are for those who are doing it every day. I suspect that the person responsible did not go out and buy a hook, so this may be pointless anyways. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: BGP FlowSpec support on provider networks
In my experience it's vendor support that is lacking, not provider support On Sat, Apr 11, 2009 at 6:08 AM, Fouant, Stefan stefan.fou...@neustar.bizwrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Stefan Fouant: NeuStar, Inc. Principal Network Engineer 46000 Center Oak Plaza Sterling, VA 20166 [ T ] +1 571 434 5656 [ M ] +1 202 210 2075 [ E ] stefan.fou...@neustar.biz [ W ] www.neustar.biz
Re: BGP FlowSpec support on provider networks
I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... shamelessplug nLayer has offered flowspec support to customers for many years now. /shamelessplug It's really quite simple to use and support too, if you happen to have a largely Juniper based network that is. I'm not aware of any other router vendor who currently supports it, but the loss is entirely theirs. We do have a fair bit of Crisco in the network, with Juniper primarily in the core and peering/transit edge, so we use a route-server to feed the flowspec routes into the Juniper core. Customers set up an ebgp multihop session with it, and can announce flowspec routes (or standard blackhole via bgp communities) for anything in their register prefix-list. It's also quite handy for distributing internal use packet filters too. As for why something so (insanely) useful is slow to be adopted... There are a few reasons, but mostly: 1) A healthy dose of inter-vendor politics. 2) A silly religious belief that bgp shouldn't be used to carry firewall information, and that some other protocol should be invented instead. I think the counter-argument to that is the ability to do inter-provider filtering is precisely why it should be done via bgp. and the success of the current implementation proves how well it works. 3) Another large network who shall remain nameless once used a third party flowspec speaking piece of software which shall also remain nameless, and managed to blackhole their entire network for a noticeable amount of time. As with anything combining the words network wide protocol and packet filter, a healthy amount of user discretion is advised. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: BGP FlowSpec support on provider networks
On Fri, Apr 10, 2009 at 6:38 PM, John Payne j...@sackheads.org wrote: On Apr 10, 2009, at 4:27 PM, Fouant, Stefan stefan.fou...@neustar.biz wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry... Can you name 3 major vendors who support it? I suspect more providers would juniper... and when they dropped the IPR stuff other vendors basically walked away :( offer it if there was vendor support. Last I checked, at least one vendor was fighting mad over the thought of supporting it. yes :( weee! poilitics!
RE: Fiber cut in SF area
I'm confussed, but please pardon the ignorance. All the data centers we have are at minimum keys to access data areas. Not that every area of fiber should have such, but at least should they? Manhole covers can be keyed. For those of you arguing that this is not enough, I would say at least its a start. Yes if enough time goes by anything can happen, but how can one argue an ATM machince that has (at times) thousands of dollars stands out 24/7 without more immediate wealth. Perhaps I am missing something here, do the Cops stake out those areas? dunno Just my 2¢
