- Test - lists.nanog.org

Alcatel 7670 RSP
by Pablo's Gmail 15 Jun '05

15 Jun '05

Does anyone have these devices deployed out in their backbone? Looking for a general feel on experience with these boxes as it relates to IP funtionality instead of ATM. Please reply offline. thanks

1 0

Alcatel 7670 as RSP
by Pablo's Gmail 15 Jun '05

15 Jun '05

Does anyone have these devices deployed out in their backbone? Looking for a general feel on experience with these boxes as it relates to IP funtionality instead of ATM. Please reply offline. thanks Pablo

1 0

FWD: Document Action: 'BGP Wedgies' to Informational RFC
by Fergie (Paul Ferguson) 15 Jun '05

15 Jun '05

Direct operational relevence, methinks. FYI. - ferg -- The IESG <iesg-secretary(a)ietf.org> wrote: The IESG has approved the following document: - 'BGP Wedgies ' <draft-ietf-grow-bgp-wedgies-03.txt> as an Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-wedgies-03.txt Technical Summary It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Working Group Summary The Grow Working Group came to consensus on this document. Protocol Quality This document was reviewed for the IESG by David Kessens. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Considering switch from Black Diamond 6808 to Catalyst 6500
by Drew Weaver 15 Jun '05

15 Jun '05

Does anyone have any real world experience with performance gain from going from one to the other? We have noticed a lot of issues with the Black Diamond's performance. The support staff tells us we should QoS everything down to the last packet, but we don't really feel that we should have to considering the amount of money we spent on this device. Perhaps I'm asking too much, who know. Some issues we have are: Even though the CPU shows 97% idle it from one server to the next connected to the same switch its 40ms between them. "Spikes" of inexplicable/random lag that only seems to effect VoIP/Game Server type applications. We're just trying to find opinions to see if A) anyone is using these switches successfully, B) if anyone had problems with them and switched, or C) if anyone has ever heard of a switch that even though its 97% idle it still has performance issues :D Off-list is fine, and I'm not trying to bash Extreme Networks. Thanks, -Drew

2 1

Calculating Jitter
by Jeff Murri 15 Jun '05

15 Jun '05

I'm hoping here that this post isn't out of line with the scope of the NANOG list, of which I've been a long time lurker. If so, please just ignore me. We're trying to calculate Jitter of a variable (non-limited) size data set. One Jitter formula that we see cited occasionally (and is in RFC 1889 - I believe iPerf uses this formula for it's Jitter #'s) looks something like this: J = J+(|D(i-1,i)|-J)/16 The problem with this formula is that it works best on small sample sets, and it also favors more recent samples. As the sample size grows, the jitter of early samples seem to get factored down to basic "noise", and then aren't really well represented in the overall Jitter number. We're trying to find a viable formula for showing a general Jitter "average" over a period of time. One possibility here is just to iterate all samples like this: Jsum = Jsum+|D(i-1,i)| and then calculating the jitter like this: J = Jsum / (sample count - 1) The sample count could be anywhere from 2 to 1 million (or more). This formula does seem to represent early sample in the "Jitter" number just as strongly as later samples, but seems like it might be a bit simplistic. Does anyone have any feedback on this alternate way of calculating Jitter, or any better ways to do this? Thanks in advance for any input. Jeff Murri Nessoft, LLC jeff(a)nessoft.com www.nessoft.com

5 5

The IETF needs your input about the Spamops document
by Dave Crocker 14 Jun '05

14 Jun '05

(The IETF is often criticised for having inadequate efforts concerning operations. Here is your opportunity to take a small step to counteract that.) Folks, This is a request for you action: A draft specification has been submitted to the IETF for standardization as a "Best Current Practices". Information about the document is at: <http://mipassoc.org/spamops/> The document is in the final stages of a public "Last Call" process, during which the IETF's management Steering Group obtains input about interest in the document and hears about possible problems with it. This document did not get developed within the IETF. So there is no record of community interest. Consequently it is particularly important to have active postings from the broad Internet community, expressing their assessment of the document, notably including any plans to implement the specifications. This document is a limited, first-step in specifying voluntary standards for service providers, in their cross-net email operations. Please send your comments to: To: ietf(a)ietf.org cc: iesg(a)ietf.org Thanks. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net

3 3

RE: ISP's Contact List
by Sanfilippo, Ted 14 Jun '05

14 Jun '05

Suresh, Sorry I meant GEOBYTES --- http://www.geobytes.com/IpLocator.htm When I enter my new /16 at this site it translates to Canada and it shouldn't. ARIN reports the address properly on the ARIN lookup. I have sent emails to the Geobytes website two weeks ago, they confirmed to me they have the email, but have done nothing to date to fix the problem. So my customers are getting a little upset because when they go to a website they are directed to the .ca portion. Ted -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: Monday, June 13, 2005 9:04 AM To: Sanfilippo, Ted Cc: nanog(a)merit.edu Subject: Re: ISP's Contact List On 13/06/05, Sanfilippo, Ted <Ted.Sanfilippo(a)paetec.com> wrote: > > Also, I ran into a problem with a new /16 block we received from ARIN. > The IP-Country info points to Canada which is not accurate. We are a US > based company. I had placed a request into Geobyte to make the change to US, > I am still waiting. Does anyone know if there is a central database that > these companies pull from to gather country info? If its ARIN, it should > have been corrected. > Sorry if I seem dense but how or where does geobyte come into the picture at all when you receive an IP block from ARIN. If the contact information for that /16 has an error in it, then ARIN has a fairly well documented procedure to change contact information for a netblock and you can follow it. Geobytes seems to use ARIN data along with what is basically wild guessing to find where an IP is located. If they make a wrong guess - its an issue thats localized to them. -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

3 2

Re: Micorsoft's Sender ID Authentication......?
by Fergie (Paul Ferguson) 14 Jun '05

14 Jun '05

That would be much appreciated. :-) - ferg -- "william(at)elan.net" <william(a)elan.net> wrote: Since it appears NANOG continues to be used for mail-related discussions and a some of what goes here is based on not understanding technologies and issues involved, I'll make a link to a paper that I'm working on available (when its ready) and it will hopefully be good information to understand what's up in email authentication front and what each technology can and can not do. -- William Leibzon Elan Networks william(a)elan.net

3 4

RE: IP->Country Data (RE: ISP's Contact List)
by Jim McBurnett 13 Jun '05

13 Jun '05

I'm sure that this made it here before but: www.analysespider.com/ip2country/ip_country.html Later, J -----Original Message----- From: william(at)elan.net [mailto:william@elan.net] Sent: Monday, June 13, 2005 1:40 PM To: nanog(a)merit.edu Subject: IP->Country Data (RE: ISP's Contact List) On Mon, 13 Jun 2005, Daniel Senie wrote: > had wrong info or no info. > > If you're the ISP, then your answer to your customers is "the web site > you are going to is using an unreliable method to attempt to determine > locality from IP address." > > Then point them at the web site's contact form and suggest they > complain to the web site owner. > > As you've already noted, ARIN got the info correct. I suspect there > are multiple vendors attempting to provide IP address to GPS address > services. I doubt any of them will be 100% reliable, but clearly there > is an interest in such services. FYI - It maybe of interest here to know that completewhois provides this data. For determining ip->country placement only RIR data on direct ip allocations and assignments is used, so if ip block is listed as having been allocated to company with corporate address in Jamaica but is used in US, the block will show up as JM. That also avoids issue of having others blame me for bad data as algorithm for how its generated is easily confirmed with RIR whois and in 98% this does provide sufficiently good data. Our lists are regenerated EVERY DAY and available at: http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/ Even though I've never promoted this, it actually is getting rather used and I've had at least dozen requests this year along to make data available though means other then raw text file. So you might as well be first to know that 3 days ago this was finished and data is now available for verification by dns. You can now do lookup in RBL style to <reverse-ip>.country-rirdata.dnsiplists.completewhois.com (i.e. for my 216.151.192.1 dns server ip, it would be lookup at 1.192.151.216.coutry-rirdata.dnsiplists.completewhois.com) For TXT lookups it will tell you country code and country name, i.e. "US - United States". For RBL "A" lookups it will answer with 127.0.a.b where a and b are ascii representation of 1st and 2nd letter of country code, so for example for US this would be 127.0.85.89 Complete list of these codes and instructions are at: http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/READ ME So feel free to use if you like for whatever reasons (and don't complain to me if you see wrong data, lookup RIR whois and send corrections there). One last point is as I noted data is based on RIR direct allocations, so swips and suballocations are not used. In the future planned is separate service and data for experimental use that will be based on SWIP data (lowest allocation), however my checks on it show that in too many places its even less accurate then RIR direct info. -- William Leibzon Elan Networks william(a)elan.net

6 9

RE: Best practice ACLs for a internet facing border router?
by Barry Greene (bgreene) 13 Jun '05

13 Jun '05

I do not think there is a "best practice." In fact, "Operational Entropy"(1) has a big factor with packet filtering ACLs on the interconnect side of an SP. So you are not going to find a lot of packet filtering on SP-SP links. There are links and presentations you can refer to help build a iACL (Infrastructure protecting ACL). Whitepaper on Infrastructure ACLs (iACLs) http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_white_pa per0900aecd802b8f21.shtml (principles in this one can be converted to any packet filter) Team CYMRU's Secure Templates: http://www.cymru.com/Documents/secure-ios-template.html http://www.qorbit.net/documents/junos-template.pdf Next Gen Peering Architectures and Tools ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/Paris-Sept-04/ File: SE12-NEXT-GENERATION-PEERING-AND-INTERCONNECTION-ARCHITECTURES-10120_08_ 2004_c1_SE12.pdf (1) Operational Entropy is the process of natural decay that starts the moment the policy gets applied. OPEX resources need to be allocated to insure the entropy does not lead to operational consequence (i.e. the decayed policy breaks things). > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Drew Weaver > Sent: Monday, June 13, 2005 7:28 AM > To: nanog(a)merit.edu > Subject: Best practice ACLs for a internet facing border router? > > > I'm just curious if anyone has ever published a list of > what is an agreed upon best practice list of ACLs for an > internet facing border router. I'm talking about things like > bogons, private Ip addresses, et cetera. If anyone is aware > of anything like this I'd like to see it. > > Thanks, > -Drew > >

1 0