Subject: Injection of DVMRP default

From: [email-masked]
Date: Tue, 22 Apr 1997 13:03:41 +0200

Hi,

my PIM/DVMRP border routers have long bitterly complained to me

Apr 21 04:36:00 no-gw2.nordu.net 16251: %DVMRP-1-ROUTEFILTER: DVMRP route 0.0.0.0/8 from 129.240.202.42 discarded

I need to protect my PIM/DVMRP border routers from this default
route.

From my perspective this default route seems to be injected by a
Cisco running 10.3 hanging behind MCI's MBONE infrastructure, see
the attachment.

One week ago I sent a message to [email-masked], but I might as
well have sent it into a black hole.  A couple of days later I
sent a message to a person at MCI which I have seen active on
this list previously, but I ended up with the same lack of
response.

I would presume that it is a bad habit to inject a default route
into the MBONE, and that such injection should be terminated?

Regards,

- Håvard
# mtrace 0.0.0.1
Mtrace from 0.0.0.1 to 129.241.120.11 via group 224.2.0.1
Querying full reverse path... * switching to hop-by-hop:
  0  lunde.runit.sintef.no (129.241.120.11)
 -1  lunde.runit.sintef.no (129.241.120.11)  DVMRP  thresh^ 1  
 -2  sauce.uio.no (129.240.202.42)  DVMRP  thresh^ 6  
 -3  stockholm.mbone.ebone.net (192.36.148.206)  DVMRP  thresh^ 40  
 -4  schnell.ebone.net (198.67.134.250)  DVMRP  thresh^ 64  
 -5  * mae-bone.psi.net (192.41.177.247)  DVMRP  thresh^ 64  
 -6  * * dec3800-2-fddi-0.Washington.mci.net (204.70.74.61)  DVMRP  thresh^ 64  
 -7  * ? (204.70.183.10) [cisco 10.3] doesn't support mtrace
Round trip time 180 ms

Waiting to accumulate statistics... * * Results after 16 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
   * * *        224.0.1.32       All Multicast Traffic     From 0.0.0.1
     v       __/  rtt  257 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
204.70.74.61    dec3800-2-fddi-0.Washington.mci.net 
     v     ^      ttl   64       99/1917 =  5%   0 pps     0/0    = --%   0 pps
192.41.177.247  mae-bone.psi.net 
     v     ^      ttl   65       29/193  = 15%  12 pps     0/0    = --%   0 pps
198.67.134.250  schnell.ebone.net 
     v     ^      ttl   66       -2/3114 =  0% 194 pps     0/0    = --%   0 pps
192.36.148.206  stockholm.mbone.ebone.net 
     v     ^      ttl   67        9/3681 =  0% 230 pps     0/0    = --%   0 pps
129.240.202.42  sauce.uio.no   
     v     ^      ttl   68       -1/2250 =  0% 140 pps     0/0    = --%   0 pps
129.241.120.11  lunde.runit.sintef.no 
     v      \__   ttl   69          1            0 pps       0            0 pps
129.241.120.11  129.241.120.11
  Receiver      Query Source

#

---

From: John Hawkinson <[email-masked]>
Date: Tue, 22 Apr 1997 12:23:24 -0400 (EDT)

> Apr 21 04:36:00 no-gw2.nordu.net 16251: %DVMRP-1-ROUTEFILTER: DVMRP rout=
> e 0.0.0.0/8 from 129.240.202.42 discarded

(It's worth noting that the current version of IOS no longer syslogs
about access list violations for DVMRP by default...)

> I need to protect my PIM/DVMRP border routers from this default

In general things are in sufficiently sad a state of affairs that
as soon as you remove one source of default, another one will spring
up to replace it.

In general it tends to not do a lot of harm, so can safely be ignored.

Providers who have the ability to filter DVMRP routes should be encouraged
to filter out default, both on customer connections (which it should
be obvious, since presumably they are filtering routes received from
customers), and on backbone connections with other providers.

Speaking for BBN, I'd been planning on doing this a while ago however
at the time there Bill was trying to look at some of the ways that
default information appeared to loop through the topology, so delayed
in implenting filters; there's no reason to delay anymore, but it's
a low-priority item on my todo list.

> Cisco running 10.3 hanging behind MCI's MBONE infrastructure, see

MCI claims to mandate pruning, and IOS running 10.3 does not support
pruning, therefore one would expect this tunnel to be terminated
with extreme prejudice.

> well have sent it into a black hole.

I believe the correct address is [email-masked]; it's worth noting that
MCI had some personnel turnover in the past month-or-so and the person
who had previously been handling all the MBone requests left, so
there processes may be a bit broken right now.

--jhawk

> A couple of days later I
> - H=E5vard
> ----Next_Part(Tue_Apr_22_13:02:49_1997)--
> Content-Type: Text/Plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> # mtrace 0.0.0.1