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