Cisco routers	http://puck.nether.net/mailman/listinfo/cisco-nsp
Juniper routers	puck.nether.net/mailman/listinfo/juniper-nsp
Foundry routers	http://puck.nether.net/mailman/listinfo/foundry-nsp
Riverstone routers	http://www.nmops.org/
FreeBSD	http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/eresources.html

network-resell	List at http://www.network-resell.com/mailman/listinfo/network-resell. The best list for for buying, selling and trading network, IT, and telecom equipment worldwide.
ISP-Services	List at http://www.ispc.org/lists/ for ISP equipment and services

1. 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.
2. 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 peering@<dommainname>.com instead.
3. 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
   Results:
   UUNET Technologies, Inc. (ASN-ALTERNET)
      22001 Loudoun County Pkwy
      Ashburn, VA 20147
      US
    
      Autonomous System Name: ALTERNET-AS
      Autonomous System Block: 701 - 705
    
      Coordinator:
         Engineering, Internetwork  (IE8-ARIN)  inter-eng@uu.net
         (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.
   

http://www.linx.net/joining/agreement-v4.html

http://groups.yahoo.com/group/model-peer.

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.

MRTG - Statistics collector and analyzer
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

RRDTool - Correlation and flexible analysis engine used in conjunction with MRTG.
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/

CRICKET - A system for monitoring trends in time-series data. Cricket was developed to help network managers visualize and understand the traffic on their networks.
http://cricket.sourceforge.net/

NAGIOS - Host, service, and network monitoring
http://www.nagios.com/

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.

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:

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/historical/0101/msg00040.html.

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.

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:

http://www.isc.org/products/BIND

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.