Exchange operator tools for ISPs (Re: Agenda for next NANOG)
Eric Ziegast
ziegast at zee.im.gte.com
Tue Sep 3 09:23:19 UTC 1996
> > 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
More information about the NANOG
mailing list