So, at POP X, I take in maybe 100 prefixes, with maybe 1000
The same way you build and maintain routing filter lists for the
prefixes you take in.
Bzzt. Routing filter lists are applied to routing updates. Packet
filter lists are applied to packets.
Big difference.
1000-entry packet filter will slow any existing router down to crawl,
and practically all future boxes won't do any better.
--vadim
Vadim Antonov wrote:
> So, at POP X, I take in maybe 100 prefixes, with maybe 1000
> The same way you build and maintain routing filter lists for the
> prefixes you take in.Bzzt. Routing filter lists are applied to routing updates. Packet
filter lists are applied to packets.Big difference.
He suggested that the SAME list of prefixes be filtered. Or to put it
another way, if you're concerned about the work involved in creating
your filter lists, you already have the data. Now onto the performance
questions...
1000-entry packet filter will slow any existing router down to crawl,
No. This is not true. Well designed filtering software WILL perform
under these circumstances. It becomes more of a challenge as the speed
of wires increases, but at a T1 rate, it is NOT very hard, and will not
slow "any existing router" though it may slow some.
and practically all future boxes won't do any better.
Would you care to explain just exactly WHY a CAM type architecture could
not filter packets WHILE BEING RECEIVED from a given type of wire? This
is NOT an unsolveable problem. Perhaps you've been blinded by the
current architecture of the equipment you've invested in to date.
Vadim, I think Alan was talking about the mechanics of building such a list,
not deploying them in particular.
Given the information required to effectively filter cutomer routes, I'd
suggest that one has enough information to create a packet filter list based
on them. It's just matter of "simple" database work and automation. 
-dorian