Subject: Current MBone AUTO-RP Brokenness

From: John Hawkinson <[email-masked]>
Date: Fri, 25 Apr 1997 18:18:00 -0400 (EDT)

Currently most cisco's on the MBone are sending large quantities
of registers throughout the MBone.

This is because atmovc-rac.cesnet.cz is announcing an improperly
scoped auto-rp announcement, and apparently most ciscos are not
filtering auto-rp discovery traffic.

If stockholm.mbone.ebone.net and further downstream mrouters
could please disable connectivity to atmovc-rec until
this configuration has been corrected, that would be appreciated.

Transit cisco routers perhaps should be configured with:

	access-list 10 deny 224.0.1.39
	access-list 10 deny 224.0.1.40
	access-list 10 permit any
	interface Tunnel0
	  ip multicast boundary 10

(replace 10 with an available access list, and apply
that boundary to all interfaces, not simply Tunnel0; if there
already a boundary in place, care should be taken to
not overwrite it blindly).

Unfortunately mrouted cannot be configured to apply
boundaries out of 239/8, so there is nothing that mrouted
operators can do (short of cutting off connectivity to atmovc-rac).

Thanks!

--jhawk

Mtrace from 194.50.6.242 to 192.216.54.1 via group 224.0.1.40
Querying full reverse path... * switching to hop-by-hop:
  0  sandbox (192.216.54.1)
 -1  disco-ext.parc.xerox.com (192.216.54.251)  DVMRP  thresh^ 32  
 -2  dodgedart.parc.xerox.com (204.162.228.7)  DVMRP  thresh^ 1  
 -3  ? (140.173.144.1)  DVMRP  thresh^ 1  
 -4  * * mbone.nsi.nasa.gov (192.203.230.241)  DVMRP  thresh^ 32  
 -5  * dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 
64  
 -6  * * paloalto-mbone1.bbnplanet.net (192.42.110.249)  PIM/Special  thresh^ 
32  
 -7  * collegepk-mbone1.bbnplanet.net (128.167.252.196)  PIM/Special  thresh^ 
64  
 -8  * * cambridge1-mbone1.bbnplanet.net (199.94.207.2)  PIM/Special  thresh^ 
32  
 -9  * * schnell.ebone.net (198.67.134.250)  DVMRP  thresh^ 32  
-10  * * stockholm.mbone.ebone.net (192.36.148.206)  DVMRP  thresh^ 64  
-11  * * pkl-sx.ten34.ces.net (195.178.64.50)  DVMRP  thresh^ 48  
-12  pklunx.cesnet.cz (194.50.6.4)  DVMRP  thresh^ 64  
-13  serv-rac.cesnet.cz (194.50.6.1)  PIM  thresh^ 0  
-14  atmovc-rac.cesnet.cz (194.50.6.242)
Round trip time 477 ms; total ttl of 73 required.

---

From: Petri Helenius <[email-masked]>
Date: Sat, 26 Apr 1997 10:11:58 +0300 (EEST)

> of registers throughout the MBone.

Not here :-) But we've been prepared.
 > not overwrite it blindly).
It's also a good idea to configure 'ip pim accept-rp auto-rp'
regardless whether you are using Auto-RP or not. That configures you
to accept registers to and joins towards the addreses you've learned
over auto-rp _ONLY_. (unless you have statically configured RP's)

This is addition to the above configuration (which is only neccessary
on your exterior border to the MBone) will keep your multicast safe
from external threats. (for now at least :-)

Pete

---

From: John Hawkinson <[email-masked]>
Date: Sat, 26 Apr 1997 03:19:53 -0400 (EDT)

> over auto-rp _ONLY_. (unless you have statically configured RP's)

This wouldn't help here (and rejection of auto-rp messages does
not work).

I think in general if you don't want to accept RPs you want something like

	ip pim accept-rp 1.2.3.4 99
	access-list 99 deny all

But that doesn't help for this particular problem.

--jhawk

---

From: Bjorn Carlsson <[email-masked]>
Date: Sat, 26 Apr 97 10:46:00 +0200

I've cut connectivity in stockholm until it's been disabled further 
downstream.

--BC

---

From: Petri Helenius <[email-masked]>
Date: Sat, 26 Apr 1997 12:47:33 +0300 (EEST)

> But that doesn't help for this particular problem.

If you have:
ip pim accept-rp auto-rp
and the boundary properly configured the functionality you get is
similar to your deny-all access-list except if you want, you can start
announcing legit RP's within your domain without reconfiguring the
boxes.

Pete

---

From: "Jeremy Hall" <[email-masked]>
Date: Sat, 26 Apr 1997 07:41:47 -0400 (EDT)

There is an override on the rp-address command, but I missed it the first
time around.  When I tried that accept-filter none routine, it just
ignored it.

_J

---

From: Vaclav Novak <[email-masked]>
Date: Sun, 27 Apr 1997 00:50:37 +0200 (MET DST)

> I've cut connectivity in stockholm until it's been disabled further 
O.K. It was caused by config errors of boxes of the Prague Academic
Network . The admins repaired it and now will be O.K. Please, start our
mbone connectivity again. I'm very sorry for your problems caused by us.

   Regards,

  Vaclav Novak, NOC CESNET

---

From: Bjorn Carlsson <[email-masked]>
Date: Sun, 27 Apr 97 10:51:24 +0200

> mbone connectivity again. I'm very sorry for your problems caused by us.

Ok, it's up again.

--BC

---

From: John Hawkinson <[email-masked]>
Date: Mon, 28 Apr 1997 13:35:10 -0400 (EDT)

> The accept-filter feature works, but you have to know that the documentation
> is incorrect, that the access list is used to specify the candidate RPs
> which you wish to IGNORE.  Thus, you likely need to invert the sense of
> the access list you built.

Let's take this discussion elsewhere.

The accept-filter does NOT work for RP discovery messages, cisco and I spent
some time pounding on this prior to my sending the email message, both
negative and positive senses were tried.

Since fortunately people have fixed the problem at the source, it's potentially
harder to tell :-)

--jhawk

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Mon, 28 Apr 1997 10:51:20 -0400

Louis Mamakos