January 2005 - Test - lists.nanog.org

Confirmation of receipt of the transfer request at Verisign for panix.com
by Bruce Tonkin 20 Jan '05

20 Jan '05

When a registrar sends a transfer request to the registry operator (and the name is not on Registrar LOCK), the registry operator sends a confirmation email to both the losing and gaining registrar. Here is the copy of the email Melbourne IT received. Regards, Bruce Tonkin From hostmaster(a)verisign-grs.com Sun Jan 9 12:40:35 2005 Return-Path: <hostmaster(a)verisign-grs.com> Received: from verisign-grs.org (snoopy.verisign-grs.net [192.153.247.4]) by galahad.inww.com (8.12.9/8.12.9) with SMTP id j091eYgt003545 for <>; Sun, 9 Jan 2005 12:40:35 +1100 (EST) Date: Sat, 8 Jan 2005 20:40:34 -0500 From: hostmaster(a)verisign-grs.com Message-Id: <200501090140.j091eXp7019959(a)verisign-grs.org> To: Melbourne IT Reply-to: hostmaster(a)verisign-grs.com Subject: Receipt of Transfer Request: PANIX.COM Transfer Request for: Domain Name: PANIX.COM Requesting Registrar: Melbourne IT, Ltd. d/b/a Internet Names Worldwide Current Registrar: Dotster, Inc. The VeriSign Global Registry Services has received your request to modify the domain name record for PANIX.COM to reflect the fact that the registrant has selected you to be its Registrar. By submitting the request using the "Transfer" command in the RRP, you have represented to the VeriSign Global Registry Services and the Current Registrar that (1) you have obtained the requisite authorization from the domain name registrant listed in the database of the Current Registrar, and (2) you have retained a copy of reliable evidence of the authorization. Pursuant to established procedures, the VeriSign Global Registry Services has notified the Current Registrar of your request. If we receive an Affirmative response to our notice within five (5) calendar days, we will make the change to the domain name record. If we receive a negative response to our notice within five (5) calendar days we will decline to transfer the domain name. If the Current Registrar takes no action within five (5) calendar days, we will make the change to the record. Sincerely, VeriSign Global Registry Services www.verisign-grs.com info(a)verisign-grs.com

4 3

Rép. : 85.68.0.0/19 Please Check Filters - BOGON Filtering IP Space
by RAMAHEFASON David FTC 20 Jan '05

20 Jan '05

oh my bad: 85.68/15 sorry for the mistake. >>> RAMAHEFASON David FTC <david.ramahefason(a)francetelecom.com> 01/20 10:44 >>> Hi, we're AS34033 and have been assigned the 85.68/19 address space from the RIPE on October 2004. But we still have some network reachability issues, due often to the use "old" BOGON filters, can you check that this supernet is not part of your bogon filters anymore. Thanks a lot David Ramahefason

1 0

Rép. : Re: Graphing Peering
by RAMAHEFASON David FTC 20 Jan '05

20 Jan '05

Hi, You can also use NetFlow/SFlow foncionalities on your Peering Interface. And then parse/treat data using tools like ntop/flowscan and such. David R. >>> Daniel Golding <dgolding(a)burtongroup.com> 01/20 12:04 >>> Andrew's issue is this - he's got an Ethernet port on a public peering switch with a bunch of peers. He can see the interface stats just fine but he's having trouble figuring out how much traffic is going to (or coming from) each peer. One interface, many peers, confusing problem. There isn't one VLAN per peer on most public peering switches - its one big Ethernet segment with each peer getting an IP out of a common subnet. Welcome to the world of broadcast multi-access peering. The classical way to do this is mac accounting. This can be pretty rough - its not really useful for anything more than a ratio, from what I've seen - the numbers tend to not add up properly. Another possibility (on Cisco) is using BGP Policy Accounting, although support can be spotty depending on hardware. For other platforms, there's some good information here: http://www.switch.ch/misc/leinen/snmp/monitoring/bucket-accounting.html The link on that page for Juniper's Destination Class Usage (DCU) is broken. Try this one instead: http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-interfaces /html/interfaces-family-config25.html - Dan On 1/19/05 5:56 PM, "Bill Nash" <billn(a)billn.net> wrote: > > > If you're already using MRTG, hopefully you're at least passingly familiar > with perl and SNMP. If so, you can do some hackery to identify your BGP > peer interfaces automatically and then use it to reference existing > interface graphs. > > Take a peek in the BGP4 mib, specifically at the BgpPeerEntry subtree. You > may need to do some correlation inside the ifTable or maybe even ifX, > depending on platform and implementation, to correctly identify the > interface of your peer. > > - billn > > > On Wed, 19 Jan 2005, andrew matthews wrote: > >> >> no i mean graph bgp sessions... >> >> it's a single interface, and i want to graph every bgp session so i >> can see how much traffic i'm doing between each peer. >> >> >> On Wed, 19 Jan 2005 22:25:37 +0000 (GMT), Stephen J. Wilcox >> <steve(a)telecomplete.co.uk> wrote: >>> On Wed, 19 Jan 2005, andrew matthews wrote: >>> >>>> Anyone have any suggestions on graphing peering on a cisco router? I'm >>>> using mrtg and i did mac address accounting but the numbers are off. >>> >>> do you mean how to graph traffic to each host on a lan..? >>> >>> what platform do you have? >>> >>> Steve >>> >>> >> -- Daniel Golding Network and Telecommunications Strategies Burton Group

1 0

85.68.0.0/19 Please Check Filters - BOGON Filtering IP Space
by RAMAHEFASON David FTC 20 Jan '05

20 Jan '05

Hi, we're AS34033 and have been assigned the 85.68/19 address space from the RIPE on October 2004. But we still have some network reachability issues, due often to the use "old" BOGON filters, can you check that this supernet is not part of your bogon filters anymore. Thanks a lot David Ramahefason

1 0

RE: Regarding registrar LOCK for panix.com
by Bruce Tonkin 20 Jan '05

20 Jan '05

Hello William, > > Stop blaming the victim! Stop blaming anybody else. > I at no stage have blamed the victim. In fact I am sincerely sorry for the damage caused to panix.com. The transfer should NEVER have been initiated. Melbourne IT has consistently acknowledged the error. I have however discussed the problem from the point of view of the overall transfer process, as I want to improve it. There have been claims made on the list that the other parts of the system did not work. I am providing factual information on what happened through the process, and exposing the process to public review on this list. I have pointed out that the process can be strengthened. This is in no way blaming the victim. It is the role of domain name registrars to educate the registrants on their options. To reiterate, for a .com name there are two optional checks/mechanisms that can be used to further prevent an unauthorised transfer (and I will say again, I agree that the transfer should not have ever been initiated). (1) A name may be placed by a registrar on Registrar-LOCK. This is optional, and it is up to a registrar to inform their customers of this option. The name was not on Registrar-LOCK at the time of the transfer request. (2) The Registry must advise the losing registrar of a transfer request. I believe this happened, as I have a copy of the corresponding email sent from the registry to the gaining registrar. This does not mean that the losing registrar actually received this email. (3) The losing registrar MAY (ie it is an option available to the losing registrar but not a requirement) send a confirmation message to the registrant. In this case it appears that this did not happen, possibly because the confirmation message in (2) was never received by the losing registrar. There is no end-to-end confirmation in the current RRP system, for Verisign to be able to confirm that the losing registrar actually received its notification. To repeat again, I am not trying to escape any blame, not cast any blame on any other party. I am interested from an engineering point of view in improving the process to avoid it happening again. Regards, Bruce

3 2

Re: [NANOG-LIST] Re: Graphing Peering
by andrew matthews 19 Jan '05

19 Jan '05

Well with mac accounting i've found that the results are not correct number they have to multiplied or something. I have a GigE and it has multiple peering sessions on it. Flowscan can't keep up, i have to export it in samples and that just defeats the purpose. I'm trying to find a way to graph indivual peers with totals. If there was a way to do it in perl i would... but i can't find the traffic on a per session basis. I'm running a cisco 12000 series router, with a current ios. I know juniper makes it really easy, but i have cisco :) Thanks everyone who has contributed. I really do appreciate it. On Wed, 19 Jan 2005 16:41:18 -0800, Brent Van Dussen <vandusb(a)attens.com> wrote: > Hello, > > Something like this would be possible with an Sflow stream if your ethernet > device supports it. By parsing out the src/dst mac addresses you could at > least visualize which MAC is using up most of your ethernet. > > -Brent > > > At 02:37 PM 1/19/2005, you wrote: > > >no i mean graph bgp sessions... > > > >it's a single interface, and i want to graph every bgp session so i > >can see how much traffic i'm doing between each peer. > > > > > >On Wed, 19 Jan 2005 22:25:37 +0000 (GMT), Stephen J. Wilcox > ><steve(a)telecomplete.co.uk> wrote: > > > On Wed, 19 Jan 2005, andrew matthews wrote: > > > > > > > Anyone have any suggestions on graphing peering on a cisco router? I'm > > > > using mrtg and i did mac address accounting but the numbers are off. > > > > > > do you mean how to graph traffic to each host on a lan..? > > > > > > what platform do you have? > > > > > > Steve > > > > > > > >

3 2

RE: Graphing Peering
by Claydon, Tom 19 Jan '05

19 Jan '05

Andrew, You could probably whip something up with a shell script, and pipe the results to something like cacti (www.cacti.net) Cacti is one of the easiest utilities I've worked with to graph other types of data besides bits in/out. Check it out. = TC -----Original Message----- From: andrew matthews [mailto:exstatica@gmail.com] Sent: Wednesday, January 19, 2005 4:38 PM To: nanog(a)merit.edu Subject: Re: Graphing Peering no i mean graph bgp sessions... it's a single interface, and i want to graph every bgp session so i can see how much traffic i'm doing between each peer. On Wed, 19 Jan 2005 22:25:37 +0000 (GMT), Stephen J. Wilcox <steve(a)telecomplete.co.uk> wrote: > On Wed, 19 Jan 2005, andrew matthews wrote: > > > Anyone have any suggestions on graphing peering on a cisco router? > > I'm using mrtg and i did mac address accounting but the numbers are off. > > do you mean how to graph traffic to each host on a lan..? > > what platform do you have? > > Steve > >

1 0

NANOG 33 Peering BOF VIII
by William B. Norton 19 Jan '05

19 Jan '05

Peering Coordinators attending NANOG in Las Vegas - We have a very exciting (and very full) Peering BOF agenda...Let me give you a flavor for what we are doing this year. At 9PM we'll start out with a "State of the Peering Internet" and, with the audience, identify a few key trends and the most pressing issues of the Peering Coordinator Community. Next we repeat last year's highly successful "Great Debate", this time on the topic of "Remote Peering : the good vs. the bad and the ugly". Remote Peering is peering without a local physical presence : tunneling ethernet frames across the ocean over MPLS into a peering fabric for example. Stephen Wilcox has graciously stepped up to present the con position - the bad and the ugly of remote peering. I have a couple volunteers to present the pro position, but I would prefer to have a Peering Coordinator that is actually using remote peering to advocate its use. If noone volunteers I have two backup debaters that have agreed to present the pro side of the debate and to debate Stephen on this matter. At the end, the audience will vote by show of hands for who made the more compelling case. If anyone would like to volunteer a prize for the winner please let me know ;-) Next, Richard Steenbergen will briefly share his Peering Coordinator community work with peeringdb.com, a resource for Peering Coordinators to obtain and share contact information. We will finish off with the Peering Personals, a chance for Peering Coordinators to introduce themselves to the group, talk about their network, what they are looking for in a peer, where they peer, their AS# and contact info, etc. I will use the RSVP form below to make sure that the relevant information is ready for Peering Coordinators in the audience to jot down in case they don't meet up with the speaker. We have found in the past that Peering Personals is very effective in facilitating peering. If you are a Peering Coordinator and would like to participate in Peering Personals, it is a great way for others to put a face to a network and AS, and to meet the North American Peering Coordinator Community. Please fill out the following form and e-mail to me (wbn(a)equinix.com) We only have time for about 10 Peering Coordinators, so please respond asap: Name: Email: Title: Company: AS#: Check each that applies: ___ We are an ISP (sell access to the Internet) --OR-- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy --OR-- ___ We are Access-Heavy ___ Peering with Content Players or Content Heavy ISPs is OK by us ___ We generally require peering in multiple locations OR ___ We will peer with anyone in any single location ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering Current Peering Locations: _______________________ Planned (3-6 mos) Peering Locations: _______________________________ After the BOF we will break for beers and exchange of business cards. Bill

1 0

Large Enterprise IP mgmt
by Network.Security 19 Jan '05

19 Jan '05

The archives didn't show a hit for "IP address management" when it comes to a large MS AD shop. We went from NetID to home-grown scripts... Men and Mice have given some presentations on their tool. Any others out there that do not force a switch to some other vendor's DNS/DHCP servers? Just looking to manage the MS AD... Thanks, Brad

1 0

Please Check Filters - BOGON Filtering IP Space 72.14.128.0/19
by Richard J. Sears 19 Jan '05

19 Jan '05

_______________________________ From: jamesl(a)pcipros.com Sent: Wednesday, January 19, 2005 9:58 AM To: 'nanog(a)merit.edu' Subject: BOGON Filtering IP Space? Our NOC is opening a lot of tickets for customers that live on our 72.14.128.0/19 network going towards local and federal government sites in particular. I'm curious if providers / vendors / managed service providers are BOGON filtering this network range as it's relatively new IP space allocated by ARIN that used to be BOGON space. If anyone has these in the BOGON list, please remove - it's real space. :-) I'd appreciate any feedback on ways to notify / check if providers are BOGON filtering this network. Regards, James Laszko Pipeline Communications, Inc. james(a)pcipros.com 760-807-5129 24x7 NOC contact 951-541-9688 office

1 0