- NANOG - lists.nanog.org

Increasing cable theft and outages
by Sean Donelan 07 Feb '08

07 Feb '08

While the conspiracy folks go crazy, cable outages are pretty much normal and increasing around the world as the price of copper increases and thieves get confused about what cables contain copper. http://www.signonsandiego.com/news/nation/20080203-1044-wst-coppercrime.html Thieves hacked up and hauled away three miles of telephone and Internet cable along the twisting mountain road leading to the remote location, apparently to sell on the thriving scrap market for copper. Burying a new cable will cost an estimated $3.2 million, so monument Supervisor Craig Ackerman is working on a microwave link. http://seattletimes.nwsource.com/html/localnews/2004141330_webphonetheft23m… Qwest workers spent most of Friday repairing vandalism to about 6,200 feet of fiber-optic cable that was cut in Kelso, and as they were headed home about 12:30 a.m. Saturday they were dispatched to handle another outage that cut long-distance service to 20,000 customers in Pacific and western Wahkiakum counties in Washington and Clatsop County, Ore. http://news.bbc.co.uk/2/hi/uk_news/england/hampshire/7184010.stm Network Rail said there had been more than 1,000 incidents of copper cable theft in the last year, costing more than #4m. http://www.channelregister.co.uk/2007/06/07/vietnam_fishermen_vs_cables/ Vietnam telecom officials estimate it will take at least a month and cost over $5.84m to fix damaged undersea fiber-optic cables stolen by fishermen for salvage.

4 3

RE: Fourth cable damaged in Middle Eest (Qatar to UAE)
by Frank Coluccio 07 Feb '08

07 Feb '08

Today's MIT Technology Review newsletter contains an article by John Borland, aided in large part by Tim Strong of Telegeography Research, covering the recent spate of submarine cable failures in the ME: Analyzing the Internet Collapse By John Borland | Feb 5, 2008 MIT Technology Review Multiple fiber cuts to undersea cables show the fragility of the Internet at its choke points. http://www.technologyreview.com/Infotech/20152/?nlid=854 -- A few afterthoughts after receiving a number of offlist mailings responding to my earlier post of yesterday concerning the naval submarine, Jimmy Carter: My comments weren't intended as disparagement or as a means of denigrating most of the excellent material that was posted on this subject. They were, instead, merely cautionary in nature, intended primarily for students who frequent NANOG for research and general interest, after noticing some folk lore and widely-held misconceptions being introduced into the thread. Upon re-reading those, however, they turn out to be mostly trivial, at worst. Besides, some would argue that passing down folk lore to the next generation of practitioners is not only a good thing, but a necessary thing, lest we get too caught up in being precise ;) On my posting about the naval submarine Jimmy Carter, that was half-intended as entertainment, although some of the dubious-seeming points made in that article have now been borne out in later releases by Egypt's telecommunications ministry in asserting that, indeed, there were no vessels in the waters surrounding the breaks, as is also noted in the reference MIT TR article above. Frank A. Coluccio DTI Consulting Inc. 347-526-6788

5 4

Repotting report
by Iljitsch van Beijnum 06 Feb '08

06 Feb '08

# dig @f.root-servers.net ns . +bufsize=1280 ; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . +bufsize=1280 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17525 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:28:37 2008 ;; MSG SIZE rcvd: 615 So far so good. But with a default buffer size: # dig @f.root-servers.net ns . ; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45287 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 ;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:29:20 2008 ;; MSG SIZE rcvd: 500 At the time of this writing A just went live, after F and M and some others, but B, C, D and G seem to need a bit more time to get used to the new situation.

9 17

Charter Communications/AS22291 peering issues
by Kameron Gasso 06 Feb '08

06 Feb '08

Anyone from Charter Communications NW (AS22291) on-list? Or, more specifically, someone who has access to the Medford, OR core? You're advertising routes to us which have a nexthop set in RFC1918 address space -- which you're also advertising, but we're filtering. For the time being, I've added a permit statement to our prefix-lists to allow a small portion of this space that you're currently advertising, but this isn't really optimal and I'd like to bring it to someone's attention... Our account rep has apparently disappeared recently, and your call center states that they know nothing about BGP -- and to contact our account rep. :) Sorry for the spam to the list, but I've exhausted all other means of contact for getting this fixed... Thanks! -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821

1 0

Route Reflector full mesh
by Adhy 06 Feb '08

06 Feb '08

Hi list, Is it possible to prove that if we have 3 RRs with each has different cluster ID and each pointing to each other may create loop ? What I've been doing is to simulate (not simulate by doing it on simulator, but by drawing it on visio) BGP update mesg if the update comes from eBGP then it propagates throughout the network. Please refer this simplified topology below. +--------+ +-------+ | | | | | RR1 | --------- | RR2 | | | client | | +-------+ +--------+ \ / client \ ASX / client \ / +-------+ | | | RR3 | | | +-------+ Note : 1. RR1 is RR on the cluster ID 1 2. RR2 is RR on the cluster ID 2 3. RR3 is RR on the cluster ID 3 4. each RR is pointing to each other as a RR client (not iBGP peer) 5. on each cluster there are more than one RR client >From what I understand, this kind of topology is _not_ recommended (I refer to http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#wp7158) But I really need to prove it(to show it to my client). I've checked the specs (rfc4456) and try to follow the route reflection behavior based on the specs. It leaves me with more headache. So please bear with me with another questions as follow : 1. If the update is propagated from RR1 to RR2 then RR3, will the ORIGINATOR_ID on the update mesg still RR1 ? 2. and will the CLUSTER_LIST being used ? the cisco specs only said that the CLUSTER_LIST being used if the update mesg is reflected from clients to non clients. how about from clients to other client (which this client also a RR for another cluster) ? I've assumed that both ORIGINATOR_ID and CLUSTER_LIST is always used when route is being reflected and come to conclusion that the loops will not occur. Is it correct ? Any comments will be appreciated. thanks. regards, -- -adhy

2 1

Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
by Suresh Ramasubramanian 06 Feb '08

06 Feb '08

http://www.marketwatch.com/news/story/third-undersea-cable-reportedly-cut/s… "We had another cut today between Dubai and Muscat three hours back. The cable was about 80G capacity, it had telephone, Internet data, everything," one Flag official, who declined to be named, told Zawya Dow Jones. The cable, known as Falcon, delivers services to countries in the Mediterranean and Gulf region, he added. etc etc. On Jan 31, 2008 10:05 PM, Martin Hannigan <hannigan(a)gmail.com> wrote: > > On Jan 31, 2008 11:20 AM, Rod Beck <Rod.Beck(a)hiberniaatlantic.com> wrote: > > > > > > > > http://www.kisca.org.uk/Web_SWApproaches.pdf > > > > And if you enlarge the map, you can see little dots on the lines > > representing the cables that denote repairs. > > > > Lots and lots of repairs. Treacherous waters. > > > > > > > The distances are consistent with repeaters/op amps. And the chart > legend notates the same. > > Coincidentally, Telecom Egypt announced a new cable to be built by > Alcatel-Lucent this morning. TE North, which looks like it's going > from Egypt to France, is an 8 pair system (128 x 10Gb/s x 8). > > Thanks for your input. > > -M< > -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

13 20

Re: Fourth cable damaged in Middle Eest (Qatar to UAE)
by Hascall Sharp 05 Feb '08

05 Feb '08

For Lebanon: Here is the MPT's web site on submarine cables: http://www.mpt.gov.lb/berytar.htm It has links to aletar and cadmos as well. Chip Sharp Marshall Eubanks wrote: > > Dear Sean; > > Do you know how Syria, Jordan and Lebanon get their connectivity ? > They have dropped off the map today for us. (Or maybe yesterday - I > wasn't able to pay any attention to this yesterday.) > > Our Egyptian audience remains very low, while Iran still seems to be > unaffected. > > Regards > Marshall > > > On Feb 3, 2008, at 6:52 PM, Sean Donelan wrote: > >> >> >> A fourth submarine cable in the middle east was damaged Sunday >> between Haloul, Qatar and Das, United Arab Emirates. >> >> This is in addition to the damage affecting FLAG, SAE-ME-WE4, FALCON >> cables. >> >> Afer reviewing surveillance video of the area, Egypt's ministry of >> maritime transportation is reporting no ships were near the FLAG or >> SAE-ME-WE4 cables 12-hours before or after the cable damage near >> Alexanderia, Egypt. The reason for outage of the cables has >> not been identified yet. >> >> >

1 0

"1 million" routes
by Jon Lewis 05 Feb '08

05 Feb '08

On paper, the Sup720-3bxl does 1 million routes. The reality is, the default config allows for: L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 524288 229921 44% 144 bits (IP mcast, IPv6) 262144 5 1% So, with not quite full BGP routes, my lab sup720 is at 44% capacity for IPv4 routes. This is tunable via "mls cef maximum-routes ..." IPv6 route slots can be traded for 2 IPv4 slots (after a reboot). FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 770048 229899 30% 144 bits (IP mcast, IPv6) 139264 5 1% So...how many IPv6 routes are people seeing/expecting? Are you running with the default split, figuring if/when the time comes, you'll adjust and reboot? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

Re: Fourth cable damaged in Middle Eest (Qatar to UAE)
by ' =JeffH ' 05 Feb '08

05 Feb '08

frank(a)dticonsulting.com said: > A few afterthoughts after receiving a number of offlist mailings responding > to my earlier post of yesterday concerning the naval submarine, Jimmy Carter I will have to read up on that boat. apropos this subthread, I recommend these two books (I've read both) that lend insight to what can be candelstinedly accomplished below the surface: Dark Waters: Insider's account of the NR-1 http://www.nr-1-book.com/ NR-1 http://www.fas.org/man/dod-101/sys/ship/nr-1.htm Blind Man's Bluff: The Untold Story of American Submarine Espionage By Sherry Sontag, Christopher Drew <http://books.google.com/books?id=IpUggPJL4t4C&printsec=frontcover&vq=blind+… s+bluff> SSN-21 Seawolf-class http://www.fas.org/man/dod-101/sys/ship/ssn-21.htm =JeffH

1 0

named.root (was: Yay! AAAA records added for root servers)
by David Freedman 05 Feb '08

05 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shame its not made it to HTTP yet: $ lynx --source http://www.internic.net/zones/named.root | grep A | wc -l ~ 17 $ lynx --source http://www.internic.net/zones/named.root | grep AAAA | wc -l ~ 0 $ lynx --source http://www.internic.net/zones/named.root | grep "last update" ; last update: Nov 01, 2007 vs $ lynx --source ftp://rs.internic.net/domain/named.root | grep AAAA | wc -l ~ 6 $ lynx --source ftp://rs.internic.net/domain/named.root | grep "last update" ; last update: Feb 04, 2008 Apologies for the crosspost Dave. Mike Leber wrote: | For anybody that hasn't already seen this, a note of celebration is in | order. Hurrah! | | dig @f.root-servers.net ns . +bufsize=1280 | | ; <<>> DiG 9.3.4 <<>> @f.root-servers.net ns . +bufsize=1280 | ; (2 servers found) | ;; global options: printcmd | ;; Got answer: | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24611 | ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 | | ;; OPT PSEUDOSECTION: | ; EDNS: version: 0, flags:; udp: 4096 | ;; QUESTION SECTION: | ;. IN NS | | ;; ANSWER SECTION: | . 518400 IN NS K.ROOT-SERVERS.NET. | . 518400 IN NS L.ROOT-SERVERS.NET. | . 518400 IN NS M.ROOT-SERVERS.NET. | . 518400 IN NS A.ROOT-SERVERS.NET. | . 518400 IN NS B.ROOT-SERVERS.NET. | . 518400 IN NS C.ROOT-SERVERS.NET. | . 518400 IN NS D.ROOT-SERVERS.NET. | . 518400 IN NS E.ROOT-SERVERS.NET. | . 518400 IN NS F.ROOT-SERVERS.NET. | . 518400 IN NS G.ROOT-SERVERS.NET. | . 518400 IN NS H.ROOT-SERVERS.NET. | . 518400 IN NS I.ROOT-SERVERS.NET. | . 518400 IN NS J.ROOT-SERVERS.NET. | | ;; ADDITIONAL SECTION: | A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 | A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 | B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 | C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 | D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 | E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 | F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 | F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f | G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 | H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 | H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 | I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 | J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 | J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 | K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 | K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 | L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 | M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 | M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 | | ;; Query time: 2 msec | ;; SERVER: 2001:500:2f::f#53(2001:500:2f::f) | ;; WHEN: Mon Feb 4 20:47:08 2008 | ;; MSG SIZE rcvd: 615 | | | +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | | Hurricane Electric Web Hosting Colocation AS6939 | | | mleber(a)he.net http://he.net | | +-----------------------------------------------------------------------+ | | - -- David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqFXPtFWeqpgEZrIRAvvsAJ47N60cunJmfbvCM5DyhVDOtUTMsQCguYQ9 c/iscQyuP4Xaf5NVdKRwYF4= =MJCW -----END PGP SIGNATURE-----

3 5