June 2010 - Test - lists.nanog.org

Re: ISP Responsibilities [WAS: Re: Nato warns of strike against cyber attackers]
by Larry Sheldon 09 Jun '10

09 Jun '10

On 6/9/2010 10:58, Owen DeLong wrote: >> What happened to the acronyms "AUP" and "TOS"? >> > I'm not sure what you mean by that. I'm talking about an ISPs liability to > third party victims, not to their customers. "Acceptable Use Policy" and "Terms of Service" > > AUP/TOS are between the ISP and their customer. Very good. Does that provide an answer to the earlier question about "what is a provider to do?" when a customer misbehaves? Does that provide a method for assigning liability? I am not a lawyer, but it doesn't seem a stretch to me to include, in this context, traffic from peers and transit providers. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

4 5

Re: Nato warns of strike against cyber attackers
by andrew.wallace 09 Jun '10

09 Jun '10

The original article is FUD. The Times newspaper is historically known as MI5, MI6's newspaper of choice. Andrew http://sites.google.com/site/n3td3v/

1 0

Re: Nato warns of strike against cyber attackers
by Michiel Klaver 09 Jun '10

09 Jun '10

-------- Original message -------- > Generally speaking, nobody wants to be the cop that makes that call. > Theoretically an ISP *might* be able to do that, but most are unwilling, > and those of us that do actually play BOFH run the risk of losing > customers to a sewerISP that doesn't. Our experiences from the Dutch ISP market indicate otherwise, customers are more than happy to be informed they might have been infected by a virus/worm. Most customers are too afraid of loosing valuable documents due to a file-eating virus for example, or afraid of loosing connection to the internet entirely and appreciate it to get an opportunity to do some clean-up when placed in quarantaine vlan. They even will recommend you, and your reputation as ISP-with-clue will increase. To stay on-topic, this is one of the first steps to prevent hosts in your network attacking NATO and decrease the risk of being disconnected by them. Commercial products that might assist you: http://www.quarantainenet.nl/?language=en;page=product-qnet Michiel Klaver IT Professional

2 1

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 09 Jun '10

09 Jun '10

Root Zone DNSSEC Deployment Technical Status Update 2010-06-09 This is the eighth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at <http://www.root-dnssec.org/>. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. PUBLIC NOTICE The US Department of Commerce National Telecommunications and Information Administration (NTIA) has issued a Public Notice regarding the deployment of DNSSEC in the root zone. http://www.ntia.doc.gov/frnotices/2010/FR_DNSSEC_Notice_06092010.pdf The Public Notice makes reference to the final report submitted to NTIA by ICANN and VeriSign which contains a summary of the project work to date together with a recommendation that full deployment should proceed. http://www.ntia.doc.gov/reports/2010/DNSSEC_05282010.pdf The Public Notice includes a public review period. Comments may be submitted by postal mail, fax or e-mail before 2010-06-21. Instructions for the submission of comments are included in the Public Notice. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.)

1 0

clueful verizon.net email contact?
by Joshua A. Fiske - jfiske 09 Jun '10

09 Jun '10

It appears that verizon.net has one email server[1] (out of a sizeable pool) that is not able to perform a proper MX lookup for our domain. Does anyone have contact information for a clue-ful individual that would have responsibility for email server maintenance at verizon.net? Josh [1] Reporting-MTA: dns;vms173001.mailsrvcs.net (tcp-daemon) - - - - Joshua Fiske '03, '04 Manager of User Services Clarkson University, Office of Information Technology (315) 268-6722 -- Fax: (315) 268-6570

1 0

Nato warns of strike against cyber attackers
by J. Oquendo 09 Jun '10

09 Jun '10

>From the NetSec mailing list... > At http://www.timesonline.co.uk/tol/news/world/article7144856.ece > > June 6, 2010 > Nato warns of strike against cyber attackers > Michael Smith and Peter Warren > > NATO is considering the use of military force against enemies who launch > cyber attacks on its member states. > > The move follows a series of Russian-linked hacking against Nato members and > warnings from intelligence services of the growing threat from China. > > A team of Nato experts led by Madeleine Albright, the former US secretary of > state, has warned that the next attack on a Nato country ³may well come down > a fibre-optic cable². > > A report by Albright¹s group said that a cyber attack on the critical > infrastructure of a Nato country could equate to an armed attack, justifying > retaliation. > > Article 5 is the cornerstone of the 1949 Nato charter, laying down that ³an > armed attack² against one or more Nato countries ³shall be considered an > attack against them all². > > It was the clause in the charter that was invoked following the September 11 > attacks to justify the removal of the Taliban regime in Afghanistan. > > Nato is now considering how severe the attack would have to be to justify > retaliation, what military force could be used and what targets would be > attacked. > > The organisation¹s lawyers say that because the effect of a cyber attack can > be similar to an armed assault, there is no need to redraft existing > treaties. > > Eneken Tikk, a lawyer at Nato¹s cyber defence centre in Estonia, said it > would be enough to invoke the mutual defence clause ³if, for example, a > cyber attack on a country¹s power networks or critical infrastructure > resulted in casualties and destruction comparable to a military attack². > > Nato heads of government are expected to discuss the potential use of > military force in response to cyber attacks at a summit in Lisbon in > November that will debate the alliance¹s future. General Keith Alexander, > head of the newly created US cyber command, said last week there was a need > for ³clear rules of engagement that say what we can stop². > > The concerns follow warnings from intelligence services across Europe that > computer-launched attacks from Russia and China are a mounting threat. > Russian hackers have been blamed for an attack against Estonia in April and > May of 2007 which crippled government, media and banking communications and > internet sites. > > They also attacked Georgian computer systems during the August 2008 invasion > of the country, bringing down air defence networks and telecommunications > systems belonging to the president, the government and banks. > > Alexander disclosed last week that a 2008 attack on the Pentagon¹s systems, > believed to have been mounted by the Chinese, successfully broke through > into classified areas. > > Britain¹s Joint Intelligence Committee cautioned last year that Chinese-made > parts in the BT phone network could be used to bring down systems running > the country¹s power and food supplies. > > Some experts have warned that it is often hard to establish government > involvement. Many Russian attacks, for example, have been blamed on the > Russian mafia. The Kremlin has consistently refused to sign an international > treaty banning internet crime. > > Obviously NATO is not concerned with proving the culprit of an attack an albeit close to impossibility. Considering that many attackers compromise so many machines, what's to stop someone from instigating. I can see it coming now: hping -S 62.128.58.180 -a 62.220.119.62 -p ++21 -w 6000 hping -S 62.220.119.62 -a 62.128.58.180 -p ++21 -w 6000 So NANOGer's, what will be the game plan when something like this happens, will you be joining NATO and pulling fiber. I wonder when all types of warm-fuzzy filtering will be drafted into networking: "Thou shall re-read RFC4953 lest you want Predator strikes on your NAP locations... -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

15 18

Re: Nato warns of strike against cyber attackers
by Michiel Klaver 09 Jun '10

09 Jun '10

> ----- Original message ----- > All that said, the biggest problem is users. Social Engineering is a far bigger threat than anything in software. And I don't know how we stop that. Anyone have an idea? Users will click anything they find 'interesting', can't change that part up front. However, after those users get infected with whatever virii/worm/botnet client came along, you could detect it [1] and place them into a quarantaine vlan routing all traffic to an information page stating they have done something stupid and educate them how to clean-up and avoiding it from happening in the future again. This will stop the abuse almost instantly (if the detection and vlan move is done automatically), and it will educate users afterwards by learning from their msitakes. Most users appreciate such kind of warnings from their own ISP (afraid of loosing documents by a virus) and are willing to clean-up. You could charge fees when users need clean-up assistance. [1] Projects like ShadowServer.org scan all kinds of botnets and (after a sign-up) send out notifications to your abuse-desk when they find infected hosts at your IP subnets. You could also setup your own Snort IDS with the detection rules from EmergingThreats.net. With kind regards, Michiel Klaver IT Professional

1 0

Strange practices?
by Dale Cornman 09 Jun '10

09 Jun '10

Has anyone ever heard of a multi-homed enterprise not running bgp with either of 2 providers, but instead, each provider statically routes a block to their common customer and also each originates this block in BGP? One of the ISP's in this case owns the block and has even provided a letter of authorization to the other, allowing them to announce it in BGP as well. I had personally never heard of this and am curious if this is a common practice as well as if this would potentially create any problems by 2 Autonomous Systems both originating the same prefix. Thanks -Bill

10 12

Re: Nato warns of strike against cyber attackers
by dlr＠bungi.com 09 Jun '10

09 Jun '10

[In the message entitled "Re: Nato warns of strike against cyber attackers" on Jun 9, 0:26, Steven Bellovin writes:] > > A liability scheme, with penalties on users and vendors, is certainly = > worth considering. Such a scheme would also have side-effects -- think = > of the effect on open source software. It would also be a lovely source = > of income for lawyers, and would inhibit new software development. The = > tradeoff may be worth while -- or it may not, because I have yet to see = > evidence that *anyone* can produce really secure software without = > driving up costs at least five-fold. > The vast majority of users that I interact with (and yes, I am first to admit that it has been only thousands, perhaps less than 10,000 over the years, so it is a small sample) are quite happy to be informed of a compromised system. It's not, for the most part, that they are malicious. Just unaware. The bad guys are very stealthy, and the "but, I can't see anything wrong on my screen!" is a huge obstacle to overcome. Once they are made aware of the problem, the vast majority work quickly to fix it. Yes, some are clueless. Some want "someone else" to fix it. But most are simply unaware that they have been owned, and want the infection gone. We've tried to educate users for tens of years of the dangers of unsafe computing. Doesn't work. The users have been trained to click and install whatever they are told, because "that makes it work". But when they _are_ compromised, and _are_ informed, most users do seek out a fix. Some will do it themselves. Some will hire someone to do it for them. When abuse desks content-filter reports, and don't pass on notifications to the customer, or "wait until there are more complaints", or... this ends up with networks that have massive levels of infection. Yes, I know - we're all busy, and abuse@ is kind of the last priority on most networks, but it really is bad out there, and we need the network operators to help. Please. For those network operators that would like a 5 year view on their network, please drop me an email with your ASN, and I'll be happy to send you a text file, xls, or ods (your pick) of a view of the historical spam traffic. No obligation, and no salesman will call. Really. --

1 0

BGP convergence problem
by Andy B. 09 Jun '10

09 Jun '10

Hi, This morning there was an ethernet loop problem on DECIX, causing many BGP sessions to flap throughout the entire platform. While this can happen, I am myself facing with BGP convergence problems on our DECIX router (SUP720-3BXL with IOS SXI3). De DECIX loop has been solved two hours ago, but my BGP sessions are still flapping and not converging at all. This has been flooding our logs, and is still going on: Jun 8 11:47:03 x.x.x.131 239447: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.32 Up Jun 8 11:47:03 x.x.x.131 239448: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.231 Up Jun 8 11:47:03 x.x.x.131 239449: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.109 Up Jun 8 11:47:03 x.x.x.131 239450: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.50 Up Jun 8 11:47:03 x.x.x.131 239451: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.81 Up Jun 8 11:47:03 x.x.x.131 239452: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.28 Up Jun 8 11:47:03 x.x.x.131 239453: Jun 8 11:48:38.364 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.212 Up Jun 8 11:47:03 x.x.x.131 239454: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.147 Up Jun 8 11:47:03 x.x.x.131 239455: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.74 Up Jun 8 11:47:03 x.x.x.131 239456: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.241 Up Jun 8 11:47:03 x.x.x.131 239457: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.5 Up Jun 8 11:47:03 x.x.x.131 239458: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.40 Up Jun 8 11:47:03 x.x.x.131 239459: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::1A44:0:1 Up Jun 8 11:47:03 x.x.x.131 239460: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::8605:0:1 Up Jun 8 11:47:03 x.x.x.131 239461: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::1A0B:0:1 Up Jun 8 11:47:03 x.x.x.131 239462: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::3029:0:1 Up Jun 8 11:47:03 x.x.x.131 239463: Jun 8 11:48:38.368 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::6E4:0:1 Up Jun 8 11:47:03 x.x.x.131 239464: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::CB0:0:1 Up Jun 8 11:47:03 x.x.x.131 239465: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::21C8:0:1 Up Jun 8 11:47:03 x.x.x.131 239466: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::8463:0:2 Up Jun 8 11:47:04 x.x.x.131 239467: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::31AA:0:1 Up Jun 8 11:47:04 x.x.x.131 239468: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.29 Up Jun 8 11:47:04 x.x.x.131 239469: Jun 8 11:48:38.372 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::62BF:0:1 Up Jun 8 11:47:04 x.x.x.131 239470: Jun 8 11:48:39.656 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.101 Down BGP Notification sent Jun 8 11:47:04 x.x.x.131 239471: Jun 8 11:48:39.656 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.101 4/0 (hold time expired) 0 bytes Jun 8 11:47:07 x.x.x.131 239472: Jun 8 11:48:41.696 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.104 Up Jun 8 11:47:10 x.x.x.131 239473: Jun 8 11:48:44.488 CEST: %BGP-3-BGP_NO_REMOTE_READ: 80.81.193.187 connection timed out - has not accepted a message from us for 20000ms (hold time), 1 messages pending transmition. Jun 8 11:47:10 x.x.x.131 239474: Jun 8 11:48:44.488 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.187 Down BGP Notification sent Jun 8 11:47:10 x.x.x.131 239475: Jun 8 11:48:44.488 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.193.187 4/0 (hold time expired) 0 bytes Jun 8 11:47:10 x.x.x.131 239476: Jun 8 11:48:44.900 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.61 Up Jun 8 11:47:10 x.x.x.131 239477: Jun 8 11:48:44.900 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.149 Up Jun 8 11:47:10 x.x.x.131 239478: Jun 8 11:48:44.900 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.136 Up Jun 8 11:47:10 x.x.x.131 239479: Jun 8 11:48:44.904 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::8463:0:1 Up Jun 8 11:47:10 x.x.x.131 239480: Jun 8 11:48:46.352 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::6268:0:1 Up Jun 8 11:47:14 x.x.x.131 239481: Jun 8 11:48:48.084 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.78 Up Jun 8 11:47:14 x.x.x.131 239482: Jun 8 11:48:49.172 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.239 Up Jun 8 11:47:14 x.x.x.131 239483: Jun 8 11:48:49.172 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.24 Up Jun 8 11:47:17 x.x.x.131 239484: Jun 8 11:48:52.160 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.45 Up Jun 8 11:47:17 x.x.x.131 239485: Jun 8 11:48:52.160 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.108 Up Jun 8 11:47:17 x.x.x.131 239486: Jun 8 11:48:52.160 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.164 Up Jun 8 11:47:17 x.x.x.131 239487: Jun 8 11:48:52.164 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.49 Up Jun 8 11:47:17 x.x.x.131 239488: Jun 8 11:48:52.164 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.139 Up Jun 8 11:47:17 x.x.x.131 239489: Jun 8 11:48:52.164 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::1536:0:1 Up Jun 8 11:47:17 x.x.x.131 239490: Jun 8 11:48:52.164 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::8601:0:1 Up Jun 8 11:47:17 x.x.x.131 239491: Jun 8 11:48:53.788 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.45 Up Jun 8 11:47:17 x.x.x.131 239492: Jun 8 11:48:53.788 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::A2DC:0:1 Up Jun 8 11:47:21 x.x.x.131 239493: Jun 8 11:48:55.056 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.91 Down BGP Notification sent Jun 8 11:49:04 x.x.x.131 239583: Jun 8 11:50:37.684 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.14 Down Peer closed the session Jun 8 11:49:04 x.x.x.131 239584: Jun 8 11:50:38.656 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.120 Down BGP Notification sent Jun 8 11:49:04 x.x.x.131 239585: Jun 8 11:50:38.656 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.120 4/0 (hold time expired) 0 bytes Jun 8 11:49:04 x.x.x.131 239586: Jun 8 11:50:38.656 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.229 Down BGP Notification sent Jun 8 11:49:04 x.x.x.131 239587: Jun 8 11:50:38.656 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.229 4/0 (hold time expired) 0 bytes Jun 8 11:49:04 x.x.x.131 239588: Jun 8 11:50:38.656 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.108 Down BGP Notification sent Jun 8 11:49:04 x.x.x.131 239589: Jun 8 11:50:38.656 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.108 4/0 (hold time expired) 0 bytes Jun 8 11:49:07 x.x.x.131 239590: Jun 8 11:50:41.944 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.73 Down BGP Notification sent Jun 8 11:49:07 x.x.x.131 239591: Jun 8 11:50:41.944 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.73 4/0 (hold time expired) 0 bytes Jun 8 11:49:07 x.x.x.131 239592: Jun 8 11:50:41.944 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::20AD:0:2 Down BGP Notification sent Jun 8 11:49:07 x.x.x.131 239593: Jun 8 11:50:41.944 CEST: %BGP-3-NOTIFICATION: sent to neighbor 2001:7F8::20AD:0:2 4/0 (hold time expired) 0 bytes Jun 8 11:49:07 x.x.x.131 239594: Jun 8 11:50:41.944 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.115 Down BGP Notification sent Jun 8 11:49:07 x.x.x.131 239595: Jun 8 11:50:41.944 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.193.115 4/0 (hold time expired) 0 bytes Jun 8 11:49:07 x.x.x.131 239596: Jun 8 11:50:44.124 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.3 Down BGP Notification sent Jun 8 11:49:11 x.x.x.131 239597: Jun 8 11:50:44.124 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.3 4/0 (hold time expired) 0 bytes Jun 8 11:49:11 x.x.x.131 239598: Jun 8 11:50:45.200 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.215 Down BGP Notification sent Jun 8 11:49:11 x.x.x.131 239599: Jun 8 11:50:45.200 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.215 4/0 (hold time expired) 0 bytes Jun 8 11:49:11 x.x.x.131 239600: Jun 8 11:50:47.336 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.141 Down BGP Notification sent Jun 8 11:49:11 x.x.x.131 239601: Jun 8 11:50:47.336 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.141 4/0 (hold time expired) 0 bytes Jun 8 11:49:14 x.x.x.131 239602: Jun 8 11:50:48.432 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::3B41:0:1 Down BGP Notification sent Jun 8 11:49:14 x.x.x.131 239603: Jun 8 11:50:48.432 CEST: %BGP-3-NOTIFICATION: sent to neighbor 2001:7F8::3B41:0:1 4/0 (hold time expired) 0 bytes Jun 8 11:49:14 x.x.x.131 239604: Jun 8 11:50:49.720 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.239 Down BGP Notification sent Jun 8 11:49:14 x.x.x.131 239605: Jun 8 11:50:49.720 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.239 4/0 (hold time expired) 0 bytes Jun 8 11:49:17 x.x.x.131 239606: Jun 8 11:50:50.976 CEST: %BGP-5-ADJCHANGE: neighbor 2001:2000:3080:B4::1 Down Peer closed the session Jun 8 11:49:17 x.x.x.131 239607: Jun 8 11:50:52.976 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.20 Down BGP Notification sent Jun 8 11:49:17 x.x.x.131 239608: Jun 8 11:50:52.976 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.20 4/0 (hold time expired) 0 bytes Jun 8 11:49:17 x.x.x.131 239609: Jun 8 11:50:54.044 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.193.21 Down BGP Notification sent Jun 8 11:49:17 x.x.x.131 239610: Jun 8 11:50:54.044 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.193.21 4/0 (hold time expired) 0 bytes Jun 8 11:49:20 x.x.x.131 239611: Jun 8 11:50:56.204 CEST: %BGP-5-ADJCHANGE: neighbor 2001:7F8::1A0B:0:1 Down BGP Notification sent Jun 8 11:49:20 x.x.x.131 239612: Jun 8 11:50:56.204 CEST: %BGP-3-NOTIFICATION: sent to neighbor 2001:7F8::1A0B:0:1 4/0 (hold time expired) 0 bytes Jun 8 11:49:23 x.x.x.131 239613: Jun 8 11:50:58.400 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.63 Down BGP Notification sent Jun 8 11:49:23 x.x.x.131 239614: Jun 8 11:50:58.400 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.63 4/0 (hold time expired) 0 bytes Jun 8 11:49:23 x.x.x.131 239615: Jun 8 11:50:59.448 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.97 Down BGP Notification sent Jun 8 11:49:23 x.x.x.131 239616: Jun 8 11:50:59.448 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.97 4/0 (hold time expired) 0 bytes Jun 8 11:49:27 x.x.x.131 239617: Jun 8 11:51:01.664 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.131 Down BGP Notification sent Jun 8 11:49:27 x.x.x.131 239618: Jun 8 11:51:01.664 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.131 4/0 (hold time expired) 0 bytes Jun 8 11:49:27 x.x.x.131 239619: Jun 8 11:51:03.872 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.83 Down BGP Notification sent Jun 8 11:49:27 x.x.x.131 239620: Jun 8 11:51:03.872 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.83 4/0 (hold time expired) 0 bytes Jun 8 11:49:27 x.x.x.131 239621: Jun 8 11:51:03.872 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.192.156 Down BGP Notification sent Jun 8 11:49:30 x.x.x.131 239622: Jun 8 11:51:03.872 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.192.156 4/0 (hold time expired) 0 bytes Jun 8 11:49:30 x.x.x.131 239623: Jun 8 11:51:06.056 CEST: %BGP-5-ADJCHANGE: neighbor 80.81.194.50 Down BGP Notification sent Jun 8 11:49:30 x.x.x.131 239624: Jun 8 11:51:06.056 CEST: %BGP-3-NOTIFICATION: sent to neighbor 80.81.194.50 4/0 (hold time expired) 0 bytes CPU load is constantly at 100% doing BGP and more BGP. We have around 200 BGP sessions on DECIX and I would not want to shut them down and bring them up individually. How can I get out of this deadlock? Andy

8 8