^ Top


Below are a few general topics related to the NANOG mailing lists. Click a topic to view the answer related to that area.

  1. Credits
  2. About NANOG and the List
  3. How to Subscribe to a NANOG Mailing List
  4. Appropriate Topics
  5. Acceptable Use Policy
  6. Posting Conventions

The following are several frequently asked questions and topics that have appeared on the NANOG list in the past. Click a topic to view all questions and answers related to that area or click on an individual question. 

1. Routers
  1. How do I know if a router configuration question is on-topic or not?
  2. Buying a used router 

2. BGP

  1. BGP How-to's and implementation tips
  2. How much RAM do I need to take a full BGP table? 

3. NOCs

  1. List of NOCs
  2. NOC/operational job postings 

4. Network Management

  1. Network monitoring tools
  2. Posting traceroutes
  3. I'm being pinged
  4. How much latency should I see?
  5. Open source IP allocation software 

5. Peering

  1. (Not) getting peering from a particular company
  2. Locating peering contacts
  3. Peering agreements
  6. Billing
  1. What is 95th percentile billing? 

7. Topics We've Already Disussed (and don't want to hear about again)

  1. What is a "Tier 1" provider?
  2. Are we running out of IPv4 space?
  3. Private address space
  4. NAT
  5. RBLs
  6. Packet Loss on Ethernet 

8. Off-Topic Questions

  1. Spam
  2. Local DNS
  3. Network certification
  4. DSL 

9. General Reference

  1. Books About Network Operations 





1. Credits

The editors of this FAQ include Etaoin Shrdlu, Rachel K. Warren, JC Dill, Joe Abley, Richard Steenbergen, Marty Hannigan, Gwendolynn Ferch Elydyr, Barry Raveendren Greene, Joe Provo, John Payne, Ginna Musgrove, Doug Clements, and Susan Harris. FAQ contributions are welcome -- please send email to [email protected]

Credit goes to the linux-kernel mailing list FAQ, which served as a model for the NANOG FAQ. 


2. About NANOG and the List 

This is the FAQ for the North American Network Operators' Group mailing list. NANOG is an educational and operational forum for coordination of network operations in North America, and holds three annual meetings. See the main NANOG web page at:


NANOG and the email list are organized by NewNOG, a non-profit Michigan organization:


The NANOG Communications Committee (CC) is made up of NANOG community members appointed by the Board. You can reach the committee at [email protected]  


3. How to Subscribe to a NANOG Mailing List

Anyone can subscribe to the NANOG list. For more information, see the subscription web page at http://www.nanog.org/list/join


4. Appropriate Topics

NANOG discussions are on-topic if they're of interest to people running wide-area networks interconnected with other networks. "Network operations" in this context means issues related to entire networks, rather than to end users. 

Appropriate topics include routing, broad-based engineering problems/issues/solutions, outages, performance measurement, evolving wide-area technologies, exchange points, traffic engineering, operational experience, ISP security, and trouble ticket systems. 

Questions that are off-topic for NANOG may be better suited to other, more specific forums. See the Other Lists/Web Sites for Non-NANOG Relevant Topics for a list of other forums. 


5. Acceptable Use Policy

A summary of the AUP follows:

  1. Discussion will focus on Internet operational and technical issues as described in the charter of NANOG.
  2. Postings of issues inconsistent with the charter are prohibited.
  3. Cross posting is prohibited.
  4. Postings that include foul language, character assassination, and lack of respect for other participants are prohibited.
  5. Product marketing is prohibited.
  6. Postings of political, philosophical, and legal nature are prohibited.
  7. Using list as source for private marketing initiatives is prohibited.
  8. Autoresponders sending mail either to the list or to the poster are prohibited.

Individuals who violate these guidelines will be contacted and asked to adhere to the guidelines. 

If groups of individuals persist in introducing topics that are outside the charter of NANOG, the MLC will send a request to the entire mailing list requesting adherence to the guidelines. 

The full Charter and AUP for the mailing list are available on the NANOG web site.

6. Posting Conventions

  1. Format 

    When posting to the NANOG list please avoid: 

    1. Top-posting, i.e., putting your reply right on top of the message you're responding to, rather than quoting and responding as follows: > relevant excerpt 1
      response to excerpt
      > relevant excerpt 2
      response to excerpt
      > relevant excerpt 3
      response to excerpt
    2. Using non-standard methods of quoting prior text;
    3. Failing to quote, or to snip, as appropriate;
    4. Sending in HTML or other non-standard attachment formats;
    5. Starting or participating in flame wars. 

    The linux-kernel mailing list FAQ provides detailed instructions for quoting prior text:


    "Dear Emily Postnews" at http://www.templetons.com/brad/emily.html makes lots of good suggestions about signatures and other items of interest. 

  2. Previously Answered Questions 

    Check to make sure your question hasn't already been answered before posting to the list. We recommend that you:

  3. Know the Experts on the List 

    As with all mailing lists, it's a good idea to familiarize yourself with the personalities and expertise involved before indulging in a dis+agreement. NANOG includes many people who have spent years of their lives building networks - and their experience is a non-trivial resource. 

    If the person you are replying to (or talking about) is unknown to you, it is best to do some research on who that person is and why they may be qualified on the topic at hand. google.com is your friend. We suggest you search for: "firstname lastname"
    "firstname lastname"
    "firstname lastname" nanog
    etc., and read up before replying. This will often save you untold embarrassment. 

  4. Thread Drift 

    Please move long threads about splinter topics such as spam to a different list where the subject is on-topic. NANOG is for moving packets. NANOG does not usually care what is in the packet unless it is a routing protocol. 

  5. Think Before You Post 

    When you send mail to the NANOG list, it will be received by thousands of current and potential peers, employers, suppliers and customers. It will be archived in many places, and will be easily found and retrieved by anybody with access to a browser and a search engine for many years to come. 

    People will form opinions of you based on the way you conduct yourself on the list. Think before you post to avoid acting foolish in front of people you might someday have to ask for a job, an emergency response to a customer problem, rackspace, or peering.


1. Routers

Q: How do I know if a router configuration question is on-topic or not?

A: If your question is "how do I do on a router?", this question is best asked on one of the router-specific mailing lists below. If your question is "How do I get Vendor A and Vendor B's implementations to work together?" then that question is on-topic for NANOG. Platform-specific lists include:

Q: Where's a good place to buy a used 'foo' router?

A: Your question is vendor-specific and is therefore off-topic for NANOG, which deals with multi-vendor networks. Examples of other mailing lists that are related to selling routing equipment include:

The best list for for buying, selling and trading network, IT, and telecom equipment worldwide.


2. BGP (Border Gateway Protocol)

Q: Does anyone have a good url/documentation/howto's about BGP and implementing it?

A: These should get you started:

Q: How much RAM do I need to take a full BGP table?

A: The precise answer to this question depends on what BGP sessions your router will have configured, who those BGP sessions will be with, what kind of router it is and what ingress policy you apply to the routes you learn. The only good way to find a precise answer is to set the router loose in the intended configuration and measure. 

A more practical answer for someone who needs to deploy a BGP speaker that will terminate a couple of full (transit) sessions plus a few more internal and peering sessions at the time of writing is 256MB. You may well be able to get by with less, but you're unlikely to get into too much trouble with 256MB.


3. NOCs

Q: Is there a list of Network Operations Centers?

A: Why, yes, there is. You may find it at: http://puck.nether.net/netops/

Q: Where can I go to find a list of NOC/operational job postings?

A: Below are some online employment sites: 






4. Network Management

Q: How do I monitor my network and what are the options?

A: There are many ways to monitor networks and there are many options. Freeware applications are a popular option. These applications are used in big and small companies and many networks striving for five nines/six sigma reliability utilize them as well. We can't address all of the tools available so we've chose some of the most popular for your review. All are highly customizable and their source is freely available.

There are also commercial products available which include HP OpenView, What's Up Gold, LogALot, and others. 

Q: Is it OK to post traceroutes or descriptions of network problems for help with debugging?

A: No. One should email/call the appropriate NOCs and ask for assistance rather than posting to NANOG. Once in a while someone puts a traceroute example on NANOG to start a flamewar or grudge match about how bad a certain company is -- this is definitely inappropriate for the list. On a side note, most of the time when people send traceroutes to NANOG, they do not give enough information for someone to even help them out with their problems. When one sends a traceroute to the appropriate parties, please provide information about your originating IP and destination IP addresses. Also give the entire traceroute to the network operators, not just part of it. Otherwise it can be difficult or impossible to troubleshoot the problem. 

If you need to know where to get assistance from a NOC, please look at http://puck.nether.net/netops/, which explains what a NOC is, when you should contact a NOC, and how to contact NOCs of various companies. You can also add your NOC details to the webpage. 

Q: My network/machine is being pinged by 'some network'. What should I do to stop them?

A: Please contact the NOC's for each of the companies if you do not want them to ping you. The companies are probably not trying to DDoS you with their pings, and most of them will be more than willing to accommodate your request. 

Q: How much latency should I see on a circuit? What is considered normal?

A: As I'm sure everyone remembers from their high school physics class, light travels through a vacuum at 299,792 km/sec (let's round up to 300,000). When it travels through a medium that isn't a vacuum, it moves more slowly, depending on that medium's index of refraction. For example, water has a refractive index of 1.33, which means light travels through water at 1 / 1.33 = 0.75c, or 75% of the speed of light in a vacuum, about 225,000 km/sec. Fiber works on a principal called "total internal refraction," which means that light is continually reflected into the core with little or no loss in the cladding. To accomplish this, a different material is used for the core and cladding. Since the cladding has a lower refractive index than the core, as long as the angle of incidence exceeds a critical angle, light will be reflected back into the core instead of escaping out the sides. The values of the refractive indexes used in current fiber are 1.46 for the cladding, and 1.48 for the core. 

This means that light propogates through fiber at approximately 0.67c, or 200,000 km/sec (or 125,000 miles/sec). By multiplying by 1ms, we find that every 200 km (or 125 miles) adds approximately 1 millisecond of one-way speed-of-light delay. Divide this by 2 to account for the round trip time (RTT) that ping/traceroute measures in, and you find that for every 100 km (or 62.5 miles), 1ms of RTT is added. 

As an example, to circle the earth at its widest point (the equator) would be a distance of 38,000 km. A perfectly straight fiber path along this distance would make it around and back again (2 x 38,000 km) in 380ms. If the value you calculate is lower than the observed value, remember that fiber paths are almost never straight, and are often composed of linked "rings" for redundancy. 

Real-world measurements seem to suggest that the following RTTs might be considered normal, and are probably not in and of themselves indicative of any congestion or performance problem: 

Coast-to-coast USA (Virginia to California) 70ms
Trans-Atlantic (Virginia to London, England) 80ms
Trans-Pacific (California to Tokyo, Japan) 140ms
Trans-Pacific (California to Sydney, Australia) 180ms


Q: Is there any open source or free software for managing my customers' IP assignments and keeping track of my IP pool?

A: Two of the popular ones are FreeIPdb (not in operation as of 2022) and NorthStar at http://www.brownkid.net/NorthStar/ 


5. Peering

Q: I got flamed when I complained about not getting peering from a particular company - how come?

A: NANOG isn't the place to complain if your peering request was denied. Trying to shame the company in a public forum will hurt your credibility and that of the company that you are working for. There are a few ways to get peering with a someone that doesn't want to peer with you. Bill Norton provides a lot of insight about this in two papers, Internet Service Providers and Peering and The Art of Peering: The Peering Playbook 

Q: How do I find the name of the peering contact for a particular company?

A: Here are some steps to follow: Go to the Exchange Point Information web site at http://www.ep.net/ and try to find the company via one of the many exchanges whose web sites provide contact information. 

Go to http://puck.nether.net/netops/ and click on "NOC Telephone List." If there is an email address for the company for [email protected], then usually one can email that to try to peer, but usually it is much better to email "[email protected]" instead.

Use the command: 

whois -h geektools.com ‹ASN› 

This usually yields the appropriate contacts. For example:% whois -h geektools.com 701
Query: 701
Registry: whois.arin.net

UUNET Technologies, Inc. (ASN-ALTERNET)
22001 Loudoun County Pkwy
Ashburn, VA 20147

Autonomous System Name: ALTERNET-AS
Autonomous System Block: 701 - 705

Engineering, Internetwork (IE8-ARIN) [email protected] (703) 886-6933

Record last updated on 06-Mar-2001.
Database last updated on 27-Jul-2002 17:42:00 EDT.

Results brought to you by the GeekTools WHOIS Proxy

Server results may be copyrighted and are used with permission.

Bill Norton maintains a Peering Contact Database that currently lists about 160 Peering Coordinators. If you're a Peering Coordinator (something Bill verifies personally), send e-mail to[email protected] to get listed and receive a copy of the PCD about every 6 weeks or so. 

Q: What terms are included in typical peering agreements?

A: The agreement at the LINX site is a good resource: http://www.linx.net/joining/agreement-v4.html 


6. Billing

Q: What is 95th percentile billing? How does it work?

A: Internet usage, and thus internet traffic, tends to operate in cycles, with a "peak time" and an "off-peak time" recurring daily. Because of this cycle, the rate of traffic being delivered at the peak time is usually significantly higher than the "average" value. A billing system based on the 95th percentile of traffic measurements was introduced in the US first by UUNET. Similar billing systems were subsequently introduced by the other major carriers, as a way to bill customers an amount that more accurately covers their costs of operating the network. For example, if a customer peaks at twice their average for 2 hours a day, the ISP must purchase expensive circuits large enough to handle this traffic even when it sits unused the other 22 hours. This would cost more than a customer that delivered the same "amount" of data, but spread out throughout the day at a steady rate. By measuring the "rate" of traffic being delivered instead of the "amount," the cost of the network is more accurately passed on to the customer. The top 5% of the peak rates are thrown away to ensure customers are only billed for consistent peaks and not short, occasional bursts. 

The procedure used by UUNET for 95th percentile billing is to sample the rate of traffic on an interface once every 5 minutes, and record these values for one billing period (usually one month, for example 8640 samples for 30 days). At the end of the billing period, the samples are sorted in order from highest to lowest, the top 5% (ex: 432 samples, or the top 36 hours) is removed, and the value immediately under this (the 8208th sample) is the 95th percentile. This process is done twice, once for inbound traffic and once for outbound, and the larger of the two values is what is used to calculate the customer bill. 

Many ISPs have developed variants on this billing method. Some bill for in + out instead of max(in, out), while others bill for (in+out)/2. If you are in doubt, or if you are comparing quotes between providers, you should make certain you know what method is being used. 


7. Topics We've Already Discussed on the List (over and over)

Q: What is a "Tier 1" provider?

A: There's no point to this discussion as there are too many varying degrees of opinions on what constitutes a Tier 1 network. For example, the editors of this FAQ couldn't even agree on a 'commonly accepted' Tier 1 provider. 

Q: Are we running out of IPv4 address space?

A: Not any time soon - see ARIN's Weekly Routing Table Report. The transition to v6 is a well under way, though, and IETF, ARIN, and NANOG are working with operators to help ensure a smooth transition to the new protocol. 

Q: I wish people would stop using private addresses on their customer point-to-point links!

A: Some organizations use RFC 1918-defined IP addresses as links in their point-to-point networks. This breaks mechanisms like Path MTU discovery and can make traceroutes look funny. 

If you don't mind the breakage, go ahead and use private addresses. Just don't think that private addressing is a substitute for other security measures. You'll find a summary on using RFC 1918 addresses with respect to security at http://answerpointe.cctec.com/maillists/nanog/hist...

Q: We should all use NAT to save address space! or NAT is evil, everyone migrate to IPv6, quick! or NAT sure makes a great firewall!

A: NAT stands for Network Address Translation, which enables private IP internetworks that use nonregistered IP addresses to connect to the Internet. The pros and cons of NAT have been discussed at great length on NANOG at various times over the years, and pretty much every argument for every viewpoint has already been made. To educate yourself on the various arguments, check the NANOG archives; to learn about NAT, see RFC 3022, Traditional NAT, and RFC 2775, Internet Transparency. 

Q: How can I stop "some RBL" from blocking my server?

A: RBLs (Realtime Blackhole Lists) are used by some mail server operators to deny mail from particular remote mail transfer agents (MTAs) in the interests of cutting down the amount of spam their users have to handle. There are lots of RBLs, and most of them have different policies relating to what addresses appear on their lists. Some are commercial, and some are not. None of them are universally loved. History shows that discussions of RBLs on NANOG are unlikely to yield useful operational content. 

Q: My ethernet's showing a lot of packet loss/packet corruption -- any suggestions?

A: Before asking questions about packet loss between ethernet-connected devices, turn off auto-netogiation everywhere and configure both ends of every piece of cable to have the same speed, and the same duplex setting. No auto-negotiation. If you don't need to do that because you know it's already set up that way, check that it is indeed set up that way because you could be mistaken, or someone else could have changed it. 

If, once you have done that, you are still getting problems and you're profoundly convinced that the problem is not vendor-specific -- if you're sure, in fact, that it relates to some wide-reaching, never-before-seen technical issue which will no doubt affect everybody in the world who uses ethernet -- then please feel free to send your findings to the NANOG list. 


8. Off-Topic Questions

Q: Help - I'm being spammed!

A: Many questions about spam, particurly those dealing with the pros and cons of various blacklists, or the legal, ethical, and moral aspects of spam, should first be taken to the lists that focus on spam prevention:

spam-l list for spam prevention and discussion

spam tools list for software tools that detect spam

net.admin.net-abuse.usenet -- usenet lists

If your question concerns the technical details of preventing spam and mechanisms by which ISPs can coordinate to ameliorate spam, it is likely on-topic for NANOG. 


Q: Is there any way to add zone(s) to our local DNS without having to restart BIND?

A: This is off-topic for NANOG, which is mainly concerned with the root name server network and its operation, and registry updates of the IN-ADDR.ARPA domain. A suitable operational DNS discussion might be about why non-root name servers improperly updated overnight, a notification that such an event occurred, a technical discussion of workarounds, ETTR, or other related issues. A topic or post that would not be suitable for the NANOG discussion list would be something like "My name server is broken. Why?". 

Remember, NANOG doesn't particularly want to talk about your local DNS - we're concerned with operational aspects of DNS that are mainly root-server related i.e. failed loads, breakdowns, query latency, and other problems. 

For help with BIND troubleshooting see the Internet Systems Consortium's web site:



Q: How can I find out who's taken a network certification test and what's on it?

A: NANOG is not the place to ask about certifications. NANOG is about North American operations of multi-vendor networks -- not about vendor-specific training or techniques. Asking about certifications is very vendor specific, and is not directly related to backbone operations. Plus, some vendor certifications ask you not to talk about the tests, especially the answers, because to them, it is cheating. They even make you sign a form saying you will not talk about the test. NANOG wants to adhere to these principles. 

There are plenty of mailing lists that are certification related. Just google-search for something like "mailing list CCNA", and you will find quite a few links to mailing lists that can help you prepare for a certification you need. 


Q: I'm having a problem with my DSL line.

A: Try the DSL Reports web site at http://www.dslreports.com/ This site has multiple excellent references on DSL, and is more likely to have an answer to your question. The NANOG list doesn't provide support for end-user topics such as DSL, but focuses on operational support for entire networks. 


9. General Referance

Q: I'm a newbie and I would like to read something in a book about network operations. RFC's are making me sleepy, they can be so dry. ;) What books should I read to complement other reading material?

A: Here are some references:

  • General, Routing, TCP/IP
    (See also the Network Operator Resources section at http://nanog.cluepon.net/
    • Routing TCP/IP series by Jeff Doyle. Cisco press.
    • OSPF: Anatomy of an Internet Routing Protocol (Addison-Wesley), 1998) and other OSPF books by John Moy.
    • Interconnections: Bridges and Routers, by Radia Perlman. Addison-Wesley, 1992.
    • Internetworking with TCP/IP series by Douglas Comer (Prentice-Hall)
    • Computer Networks, by Andrew S. Tanenbaum (Prentice-Hall)
    • TCP/IP Network Administration (3rd Edition; O'Reilly Networking), by Craig Hunt, 2002.
    • Integrated IS-IS Design and Deployment Guide, from Cisco, http://www.gweep.net/~crimson/isis-designguide.pdf
    • Sonet & T1 - Architectures for Digial Transport Networks, by Uyless Black and Sharleen Waters, 2002. 
  • BGP
    • Internet Routing Architectures, by Bassam Halabi. Cisco Press, 1997. 
    • BGP4: Inter-Domain Routing in the Internet, by John W. Stewart III. Addison-Wesley Networking Basics Series, 1999. 
  • Other Protocols
    • DNS and BIND, 4th Edition, by Paul Albitz and Cricket Liu, 2001.