- NANOG - lists.nanog.org

more PGP key signing
by Joe Abley 03 Jun '03

03 Jun '03

The BOFs ran late this evening, so we're going to try again tomorrow, during the morning break. There will be handwaving tomorrow morning at some approprate juncture during which the location will be announced.

1 0

Another Data Center Fire
by Allan Liska 03 Jun '03

03 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: MD5 Wow, second problem at a major hosting center inside a week. - From Rackshack: At just after 7 PM CST, a major transformer in the Rackshack data center parking lot exploded. At this time, it is still on fire. We have implemented our emergency response plans. Our backup generators are working as designed and a fuel truck has been dispatched. We are also bringing in 2 truck mounted generators as additional backup due to teh length of time we anticipate running on generator. LIMITED staff is working in the building at this time as a precaution. HOWEVER, our full management and administrative staff has been dispached to the facility. Please bear with us if you have reboot or restore tickets pending, we will get to them as fast as possible given the limited in building staff. Just to put the magnitude of this in perspective, we currently have 8 fire trucks, 6 vpolice cars, and two ambulances on our property and in the roadway ... this in addition to several news helicopters. Thanks for your patience. allan - -- Allan Liska allan(a)allan.org http://www.allan.org http://www.hosthideout.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUAPtv8nSkg6TAvIBeFAQF7ggP9FcpaaowDH9GQQ7k97BwNgHfYQSsOPzt8 XTqJIfhb4JIwoIOXClpuhia2ekTHjZMrboRMoxMJ5qMJBFlbeJIfwEOP/OSAF/r4 AbgDeN/P4dlheLF7l7ejXNUiAgfSBLfkL1yFiyZhd+OYPhyZtnIS2ljXnmRUORul yYE1C+gJY0w= =C7WN -----END PGP SIGNATURE-----

1 0

DDoS mitigation, ACLs and router forensics
by Nicolas FISCHBACH 02 Jun '03

02 Jun '03

Hi, Since we had lots of interesting discussions on the subject in the hall at NANOG 28 and people asked for the slides, here they are :) DDoS Mitigation and Analysis at the Infrastructure Level [and router forensics] (PPT&PDF) http://www.securite.org/presentations/ddos/ And since we have two talks on BGP (in)security and a panel on S-BGP/soBGP, an "older" presentation on the subject: IP Backbone Security (PPT&PDF) http://www.securite.org/presentations/secip/ And BTW, I haven't seen a network being that actively scanned by various hosts for quite some time now. Maybe we'll soon see a PR from [put your favorite group's name here]: "thanks to NANOG all your routers/networks are belong to us" ;-)) Nico. -- Nicolas FISCHBACH (nico(a)securite.org) <http://www.securite.org/nico/> Senior Manager - IP Engineering/Security - COLT Telecom Securite.Org Team <http://www.securite.org/>

1 0

MRV Media converter
by Gerald 02 Jun '03

02 Jun '03

Would anyone with experience on MRV Fiber to Ethernet media converters please contact me off list. Thanks, Gerald

1 0

BGP analytics
by Timothy Brown 02 Jun '03

02 Jun '03

Hi; I'm searching for people who are doing analysis of BGP data on production networks. I'm particularly interested in graphing growth of particular AS_PATH regular expressions. I realize I could scrape this data using expect or similar, but I'm looking more for solutions already operating using zebra, bgpd.pl, or similar toolsets. An added bonus would be the ability to throw this kind of data into an SQL database. I know about CAIDA and routeviews; i'm more interested in this within my own network. Please reply off-list -- i'll post a summary. Thanks, Tim

1 0

Re: NTp sources that work in a datacenter (was Re: Is latency equivalent
by Peter Lothberg 02 Jun '03

02 Jun '03

The receiver do not need to be in the datacenter, there is this thing called "the internet" that you can hook it up to. > > >in every PoP to do measurements. In that case, the difficulty isn't in > > >measuring one-way latency, it's in synchronizing the time on all the > > >servers. And with fairly cheap GPS and CDMA clocks that is a lot > > >easier/cheaper than it once was. > > a robust mesh of strat-2 chimers gives one more resilence > and more accuracy than syncing off a single source. > > > But what GPS clock can you install in a datacenter? AFAIK, they all > > require roof (or at least window) access in order to install the > > antenna. (At least, all the GPS based ntp servers I've looked at do). > > Is that not true of CDMA servers? > > some GPS, some PPS, and an atomic source here and there > give great diversity and only a few need roof access. > > > How have others solved this issue? (Short of owning their datacenters.) > > Use NTP, run most systems as strat-2 Time2.Stupi.SE and Time4.Stupi.SE are both stratum-1 accessable through the Internet, tracable to UTC-SP (part of TAI) without use of GPS or slaving to CDMA (that slaves to GPS). -P

3 2

Re: Nanog LAN - no rDNS?
by Stephen J. Wilcox 02 Jun '03

02 Jun '03

On Mon, 2 Jun 2003, Simon Leinen wrote: > Stephen J Wilcox writes: > > Hi, > > can we get any reverse DNS for the meeting LAN? > > Works for me: > > : leinen@debian[leinen]; host 192.35.165.63 > 63.165.35.192.in-addr.arpa domain name pointer eth-0-2-2d-84-f7-d0.dhcp.nanog28.merit.net. > It appers to only work on the local nanog DNS servers $ host 192.35.163.157 Host 157.163.35.192.in-addr.arpa not found: 3(NXDOMAIN) $ host 192.35.163.157 ns1.nanog.org Using domain server: Name: ns1.nanog.org Address: 192.35.164.32#53

1 0

Nanog LAN - no rDNS?
by Stephen J. Wilcox 02 Jun '03

02 Jun '03

Hi, can we get any reverse DNS for the meeting LAN? Steve

3 2

Re: AS number consolidation
by Kevin Oberman 02 Jun '03

02 Jun '03

I just spoke with a couple of the people involved in the SBC transition and they are thinking about putting a presentation for a NANOG after they transition the former Ameritech ASes. This is a truly massive undertaking merging around 100 ASes from coast to coast and re-aggregating all of the routing and, from my viewpoint, have done an amazing job. I hope they do the presentation. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634 > Date: Fri, 30 May 2003 09:03:54 -0500 (CDT) > From: Daniel Golding <dgold(a)FDFNet.Net> > Sender: owner-nanog(a)merit.edu > > > SBC just did one of the largest AS merges ever accomplished. Maybe one of > their engineers will give a brief report? One item to always look out for, > if you have BGP-speaking customers is the particular implementation of > "local-as" on your favorite brand of router. There are some variations... > > - Some include the "imposter AS" in the AS path > - Some have a keyword for stripping out the "imposter AS" > > The vendor documentation on this feature has been historically weak, > necessitating some lab work. > > This can be an issue, as you could be accidentally prepending route > announcements learned from your downstreams by having both the new and old > AS in the path. > > Thanks, > Daniel Golding > > On Fri, 30 May 2003, David Luyer wrote: > > > > > > > > Does anyone know of case studies of companies collapsing > > > multiple ASes > > > into one on their network? I have the Allegiance Telecom > > > presentation from > > > NANOG 27 but I would like to hear how other people have done > > > it as well. > > > > We have to date collapsed 6 AS numbers into 1. > > > > Approach was relatively simple - but it's been at > > least a couple of years since the last merge so I'm > > a little light on exact memory/detail: > > > > 1. Duplicate RADB (or other) entries across to new > > AS. > > > > 2. Merge interior routing protocols across the ASen > > which are about to be merged. > > > > 3. Gradually grow the largest AS adding a router at > > a time (notify the BGP peers on the router, set a > > time, make the change). > > > > To me this is one of the things where you can go over the > > top in planning (I know an ISP who have been planning an > > AS merge for years) or you can 'just do it'. > > > > The second hardest thing, if you bother to do it, is > > "cleaning" the old AS (in terms of RADB, other registries, > > route filters in peers, etc) before returning it to the > > registry. > > > > The hardest thing is convincing the registry to take them > > back... (you'd think that'd be easy, but it took by far > > the longest of the whole job). > > > > David. > > > > >

1 0

RE: Net-24 top prefix generating bogus RFC-1918 queries
by McBurnett, Jim 02 Jun '03

02 Jun '03

Forgive me.. I thought I understood that 1918 routes were leaking.... Jim >-----Original Message----- >From: Sean Donelan [mailto:sean@donelan.com] >Sent: Monday, June 02, 2003 12:26 AM >To: nanog(a)merit.edu >Subject: RE: Net-24 top prefix generating bogus RFC-1918 queries > > > >On Sun, 1 Jun 2003, McBurnett, Jim wrote: >> guys.. I have a thought... >> I am a charter fiber customer.. >> AND they use lots of 1918 address for management even some >customer links. >> I have seen this on all the cable providers.. >> unlike Sprint/MCI/ATT they don't use 100% RW on all their equipment.. >> >> then they leak because the BGP is not filtering properly.. > >Uhm, incorrect. > >A DNS lookup for a RFC1918 in-addr.arpa record is unrelated to BGP or >BGP filters. > >If you want to generate an RFC1918 in-addr.arpa query to the AS112 >servers do the following > >> nslookup >Default Server: localhost >Address: 127.0.0.1 > >> set querytype=any >> 10.in-addr.arpa >Server: localhost >Address: 127.0.0.1 > >Non-authoritative answer: >10.in-addr.arpa > origin = prisoner.iana.org > mail addr = hostmaster.root-servers.org > serial = 2002040800 > refresh = 1800 (30M) > retry = 900 (15M) > expire = 604800 (1W) > minimum ttl = 604800 (1W) > >Authoritative answers can be found from: >10.in-addr.arpa nameserver = BLACKHOLE-1.iana.org >10.in-addr.arpa nameserver = BLACKHOLE-2.iana.org >BLACKHOLE-1.iana.org internet address = 192.175.48.6 >BLACKHOLE-2.iana.org internet address = 192.175.48.42 >> > >Your query will then be included in John's statistics. You BGP filters >will not stop it. > > >

1 0