And with co-operative NAP peers, the same test kit could be used with T1's out to various locations that feed into the NAP so as to run the same tests across the peer's routers and lines.
Would this kind of testing reveal any useful information that could not be gotten from examining router stats?
Actually, it would be nice if this "portable test kit" were actually an optional board for a router. You could, for example, stick the "portable test kit" board in a router and then test at will.
It would be nice, but (IMHO) not likely unless alot of big customers of the router vendors asked for it. If I were an ISP engineer (*), I'd want to have my exchange provider provide a public router or diagnostic box (or both) connected to or near the level 2 switching fabric that would have the following features: router and diag boxes allow ICMP ping packets "I can't even ping _your_ box." router maintains peering sessions with each customer - Only back-end diagnostic net is advertised by the router. - Accepts all routes from all customers. - Connected and operator-owned nets are static. - Provides a BGP testing ground for the exchange point newbies. router allows loose-source routing For "traceroute -s" debuggung. router can have restricted logins for customers Look at your netowrk from outside your network just like CIX or route-server.cerf.net. This is very helpful for process of elimination for inter-provider routing problems. diag boxes (or even router) would be snmp-queryable "Wow, look at all the red around MAE-West. At least MFS's SJ router is still green, so we still have OK connectivity through our FDDI." diag boxes could monitor customers Ok, maybe not, unless perhaps the exchange operator had a NOC that cared if an ISP customer went down. diag boxes allow udp or tcp echo packets (real payload) "Real traffic through the exchange provider box doesn't seem to be lossy, perhaps that other ISP's router is out of CPU." This is all off the top of my head. Others could probably think up more. One diagram: Customer ISPs | | | +-+--+--+-+ | switch | +-+-------+ | | +-+----+ |router| +---+--+ | -+-+----+- switched ether or cddi/fddi | | +-+--+ +-+--+ |diag| |diag| +----+ +----+ Some might contend that the functions of the router and diagnostic box could be put into one (Unix?) box, possibly at relatively low cost. If an exchange-point had multiple switches connected by operator-owned lines (ala MAE-West or LA-NAP), a diagnostic router/box would be desired at each switching site. "See? There's no IP packet loss on the OC3 between the NAP ATM switches in LA and SF." Exchange operators have some really smart customers (ISP engineers) that could probably use more tools to diagnose inter-provider and exchange problems faster. Having the above-mentioned equipment at an exchange point not only helps dignose problems, they serve as a neutral test platform (ala Merit RA) for gathering private statistics about the health of the exchange point. BTW: Kudos go to CIX, CERFnet and Digex for allowing diagnostic access (more or less) to their routers. (*) Disclaimer: I'm not currently an IAP/ISP operator, just kibitzing. Many of you know better than I do what you want or need. I'm just offering an opinion that might be worth discussing. -- Eric Ziegast