Mitch, The version you are running (10.3(4)) has this bug and this has been fixed in 10.3(4.2). Upgrading to later version should avoid removing the aggregate route when one of the more specific entry is removed.. Hope it helps. --ravi
Hi there, We've been tracking a problem with our cisco's screwing up aggregation of net38 at our borders. Cisco finally issued a bug ID for the problem today (CSCDI-43165). We had been holding off announcing the problem to the world until cisco confirmed where the problem is though we have explained the situation to many that have complained directly to us about the various side-effects of the bug and its workarounds. The symptom is that our statically aggregated announcement of net38 ("aggregate-address 38.0.0.0 255.0.0.0 summary-only") which we had thought had been working for many months apparently had been flapping, as seen by our neighbors (though not by us). This was undetected until Sprint enabled the route-dampener and discovered that net38 was being deleted from their routing tables due to flaps. It should be impossible, with the static aggregation, to have this flap, we thought. Not so, apparently. Cisco suggested many variations of work-arounds, some of which were not completely successful (the most notable of which resulted in announcement of many net38 subnets, as pointed out last week on the nanog list). Our current config, which seems to be working fine, forces us to allow auto summary, resulting in us withdrawing from the net39 experiment until a real bug fix is generated by cisco. Our environment includes many interior routing protocols and there may be lots of inter-related issues coming together here. We have not isolated the issues sufficiently to tell you what to look for, but perhaps cisco can comment here on what might tickle this. At any rate, we believe the current situation is stable as far as our announcements go. We hope to be able to rejoin the net39 effort again soon...
-Mitch