On Thu, 9 Apr 1998, Jason L. Weisberger wrote:
Having strong filters on what routes you will and will not accept from your downstreams is important - so Joe Terrorist or Joe Halfaclue can't screw up and cause you trouble. Generally if the people doing the bulk of the route trading are managing things well this shouldn't be a problem and we'll all continue to live with the possibility that we'll be woken up in the middle of the night for minor and friendly glitches.
I agree that filters are useful. However, I think it is missing half of the problem if you simply assume that moving the configuration problem into the filters doesn't still remain a problem. For example, recently we added a new transit customer, and asked UUNet (who we have been very happy with despite this incident) to add their aggregates to their prefix filters for us. They did so, but a couple of weeks later we cleared the BGP session to make changes in our inbound route policy, and noticed we were getting almost no inbound traffic from them. Checking at the various looking glasses, it was obvious that UUNet was only accepting routes from us for this new transit customer (ie, they had replaced our existing filters with the new aggregates rather than appending them to the list). It took 14 hours to get them to understand what the problem was and to correct it. I'm not saying that filtering prefixes isn't a good safety net, but what I am saying is that you are simply moving the configuration problems to a different place. Granted, the scope of who is affected by an error is generally much smaller, but the root of the problem is manual configuration. We have never had a similar problem with MCI, and they build the filters from the IRR. As long as our route objects (and those of ASes we provide transit for) are correct, the filters on our BGP session are correct. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801