Richard

I do not see a syntactic error. So it would be reasonable to assume that there is an error in the logic. But we do not have anything that shows us what the logic should be of what should be permitted and what should be denied. It would be helpful if you would post some of the routes that appear in the BGP table from this neighbor that you think should not be permitted.

I will note that distribute lists are a bit more tricky in BGP than in the Interior Routing Protocols. And therefore in BGP we sometimes prefer to use prefix lists. In the Interior protocols the distribute list is usually a standard access list which identifies routes to be permitted or denied. In BGP it is common to use an extended access list. But in this use an extended access list is not talking about source address and destination address (as extended access lists usually do) but is talking about the prefix and the masking of the prefix.

The second thought that occurs to me is to wonder if the distribute list was configured and applied after the neighbor was already established? If the neighbor relationship is established before the distribute list then all the routes from the neighbor would be accepted. And when the distribute list is applied it only affects new advertisements. So routes already in the table remain in the table. A way to check this is to reset or clear the neighbor relationship. If you tear down the neighbor relationship and re-establish it then only the routes permitted in the distribute list should appear in the table.

HTH

Rick