- Test - lists.nanog.org

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

AAAAs in the Root and /48 Filtering
by Scalzo, Frank 05 Feb '08

05 Feb '08

All, As you may be aware, the DNS root zone will be updated on Monday, February 4, with AAAA resource records for six of the root servers. (Please see http://iana.org/reports/root-aaaa-announcement.html for IANA's official announcement.) In preparation for this change, we have noticed that some sites seem to be having reachability problems to the new root server IPv6 addresses that are located in critical infrastructure Micro-allocations (/47s or /48s), but not to the root servers located in /32s. Further testing has shown that we can ping these sites experiencing reachability problems when sourcing the provider allocated (PA) space on our links that aggregates up to a /32, but not when sourcing from the provider independent (PI) /48s of our root servers. With the AAAA RRs going into the root zone on Monday, now is a good time to check your IPv6 route filters. To prevent reachability problems, network operators should update IPv6 route filters to permit up to at least /48s from the appropriate RIR Micro-allocation blocks. I tried to gather as many of these blocks as I could find from the RIRs. Notably, I wasn't able to identify anything from AfriNIC -- hopefully someone on the list will be able to fill in that gap. This list is not meant to be complete nor authoritative, but it does cover all of the root server IPv6 addresses that are going live on Monday (that we are aware of) and that are in blocks allocated as /47s or 48s. That being said, please accept at least /48s from these blocks ASAP, or your network may experience reachability problems to the IPv6 root servers. ARIN (http://www.arin.net/reference/micro_allocations.html, http://www.arin.net/policy/nrpm.html#six10) 2001:0500::/30 RIPE (https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html) 2001:7F8::/29 APNIC (http://www.apnic.net/db/min-alloc.html) 2001:0C00:/23 2001:07FA:/32 LACNIC (http://lacnic.net/en/registro/index.html) 2001:12f8:0000::/35 2001:12f8:4000::/35 If you are having IPv6 reachability problems to the V6 IP addresses for a.root-servers.net and j.root-servers.net (2001:503:BA3e::2:30 and 2001:503:C27::2:30) please feel free to contact us. We may be able to assist in getting filters updated or working around any connectivity issues. Thank you, Frank Scalzo VeriSign

3 3

FW: [menog] FLAG Cable Cut - Update
by Barry Greene (bgreene) 05 Feb '08

05 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Reposted with author's permission.] + Notice that there are more issues than what is reported in the popular press. + Notice that there are issues with more submarine systems (APCN), but they are not "news." As has been pointed out before, there are always issues with submarine systems. That is why we have so many repair ships in the global fleet: http://www.iscpc.org/information/Cableships_1.htm http://www.iscpc.org/information/Cableships_2.htm ==================================== http://www.flagtelecom.com/media/PDF_files/Submarine%20Cable%20Cut%20U pdate% 20Bulletin%20Release%20050208.pdf - -----Original Message----- From: menog-bounces(a)menog.net [mailto:menog-bounces@menog.net] On Behalf Of Sanghani, Bijal Sent: Tuesday, February 05, 2008 1:26 AM To: menog(a)menog.net Subject: [menog] FLAG Cable Cut - Update Dear All, Thought I'd give you all an update on where we (FLAG) are with the cable cuts - FEA Segment D - The Cable ship CS Certamen is now expected to arrive at the Alexandria repair ground on Wednesday 6th February. A Permit for the repair is currently being expedited with the Egyptian authorities. FEA Segment M - The cable ship CS Asean Restorer has been booked for this repair. It is currently out on an APCN repair and with current plan will be ready to start any work on our cable on or after 11th Feb. We have the OTDR traces from Penang and see that the fault is around 28km out from the station. FALCON Segment 7b (Bandra Abbas - Al Seeb) - E-Marine continues to await the permit to enter the Iranian waters and current forecast for the ship to start a work is around 19th February. FALCON Segment 2 - Fault 1st February 41km from repeater, which is between the first two repeaters out of Dubai toward Muscat (Al Seeb). The ship has left Abu Dhabi and is on route to the repair ground. The repair is expected to start in the next 12 hours (weather permitting). FALCON Segment 7a - Fault 1st February between BND (Bandar Abbas, Iran) and KWI (Kuwait), we are waiting for ship to go out and it maybe fixed before going out the fault on 7b - to be confirmed. I hope this helps, Regards, Bijal Sanghani Sr. IP Technical Support Engineer Technical Services Group FLAG Telecom Tel. +442 082 821 564 www.flagtelecom.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR6hEeb/UEA/xivvmEQL5YgCg9tX2lZmq937MhRd65qm0wk9EYPUAniED VAxSCsr92aysSkrs6dGspaVm =45sb -----END PGP SIGNATURE-----

1 0