[118692] in North American Network Operators' Group
Re: Alcatel-Lucent VPN Firewall Brick
daemon@ATHENA.MIT.EDU (Justin M. Streiner)
Mon Oct 26 18:33:55 2009
Date: Mon, 26 Oct 2009 18:32:48 -0400 (EDT)
From: "Justin M. Streiner" <streiner@cluebyfour.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <75cb24520910261429h54a97bddp591005ee90aff596@mail.gmail.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1463794431-1259675409-1256596368=:3556
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Mon, 26 Oct 2009, Christopher Morrow wrote:
> On Mon, Oct 26, 2009 at 12:36 PM, Justin M. Streiner
> <streiner@cluebyfour.org> wrote:
>> On Mon, 26 Oct 2009, Jay Nakamura wrote:
>>
>>> Looking for input on Alcatel-Lucent VPN Firewall Brick. =A0I can look u=
p
>>> spec and other published information but, as always, the devil is in
>>> the detail and you just never know what wall you run into until you
>>> actually try it so I wanted to see if anyone has used this and can
>>> point out good/bad things about this device.
>>>
>>> Our other option is Cisco IOS router right now. =A0Are there better
>>> options than these two?
>>
>> Fair warning: v6 honestly seems to have caught most firewall vendors wit=
h
>> their pants down.
>
> I'm not really sure that in the year 2009 that's a fair thing to still
> expect... honestly ipv6 has been in 'production' for ~7 years, for a
> CPE deployment it's certainly been to the point where it should be
> included by default.
>
> -1 alcalu :(
I don't know about AL's v6 status because I'm in the process of migrating=
=20
away from them, and have been in the process of lots of due diligence with=
=20
vendors in the past 6-ish months. v6 support is pretty high on our=20
list of 'must have' items. I've been pretty disappointed with the=20
response from most vendors. Many of those have been along the lines of:
"Yeah... our v6 code should be out of customer trials in Q2 2010..."
"We do v6 in software today, and the next spin of XYZ hardware will do it=
=20
in the ASICs..."
"We're working some kinks out, so the box forwards X pps of v6 today=20
(let Y =3D the amount of v4 traffic the box can handle, let X =3D some=20
amount significantly lower than Y), but we should have all of that sorted=
=20
out in the next major code release and be able to handle Y pps of v6=20
then."
"The firewall handles v6 today, but v6 support in the management front-end=
=20
is still baking. Should be ready to go in the next release."
Vendor responses to my "v6 has been around for about 10 years... why is=20
all of this only happening *now*?" questions have largely been along the=20
lines of "Customers only started asking for or requiring v6 support in the=
=20
last X months/years...". This gets us back to chicken-and-egg time.
I can understand their position to a degree, i.e. why waste resources on=20
things that customers aren't requesting (read: won't compel them to buy=20
more/bigger hardware or renew/upgrade support contracts)? This might have=
=20
been a somewhat valid position several years ago, but v6 as a necessity=20
has been on many customers' radars for several years ago. Frankly, not=20
having fully baked v6 support today is pretty much inexcusable IMHO.
jms
---1463794431-1259675409-1256596368=:3556--
