- Test - lists.nanog.org

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

Team Cymru BOGON feed over IPv6
by Steve Bertrand 09 Jun '10

09 Jun '10

off and on list feedback welcome. I'd personally like to get an idea of how many people are: 1) using the new Team Cymru BOGON lists *via BGP* 2) use the new v4 list 3) use the v6 list 4) monitor the Cymru BGP session as diligently as they would a peer/provider session 5) attempted the BOGON peering over IPv6 6) have a stable BOGON peering over IPv6 Disclaimer: I don't work for, nor do I have any personal or business interests in anything that Team Cymru does. I'm just very curious, and would like to compile some initial statistics based on feedback for myself. Steve

2 1

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 8, 14:30, Brielle Bruns writes:] > > Legit customers get caught in the cross-fire, and they suffer - but at > the same time, those legit customers are the only ones that will be able > to force a change on said provider. > > They contact us, and act all innocent, and tell people we're being > unreasonable, neglecting to tell people at the same time that the > 'unreasonable' DNSbl maintainer only wants for them to do a simple task > that thousands of other providers and administrators have done before. > I'm somewhat familiar with the concept :-) But yes, this indeed is currently the only effective way to cause change at the ISP level. Ferg is very correct in that Change Is Coming at the goverment level. That is the wrong place for it to happen, but it will also be very effective. I'm hopeful that more networks will take it upon themselves to make it happen before it is forced on them. --

3 2

RE: Strange practices?
by Joel M Snyder 08 Jun '10

08 Jun '10

On 6/7/10 11:51 PM: > 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? Yes, this is common and works fine. We do it with a number of customers who want a backup provider but don't want to go to the trouble of getting portable address space, an ASN, and so on. As long as both providers have a way of shutting down the advertisement (typically because they learn it via BGP) and as long as the customer doesn't try to load balance (i.e., treats it as active/passive not true active/active), then it's not a bad solution. Ugly, but given the vast chalice of despair that is the global BGP table, hardly a drop in the bucket. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms(a)Opus1.COM http://www.opus1.com/jms

2 1

RE: Strange practices?
by Murphy, Jay, DOH 08 Jun '10

08 Jun '10

"So if the enterprise loses connectivity to one of these two providers, does the provider without working connectivity to the enterprise have mechanism in place to cease originating the address space?" Yes, BGP updates. ~Jay Murphy IP Network Specialist NM State Government IT Services Division PSB - IP Network Management Center Santa Fé, New México 87505 Bus. Ph.: 505.827.2851 "We move the information that moves your world." "Good engineering demands that we understand what we're doing and why, keep an open mind, and learn from experience." "Engineering is about finding the sweet spot between what's solvable and what isn't." Radia Perlman P Please consider the environment before printing e-mail Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.

5 8

APNIC 30 - Call for Papers
by Jonny Martin 08 Jun '10

08 Jun '10

[Apologies for duplicates] ________________________________________________________________________ APNIC 30 - Call for Papers ________________________________________________________________________ The APNIC 30 Program Committee is now seeking presentations for APNIC 30 to be held at Gold Coast, Australia from 24 - 27 August 2010. We are looking for presentations that would suit technical conference sessions. Please submit proposals online at: http://submission.apnic.net/ KEY DATES --------- Call for Papers Opens: 8 June 2010 First Deadline for Submissions: 9 July 2010 First Draft Program Published: 16 July 2010 Final Deadline for Submissions: 6 August 2010 Final Program Published: 10 August 2010 Final Slides Received: 20 August 2010 PROGRAM MATERIAL ---------------- APNIC 30 Technical sessions will include presentations relevant to Internet Operations and Technologies. Here are some ideas for technical sessions relevant to APNIC 30: - IPv4 exhaustion / IPv6 deployment & operations - ISP, Peering, Carrier, and IXP services - Network security - Internet policy - Access and Transport Technologies - Content & Service Delivery If you have another idea, feel free to submit your proposal. CFP SUBMISSION -------------- Draft slides must be provided with all submissions. For work in progress, the most current information available at the time of submission is acceptable. Remember to submit early so you have plenty of time to arrange visas and travel! If you have questions, please email the Program Chair: pc-chair(a)apnic.net For more information about APNIC 30, please visit: http://meetings.apnic.net/30 Regards, Jonny Martin Chair, APNIC 30 Program Committee

1 0

quagga isisd
by Randy Bush 08 Jun '10

08 Jun '10

would appreciate clue bat from anyone successful with isisd under quqgga. please contant me off list. thanks. randy

1 0

Re: Strange practices?
by deleskie＠gmail.com 07 Jun '10

07 Jun '10

Should work fine. ------Original Message------ From: Dale Cornman To: nanog(a)nanog.org Subject: Strange practices? Sent: Jun 7, 2010 5:50 PM 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 Sent from my BlackBerry device on the Rogers Wireless Network

1 0