> 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
- Accepts all routes from all customers.
- Connected and operator-owned nets are static.
- Provides a BGP testing ground for the exchange point
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
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.