nanog mailing list archives

Black holes caused by aggregation


From: bmanning () ISI EDU
Date: Thu, 26 Oct 1995 04:32:24 -0700 (PDT)


My appologies if you have already seen this.  It appears to be an
operational/configuration issue that our clients might be interested
in..... :)  Perhaps its time to upgrade all that mbone/mrouted software
out there.  


From: Bill Fenner <fenner () parc xerox com>
Subject: Black holes caused by aggregation
Date: Wed, 25 Oct 1995 18:52:46 PDT

Longest-match routing was introduced in mrouted version 3.5 .  Previous
versions would only accept the least specific route that it heard, and
if it heard routes that overlapped it would log a message and drop the
new route.

People now appear to be using Cisco's route aggregation feature in
places that it shouldn't be used, which will cause problems when
forwarding through mrouted versions previous to 3.5 (which is about 75%
of the MBONE).  A nice example of the breakage is net UIUC-CAMPUS-B,
128.174.  (Not to pick on UIUC in particular, but it's the easiest
example for me.)  The three routes that I have in my routing tables for
128.174 are:

128.174.212.0/25
128.174.240/24
128.174/16

Note that the last route covers the first two, and mrouted versions previous
to 3.5 will only accept the last route.  In fact, if I traceroute towards
128.174.0.0, I have a nice short route:

Mtrace from 128.174.0.0 to 204.162.228.2 via group 224.2.0.1
Querying full reverse path... 
  0  dartvader (204.162.228.2)
 -1  parc.dart.net (204.162.228.1)  DVMRP  thresh^ 1  200 s   
 -2  ames.dart.net (140.173.144.1)  DVMRP  thresh^ 1  200 s   
 -3  mbone2.nsi.nasa.gov (192.203.230.242)  DVMRP  thresh^ 64  200 s   
 -4  mbone.nsi.nasa.gov (192.203.230.241)  DVMRP  thresh^ 1  200 s   
 -5  oday.psc.edu (192.88.114.10)  DVMRP  thresh^ 64  176 s   
 -6  mbone.merit.edu (198.108.2.20)  DVMRP  thresh^ 64  201 s   
 -7  tibia.cic.net (192.217.65.100)  DVMRP  thresh^ 32  254 s   Next router no mtrace
 -8  dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace

However, if I trace towards one of the specific routes, I end up taking
the shortest mrouted-3.5-or-greater path:

Mtrace from 128.174.240.0 to 204.162.228.2 via group 224.2.0.1
Querying full reverse path... 
  0  dartvader (204.162.228.2)
 -1  parc.dart.net (204.162.228.1)  DVMRP  thresh^ 1  200 s   
 -2  ames.dart.net (140.173.144.1)  DVMRP  thresh^ 1  200 s   
 -3  mbone2.nsi.nasa.gov (192.203.230.242)  DVMRP  thresh^ 64  200 s   
 -4  mbone.nsi.nasa.gov (192.203.230.241)  DVMRP  thresh^ 1  200 s   
 -5  mbone.sdsc.edu (198.17.47.39)  DVMRP  thresh^ 64  200 s   
 -6  VINEGAR.SESQUI.NET (128.241.0.91)  DVMRP  thresh^ 64  201 s   
 -7  mae-bone.psi.net (192.41.177.247)  DVMRP  thresh^ 64  128 s   
 -8  MBONE1.UU.NET (137.39.43.34)  DVMRP  thresh^ 64  201 s   
 -9  MBONE2.UU.NET (137.39.246.98)  DVMRP  thresh^ 64  201 s   
-10  dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 64  2828 ms  
-11  dec3800-2-fddi-0.Denver.mci.net (204.70.152.61)  DVMRP  thresh^ 1  41 s   
-12  dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29)  DVMRP  thresh^ 1  -24 s   
-13  tibia.cic.net (192.217.65.100)  DVMRP  thresh^ 32  254 s   Next router no mtrace
-14  dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace
Round trip time 295 ms

Now, you might say "Well, that just means that traffic is taking a suboptimal
path, no big deal."  But, because of the way DVMRP builds its forwarding
trees, traffic that matches the specific routes (e.g. 128.174.240.1) will
*not* get forwarded from a 3.5-and-up to a 3.4-and-down mrouter.  Here is
a (slightly altered, since there is no active source in 128.184.240.x right
now) mtrace showing what you would see on that boundary:

Mtrace from 128.174.240.0 to 141.210.188.1 via group 224.2.0.1
Querying full reverse path... 
  0  ? (141.210.188.1)
 -1  ? (141.210.188.3)  DVMRP  thresh^ 1  208 s   
 -2  mbone.wayne.edu (141.217.1.74)  DVMRP  thresh^ 32  -250 s   Not forwarding
 -3  mbone.merit.edu (198.108.2.20)  DVMRP  thresh^ 32  201 s   
 -4  tibia.cic.net (192.217.65.100)  DVMRP  thresh^ 32  254 s   Next router no mtrace
 -5  dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace

Note the "Not forwarding" error code on the mbone.wayne.edu line.
141.210.188.3 is 3.4, mbone.wayne.edu is 3.5 .  (Again, not to pick
on wayne.edu; this was the easiest test case that I could come up with.)

This means that if you are one of the people advertising this kind of
specific and general routes, that you are isolating your traffic from
the specifically routed subnets to the connected cloud of 3.5-and-above
routers.  Of course, the long term solution is to get the whole MBONE
able to accept this kind of routing; the short term solution, however,
is not to advertise this kind of route.  Therefore, I will be periodically
posting a list of routes that fall into this category; hopefully, the
people responsible for those networks will reconfigure their routers to
either advertise only a general route or only non-overlapping specific
routes.

The list follows.  I will be posting this list (with a shorter explanation)
periodically.

  Bill

36.18/16 is covered by 36/8
36.53/16 is covered by 36/8
36.56/16 is covered by 36/8
36.103/16 is covered by 36/8
36.153/16 is covered by 36/8
36.224/16 is covered by 36/8
128.32.211/24 is covered by 128.32/16
128.32.226/24 is covered by 128.32/16
128.171.3/24 is covered by 128.171/16
128.171.10/24 is covered by 128.171/16
128.171.11/24 is covered by 128.171/16
128.171.45/24 is covered by 128.171/16
128.174.212.0/25 is covered by 128.174/16
128.174.240/24 is covered by 128.174/16
132.250.88.170/32 is covered by 132.250.88.160/28
137.194.2/23 is covered by 137.194/16
137.194.34/23 is covered by 137.194/16
137.194.98/23 is covered by 137.194/16
137.194.160/23 is covered by 137.194/16
137.194.224/23 is covered by 137.194/16
137.194.230/23 is covered by 137.194/16
137.194.232/23 is covered by 137.194/16



-- 
--bill


Current thread: