Please see question #34 for some protocol information that might be helpful when building filters.
Filters (either type) can be applied in two different ways: as data filters, or as call filters. Data filters will examine packets and drop (or forward) matching entries, depending on filter construction. Call filters don't drop packets, but packets that match will not cause the unit to bring up a new call, and won't reset the idle timer (which means the line will eventually time out properly).
NOTE: Packets are always compared to Data filters before Call filters.
Finally, filters can be applied to different ports on the Ascend units, in different "directions". A packet can be examined as it enters the port, or as it leaves the port (input and output, respectively).
Filters are actually defined under Ethernet->Filters. A Pipeline 50 only allows four different filter sets, each of which can include 12 independent input and output rules each. The order in which they are defined is important!
In any live connection, there are essentially four choke points at which packets can be filtered:
With different directions being examined, that means eight different filtering sets can be implemented, with varying results. A simplistic diagram might look like this:
.----. T A._____.B C._____.D T
[remote PC]__|___| P50 | ~ ~ ~ ~ ~ ~ ~ | P50 |_____| [office LAN]
|____| | `-----' `-----' |
l l
[ethernet] [ethernet]
Input and output call filters applied at point "B" would prevent
matching packets from bringing up the connection to point "C", or
from keeping the line up. Once up, the packets would still traverse
the link. An input data filter set applied at point "C" would drop
any matching packets arriving over the wide-area connection. This
is generally a desired effect.(My rule of thumb for filtering is to apply call filters at the calling Ascend, and apply data filters (for security) at the answering one; the reason I do it this way is because the central office network is more important to protect than the remote user. I apply filters only to the WAN ports (in the appropriate connection profiles), although they certainly can be applied to the local area networks.)
Brian Del Vecchio describes Ascend filtering methodology in the following way:
> On output to the WAN, we filter packets in this order: > > 1) Apply the output data filter. Packets may be explicitly forwarded or > dropped. If there are any filter entries, the default for a packet that > does not match is to DROP. If no filter entries, the default is to > FORWARD. > > 2) Apply the output call filter. If a connection to the designated target > is up, then packets are always forwarded--the call filter is used only to > determine when to reset the idle timer. For multi-channel connections, > there is one idle timer. If a call is not up, then only a packet that > passes the call filter will cause a call to be placed. Otherwise, the > packets will be dropped. Again, the default behavior is DROP if there > are any output call filter entries specified, FORWARD if there are none. > > On Input, we do the same, applying the Data filter before the call filter. > > Ethernet filtering is often used to prevent certain protocols from being > bridged. For example, one could place an Input filter on the Ethernet > that told the Pipeline to ignore all IPX packets. > > One thing to watch out for if you apply an IP filter to the Ethernet: If > you terminate your filter list with an IP type filter that says "forward > everything," it really means IP, and excludes ARP. Without ARP, you'll > see everything work for five to ten minutes, and then your Ethernet will > appear to break. Instead, terminate the filter list with a Generic type > filter that says "forward all." > > This is a particularly subtle misconfiguration, since everything seems to > work fine for a few minutes until the ARP entries age out.
Go to Previous Question
Go to Next Question
Go to Table of Contents