- Test - lists.nanog.org

Re: Six PCs caused BigPond problems
by Fergie (Paul Ferguson) 15 Apr '05

15 Apr '05

...which reminds me of the Spoofer Project: The Spoofer Project: State of IP Spoofing http://momo.lcs.mit.edu/spoofer/summary.php - ferg -- Bill Stewart <nonobvious(a)gmail.com> wrote: That's ok. At least six more Telstra PCs will get compromised tomorrow. I don't know if they're doing uRPF etc. to stop address spoofing, or blocking RFC1918, but if not, that may help keep the load down. I'm not a fan of using anycast as opposed to building scalable distributed configurations of DNS servers and coordinating them with the DHCP settings that tell customers what server to use, (and monitoring them to make sure they keep working :-), but it can be good for isolating some problems like this. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://spaces.msn.com/members/fergdawg/

1 0

RE: Anyone familiar with the SBC product lingo?
by Hannigan, Martin 15 Apr '05

15 Apr '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Michael.Dillon(a)radianz.com > Sent: Friday, April 15, 2005 6:34 AM > To: nanog(a)merit.edu > Subject: Re: Anyone familiar with the SBC product lingo? > > > > > you'll never get better redundancy than having more than > one carrier. > > On the contrary, you get better redundancy by sticking to > one carrier and making sure that they really provide > separacy though the entire span of the circuit. If you > have two carriers running fibre to yoiur building down > the same conduit, then you do NOT have separacy and as > a result, the redundancy is not there. Which is the case in about 99% of the commercial buildings providers serve. Unless you're designed as a carrier hotel or a colo (even some colos aren't diverse entrance facility), this is the de-facto standard. The reason why is carriers et. al. must pay for conduit access to a building and it impacts pricing, especially if you're not servicing a huge load of service to the building. From the entrace facilities, carriers typically also pay riser conduit fees. Service delivery inside of the prem is insidiously complicated unless you understand a little RE and how OSP is linked to the ISP (in side plant). > > Of course, you can get separacy with two carriers but > it is generally more work to verify that the two companies > do not share fibre or conduit or tunnels. Im a metro loop, they are almost certainly going to share the same path. It is less certain that they will share a conduit. This is standard if you have the route diversity, which is why you want the provider diversity to make it all work. Hope that helps. -M<

2 1

The Cidr Report
by cidr-report＠potaroo.net 15 Apr '05

15 Apr '05

This report has been generated at Fri Apr 15 21:48:05 2005 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-04-05 155649 106425 09-04-05 155822 106490 10-04-05 155876 106556 11-04-05 155931 106518 12-04-05 155938 106693 13-04-05 156063 106855 14-04-05 156161 106970 15-04-05 156270 107016 AS Summary 19324 Number of ASes in routing system 7911 Number of ASes announcing only one prefix 1470 Largest number of prefixes announced by an AS AS7018 : ATT-INTERNET4 - AT&T WorldNet Services 90489600 Largest address span announced by an AS (/32s) AS721 : DLA-ASNBLOCK-AS - 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'). --- 15Apr05 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 156432 106991 49441 31.6% All ASes AS4323 1090 225 865 79.4% TWTC - Time Warner Telecom AS18566 789 8 781 99.0% COVAD - Covad Communications AS4134 887 216 671 75.6% CHINANET-BACKBONE No.31,Jin-rong Street AS721 1118 563 555 49.6% DLA-ASNBLOCK-AS - DoD Network Information Center AS7018 1470 953 517 35.2% ATT-INTERNET4 - AT&T WorldNet Services AS27364 517 22 495 95.7% ACS-INTERNET - Armstrong Cable Services AS22773 477 23 454 95.2% CCINET-2 - Cox Communications Inc. AS6197 887 469 418 47.1% BATI-ATL - BellSouth Network Solutions, Inc AS3602 507 141 366 72.2% SPRINT-CA-AS - Sprint Canada Inc. AS17676 430 77 353 82.1% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS9929 347 45 302 87.0% CNCNET-CN China Netcom Corp. AS4766 572 277 295 51.6% KIXS-AS-KR Korea Telecom AS6478 383 96 287 74.9% ATT-INTERNET3 - AT&T WorldNet Services AS9583 708 448 260 36.7% SIFY-AS-IN Sify Limited AS6140 399 142 257 64.4% IMPSAT-USA - ImpSat AS14654 263 6 257 97.7% WAYPORT - Wayport AS9443 373 122 251 67.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS1239 911 663 248 27.2% SPRINTLINK - Sprint AS7545 484 250 234 48.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS4755 451 219 232 51.4% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS23126 252 21 231 91.7% KMCTELCOM-DIA - KMC Telecom, Inc. AS15270 266 37 229 86.1% AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc. AS6198 457 232 225 49.2% BATI-MIA - BellSouth Network Solutions, Inc AS2386 842 624 218 25.9% INS-AS - AT&T Data Communications Services AS5668 489 282 207 42.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS11456 318 111 207 65.1% NUVOX - NuVox Communications, Inc. AS9498 270 72 198 73.3% BBIL-AP BHARTI BT INTERNET LTD. AS22909 348 151 197 56.6% DNEO-OSP1 - Comcast Cable Communications, Inc. AS6167 272 78 194 71.3% CELLCO-PART - Cellco Partnership AS6147 205 20 185 90.2% Telefonica del Peru S.A.A. Total 16782 6593 10189 60.7% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 ANDARA-HSI - Andara High Speed Internet c/o Halifax Cable Ltd. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 64.17.32.0/24 AS5024 BRIDGE - BridgeNet, LC 64.17.33.0/24 AS5024 BRIDGE - BridgeNet, LC 64.17.37.0/24 AS5024 BRIDGE - BridgeNet, LC 64.57.160.0/19 AS3561 SAVVIS - Savvis 64.127.0.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 66.37.96.0/20 AS3764 IA-HOU-AS - Internet America, Inc. 66.164.232.0/24 AS6197 BATI-ATL - BellSouth Network Solutions, Inc 67.47.0.0/17 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 67.47.0.0/18 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 67.47.64.0/18 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 172.32.0.0/24 AS7011 CITLINK - Citizens Utilities 172.122.28.0/24 AS210 WEST-NET-WEST - Utah Education Network 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.43.230.0/24 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.44.0.0/24 AS5501 FRAUNHOFER-CLUSTER-BW Fraunhofer Gesellschaft 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.81.182.0/24 AS719 ELISA-AS Elisa Oyj 192.81.183.0/24 AS719 ELISA-AS Elisa Oyj 192.81.184.0/24 AS719 ELISA-AS Elisa Oyj 192.119.135.0/24 AS270 PSCNI-AS - National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK & Greece Autonomous System 192.135.50.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 192.136.53.0/24 AS8346 SONATEL-AS Autonomous System 192.153.144.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.172.0.0/19 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.188.208.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 192.200.100.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 196.2.96.0/20 AS2905 UUNET-ZA uunet south africa 196.192.0.0/20 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 196.192.12.0/22 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 196.192.32.0/24 AS5511 OPENTRANSIT France Telecom 196.192.33.0/24 AS5511 OPENTRANSIT France Telecom 196.192.34.0/24 AS5511 OPENTRANSIT France Telecom 196.192.35.0/24 AS5511 OPENTRANSIT France Telecom 196.192.36.0/24 AS5511 OPENTRANSIT France Telecom 196.192.37.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 196.192.38.0/24 AS5511 OPENTRANSIT France Telecom 196.192.39.0/24 AS5511 OPENTRANSIT France Telecom 196.192.40.0/24 AS5511 OPENTRANSIT France Telecom 196.192.41.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 196.192.45.0/24 AS5511 OPENTRANSIT France Telecom 196.192.46.0/24 AS5511 OPENTRANSIT France Telecom 196.192.47.0/24 AS5511 OPENTRANSIT France Telecom 196.192.64.0/21 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 196.192.80.0/24 AS30999 196.192.96.0/20 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.97.72.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.80.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.88.0/24 AS89 NUSC-CSTLNET-AS - Naval Underwater Systems Center 198.97.240.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.97.247.0/24 AS3475 LANT-AFLOAT - Department of the Navy 198.101.4.0/22 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 198.136.32.0/20 AS19329 MCNET - Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY-NET - CityNet, Inc. 198.160.171.0/24 AS7046 UUNET-CUSTOMER - UUNET Technologies, Inc. 198.161.87.0/24 AS6539 GROUPTLCOM - GT Group Telecom Services Corp. 198.163.155.0/24 AS684 MBNET-AS - Manitoba Regional Network 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASKTEL - SaskTel 198.232.133.0/24 AS23075 SKOTOS-AS - Skotos Tech, Inc 199.10.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.60.0.0/20 AS271 BCNET-AS - University of British Columbia 199.96.44.0/23 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NETWORKS-US - 360Networks (USA) Inc. 199.114.0.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.128.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.130.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.132.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DISA/UNRRA 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DISA/UNRRA 199.114.142.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.144.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.148.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.150.0/24 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.120.32.0/19 AS16582 NEXTLEVELINTERNET - NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.0.0/18 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.16.0/20 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.123.80.0/21 AS721 DLA-ASNBLOCK-AS - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 ALTERNET-AS - UUNET Technologies, Inc. 202.72.240.0/20 AS24320 RAILCOM Mongolian Railway Commercial Center Railcom 202.86.252.0/22 AS4748 RESOLINK-AS Resources Linke Network Limited 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.123.0.0/19 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 202.123.2.0/24 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 202.123.8.0/22 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 202.123.16.0/20 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 TELEONE-HK TeleTeleOne (HK) Limited 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.99.0.0/19 AS17746 ORCONINTERNET-NZ-AP Orcon Internet 203.99.142.0/24 AS9826 ILINK-HK-AP iLink.net Ltd 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 204.48.119.0/24 AS29912 CITIZENS-PROPERTY-INSURANCE-CORPORATION - Citizens Property Insurance Corporation 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBIT - Exobit Networks Inc. 205.150.0.0/15 AS701 ALTERNET-AS - UUNET Technologies, Inc. 206.108.96.0/19 AS577 BACOM - Bell Advanced Communications Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.167.57.0/24 AS376 RISQ-AS - Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 206.191.96.0/19 AS15290 ALLST-15290 - Allstream Corp. Corporation Allstream 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc 208.53.224.0/19 AS13576 SDNET - SOUTH DAKOTA NETWORK 208.138.48.0/20 AS6971 ATG-1 - Advanced Telcom Group, Inc 209.27.51.0/24 AS14132 INTERNETGATEWAY - Internet Gateway Inc. 209.134.0.0/18 AS8082 WORLDSITE - Worldsite Networks 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.213.32.0/19 AS10629 INTERPAC - Inter-Pacific Network Services 209.213.48.0/24 AS10629 INTERPAC - Inter-Pacific Network Services 209.213.49.0/24 AS10629 INTERPAC - Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL - Telesat International Ltd. 209.251.0.0/19 AS11036 SISCOM - SISCOM, Inc 216.37.110.0/23 AS4264 CERNET-ASN-BLOCK - California Education and Research Federation Network 216.82.160.0/20 AS13823 CALYX-USA - Calyx Internet Access Corp. 216.96.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.145.200.0/21 AS20304 JVLNET - JVLNET Internet Services 216.171.96.0/20 AS3356 LEVEL3 Level 3 Communications Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org swinog(a)swinog.ch

1 0

Re: Microsoft SOHO router multicast problem? - or maybe it's just doing what it's supposed to be doing...
by Mark Radabaugh 15 Apr '05

15 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chance Whaley wrote: | Sorry about that. Didn't look in detail. Saw the UDP port 6257 and | stopped. | | The mcast is coming from someplace upstream from | fastethernet-0-0.genoa-gw.amplex.net (that is if I did my mcast | MAC to mcast IP conversion right). Without knowing your topology | and seeing more traffic it's kinda hard to figure out. | | | If you want to send more traffic captures I will be happy to look | at them. | | .chance | The destination mac address the routers start using is 01:00:5e:76:6c:7e. The 01:00:5e is the ethernet multicast header. The 76:6c:7e is supposed to be the lower 23 bits of the Ethernet multicast address - which translates to 118.108.126. With the 23 bits from the multicast spec for encoding the IP address 118 is the correct conversion of 246 with the high bit stripped off. The gateway on this subnet is 64.246.108.126 (netmask is 255.255.255.0 but originally was .128 - hence the odd spot for the gateway). The routers decided to convert a mangled unicast packet to a multicast packet - for them to then loop on it is even stranger. It makes for a pretty good DOS attack. 2 or more of these routers in a broadcast domain can get ugly in a hurry. Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX3F2g0PQSWMG2wsRAhYaAKCDeTpKF1QuDhX82rQIOpPTQW4xwACggXhd uHRnFxzmWbrfHSvZGS9ljrs= =IcaN -----END PGP SIGNATURE-----

1 0

Microsoft SOHO router multicast problem? - or maybe it's just doing what it's supposed to be doing...
by Mark Radabaugh 15 Apr '05

15 Apr '05

So which one of the gods of Multicast would like to take a look at a short tcpdump and tell me if the multicast broadcast storm is a problem with the protocol, the Microsoft implementation, or just a really weird coincidence? We run a fixed wireless network that for various reasons is bridged. Yes - it's a crappy design and we are working on changing it but that's not really the point. I have been trying to track down a broadcast storm that shows up on the network intermittently. I finally managed to capture the start of one tonight. The process starts with a slightly mangled packet (intentional? - can't tell yet) with the 'multicast promiscuous bit' set. All of the customers with Microsoft routers (and one Belkin) then rewrite the mangled packet into a multicast packet, decriment the TTL, and forward it back out the interface it came in on. This process then repeats with each of the Microsoft routers responding to the packets from the other routers and sending them out again. With 4 of these routers it manages to generate 20,000+ packets before all of the TTL's drop to 0. Needless to say this results in a little bit of a performance hit. I have blocked Multicast at several points on the network so the problem should be gone for now. The tcpdump file is at http://www.amplex.net/images/multicast.cap Mark Radabaugh Amplex

1 0

fwd: Cobell lawyers ask trust systems be shutdown again (3rd time)
by Eric Brunner-Williams in Portland Maine 15 Apr '05

15 Apr '05

Howdy all, "Because it is indisputable that the 'poor state of network security' creates an imminent risk of irreparable injury... plaintiffs request that this court disconnect from the Internet and shut down each information technology system which houses or access individual Indian trust data to protect plaintiffs against further injury to their interests...," The perenial fuck't up ness of the US DOI BIA Trust is something that could be fixed, if the contracting office and/or contractors had competitive clue, but they don't, and probably won't ever. Think of it as a finding of fact that depeering is in the best interests of the putative beneficiaries of the Indian Trust systems. Eric ------- Forwarded Message Date: Tue, 12 Apr 2005 11:08:44 -0400 (EDT) From: Indian Trust ListServ <listadmin(a)list.indiantrust.com> To: Indian Trust ListServ <list(a)list.indiantrust.com> Subject: Cobell v. Norton - "Sham" Certification Process Used to Okay Defective Computer Systems WASHIINGTON, April 12 -- The Interior Department used "a sham certificati on and accreditation process" to operate defective computer systems which house or access individual Indian Trust accounts, plaintiffs told a federal judge. Citing the Interior Department's own records, lawyers in the Cobell laws uit against Interior Secretary Gale Norton have asked U.S. District Judge Royce Lamberth to reimpose a temporary restraining order, shutting down all trust syst ems. The temporary restraining order and a preliminary injunction against the department are essential to protect 500,000 trust account beneficiaries from fu rther irreparable harm, the petition notes. "Because it is indisputable that the 'poor state of network security' cr eates an imminent risk of irreparable injury...plaintiffs request that this cour t disconnect from the Internet and shut down each information technology system which houses or access individual Indian trust data to protect plaintiffs agains t further injury to their interests...," the petition reads. It cited a study by the Interior Department's own inspector general who reported that "given the poor state of network security...and the the weak acces s controls we encountered on many systems, it is safe to say that we could have easily compromised the confidentiality, integrity and availablity of the identif ied Indian Trust data residing on such systems." Judge Lamberth has twice directed cutoffs of Interior's computer systems to protect trust data. But each time the department has reopened those systems , contending that they were safe from computer hackers. The new filing by the Cobell lawyers reports that Interior's chief infor mation officer, Hord Tipton, has said in a deposition that Interior officials di d not even consider the risk to Indian trust data when they reviewed the systems . Additional details of how the department reconnected its computers using the sham accreditition process are available in the filing for the temporary re straining order at www.indiantrust.com. ------- End of Forwarded Message

1 0

RE: Anyone familiar with the SBC product lingo?
by Dan Lockwood 15 Apr '05

15 Apr '05

Thanks all who replied. Since we have an OC-3 currently I went down the hall and pulled out the actual bill. I was even more confused when I looked at the bill. The situation is as follows... We have 4 DS3s and an OC3 which SBC provides to us via a Nortel mux that they placed on our premise. The OC3 we have now is hooked up to their ATM network to connect up some other high speed sites. On the actual bill for that OC3 it shows a charge for $2200, no more, no less. The service described is "SONET Circuit Service OC3" which I find very puzzling since we don't interface with SBC using SONET. Someone explained this weirdness as "you pay for the OC-3 that is provisioned through their SONET infrastructure of which the premise mux is the last stop". OK fine. So to continue with my current puzzlement, what types of USOCs should I expect to be quoted when provisioning an OC3 for voice? Basted on Matts recommendation it would seem that I need a regular old OC3. Additionally I would expect to see some misc tax and surcharge items; probably some sort of E911 charge as well. Anything else I am missing or do I just tell them that I want the transport plugged into the PSTN and give them the phone numbers that I want to ride on that circuit? Thanks all, Dan -----Original Message----- From: Matthew Crocker [mailto:matthew@crocker.com] Sent: Thursday, April 14, 2005 2:55 PM To: Dan Lockwood Cc: nanog(a)merit.edu Subject: Re: Anyone familiar with the SBC product lingo? > > SONET Circuit Service OC3-c (155Mbps) $2200 vs. Central Office Node > Circuit Service OC3/3c (155Mbps) $675 SONET is a method of transporting TDM channels over fiber. SONET is made up of building blocks calls a STS. A STS is equivalent to a DS-3 + SONET Wrapper. An OC-3 equals 3 STSes. OC-3s come in two types, 'channelized' OC-3 which is 3 DS-3s in 3 STSes and Packet Over SONET (POS), concatenated OC-3c which is 155mbps. If you are planning on using this circuit for TDM based voice (84 T1s in 3 DS-3 chunks) then you will want an OC-3 not an OC-3c. If you are planning on running 155mbps POS IP traffic you want an OC-3c. OC-3 = 3 x STS-1 = 3 x DS-3 = 3 x 28 DS-1s, 84 DS-1s = 2016 DS0 voice channels. OC-3c = 1 x STS-3 = 155mbps You can use an Adtran OPTI-3 to break an OC-3 into 3 distinct DS-3 channels which can be plugged into M13 muxes (Carrier Access Widebank 28) which will break a DS-3 into 28 DS-1s. If you want IP bandwidth you can use an OC-3 POS line card from your router vendor of choice. -Matt

2 1

New international IPv6 operators forum
by Daniel Roesen 15 Apr '05

15 Apr '05

Dear NANOGers, people were missing a global mailing list (not regional RIR/NOG) dedicated to _operational_ matters of the global IPv6 (production, not 6BONE) Internet. To fill this void I've created such a mailing list: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ So if you're taking part in IPv6 BGP or are interested in global IPv6 operational matters, feel more than invited to join the list! We'll try to get IPv6 ops people from all regions on board to foster exchange of experience and resolve problems which require someone non-local coordination as well as discuss problems people face while deploying IPv6. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

1 0

Today's tech news highlights
by Fergie (Paul Ferguson) 14 Apr '05

14 Apr '05

For your perusal: Murdoch urges editors to embrace Internet It's official: ChoicePoint, LexisNexis privacy data compromised many times before HSBC warns 180,000 over retailer's security breach P2P Fuels Global Bandwidth Binge? AOL extends AIM's enterprise interoperability Tufts warns 106,000 alumni, donors of security breach Cisco to Buy Switching Company Topspin for $250M Web Censors In China Find Success Internet casino buys monkey naming rights Frozen polar waste gets Wi-Fi hotspot Second Night of Outages Hit Comcast CIA invests in wireless security Cary Sherman of the RIAA speaks with college journalists California goes to court to shut down major California- based spam operation British banks to provide extra Web security Worm attack forces Reuters IM offline Study finds that ISPs may be blocking more e-mail than they are aware of... Fortinet Under Fire for Allegedly Violating GPL Terms Comcast Sued for Disclosing Customer Information Articles & pointers via: http://spaces.msn.com/members/fergdawg/ Cheers, - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://spaces.msn.com/members/fergdawg/

1 0

RE: BGP Anywhere - Global Redundancy
by Vandy Hamidi 14 Apr '05

14 Apr '05

Bill, Excellent suggestion to advertise a more specific block at the Primary Datacenter and a less specific block at the Backup DC. I can't get a /20, but I can justify a /23. With that I can advertise, for example: 192.168.0.0/24 at the PDC 192.168.0.0/23 at the BDC If the PDC advertisements fail due to a disaster/failure the less specific /23 will route to the BDC. Question for NANOG: If I advertise a /24 and /23, are you aware of any ISPs that would drop the /24 advertisement but keep the /23. If that were to happen, I could get some traffic sent to the BDC? Or would it be ok as my direct peer ISP wont (shouldn't) drop the /24? -=Vandy=- -----Original Message----- From: Bill Stewart [mailto:nonobvious@gmail.com] Sent: Wednesday, April 13, 2005 10:01 PM To: Vandy Hamidi Subject: Re: BGP Anywhere - Global Redundancy Depending on what your address space needs are, you might also consider advertising the PDC with a more specific address space and the BDC with a less specific space, and make sure that the transit providers you're using at both ends will accept routes for the more specific space (e.g. /20? /24?) That rule is supposed to trump AS Path Length rules and just about anything else, so if you're using both to point traffic to the PDC, you're likely to win. It also lets you address specific destinations in the BDC-only space if you want to reach them when the PDC is up. And I'm puzzled that somebody said 15 minutes +/- 5. Typical BGP timers are set for ~30-60 seconds, so you should see recovery in 90-180 seconds, or faster if the failure can be detected by Layer 2 or Layer 1 protocol handling at your upstream provider (e.g. backhoe problems should be detectable almost immediately; router CPU flakeouts will need to wait for timeout.) On 4/6/05, Vandy Hamidi <vandy.hamidi(a)markettools.com> wrote: > > All, > We're an ASP and are considering adding a secondary Backup Datacenter > (BDC) in the US to protect our web presence. > > My goal is to ensure automatic failover of my Primary DC's (IP) traffic > to the BDC in the event of a catastrophic failure of the PDC. > > I'm considering geographic load balancing and BGP Anywhere as the two > options. I'm clear on how the Geo LB works, but have some doubts about > BGPAW as I've never implemented it before and documentation online is > pretty weak to non-existent. > > Below is how I believe it should be done. > From PDC: > -Advertise CIDR block to all peers w/good metric (0 hop count) > From BDC: > -Advertise same CIDR block to all peers w/poor metric (+20 hop > count) > > During normal operation, all ASes will route production traffic to PDC. > In the event of catastrophic failure at PDC; PDC advertisements will > cease, BDC route will become the only one on the net and traffic will > route to the BDC. > > Questions: > 1) Will this work? > 2) Other suggestions or alternatives? > 3) Any chance that traffic could flow to BDC for any reason? > 4) Any internet etiquette I could be ignoring? > 5) What would you estimate the failover time would be? > 6) Assuming the routers at PDC and BDC pull down full routing table, how > will the receipt of the PDC CIDR advertisement be treated? BGP rules > say it will be dropped as a routing loop. What alternatives would I > have if I want to be able to route that CIDR block traffic from the BDC > to the PDC. Confed? Cisco conditional advertisements? > > Thanks all. This is the only place I can think of that would have the > expertise to comment. > > -=Vandy=- > > -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.

1 0