jlarsen at richweb
Jul 4, 2008, 7:29 AM
Post #18 of 36
(378 views)
Permalink
|
Ted,
Peder is correct. Cisco bought the company that made the pix (NTI) because
NTI was one of the first companies to have a decent working NAT overload
implementation. NAT was a big deal back then - around 1995/1996 and Cisco
routers did not have NAT in the IOS until 11.2 I think. At that
time UUnet and many other SPs were tossing out a full /24 for every t1,
but the smaller ISDN and frac t1 based connections started coming with much
smaller allocations, and PAT was something everyone (small customers)
started wanting badly. There was a smattering of non cisco boxes that
could do a little nat, but customers wanted solid state hardware that was
easy to configure or at least flexible enough to be able to configure for a
variety of wan service offerings - smds, atm, frame, isdn, x.25 was still
here and there, and on the lan side decnet, ipx/spx, netbeui etc were
still in play.
Cisco, Proteon and Wellfleet and 3com to a lesser extent
were the big router players but none of them were addressing the
emerging NAT market very well.
NTI was a small company with good engineers that wrote a
custom kernel that did what few others were doing. I saw a few customers
that actually bought the NTI box or were going to buy the box BEFORE cisco
bought NTI. When Cisco bought NTI and threw their marketing behind the
PIX, and started pushing it to resellers, it took off because it was a
good box that fit a niche market very well. In fact the original NTI boxes
were again more of a nat box that a firewall. When you installed a pix you set
the screening router (a cisco of course) up as the dmz firewall with its
acl capability to protect the dmz hosts and the pix had the outbound nat
config and the conduits for the inbound flow to the inside network. The
original pixes were pretty limited as a firewall and of course had no
capability for a 3rd or 4th interface. They were strictly used for the
corporate/inside network interface/connect point.
Customers bought PIXes at that time because they were easier than having
to figure out how to setup a linux or Sun bastion host / proxy toolkit or
fiddle with ipmasq for most companies that did not have in house un*x
talent. Customers were running out of IPs to number their PCs (and MACs
- remember the need to browse the internet killed appletalk and localtalk)
that and the ISPs were not handing them out (/24s) like candy anymore.
As far as firewall feature set on a router goes ... I had to laugh. I have
always considered that somewhat fiddly / buggy. Good way to make a solid
product (a cisco router) into something that needs more attention and is
slightly less reliable - especially when implemented on low end hardware
like 800s, or 16xx, or 17xx, 2610s, etc. I have seen at least 3 or 4 fw
feature set implementations on routers that were backwards - i.e.
inspecting traffic in the wrong direction. There is also at least one
config for the fwfs on cisco.com's website that has it backwards too that
I ran across.
As far as cisco discontinuing the pix ?? Thats plain wrong. The PIX
lives on, it just has a new name (ASA) so cisco can move upmarket
and charge more for the same code base :)
Of course the cpus are much faster in the ASA boxes, and it has a more
extensible/modular hardware architecture than the pix and you can plug in
the IDS/IPS modules, etc. The ASA boxes usually have a celeron cpu in the
2Ghz range whereas the pixes started of as 486 dx2 66MHz chips (yes
really, with like 4MB or maybe 8MB of main DRAM) and worked their way up
to 300 or 400Mhz PII chips in the beefier models.
Cisco has no interest in migrating any customers from PIX/ASA to routers.
They want to sell you BOTH and a few Cat switches while they are at it :)
And finally, Peder is correct again about the Centri. Centri was a flaming
pile of junk. It ran on windows nt server (workstation was also
supported I'm pretty sure).
Of course it was terrible (the centri) - windows nt was a terrible product
that never really did get stable enough for use as a reliable pc server
much less as a critical piece of network gear. Centri did have some
really "impressive" guis tools for managing firewall configs. At that
time the pix was popular but hard to configure for end customers who
typically have net admins on staff and not network engrs (times
really have not changed have they :). Customers wanted to manage their
own boxes and not have to call an integrator every time an acl needed a
tweak. Thus the pretty gui of the cenrti appealed (in theory). I never saw
one get sold and work though. Couple of demo/evals, and it usually died
there in the sales process :)
It would have been near impossible for anyone to build a firewall based
on windows 3.1 technology. Windows 3.1 did not have a true kernel or built
in (native) tcp stack. Remember Chameleon anyone ? trumpet winsock ?
Those DOS TSR-based "tcp mini kernels" as they were called were so
unstable that a windows 3.1 or 3.11 based firewall would have keeled over
the minute it saw real use. Those stacks were barely functional as a
client, much less a server or firewall.
I dont remember any vendors coming out with windows based "firewalls"
until win nt 4.0. Windows in all its versions just was not stable enough
until then and recall that Windows 3.5 and up are not the same product at
all as win 3.1. Win 3.1 was 16bit dos with a gui command shell and a
gui api. Win 3.5.x and up was Cutler's 32bit rewrite of VAX and
Microsofts first true operating system :)
No way would cisco have purchased or built or sold or recommended
to clients anything based on win3.1 other than maybe a terminal emulator
to attach to a cisco serial console :)
I remember a customer that badly wanted to migrate off of netware to
"save" licensing $$. Remember this was before CALs and such and windows
3.5.1 was almost free as a network server. They had to boot the 3.5.1
server every nite so it would not crash the next day. The netware
3.12 server had been up for like 3-4 years at a time :)
On Fri, 4 Jul 2008, Peder @ NetworkOblivion wrote:
> What!? The original PIX code was < 500k as the first versions from Network
> Translations only had 512k flash moodules in them. There is no way that it
> was based on Windows, not even 3.1. I think you are thinking of the Centri
> (or whatever it was called) that was windows based that they bought many
> years ago. I actually worked at Cisco when they bought the PIX and the
> Centri and then they killed the Centri shortly thereafter. I think the
> Centri ran on Windows 95, but I am not 100% sure as that was 10+ years ago.
>
> IMO, the reason that so many people use(d) the PIX is that they just work.
> You set it up and forget it for two years. You rarely even need to update
> the software on it as there are so few bugs that are show stoppers. Now, the
> ASA is a different story. There is a lot more stuff in it and hence a lot
> more bugs.
>
> Ted Mittelstaedt wrote:
>> Rubbish.
>>
>> The reason the PIX doesen't allow Telnet is that the original
>> PIX devices were built on a Windows core, Windows 3.1 as I
>> believe, with the GUI and most of the command line utilities
>> stripped away. Because the PIX was an early out-of-the-hole
>> firewall, it captured a customer base of customers who needed
>> a firewall but frankly didn't understand much about what they
>> needed. ie: dumb bunnies in cash-rich organizations willing
>> to buy sub-par technology that was hyped up to rediculous
>> amounts. It's an old story in technology.
>>
>> This was a very valuable customer base which is why Cisco
>> purchased the PIX product line. Cisco had little interest
>> in the lame firewalling technology of the PIX and has
>> spent at least a decade of careful work grooming the PIX
>> customers off PIXes and on to Cisco router platforms. To
>> accomplish this they were -extraordinairly- careful to
>> preserve the PIX interface and limitations over the years.
>> But as anyone who works with PIXes knows, Cisco has really
>> not improved the basic technology of the PIX over the years.
>>
>> That is why the current Cisco IOS-based firewalls have
>> a firewalling feature set that knocks a PIX into a cocked
>> hat.
>>
>> It is also why Cisco has finally felt comfortable enough
>> that they have migrated the PIX customers worth keeping
>> over to their own product line, to announce that they were
>> discontinuing the PIX product line. As they did recently.
>>
>> Ted
>>
>>> -----Original Message-----
>>> From: cisco-nsp-bounces[at]puck.nether.net
>>> [mailto:cisco-nsp-bounces[at]puck.nether.net]On Behalf Of Ziv Leyes
>>> Sent: Monday, June 30, 2008 5:31 AM
>>> To: Joerg Mayer; Aaron R
>>> Cc: cisco-nsp[at]puck.nether.net
>>> Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
>>>
>>>
>>> I guess it's more as a "working right" educational purpose, so you won't
>>> use your firewall as a debugging client.
>>> In newer versions there's the packet tracker that can help you debug
>>> connectivity problems.
>>> Ziv
>>>
>>>
>>> -----Original Message-----
>>> From: cisco-nsp-bounces[at]puck.nether.net
>>> [mailto:cisco-nsp-bounces[at]puck.nether.net] On Behalf Of Joerg Mayer
>>> Sent: Monday, June 30, 2008 2:21 PM
>>> To: Aaron R
>>> Cc: cisco-nsp[at]puck.nether.net
>>> Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
>>>
>>> On Mon, Jun 30, 2008 at 06:30:59PM +0800, Aaron R wrote:
>>>> It is disabled as a security feature. I have also wanted to do
>>> the same for
>>>> troubleshooting purposes.
>>> And why exactly is this a security feature? What is the *gain* in
>>> security?
>>>
>>> Ciao
>>> Joerg
>>> --
>>> Joerg Mayer <jmayer[at]loplof.de>
>>> We are stuck with technology when what we really want is just stuff that
>>> works. Some say that should read Microsoft instead of technology.
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp[at]puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>>>
>>>
>>>
>>> ******************************************************************
>>> ******************
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
>>> viruses.
>>> ******************************************************************
>>> ******************
>>>
>>>
>>>
>>>
>>>
>>>
>>> ******************************************************************
>>> ******************
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
>>> viruses.
>>> ******************************************************************
>>> ******************
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp[at]puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp[at]puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp[at]puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp[at]puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
|
