Subject: Top 50 unstable DVMRP routes

From: Bill Fenner <[email-masked]>
Date: Mon, 1 Dec 1997 13:24:59 PST

Dear MBone and MBone-EU-OP mailing lists,

  UCLA and PARC are engaged in MBone monitoring and
measurement.  One of the major problems with the current DVMRP
MBone is route instability.  Most of the instability appears to
be caused by pathologies as opposed to real link or router
instability.  DVMRP does not handle instability well, so it's to
everyone's benefit to eliminate these pathologies.  This
periodic message is meant to point out the routes that appear
unstable in the hopes that the cause of the instability will be
corrected.

  More information on the data collection is available from

	http://ganef.cs.ucla.edu/~masseyd/Route/

  More information on the known bugs which cause instability
is available from

	http://ganef.cs.ucla.edu/~masseyd/Route/bugs.html

  We are still experimenting with the best format in which to
present this information.  We're currently grouping routes
by unicast AS number, and only reporting the worst offender
in a given AS.  Other unstable routes in the same AS can be
found by referring to the "AS Number Search" from the search
menu of the above web page, or by looking at this week's or
this month's current data on the web page.

  The fields in the following table are:
AS:
	The AS number associated with the source in the unicast
	routing table.  This may be the route's source, or may be
	the route's source's unicast provider, who may or may not
	be their multicast provider.
#sources:
	The number of sources in the DVMRP routing table associated
	with this AS.
#down:
	The number of above sources whose DVMRP routes are currently
	considered down.
Route:
	The most unstable route in the AS over the measurement period.
flaps/hour:
	The average flaps-per-hour of the most unstable route.
	A stable route never flaps; if a link goes down and
	comes back up routes related to it might flap once or
	twice.  A route which flaps, on average, more than once
	per hour over a week's time, is clearly either behind a
	link that goes up and down about once an hour (which
	deserves to be investigated) or is experiencing a
	pathology like those listed on the above-referenced bugs
	page (which deserves to be investigated).

  The table lists the 50 worst AS's, ranked by most unstable
route in the AS.  This data is from a single point of view at
UCLA; the data is of course colored by its collection point.  In
particular, network problems close to the collection point can
raise the perceived instability for a large number of sources.
However, we believe that averaging over the week lessens these
effects greatly, so although there may be occasional blips, in
general if you're in this table, you should try to find out
why.

     AS	#srcs    #down   Route		     avg.flaps/hour
------- ----- ---------- ------------------- --------------
    766	  391  309(20%)  130.206.0.0/26       137
   1746	  240    5(97%)  206.187.0/24         137
   6461	  126   10(92%)  199.46.16/24         123
      0	  329  153(53%)  10/8                 119
   6297	    9    2(77%)  207.76.136/24        118
   2907	  197  146(25%)  133.62.192/19         96
   2506	   11    1(90%)  150.32/16             48
   2150	   30   17(43%)  132.241.60.64/28      48
    701	  324  242(25%)  208.196.3.56/29       44
    600	   53   30(43%)  206.244.58/24         43
   3561	  320  214(33%)  204.70.167/24         38
     81	   42   20(52%)  152.15/16             34
   1717	  265  265(0%)   147.210/16            33
   6744	   18   18(0%)   150.140.7/24          31
   4672	    5    2(60%)  202.235.6/24          31
   6097	    4    0(100%) 206.152.41/24         31
   7276	    3    2(33%)  129.7/16              30
    226	   34   13(61%)  128.125.10/24         28
    145	   98   15(84%)  204.147.131.180/30    28
   1741	  354   46(87%)  193.167.224/24        27
    577	   12    3(75%)  205.189.33/24         27
   6379	   44   11(75%)  207.135.112/24        26
   7260	    2    1(50%)  207.170.6/24          26
   4129	    6    3(50%)  204.62.130/24         26
   1755	    8    8(0%)   192.121.156/24        26
   3493	   73   65(10%)  206.167.88/24         25
   5646	    2    1(50%)  207.227.0/24          25
   2546	    1    1(0%)   143.233/16            25
     27	   11    7(36%)  206.196.190/24        24
   2874	   18   11(38%)  194.52/16             24
   2548	   38   34(10%)  209.116.194/24        22
   6441	    8    1(87%)  206.100.151.236/30    21
   1239	  173  138(20%)  205.166.205/24        21
   1653	   92    9(90%)  193.10.60/24          20
    714	  397  394(0%)   17.32.16.209/32       20
   3352	    3    2(33%)  147.84/16             19
   1275	  743  513(30%)  134.34.89.138/32      15
   3967	   14    7(50%)  199.46.18/24          14
      1	  298  197(33%)  198.79.15/24          14
    114	   20   13(35%)  128.42.12/24          13
   1237	   56    8(85%)  165.246.121/24        13
   6431	    4    1(75%)  135.207.128/22        13
   1280	    1    0(100%) 149.20/16             12
     16	   24    1(95%)  128.3/16              12
   7018	   16   14(12%)  12.3.167.0/25         12
    174	  221  208(5%)   206.236.34/24         12
   4681	    2    2(0%)   202.208.25/24         12
    237	   99   36(63%)  206.15.56/21          11
     93	   21   17(19%)  204.233.65/24         11
   1800	   12   11(8%)   192.41.177/24         11

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Dec 1997 14:08:31 -0800 (PST)

>> 	http://ganef.cs.ucla.edu/~masseyd/Route/bugs.html

    There are many errors in the second bug description.

    o In the configuration given, the problem will not occur because directly
      connected unicast routes always have precedent over any DVMRP route
      (regardless of DVMRP metric). So the configuration diagram needs to
      change to illustrate a non-directly connected subnet.
    o The second paragraph about requiring "ip dvmrp metric" on each interface
      to avoid feedback routing loops is incorrect. You need to have the 
      unicast route that your injecting into DVMRP have a better distance so 
      when the DVMRP route that comes back to the cisco, won't be used or 
      readvertised.
    o On the Solution section describing distance C, the cisco won't advertise
      unicast routes where the next-hop interface or next-hop neighbor is
      not multicast capable (not PIM-enabled or the neighbor isn't a PIM
      router).
    o There is a reference to the command "ip dvmrp default-distance". There
      is no such command. The correct command is "ip dvmrp distance <0-255>".
    o The last paragraph indicates that if you have many unicast routing
      protocols in which you are injecting routes from, you have to deal with
      distances for each one. There is another approach which is simpler where
      you just have to make the DVMRP distance worse (higher value) than any
      unicast route.

Dino