September 2007 - Test - lists.nanog.org

Trouble with Marconi ASX-200BX
by Bjoern 21 Sep '07

21 Sep '07

Hi, sorry for a little offtopic. But i don´t knew a better place for hopefully find help. We had a little trouble when trying to configure a "new" Marconi Fore ASX-200BX ATM Switch with an running config from another Marconi ASX-200BX. Some of the config commands, seemed not to be known by the newer Foreos 7.1 on the "new". we tried to do downgrade the Foreos on the "new" Marconi Fore ASX-200BX ATM Switch. Installed was Foreos7.1 on a Pentium based SCP (SCP-ASXp5), careless we decided to delete the whole files and wanted to copy the Foreos7.0 files from another System. We backuped the Files to a tftp server, and then we deleted the folders :( No we have the Problem, that we could not create a folder LD7.0 to copy the files from the other System. And we can´t go back with the saved files, because we was to fast to delete the LD7.1 folder :( We have access to Webfrontend and console. But i´m afraid that the SCP is electronic trash if i try to boot now. I think there are 2 possible solutions to solve our Problem: 1. someone could tell us, how to create a folder and we copy the saved files back to the flash Looking back and thinking about what we have tried, and realization how naive we have acted, in my eyes the best way. 2. We make a "system uprade" and this upgrade will recreate the files. Our Problem with the second solution is, that we can´t find a download link for a System upgrade file, like discriped in the manual. We tried to get an public account for the Software http://tactics.marconi.com/services/index.cgi?loadPage=software/software.cg… But we did not get an answer on our request since more then 2 days. Could anyone help us ? Or did we create electronic trash? thanks Bjoern

1 0

Question on Loosely Synchronized Router Clocks
by Xin Liu 20 Sep '07

20 Sep '07

Dear Nanogers, We are a bunch of academic researchers interested in Internet security. We notice that some research papers require that BGP router clocks be globally synchronized to a 5-minute granularity. If a router's clock is off by more than 5 minutes, it cannot forward packets, but there's no other side effect. From an operational point of view, do you think it is a practical requirement? If not, what are the potential problems that prevent router clocks from being loosely synchronized? If you consider 5-minute too small, what do you consider as a practical clock skew requirement for BGP routers on the Internet? We'd appreciate your input very much. It will help us understand what's practical and what's not in our work. Please reply to us directly. Thanks, Xin Liu

17 26

ticket research
by Randy Bush 20 Sep '07

20 Sep '07

a respected researcher (with a grad student) i trust wants to > obtain trouble ticket logs from different networks to understand the > nature of failures in ISP networks. we hope that this analysis will > help us develop troubleshooting techniques. they have some data already from abiline and a large euro telco. further, > we can sign NDAs if needed and we'll anonymize the data before > publishing. they realize that such data are extremely sensitive. and also know that they are buried in kinky databases etc. but one has to try. ( and let's try not to rat-hole on nanog about why this is good, insane, will cause starvation in iowa, might end global warming, ... :) if you think you might be willing to help, drop me a note and i will introduce you. thanks. randy

2 1

Level 3 in Ohio
by Marshall Eubanks 20 Sep '07

20 Sep '07

Is anyone reporting Level3 outages in Ohio or DC ? One of my clients is down, and L3 is not answering the phones (!) traceroute 65.89.42.1 (From Cogent in Tyson's Corner) traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets 1 dmz-mct2.multicasttech.com (63.105.122.1) 0.367 ms 0.265 ms 0.238 ms 2 g0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.598 ms 0.548 ms 0.529 ms 3 g2-1-3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 0.862 ms 0.834 ms 0.740 ms 4 t4-1.mpd01.dca01.atlas.cogentco.com (154.54.3.158) 0.801 ms 0.879 ms * 5 v3493.mpd01.dca02.atlas.cogentco.com (154.54.7.2) 1.328 ms 1.311 ms 1.247 ms 6 t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162) 1.693 ms 1.598 ms 1.605 ms 7 g4-0-3490.core01.iad01.atlas.cogentco.com (154.54.3.225) 1.411 ms 1.453 ms 1.552 ms 8 oc48-6-0-2.edge2.Washington3.Level3.net (4.68.127.9) 1.577 ms 1.588 ms 16.498 ms 9 ae-44-99.car4.Washington1.Level3.net (4.68.17.198) 2.766 ms ae-24-79.car4.Washington1.Level3.net (4.68.17.70) 3.282 ms ae-34-89.car4.Washington1.Level3.net (4.68.17.134) 2.808 ms <time out> Cox Cable in Northern Virginia [TME-Laptop-2:~/Movies/NoisiVision] tme% traceroute 65.89.42.1 traceroute to 65.89.42.1 (65.89.42.1), 64 hops max, 40 byte packets 1 * * * 2 ip70-179-104-1.dc.dc.cox.net (70.179.104.1) 14.989 ms 11.563 ms 11.782 ms 3 ip68-100-1-161.dc.dc.cox.net (68.100.1.161) 18.078 ms 12.329 ms 12.036 ms 4 ip68-100-0-1.dc.dc.cox.net (68.100.0.1) 13.368 ms 12.301 ms 11.960 ms 5 mrfddsrj01-ge110.rd.dc.cox.net (68.100.0.161) 12.504 ms 11.729 ms * 6 xe-9-2-0.edge1.washington1.level3.net (4.79.228.61) 59.189 ms 12.721 ms 11.749 ms 7 ae-44-99.car4.washington1.level3.net (4.68.17.198) 13.502 ms 13.389 ms ae-34-89.car4.washington1.level3.net (4.68.17.134) 14.290 ms <time out> (Note that both trace routes appear to be flapping at the last reported hop. Regards Marshall

3 3

dotted AS numbers in asn.txt
by Andreas Ott 20 Sep '07

20 Sep '07

Hi, since when does ftp://ftp.arin.net/info/asn.txt contain dotted AS numbers? Where is the new formatting documented, asn.h ? It just broke a scriptology we use to generate AS lookups for 'offline' customers (please don't ask :) ). $ head -2 asn.txt [asn.txt] 2007-09-19 02:45:00Z $ tail -7 asn.txt [reformatted some whitespace here] 44032-64511 IANA-RSVD IANA-IP-ARIN (Abuse) 64512-65535 IANA-RSVD2 IANA-IP-ARIN (Abuse) 6.0 B6 WM110-ARIN (Tech) 6.1 ASN4-TELUS AAT-ARIN (Abuse), FTS1-ARIN (Tech), TBOTP-ARIN (Tech) 6.3 H6 KML9-ARIN (Tech) 6.5 ISC-32AS ISCAT-ARIN (Abuse), JDA87-ARIN (Tech) 6.6 BLUEFIN-TRADING HOSTM912-ARIN (Abuse) "Your search - AS number 6.5 ISC32-AS - did not match any documents. " Thanks, andreas -- Andreas Ott K6OTT andreas(a)naund.org

6 5

APRICOT CFP
by Randy Bush 20 Sep '07

20 Sep '07

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) Taipei, Taiwan 20 - 29 February 2008 http://www.apricot2008.net Summary Call for Papers --------------------- Please submit online at http://submission.apricot.net/paper/user/login.php?event=7 The APRICOT 2008 Program Committee is now seeking contributions to the program. This is the main call for Presentations & Tutorials before the final program is fixed. We would like to give people the opportunity to submit their proposals early and to encourage people in the Asia Pacific region who have not previously presented their work to do so. They key dates are Call for Papers Opens: 1 July 2007 Deadline for Speaker Submissions: 30 September 2007 First Draft Program Published: 15 October 2007 Final Program Published: 15 January 2008 Topics of interest to the network operations community are invited for both tutorial and conference presentation. APRICOT also co-hosts the APNIC members' meeting, Asia Broadband Summit, Asia Pacific IPv6 Task Force meeting, as well as the members meeting of Asia Pacific Top Level Domains, making it the largest network operations meeting in the region. The full cfp is at : http://submission.apricot.net/apricot08-cfp.htm You can make your submissions online at : http://submission.apricot.net/paper/user/login.php?event=7 Thanks APRICOT Program Committee

1 0

RH0 and Enterprise Input
by Azinger, Marla 20 Sep '07

20 Sep '07

Nanogers- Specifically Enterprise nogers. Not sure if you are aware of this IETF draft on RH0. Its in last call. So if you want to voice your opinion on whether you feel everyone should stop the traffic "that has RH0 headers" from moving on or just ignore it and let it on by, you will need to make your voice heard now. For the most part everyone is ok with this draft because it doesnt effect them and it helps address a security issue. I havnt heard a large voice from the Enterprise arena who might actually need the traffic to be passed on and not stopped. Thus, my posting this on nanog. -Cheers! Marla Official last call notice: > The IESG has received a request from the IP Version 6 Working Group WG > (ipv6) to consider the following document: > > - 'Deprecation of Type 0 Routing Headers in IPv6 ' > <draft-ietf-ipv6-deprecate-rh0-01.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf(a)ietf.org mailing lists by 2007-09-24. Exceptionally, > comments may be sent to iesg(a)ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt AD's follow-up: > I wanted to mention a few points regarding this > document, given that the matter has been the > subject of some controversy. There was clear > consensus in the WG for picking this approach, > but it was also a rough consensus, with a number > of differing opinions. > > One of the concerns was that the discussed > vulnerabilities do not justify changing the > specifications. > > First, this is not the first or the last time we find > security issues or other bugs in our protocols. > This particular issue has gotten more interest > than it probably deserves; as bugs and changes > go, its a very small one. But this does not imply > that we can forget it and do nothing. The IETF > is responsible for its specifications much the same > way as vendors are responsible for their products. > When there's a bug or a security vulnerability in > our specifications, it is our duty to take notice > and take appropriate action. Perhaps we can debate > what that action should be, but it most certainly > should include documentation of the issue, and > in some cases modification of the spec in question. > I personally want to ensure that IETF specifications > and the real world are in sync, both in terms of > describing what implementations actually do, and > in the specifications being complete descriptions > of the issues that one must think about. No one > should have to hunt list discussions and operational > folklore to find out how to implement key parts of > our protocol stacks. > > A similar concern was why IPv6 is being treated > differently from IPv4, which has similar source > routing features. But there is a fairly big difference > between the features when looking at the details. > Specifically, IPv6 allows a much larger number of > addresses to be used in the routing list, resulting > in a greater potential for amplification. (But frankly, > I suspect that even in IPv4 we have a difference > between what our RFCs say and what the true > implementation and operational practice is. > Maybe the by-default-on rule from RFC 1812 should > be revisited. Once we are done with this document > we need to look at the IPv4 situation as well.) > > Another concern is that if Type 0 Route Header is > deprecated, it is hard to bring back, if we later > find out that we need it. However, new Types can be > defined with relative ease -- in fact, I have personal > experience of this in RFC 3775, and the process > was smooth, I can recommend it. > > Finally, a process note required by our downref > process: The document Updates both RFC 2460 > (core IPv6 spec, DS) by removing functionality and > RFC 4294 (IPv6 node requirements, Informational) > while itself being destined for PS. > > Jari Arkko > AD for IPv6 WG

1 0

RE: dotted AS numbers in asn.txt
by tariq biziou 19 Sep '07

19 Sep '07

> since when does ftp://ftp.arin.net/info/asn.txt contain dotted AS numbers? 32 bit ASNs > Where is the new formatting documented, asn.h ? many locations, arin for instance talks about it here: http://www.arin.net/policy/nrpm.html#five1 -- --tariq

1 0

Welcome Marty Hannigan to the MLC
by Joe Abley 19 Sep '07

19 Sep '07

People of NANOG, Marty Hannigan volunteered to join the MLC in response to our (somewhat) recent call for volunteers, and the NANOG SC has decided to take him up on his generous offer of time and energy. Welcome, Marty, to the MLC. Joe

1 0

[Fwd: [Outages] FW: SMC INITIAL OUTAGE NOTIFICATION: MULTIPLE fBroadwing Markets]
by virendra rode // 19 Sep '07

19 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI -/ - -------- Original Message -------- Subject: [Outages] FW: SMC INITIAL OUTAGE NOTIFICATION: MULTIPLE fBroadwing Markets Date: Wed, 19 Sep 2007 12:50:58 -0500 From: W. Kevin Hunt <Kevin(a)hbcorporate.com> To: <outages(a)isotf.org> City/State: Mobile, AL Brief description of symptoms: ............. Multiple internet customers down due BGP being removed off multiple fBroadwing routers Cause of outage/impairment: BGP configuration removed The outage began at: 13:00 The outage is affecting: Multiple Customers Number of Reports: Unknown The department currently working on this problem is: Ops Eng/IP Core The external department/Telco currently working on this problem is: None Master Ticket number on this trouble: 2130326 Additional Comments/ETR: ...................... The following routers are impacting: a0-1-lsancaa1.bwng.log a0-1-phnxazb1.bwng.log a0-2-brkrdc.bwng.log a0-2-brkrtx04.bwng.log a0-2-dllstx02.bwng.log a0-3-atlnga8a.bwng.log a0-3-mdlyfla1.bwng.log a0-4-bltmmda1.bwng.log a0-4-nwrkdc.bwng.log a0-4-nwrkdea1.bwng.log a0-4-washdca1.bwng.log a0-5-chcgil02.bwng.log a0-5-cncnoha2.bwng.log a0-6-nwaknja1.bwng.log a0-6-nwyknya1.bwng.log a0-7-slkcdc.bwng.log a0-7-slkcuta2.bwng.log a0-8-sttlwa01.bwng.log a0-mplsmna2.bwng.log a1-2-brkrdc.bwng.log a1-7-slkcdc.bwng.log rp0-1-snjcca13.bwng.log rp0-2-dllstxri.bwng.log rp0-4-asnbvaas.bwng.log rp0-5-chcgilca.bwng.log -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8WUrpbZvCIJx1bcRAksBAKCKgjwX2jGoT7G2SNbGwAiugZ5tFwCZAbeD UOgG+/mgvhH8A7qhY0lPGgY= =TNwy -----END PGP SIGNATURE-----

1 0