FYI, on ACL's and filtering performance...
A while back (Dec 93), we ran a fairly extensive test to
attempt to measure "real-world" performance loss in 3 major
router vendors; ourselves, and two other well-known vendors
of "high-performance" routers. For reasons of ethics, I
will not divulge which vendors these were. They can (and do :-))
speak for themselves.
The tests were in two parts; measuring a baseline IP-only
stream (the single-protocol tests from Prof. Bradner) without
any filtering, and then a mixed protocol stream (IP, IPX, Decnet
phase IV, and bridging) together with a background load of IPX
RIP and SAP (simulating a large IPX internetwork), with a large
IP filter list active. The units tested had similar list
(retail) prices.
The results are not surprising. Because of system architectural
differences, the degradation of performance had a large variance.
The NSC degraded approximately 8% (from 12,500 64-byte pps to 11,500
pps) in overall IP forwarding rate. The other two vendors degraded
over 70%; both from 14,880 (wire rate) pps to 4,100 pps.
One vendor was particularly susceptible to the filtering load,
because their mainline routing code path was disrupted by the
filtering mechanism; their filtering is not tightly integrated
into the mainline path. This vendor handled the IPX SAP background
load well.
The other vendor was the opposite; they performed the filtering
well, causing little degradation, but the background SAP load
caused considerable pain, because a single CPU had to perform
both, whereas the NSC and the first vendor perform this task
on different CPU's. Even though this vendor's router has multiple
CPU's, both mainline and background processing are only performed
on a single CPU.
The NSC unit has multiple CPU's to handle the foreground (main
packet routing) and background (router protocols) tasks; it also
has very tightly integrated the filtering mechanism into the
foreground code path.
This, of course, is only one experiment out of a large possible
universe. However, FWIW, it does demonstrate that there are
large variances present in networks carrying a large, 'real-world'
packet pattern. If confronted with a simple, IP-only stream, either
NSC or the second vendor tested would be adequate choices. If
a multi-protocol stream was present with little or no filtering,
either NSC of the first vendor tested would suffice. With both,
however, there is a clear choice.
Regards,
Rob
--
Rob Peglar Network Systems Corporation
Channel Strategic Group 7600 Boone Avenue North
robp @
network .
com Minneapolis MN 55428 (612)424-4888 x1028
> At 18:04 1/26/95, Paul Traina wrote:
> > From: steveg @
cseic .
saic .
com (Stephen Harold Goldstein)
> > Subject: Dynamically Re-arranged Access Lists?
> >
> > I just got back from ComNet '95 in D.C., and heard some rather
> > disturbing "info" from a firewall vendor who shall remain nameless.
> > He claimed that some manufacturer's routers (wouldn't specify) will
> > re-arrange the order in which ACL entries are processed for efficiency
> > reasons, possibly leading to unintended results such as packets getting
> > through that should have been blocked.
> >
> >Said firewall vendor is blowing smoke up your butt. Flame him.
> >
> >I know of at least one vendor that does what you're describing, but
> >the conclusion you were fed is BS.
> >
> >I'm going to assume you're talking about cisco, since I've heard of people
> >complaining about this feature in cisco routers, but if you look more
> >closely at it, it's not a bug at all...
>
> I don't think they were talking about Cisco. The kind of "reordering" that
> Cisco does (basicly behind-the-scenes optimizations that preserve the
> user's ILLUSION that rules are being implemented in the order specified) is
> good, and I wish more vendors were doing it, for better performance.
>
> Other vendors, such as Telebit, explicitly reorder and merge rules, and
> this can undermine an admin's understanding of what's going on and cause
> them to improperly specify rules. I don't know about you, but this fits my
> definition of "unintended results"; the router is doing exactly what the
> user told it to do, but the user didn't understand how to tell it to do
> what they really wanted.
>
> See my paper "Network (In)Security Through IP Packet Filtering" for
> examples of these kinds of problem. The paper is available for anonymous
> FTP from:
>
> ftp://ftp.greatcircle.com/pub/firewalls/papers/chapman/pkt_filtering.ps.Z
>
>
>
> -Brent
>
> --
> == For info about the Internet Security Firewalls Tutorial and a schedule ==
> == of upcoming dates, please send email to Tutorial-Info @
GreatCircle .
COM ==
> ==============================================================================
> == Brent Chapman Great Circle Associates ==
> == Brent @
GreatCircle .
COM 1057 West Dana Street ==
> == +1 415 962 0841 Mountain View, CA 94041 ==
>
>
>
--
Rob Peglar Network Systems Corporation
Channel Strategic Group 7600 Boone Avenue North
robp @
network .
com Minneapolis MN 55428 (612)424-4888 x1028
Follow-Ups:
References:
|
|
