- Test - lists.nanog.org

ARIN Public Policy Meeting
by Mary Schultz 29 Jul '99

29 Jul '99

ARIN Public Policy Meeting Denver, CO, October 18-19, 1999 The American Registry for Internet Numbers (ARIN) will be hosting its first public policy meeting this October 18th & 19th in Denver, Colorado, USA. It will be open to all those interested in IP-related issues and will consist of one day of working groups, including: * The Database Implementation WG (DBWG) * Community Learning and Education WG (CLEW) * IP Allocations Policies WG * Routing Table Measurement and Analysis WG (RTMA) and one day of discussions on issues relating to global IP policy, ARIN operations and the ICANN/ASO. If you have ideas for topics of discussion, please send your suggestions to ARIN's policy discussion list, ppml(a)arin.net To subscribe, please send a message to arin-ppml(a)arin.net with the word "subscribe" in the body of the message. Alternatively, you can mail suggestions directly to me, marys(a)arin.net. The agenda will then be announced well in advance of the meeting. ARIN wishes to thank Qwest for their support and sponsorship of this event. For more information on the upcoming ARIN Public Policy meeting, please visit http://www.arin.net/announcements/memmeet.html Registration will begin on August 1, 1999. Mary Schultz Membership Coordinator marys(a)arin.net

1 0

RE: Problems relating to BGP configuration
by Pravin Bhandarkar 29 Jul '99

29 Jul '99

Hi, I am looking at BGP configuration and related issues. I will be working on a project to enable the same. I have read about the different issues in BGP configuration however want a practical perspective to try a nail down the issues. The primary issues could be classified as relating to EBGP configuration and IBGP. 1. How prevelant is the usage of route-reflectors for routing within the AS or is confederation preferred?. Will the conversion from fully-connected mesh to route-reflectors be useful? for eg. ( suggesting the cluster with x number of clients and interaction with other route reflectors) 2. Are the important issues in EBGP relating to 1. Policy configuration and detection of conflicts 2. effective aggregation of routes 3.Are there fixed templates on basis of which AS's could be classified. for eg. Multihomed SIngle provider, multihomed multiple provider So can fixed templates for configuration of these type of systems be useful. I would really apreciate it if I could get some practical insight into the issues. I would also like to know if there are other more important issues that I have missed out and any pointers towards reading material relating to those issues. Thanks, Pravin

1 0

Re: SYN spoofing
by Deepak Jain 28 Jul '99

28 Jul '99

The thread I was responding to refered to filtering all routes (outbound) except those sourced from customers'/internal addresses. Regards, Deepak Jain AiNET On Wed, 28 Jul 1999, Mike Heller wrote: > I have an access list that I apply to all of our incoming interfaces that > blocks the announcement of 127.0.0.1, 192.168.0.0, 10.0.0.0, and > 172.16.0.0. It never changes. I don't see the stated impact on management. > > Mike > > On Wed, 28 Jul 1999, Dan Hollis wrote: > > > > > On Wed, 28 Jul 1999, Deepak Jain wrote: > > > While it is easy, it is not always practical because you often have > > > customers who advertise thousands of prefixes. > > > > Why would this have any impact on filtering rfc1918 and other invalid nets > > like 127.0.0.0/8 and 255.255.255.255? > > > > Or perhaps someone could explain a valid reason to route these addresses. > > > > -Dan > > > > > > >

1 0

Internic (Network Solutions)
by Spencer Plantier 27 Jul '99

27 Jul '99

Has anyone had any problems trying to change a Domain Name entry this week?

2 1

Synergery?
by Sean Donelan 27 Jul '99

27 Jul '99

Ever have one of those 'synergy' kind of days? DRA's network dates back to 1984, and is positively ancient compared to some networks. But even I was left speechless by today's outage. Here's an extract from DRA's trouble ticket diary. >But, I have been give a bit of background information on why they are having >so much trouble repairing the circuit. This circuit, a DS3 between LA and >San Diego, was owned by Western Union, which was bought out by MCI Local, >which is a part of MCI, which merged with World Comm. So, MCI/World Comm has >no idea what the circuit ID is of the circuit that is down. There is an MCI >tech on site in LA tracing cables to see where this circuit plugs into the >Western Union equipment so that they can trouble shoot it. Do other people have problems like this? Or does Murphy just likes me? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Synergery?
by David Lesher 27 Jul '99

27 Jul '99

Unnamed Administration sources reported that Sean Donelan said: > Do other people have problems like this? Or does Murphy just likes me? I am reminded of a major Mother cable cut in the 70's. This cut involved oh 8-10 cables. Then, you had 600-1200 (or maybe bigger) pair cables running between CO's. They were not color-coded... The splicer would grab a pair, any pair, from each cable, splice together, grab another pair...... Then two CO men at the ends would 'buzz out' each and every pair to figure which went where, and mark it down. Of course, if^H when they made a mistake.... And we wonder why it's so hard to get accurate circuit data. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Weird routing Cable & Wireless
by Sean Donelan 27 Jul '99

27 Jul '99

It appears C&W is having a bad hair day. We're having problems getting through Bloomington, and other weirdness. Did AGIS buy C&W when I wasn't looking? traceroute to 207.1.134.34 (207.1.134.34), 30 hops max, 38 byte packets 1 StLouis22-fe6-0-0.dra.net (192.65.218.2) 10 ms 0 ms 0 ms 2 xcore4-serial5-0-0-4-0.Chicago.cw.net (204.70.27.9) 10 ms 20 ms 0 ms 3 core2.Bloomington.cw.net (204.70.4.65) 60 ms 50 ms 70 ms 4 border7-fddi-0.Bloomington.cw.net (204.70.208.51) 50 ms 60 ms 70 ms 5 * * $ traceroute wilma.cary.cw.net traceroute to wilma.cary.CW.NET (159.24.65.124), 30 hops max, 38 byte packets 1 StLouis22-fe6-0-0.dra.net (192.65.218.2) 10 ms 0 ms 0 ms 2 SantaClara1-a1-1.dra.net (150.147.25.22) 40 ms 50 ms 40 ms 3 PaloAlto1-s4-0.dra.net (150.147.74.17) 50 ms 50 ms 50 ms 4 palo-alto.west.cix.net (198.32.176.6) 40 ms 50 ms 40 ms 5 agis.west.cix.net (149.20.64.8) 160 ms 150 ms 150 ms 6 ga020.santaclara4.agis.net (206.84.226.241) 160 ms 170 ms 140 ms 7 ga0119.inindrr01.agis.net (206.84.253.29) 200 ms 220 ms 230 ms 8 ga0010.ilchicr01.agis.net (206.185.193.5) 130 ms 110 ms 120 ms 9 * * * 10 -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Secure DHCP?
by Nicholas Bastin 26 Jul '99

26 Jul '99

(I felt this message had enough operational relevance to post on this list. If any feels otherwise, please let me know.) After having experienced a rather malicious attack on our corporate network by someone running a rogue DHCP server, I'm wondering if there's any way to prevent this from happening again? The perpetrator basically managed to renumber most of an entire subnet (into an entirely different IP block) of our network, causing a major denail of service. I've read the RFC's and checked all the network reference books I can find, and none of them indicate any way to prevent this from happening again. Am I missing something here, or is it time to start writing RFC's? Thanks in advance. -- Nick Bastin - RBB Systems, Inc. The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams

7 7

AS3951 peering at AADS
by Jeremiah Kristal 26 Jul '99

26 Jul '99

Due to a telco SNAFU, the AS3951 (Iconnet) connection to the AADS peering point has been disconnected. We are working with the telco to restore service, but have been told that this was disconnected in 1996, and must therefore be totally re-engineered. We hope to have this restored this week. Jeremiah Kristal Qwest Internet Solutions Manager, Network Services 201-319-5764 x284 internal

1 0

None
by Dean Anderson 23 Jul '99

23 Jul '99

test please ignore

2 1