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)
|Trans-Atlantic (Virginia to London, England)
|Trans-Pacific (California to Tokyo, Japan)
|Trans-Pacific (California to Sydney, Australia)
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 at http://www.freeipdb.org/ and NorthStar at http://www.brownkid.net/NorthStar/
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 noc@.com, then usually one can email that to try to peer, but usually it is much better to email "firstname.lastname@example.org" instead.
Use the command:
whois -h geektools.com ‹ASN›
This usually yields the appropriate contacts. For example:% whois -h geektools.com 701
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@example.com (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 firstname.lastname@example.org 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
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.
- 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.