- Test - lists.nanog.org

Rush to Fix Quake-Damaged Undersea Cables
by Marshall Eubanks 18 Mar '11

18 Mar '11

In this WSJ article http://online.wsj.com/article/SB10001424052748704893604576199952421569210.h… or http://on.wsj.com/gaPk8V This caught my eye : About half of the existing cables running across the Pacific are damaged ... It that realistic ? That seems like much more damage than anything I have heard or seen. Regards Marshall

6 6

i386 home firewall/router/nat bottleneck diagnostics?
by Atticus 17 Mar '11

17 Mar '11

I have a four or five of 'em I don't use. If anyone needs one, I'll mail it, just contact me off list.

1 0

Service Provider Route Flap Damping Deployment Status Survey
by Shishio Tsuchiya 17 Mar '11

17 Mar '11

Dear NANOG, I'm Shishio,Cisco Systems Japan. I,Seiichi and Randy did presentation about "BGP topic" on JANOG27 which held 20th & 21st January 2011 in Kanazawa. http://www.janog.gr.jp/en/index.php?JANOG27%20Programs#qe7ec71d Randy explained "Route Flap Damping Considered Useable". http://ripe61.ripe.net/presentations/222-101117.ripe-rfd.pdf This report explains how to improve today's harmful RFD. We heard various opinion from bgp operators about RFD. So we took survey about "Service Provider Route Flap Damping Deployment Status" on janog(a)janog.gr.jp. We would like to hear more opinions to analyze current RFD operation,problem and so on. Could you please open the following url and answer the questionaire? https://www.surveymonkey.com/s/rfd-survey The JAPAN result summary is below. ----------------------------------- Q1.Do you use Route Flap Damping ? Yes: 5 No: 13 Q2.If you select No on Q1,why? Do not have the need: 3 Did not know about the feature: 2 No benefits expected: 3 Customers would complain:1 Because I read RIPE-378 :2 Other: 3 Q3.If you select Yes on Q1,what parameter do you use? Default parameters: 3 RIPE-178 : 0 RIPE-210 : 0 RIPE-229 : 0 Other: 3 Q4.Do you know Randy Bush et. al's report ''Route Flap Damping Considered Usable?'' Yes: 12 No: 7 Q5.IOS's max-penalty is currently limited to 20K. Do you need this limitation to be relaxed to over 50K? Yes: 10 No: 9 Q6.If you have any comments, please fill this box. -Our peer seems to have damping enabled, and our prefix gets damped sometimes. -We do not enable damping because we think that customers want a non-damped route. -From the perspective of a downstream ISP, if our upstream told us that an outage occurred because a route was damped, I may call and ask "is it written in the agreement that you will do this?" -We use damping pretty heavily -I had RFD turned on until this morning when I discovered our router has CSCtd26215 issues. I would like to turn on a "useful" RFD. ----------------------------------- other reference: https://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-01 https://tools.ietf.org/html/draft-ymbk-rfd-usable-00 Best Regards, -- Shishio Tsuchiya <shtsuchi(a)cisco.com>

1 0

Deferral Announcement for the March 2011 Cisco IOS Software Security Advisories
by Cisco Systems Product Security Incident Response Team 17 Mar '11

17 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco PSIRT regularly discloses vulnerabilities in Cisco IOS Software on the fourth Wednesday in March and September via the Cisco IOS Security Advisory bundle. The next bundled disclosure was planned for Wednesday, March 23, 2011, but Cisco will defer this disclosure until the next scheduled Cisco IOS bundle on September 28, 2011. Cisco has a long-standing policy of disclosing vulnerabilities to customers and the public simultaneously to ensure equal access to patched software. Based on recent events in Japan and eastern Asia, we are sensitive to the fact that customers globally are impacted directly or indirectly by these events and may not be able to respond effectively to the scheduled disclosure event. This regional disaster has not affected the ability of Cisco to disclose vulnerability information. In keeping with our policy, if we see evidence of active exploitation of a vulnerability that could lead to increased risk for Cisco customers, we will disclose appropriate information out of cycle. Please direct any questions about this announcement to either psirt(a)cisco.com or your local Cisco support team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk2CKzMACgkQQXnnBKKRMNBLjgD/bPLtpIYQd/8DSNfx9/PQg1jA Wmpe6qGaHA3L1YXSzP0A/i7Kyal+nGaJJnqwSsAzaQeV+Lh261Ah9fozXSBba0Kb =kX8s -----END PGP SIGNATURE-----

1 0

Re: bfd-like mechanism for LANPHY connections between providers
by Sudeep Khuraijam 17 Mar '11

17 Mar '11

On Mar 16, 2011, at 6:05 PM, Jeff Wheeler wrote: >>There a difference of several orders of magnitude between BFD keepalive intervals (in ms) and BGP (in seconds) with generally configurable multipliers vs. >>hold timer. >>With Real time media and ever faster last miles, BGP hold timer may find itself inadequate, if not in appropriate in some cases." >For eBGP peerings, your router must re-converge to a good state in < 9 >seconds to see an order of magnitude improvement in time-to-repair. >This is typically not the case for transit/customer sessions." Not so, if your goal is peer deactivation and failover. Also you miss the point. Once the event is detected the rest of the process starts. I am talking about event detection. One may want longer than a 30 second hold-timer but peer state deactivated instantly on link failure. If thats the design goal AND link state is not passed through, then BFD BGP deactivation is a good choice. >To make a risk/reward choice that is actually based in reality, you >need to understand your total time to re-converge to a good state, and >how much of that is BGP hold-time. You should then consider whether >changing BGP timers (with its own set of disadvantages) is more or >less practical than using BFD. Yes I see that and I mentioned "in some cases" not all or most cases. >Let's put it another way: if CPU/FIB convergence time were not a >significant issue, do you think vendors would be working to optimize This goes orthogonal to my point. The Table size taxes, best path algorithms and the speed with which you can re-FIB &rewrite the ASICs are constant in both the cases. But thats post event. >this process, that we would have concepts like MPLS FRR and PIC, and Those are out of scope in the context of this thread and have completely different roles. >that each new router product line upgrade comes with a yet-faster CPU? For things they can sell more licenses for such as 3DES, keying algorithms , virtual instances, other things on BGP, stuff that allow service providers to charge a lot more money while running on common infrastructure such as MPLS & FRR and zillion other things like stateful redundancy, higher housekeeping needs, inservice upgrades and anything else with a list price. And its cheaper than the old cpu. >Of course not. Vendors would just have said, "hey, let's get >together on a lower hold time for BGP." Because it would be horrible code design. Link detection is a common service. Besides BGP process threads can run longer than min intervals for link. Vendors would have to write checkpoints within BGP code to come up and service link state machine. And wait its a user configurable checkpoint!! So came BFD. Write a simple state machine and make it available to all protocols. >As I stated, I'll change my opinion of BFD when implementations >improve. I understand the risk/reward situation. You don't seem to >get this, and as a result, your overly-simplistic view is that "BGP >takes seconds" and "BFD takes milliseconds." I have no doubt that you understand your risk/reward but you don't for every other environments. For event detection leading to a state change leading to peer deactivation, "my overly-simplistic view" is the fact ( not as you put it, but as it was written unedited). How you want to act in response is dependent on design. >is that "BGP >takes seconds" and "BFD takes milliseconds." Thats what you read not what I wrote. I was comparing the speed of event detection. Now like I said for speed of deactivation "BGP hold timer may find itself inadequate, if not in appropriate in some cases" in this same context. But as I mentioned , we don't know the pain we are trying to solve for the requirements thats drove this thread in the first place. So I simply put the facts and a business driver. BFD is no different than deactivating a peer based on link failure. Your view is that there is no case for it. My point is - it arrived yesterday, its just a damn hard thing to monetize upstream in transit. >>For a provider to require a vendor instead of RFC compliance is sinful. >Many sins are more practical than the alternatives. Few maybe. -- Jeff S Wheeler <jsw(a)inconcepts.biz<mailto:jsw@inconcepts.biz><mailto:jsw@inconcepts.biz<mailto:jsw@inconcepts.biz>>> Sr Network Operator / Innovative Network Concepts

1 0

Test
by Uddin, Anees M 17 Mar '11

17 Mar '11

Test

1 0

gmail issues ?
by Mike Tancsa 16 Mar '11

16 Mar '11

Anyone seeing gmail issues ? I checked at http://www.google.com/appsstatus#hl=en and it says all ok. Yet I either get an RST, or it just times out, or the 3 way handshake completes, and then just FINs my connection. I tried a number of different source IPs inside my network as well as some outside my AS. # telnet gmail-smtp-in.l.google.com 25 Trying 74.125.95.27... telnet: connect to address 74.125.95.27: Connection refused telnet: Unable to connect to remote host 17:12:29.464719 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [S], seq 688245543, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2436358711 ecr 0], length 0 17:12:29.496153 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [S.], seq 2208544696, ack 688245544, win 5672, options [mss 1430,sackOK,TS val 1980791251 ecr 2436358711,nop,wscale 6], length 0 17:12:29.496174 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 1, win 8330, options [nop,nop,TS val 2436358743 ecr 1980791251], length 0 17:12:29.528117 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [F.], seq 1, ack 1, win 89, options [nop,nop,TS val 1980791283 ecr 2436358743], length 0 17:12:29.528135 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.528195 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [F.], seq 1, ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.559511 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [.], ack 2, win 89, options [nop,nop,TS val 1980791314 ecr 2436358775], length 0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/

9 9

US .mil blocking in Japan
by ryanL 16 Mar '11

16 Mar '11

should i be surprised that this hasn't been discussed much? anyone care to elaborate and/or expand on the real telecom damage done in japan? re: http://on.cnn.com/h8wiYg .rL

2 1

Microsoft contact
by Andy Ringsmuth 15 Mar '11

15 Mar '11

Any chance there's someone on here from Microsoft that could reply to me off-list? Thanks in advance. --- Andy Ringsmuth andyring(a)inebraska.com

2 2

Announcement: New RIPE NCC E-Learning Module DNS Vulnerabilities
by Sandra Bras 15 Mar '11

15 Mar '11

I sent this as an official announcement to several RIPE mailing lists, and I am sending it to you because I think you would appreciate this information too. The RIPE NCC announced today the launch of "DNS vulnerabilities", the second module of our DNSSEC E-Learning course. This module explains two common DNS security problems: "Man in the Middle" and "Kaminsky Attack". It can be viewed at: http://www.ripe.net/lir-services/training/e-learning/dnssec/dns-vulnerabili… We will be releasing more modules in the coming months, including: Module 3 DNSSEC and RIPE Database Modules. The RIPE NCC E-Learning is a free service that is available to everyone. If you have any questions, please feel free to contact us at e-learning(a)ripe.net. I hope this is useful for you. Sandra Brás Trainer/E-Learning Coordinator RIPE NCC

1 0