- Test - lists.nanog.org

Re: [routing-wg]BGP Update Report
by Marshall Eubanks 11 Sep '06

11 Sep '06

Hello; On Sep 11, 2006, at 6:32 AM, Oliver Bartels wrote: > Hi Gert, > On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: >> Ummm, well, this is a damn fast plane if it will reach another >> continent >> 1843 times per day (or even "per week")... - which should be the only >> time the BGP announcement moves. >> >> Sounds more like "the BGP-follows-plane system has some stability >> problems". > > Nack. > > Probably they are using low or medium earth orbit satellites, which > _are_ damn fast in orbit. Otherwise the round trip time would be > unacceptably high. > I believe that all Connexion support is / was from geostationary satellites. > As the whole thing is 3D, some of them might have contact to > ground stations on this or the other side of the great lake, > depending on their 3D position, even thru the plane travels > on a well defined track (probably a 3D circle, too) in just one > direction only. > > Ceterum censeo: Nevertheless this moving-clients application shows > some demand for a true-location-independend IP-addresses > announcement feature (provider independend "roaming") in IPv6, > as in v4 (even thru this isn't the "standard" way, but Connexion is > anything but standard). Shim etc. is not sufficient ... > That seems like a reasonable conclusion. > Kind Regards > Oliver Regards Marshall > > > > Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany > oliver(a)bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > > >

1 0

Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
by Mark Kent 11 Sep '06

11 Sep '06

Joe McGuckin typed: >> 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedings that generated that order? Let's say you're eating lunch one day, minding your own business, and a sheriff comes up with an official looking document and says "You need to hand your car over to Fred..." because, unknown to you, Fred and Barney just finished court proceedings where the judge ruled that Barney had to give Fred "his" car, even though that car was owned by you and just loaned to Barney. Not a great analogy, because of the whole pink slip thing, but you get the point. -mark

9 9

BGP Update Report
by cidr-report＠potaroo.net 11 Sep '06

11 Sep '06

BGP Update Report Interval: 25-Aug-06 -to- 07-Sep-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4134 37938 2.8% 61.8 -- CHINANET-BACKBONE No.31,Jin-rong Street 2 - AS17974 18693 1.4% 36.9 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 3 - AS8685 13836 1.0% 406.9 -- DORUKNET DorukNet Istanbul / Turkey 4 - AS6197 11668 0.9% 11.3 -- BATI-ATL - BellSouth Network Solutions, Inc 5 - AS9121 11449 0.8% 97.0 -- TTNET TTnet Autonomous System 6 - AS15464 11391 0.8% 474.6 -- IHLASNET IHLASNET Autonomous System 7 - AS8386 10412 0.8% 433.8 -- KOCNET KOCNET-AS 8 - AS17557 10189 0.8% 28.4 -- PKTELECOM-AS-AP Pakistan Telecom 9 - AS15611 10017 0.7% 88.6 -- Iranian Research Organisation 10 - AS855 9974 0.7% 17.7 -- CANET-ASN-4 - Aliant Telecom 11 - AS34104 9297 0.7% 464.9 -- TELETEK-AS TELETEK TELEKOMINIKASYON HIZMETLERI A.S 12 - AS12497 8715 0.6% 174.3 -- SANET-GE SANET NETWORK (AS) 13 - AS7011 8589 0.6% 12.8 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 14 - AS33783 8176 0.6% 76.4 -- EEPAD 15 - AS4621 8164 0.6% 60.9 -- UNSPECIFIED UNINET-TH 16 - AS4787 8063 0.6% 30.2 -- ASN-CBN ASN CBNnet 17 - AS9394 8062 0.6% 17.6 -- CRNET CHINA RAILWAY Internet(CRNET) 18 - AS9021 7775 0.6% 555.4 -- ISNET ISBANKASI Autonomous System 19 - AS6198 7755 0.6% 15.0 -- BATI-MIA - BellSouth Network Solutions, Inc 20 - AS34695 7252 0.5% 164.8 -- E4A-AS E4A Primary AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3043 3039 0.2% 3039.0 -- AMPHIB-AS - Amphibian Media Corporation 2 - AS30298 988 0.1% 988.0 -- FIRST-AMERICAN-BANK-SSB - First American Bank 3 - AS34378 900 0.1% 900.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS12922 842 0.1% 842.0 -- MULTITRADE-AS Bank Outsourcer 5 - AS34984 794 0.1% 794.0 -- BITEL-AS BILISIM TELEKOM 6 - AS35080 784 0.1% 784.0 -- OYAK-TELEKOM-AS Oyak Telekom Hizm. BGP AS 7 - AS39298 762 0.1% 762.0 -- SERI Seri Bilgi Teknolojileri ve Destek Hizmetleri 8 - AS4271 1493 0.1% 746.5 -- WORX - Networx 9 - AS31526 745 0.1% 745.0 -- TEKOFAKS-AS TEKOFAKS 10 - AS29666 725 0.1% 725.0 -- TRHENKEL Turk Henkel Kimya Sanayi 11 - AS39080 721 0.1% 721.0 -- SIMETRI-AS SIMETRI YAZILIM 12 - AS31365 1432 0.1% 716.0 -- SGSTELEKOM SGS Telekom Autonomous System 13 - AS31085 711 0.1% 711.0 -- VIKINGNET-AS VIKING TUR 14 - AS29635 700 0.1% 700.0 -- BANVIT-AS Banvit A.S 15 - AS30734 682 0.1% 682.0 -- METISBILG-AS Metis Bilgi Sistemleri A.S 16 - AS31704 677 0.1% 677.0 -- ROBERTCOLLEGE-AS Robert College 17 - AS38920 676 0.1% 676.0 -- MNGBANK-TR Mng Turkiye 18 - AS39328 668 0.1% 668.0 -- BOTO-AS Borusan Oto 19 - AS31307 668 0.1% 668.0 -- YKYATIRIM YAPI KREDI YATIRIM 20 - AS29549 2646 0.2% 661.5 -- ZIRAATBANK-AS T.C. Ziraat Bankasi A.S. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.125.147.0/24 3980 0.2% AS17557 -- PKTELECOM-AS-AP Pakistan Telecom 2 - 208.0.225.0/24 3068 0.2% AS11139 -- CWRIN CW BARBADOS 3 - 209.140.24.0/24 3039 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 5 - 143.81.0.0/21 1618 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 6 - 205.98.32.0/20 1147 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 7 - 195.46.34.0/23 1013 0.1% AS31200 -- NTK Novotelecom ltd. 8 - 216.85.162.0/23 1001 0.1% AS6467 -- ESPIRECOMM - Xspedius Communications Co. 9 - 209.189.231.0/24 988 0.1% AS30298 -- FIRST-AMERICAN-BANK-SSB - First American Bank 10 - 205.97.69.0/24 933 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 11 - 130.36.88.0/21 931 0.1% AS2686 -- AT&T Global Network Services - EMEA 12 - 205.97.70.0/24 930 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 13 - 80.64.80.0/23 928 0.1% AS31200 -- NTK Novotelecom ltd. 14 - 193.242.123.0/24 900 0.1% AS34378 -- RUG-AS Razguliay-UKRROS Group 15 - 217.195.192.0/21 843 0.1% AS9121 -- TTNET TTnet Autonomous System 16 - 194.105.61.0/24 842 0.1% AS12922 -- MULTITRADE-AS Bank Outsourcer 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 18 - 216.51.192.0/18 808 0.1% AS5056 -- INS-NET-2 - Iowa Network Services 19 - 213.91.174.0/24 800 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 20 - 85.29.0.0/18 794 0.1% AS34984 -- BITEL-AS BILISIM TELEKOM Details at http://bgpupdates.potaroo.net ------------------------------------ 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 ausnog(a)ausnog.net

13 12

apple.com/mac.com Postmaster Contacts
by Tom Daly 10 Sep '06

10 Sep '06

Hi Folks, Does anyone have specific contact information for apple.com or mac.com postmasters? I've tried the standard postmaster/hostmaster addresses at both domains, with no response/autoresponders, etc. If you have this information available and are willing to share, please contact me of list. Thanks, Tom Daly -- Thomas J. Daly tom(a)dyndns.com Dynamic Network Services, Inc. http://www.dyndns.com/

1 0

Multiple BGP Routes in FIB
by Glen Kent 10 Sep '06

10 Sep '06

Hi, There is an interesting discussion going on in the IDR WG and i am cross posting a mail on Nanog to hear from the operators, if what is described below, a common practise followed by them: >> >> I don't think its correct to advertise one while using both for >> >> forwarding. >> >> NOTE: I am assuming that the routes share the same path length but have >> >> different AS Paths (as mentioned by you earlier in this mail) >> > >> > I think this is being done by many providers. >> >> Consider two paths for nlri X >> >> as_path 1 {x y z} next_hop n1 >> as_path 2 {m n z} next_hop n2 >> >> Are you suggesting that providers are installing ecmp routes for X with >> next-hops n1 and n2, while advertising only one of the paths to their IBGP >> peers? >> > Yes. Do providers really do this? Would they install multiple BGP Paths with different AS Paths (but same length) in their FIB, and yet advertise only one? Is the the right thing to do? Glen

4 4

Re: portability... HAH!
by Fergie 10 Sep '06

10 Sep '06

-- bmanning(a)vacation.karoshi.com wrote: [snip] >man I'd love to live in your universe... or are you suggesting >that things have evolved in the last decade to the point that the >ostensible goal of the IETF PIER wg can finally be met, to >completely renumber the entire Internet every 20 minutes... :) Man, I remember that vaguely. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Fergie 09 Sep '06

09 Sep '06

-- "Stephen Sprunk" <stephen(a)sprunk.org> wrote: >The entire suit is predicated on the concept that IP addresses can >be owned and traded like other property. The rest is a house of >cards that will fall if ARIN can prove that to be incorrect -- and >will probably stand if they can't. [snip] I like how Jack Bates framed it: The IP address space is a "community asset" and as such, the allocation of it needs to be done in a way which serves & benefits the Internet community at-large. That said, we have had this discussion many times over the years, especially within IEPG discussions, and punching holes in CIDR blocks, for the sake of alighning address space w.r.t. special interests (as opposed to some sanity in allocation policy which attempts to preserve allocation to allow CIDR aggregation) is a Bad Thing. It will be interesing to see how this plays out... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: Data Center Wiring Standards
by Frank Coluccio 09 Sep '06

09 Sep '06

I would add to the recommendations already stated by Mark and John the folllowing: Depending on the dimensions of the colo in question and the length of the cabling runs you plan to install, take note of the distance limitations of STP for DS1 signals and the in-house coaxial connections for DS3 signals and higher, which are (were) governed by ANSI/Bellcore, the last time I looked. Fiber, likewise, must be coordinated with network element interfaces (GBICs, ST, etc.) and here again distance is a major consideration. The latter may become an issue in large structures, or in the event that you plan to run media between buildings, or if you plan to interconnect with service providers at the f-o level (Layer1). For your optical media and connection hardware (patch panels, raceways, etc.), have a long hard talk with at least two reputable fiber optic cable suppliers (e.g., Corning, CommScope, Sumitomo, etc.) and develop an understanding about the limitations and advantages of the various s-m and m-m options you have available to you, per the types of solutions you need to implement and the distances they dictate. Incoming fiber from the street (dark fiber providers, included) will be single-mode, primarily, but the preponderance of your in-house cabling between switches, routers and servers, if fiber distances are indicated, will be multi-mode, requiring a different patch bay selection. Where distances permit (<100 meter channels) UTP should suffice for Ethernet speeds up to 10Gb/sec now, with 10Gb/sec (10GBASE-T) ratified only recently (I'm quite certain), but I suggest reading the following article from Cabling Installation & Maintenance Magazine, just the same. http://tinyurl.com/mrack Note, Cat5e and vanilla Cat6 will not suffice (perhaps a Cat6A will, not sure at this stage, but do your homework before purchasing anyone's Cat7) for 10GbE (it may work, but your hardware vendors will not honor warranties when problems arise), so be prepared to make some long range planning decisions in coming to terms with a cabling plant that's going to last you a while. HTH. Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile On Fri Sep 8 23:31 , John L Lee sent: > > > > > > > >Rick, > > > >The organization and standards you are looking for are: > > > >BICSI - http://www.bicsi.org/ and TIA/EIA 568 et al for structured >cabling design for low voltage distribution. > > > >The BICSI organization has training and certification for RCDD >Registered Communications Distribution Designer > > > >A BICSI article that is on there web site about data center design is >http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf. > > > >TIA/EIA 568(ab) how ever many they are up to discuss structured cabling >design for UTP/STP/fiber/coax including patch cables single and multi >pair UTP/STP/fiber patch panels, HVAC control, fire system control >and security systems. > > > >John (ISDN) Lee > > > > > > > >Rick Kunkel wrote: > > > Heya folks, > >I hope this is on-topic. I read the charter, and it falls somewhere along >the fuzzy border I think... > >Can anyone tell me the standard way to deal with patch panels, racks, and >switches in a data center used for colocation? I've a sneaking suspicion >that we're doing it in a fairly non-scalable way. (I am not responsible >for the current method, and I think I'm glad to say that.) Strangely >enough, I can find like NO resources on this. I've spent the better part >of two hours looking. > >Right now, we have a rack filled with nothing but patch panels. We have >some switches in another rack, and colocation customers scattered around >other racks. When a new customer comes in, we run a long wire from their >computer(s) and/or other device(s) to the patch panel. Then, from the >appropriate block connectors on the back of the panel, we run another wire >that terminates in a RJ-45 to plug into the switch. > >Sounds bonkers I think, doesn't it? > >My thoughts go like this: We put a patch panel in each rack. Each of >these patch panels is permanently (more or less) wired to a patch panel in >our main patch cabinet. So, essentially what you've got is a main patch >cabinet with a patch panel that corresponds to a patch panel in each other >cabinet. Making connection is cinchy and only requires 3-6 foot >off-the-shelf cables. > >Does that sound more correct? > >I talked to someone else in the office here, and they believe that they've >seen it done with a switch in each cabinet, although they couldn't >remember is there was a patch panel as well. If you're running 802.1q >trunks between a bunch of switches (no patch-panels needed), I can see >that working too, I suppose. > >Any standards? Best practices? Suggestions? Resources, in the form of >books, web pages, RFCs, or white papers? > >Thanks! > >Rick Kunkel > > > > > > >

1 0

TCP receive window set to 0; DoS or not?
by Travis Hassloch 09 Sep '06

09 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New listener, first-time caller. I've been seeing some systems that stop serving pages, and I also see the Linux "Treason Uncloaked!" kernel messages that indicate a remote system reduced its rcv win from 1 to 0... is there a non-malicious explanation for this, aside from a remote host running out of socket buffers? Seems to happen too often for that to be the case, and my googling has shown that it may be outside of spec. Certainly the warning is clear enough... - -- The whole point of the Internet is that different kinds of computers can interoperate. Every time you see a web site that only supports certain browsers or operating systems, they clearly don't get it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAI+QPlSPhv5tocwRAg5hAKCBNvX4U8hAmtfnGImRug5t1IUoBACfbXlS kNJe5BAexBENqtsb1TULL3I= =2Cit -----END PGP SIGNATURE-----

6 8

RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Fergie 08 Sep '06

08 Sep '06

Don't be so sure. What probably _would_ police these willy-nilly announcements, however, are prefix-length filters on the various ISP routers. :-) And again, this could certainly lend itself to folks sic'ing their lawyers on eacvh other in the name of anti-competitive lawsuits. A mess ensues that I don't think any of us wishes to see happen. - ferg -- <andrew2(a)one.net> wrote: > Another somewhat important point is that we also need to conserve routing entries. If you make a market for addresses without regard to routability, you risk > creating a situation where you flood the world with /32's. No thanks. > > Tony I would think that would tend to police itself. Even now with things as they are you're going to have serious reachability problems if you try to announce anything smaller than a /24. And if routing tables suddenly explode, I'd expect that threshold to quickly move in reaction. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0