Subject: Detecting non-pruning routers

From: Bill Fenner <[email-masked]>
Date: Fri, 18 Apr 1997 10:09:21 PDT

There's been a lot of talk about requiring pruning on the MBone, but
not much action on measurement tools that help to enforce this mechanism.
Some service providers even include it in their requirements to connect
to their MBone topology, but have no way to check conformance.

At the Stockholm IETF (was it really that long ago?), in a conversation
with Petri Helenius and others, I thought of what the "signature" of a
non-pruner would be, and how mrouted could detect it.  What didn't
occur to me until a conversation with Matt Mathis in Memphis was that
this signature is determinable "off-line", e.g. from the mrouted.dump
and mrouted.cache files that mrouted creates.  It's also present in
the output of the Cisco "show ip mroute" command.

I wrote the following two perl scripts to determine this signature.
The documentation is in the comments at the top of the scripts.

Note that this is *only* a heuristic (which is why I was reluctant to
implement it in mrouted in the first place).  Don't start taking
drastic actions based upon its output -- just ask the neighbors to
which it points to run the script themselves =)

It also only checks the paths that are currently active because of
existing traffic sources.  There might be a non-pruning router right
next to you but if all of the currently-active sources flow through
a different link, these scripts won't catch it.

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Fri, 18 Apr 1997 21:42:36 +0300 (EEST)

> non-pruner would be, and how mrouted could detect it.  What didn't

Dallas...
 > The documentation is in the comments at the top of the scripts.
Great job!

 > which it points to run the script themselves =)
I'll run some tests with the script (the cisco one) and see if it
behaves itself.

Pete

---

From: John Meylor <[email-masked]>
Date: Sat, 19 Apr 1997 15:39:09 -0700

Bill Fenner wrote:

> The documentation is in the comments at the top of the scripts.

Bill, excellent contribution as usual!

For education purposes, and since we mroute for an interexchange point
I thought it might be useful to post results I got from FIX/MAE-West
where we currently use both mrouted and PIM mrouters.   All constructive
comments are welcome and appreciated.

The ISP<->ISP mrouting on FIX/MAE is currently performed by two
platforms:

1) A cisco which mroutes between the FIX and MAE:
on MAE-West (198.32.136.99)
on FIX-West (192.233.230.243)

all interfaces are using dense-mode

FDDI 0		PIM enabled on FIX
FDDI 1		disabled for multicast on MAE (but we're their soon)
Tunnel 0	Advantis
Tunnel 1	ANS
Tunnel 2	@HOME
Tunnel 3	GEONet
Tunnel 4	BBNPlanet (temporarily down)

nsipo[126]: ./findnonpruners.cisco*  mroutes.temp
Tunnel0: 23/202 (11%)
Tunnel1: 200/200 (100%) <- possible non-pruner
Tunnel2: 39/205 (19%)
Tunnel3: 21/201 (10%)

2) A Sun running mrouted, single attached on FIX, which supports
tunnels until we move to full native routing there:
mbone.nsi.nasa.gov (192.203.230.241)

le0		disabled for multicast (adminstrative backdoor)
fddi0		disabled for multicast on FIX
vif2		mbone2 (a few test sites)
vif3		NASA
vif4		ESNet
vif5		DREN (temprorarily down)
vif6		NLANR (backup tunnel)
vif7		MCI
vif8		Srintlink
vif9		DARTNet

nsipo[135]: findnonpruners.mrouted*
vif 2: 65/243 (26%)
vif 3: 225/233 (96%) <- suspicious amount of traffic towards tunnel to
192.203.230.244
vif 4: 234/234 (100%) <- possible non-pruner towards tunnel to
134.55.12.229
vif 6: 168/237 (70%)
vif 7: 54/54 (100%) <- possible non-pruner towards tunnel to
204.70.158.61
vif 8: 169/169 (100%) <- possible non-pruner towards tunnel to
207.12.55.99
vif 9: 184/218 (84%)

So from these two perspectives, I see "suspicious" traffic rates going
into 
NASA - I'll be sure to contact them :-), and "possible non-pruners"
somewhere
in or beyond ANS, ESNet, MCI and Sprintlink.

Of course ANS, ESNet, MCI, and Sprintlink all are major providers
so it is possible they would have at least one non-pruner within 
their service areas, but it would be nice to have none. 

Perhaps they each can now run these tests internally.

And I'll focus on the NASA sources:
Most traffic into NASA from the core mbone must pass through our
border mrouter ARC-MBONE.NSN.NASA.GOV (192.203.230.244)
which speaks native PIM dense-mode on the FIX-W FDDI,
but temporarily receives the core mbone traffic via
a tunnel to mbone.nsi.nasa.gov. 

FDDI0		PIM to ISPs
Tunnel0		DVMRP to ISPs
Tunnel1		NASA Internet 
Tunnel2		NASA Aerodynamic Simulation Facility (NAS)
Tunnel3		NI multicast backbone route to JPL interconnect
Tunnel4		NI multicast backbone route to GSFC interconnect
Tunnel5		Ames Research Center 

nsipo[130]: ./findnonpruners.cisco* mroutes.arc.temp
Fddi0: 194/194 (100%) <- possible non-pruner
Tunnel0: 8/8 (100%) <- possible non-pruner
Tunnel1: 26/195 (13%)
Tunnel2: 37/194 (19%)
Tunnel3: 195/195 (100%) <- possible non-pruner
Tunnel4: 155/189 (82%)
Tunnel5: 25/195 (12%)

So as we investigate further, we see that we're forwarding
100% of S/G going to the mbone.nsi.nasa.gov (apparently we have 8) 
via Tunnel0) which are not being pruned since, as we saw above there
are potential non-pruning tunnels on mbone.nsi.nasa.gov.  We also see
all
S/G pairs being forwarded on Fddi0, since this speaks native pim with 
FIXW-MBONE.NSN.NASA.GOV which we also saw had a potential non-pruning
tunnel.
Finally we see that the tunnel to our JPL interconnect might have 
possible non-pruners.  So I will look further in my own backyard:

The JPL core mrouted sits on our Ethernet interexchange and
currently feeds the local interconnect and JPL.
JPL-MBONE.NSN.NASA.GOV (128.161.14.8)

Ethernet0	pim dense-mode
Tunnel0		NI multicast backbone route to FIX-W and Mbone
Tunnel1		NI multicastbackbone route to JSC interconnect
Tunnel2		Jet Propulsion Labs (JPL)

nsipo[137]: ./findnonpruners.cisco* mroutes.jpl.temp
Ethernet0: 9/9 (100%) <- possible non-pruner
Tunnel2: 193/193 (100%) <- possible non-pruner

Ethernet0 currently satisfies Bill's second possible explanation
for 100% ratio:

"2) The interface has no multicast router neighbors, only group
members."

Tunnel2 is the feed into JPL and will be a good target for a search for
possible sources of non-pruning behavior.

Good tool Bill.

- John

---

From: Bill Fenner <[email-masked]>
Date: Sun, 20 Apr 1997 10:14:11 PDT

Thanks for that peek, John.  I think it's inevitable that we'll see
non-pruners in every provider for a while.  I expect that the main use
of this tool will be to help providers to "clean up" their own internal
topologies.

On some nodes, the output will not be very useful at all -- it will
effectively say "Non-pruners!  Non-pruners everywhere!", especially
on backbone/transit routers.  The clean-up really has to start at
the leaves, as you showed with your JPL example.

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Sun, 20 Apr 1997 22:07:04 +0300 (EEST)

> the leaves, as you showed with your JPL example.
How about the idea that was raised a while back to inject a steady
multimegabit stream to a random group address. Would make people to
fix their systems quicker :-)

Pete

---

From: Christoph Fleck <[email-masked]>
Date: Tue, 17 Jun 1997 11:19:04 +0200 (MET DST)

Hi Bill,

You are able to patch findnonpruners.mrouted for mrouted3.9 ?
I get some missleading Output (more than 100%) from findnonpruners.mrouted
with cache & dump-Files from mrouted3.9:

vif 2: 270/252 (107%) <- possible non-pruner towards tunnel to 130.149.238.59
vif 3: 282/20 (1410%) <- possible non-pruner towards tunnel to 131.188.6.3
vif 4: 150/282 (53%)
vif 6: 39/283 (13%)
vif 7: 27/283 (9%)
vif 9: 30/282 (10%)
vif 11: 30/282 (10%)

rgs Christoph

,------------------------------------------------------------------.
| Referenzzentrum fuer multimediale Teledienste (MMRZ), TU Dresden |
|         Dr. Klaus Koehler, Christoph Fleck, Rainer Kranz         |
| e-mail: [email-masked]             Tel.: 0351 / 463 5653  |
|    WWW: http://www-mm.urz.tu-dresden.de               (GERMANY)  |
`------------------------------------------------------------------'