Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

3640 and 3DES IPSec

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


barney.gumbo at gmail

Sep 19, 2005, 11:59 AM

Post #1 of 12 (1023 views)
Permalink
3640 and 3DES IPSec

Can anyone provide info on realistic CPU utilization expectations for a 3640
running NAT overload, CBAC, IPSec 3DES for encryption, GRE over the IPSec,
with BGP as the routing protocol, with a single T1 to the internet for the
IPSec transport?

When there is approx 900 kbps in/out on the T1, CPU utilization on a 3640 I
have is between 99-100%. Show proc cpu has the encryption process using 75%
of the CPU consistently.

The BGP process has approx 100 routes, it is used for internal routing, not
peering with internet routers. There is nothing else interesting happening
on the router, the only traffic being NAT'd is the IPSec/GRE tunnel. CBAC
looks normal as well.

I don't recall ever seeing this type of CPU utilization for IPSec before. I
did some research and can't find any hard numbers. I know a basic VPN
accelerator module is supposed to be able to support approx 10 Mbps in/out
for 3DES IPSec, I hope a standard 3640 can support at least 1 Mbps.

Can anyone provide any real world experience with throughput on a 3640 with
the config and operations mentioned above?


mahargk at gmail

Sep 19, 2005, 12:30 PM

Post #2 of 12 (1005 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

On 9/19/05, barney gumbo <barney.gumbo [at] gmail> wrote

> When there is approx 900 kbps in/out on the T1, CPU utilization on a 3640 I
> have is between 99-100%. Show proc cpu has the encryption process using 75%
> of the CPU consistently.
>
> Can anyone provide any real world experience with throughput on a 3640 with
> the config and operations mentioned above?

That's pretty consistent w/ what I've seen, certainly don't expect
much more. I never tried other variants (ie. SEAL) due to lack of HW
support on the far-end, only 3DES or AES which came in around the
same.

Given what a NM-VPN/MP would cost (and that its only useful on a 3620
or 3640), take a look at the 2811SEC-K9 bundle -- it will handle this
load w/ plenty of headroom.


bpalmer at fxcm

Sep 19, 2005, 8:02 PM

Post #3 of 12 (1024 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

>>> barney gumbo <barney.gumbo [at] gmail> 2005.09.19 14:59:28 >>>
Can anyone provide info on realistic CPU utilization expectations for a 3640
running NAT overload, CBAC, IPSec 3DES for encryption, GRE over the IPSec,
with BGP as the routing protocol, with a single T1 to the internet for the
IPSec transport?


3640s are a dog for IPsec. For T1s, use 2811-k9 or for T3s use 2821s.

IPSec without the AIM modules (part of the 2800s by default, but not on the 3640s) kills the router CPU.

On our 2821s, we see full speed crypro on the T3. The 2811s don't even break a sweat with 4 T1s. A 3725 started crying at about 4mb/s unless we added an AIM module.

- Brandon


nick.nauwelaerts at thomson

Sep 20, 2005, 12:16 AM

Post #4 of 12 (1005 views)
Permalink
RE: 3640 and 3DES IPSec [In reply to]

> -----Original Message-----
> From: cisco-nsp-bounces [at] puck
> [mailto:cisco-nsp-bounces [at] puck] On Behalf Of FXCM
> - "Brandon Palmer
> Sent: Tuesday, September 20, 2005 05:02 AM
> To: barney gumbo; cisco-nsp [at] puck
> Subject: Re: [c-nsp] 3640 and 3DES IPSec
>
>
> >>> barney gumbo <barney.gumbo [at] gmail> 2005.09.19 14:59:28 >>>
> Can anyone provide info on realistic CPU utilization
> expectations for a 3640
> running NAT overload, CBAC, IPSec 3DES for encryption, GRE
> over the IPSec,
> with BGP as the routing protocol, with a single T1 to the
> internet for the
> IPSec transport?
>
>
> 3640s are a dog for IPsec. For T1s, use 2811-k9 or for T3s
> use 2821s.
>
> IPSec without the AIM modules (part of the 2800s by default,
> but not on the 3640s) kills the router CPU.
>
> On our 2821s, we see full speed crypro on the T3. The 2811s
> don't even break a sweat with 4 T1s. A 3725 started crying
> at about 4mb/s unless we added an AIM module.

And 1 more vote to that. CPUs in these boxes just aren't up to
encrypting that amount of data. Adding AIMs or VPN modules for the
36(2,4)0's will drop your cpu usage significantly. To give you an idea,
the 2600's we've got running doing ipsec & compression do so at about
60% CPU for a 512kbit line, and at 5% CPU when we add an AIM. Only had
3660's with AIMs and 3845's, but I expect the results to be comparable.

// nick


tedm at toybox

Sep 21, 2005, 9:08 AM

Post #5 of 12 (1002 views)
Permalink
RE: 3640 and 3DES IPSec [In reply to]

what about switching to single DES not triple DES?

Ted

>-----Original Message-----
>From: cisco-nsp-bounces [at] puck
>[mailto:cisco-nsp-bounces [at] puck]On Behalf Of barney gumbo
>Sent: Monday, September 19, 2005 11:59 AM
>To: cisco-nsp [at] puck
>Subject: [c-nsp] 3640 and 3DES IPSec
>
>
>Can anyone provide info on realistic CPU utilization
>expectations for a 3640
>running NAT overload, CBAC, IPSec 3DES for encryption, GRE over
>the IPSec,
>with BGP as the routing protocol, with a single T1 to the
>internet for the
>IPSec transport?
>
>When there is approx 900 kbps in/out on the T1, CPU utilization
>on a 3640 I
>have is between 99-100%. Show proc cpu has the encryption
>process using 75%
>of the CPU consistently.
>
>The BGP process has approx 100 routes, it is used for internal
>routing, not
>peering with internet routers. There is nothing else
>interesting happening
>on the router, the only traffic being NAT'd is the IPSec/GRE
>tunnel. CBAC
>looks normal as well.
>
>I don't recall ever seeing this type of CPU utilization for
>IPSec before. I
>did some research and can't find any hard numbers. I know a basic VPN
>accelerator module is supposed to be able to support approx 10
>Mbps in/out
>for 3DES IPSec, I hope a standard 3640 can support at least 1 Mbps.
>
>Can anyone provide any real world experience with throughput on
>a 3640 with
>the config and operations mentioned above?
>_______________________________________________
>cisco-nsp mailing list cisco-nsp [at] puck
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>--
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date:
>8/31/2005
>


barney.gumbo at gmail

Sep 21, 2005, 10:19 AM

Post #6 of 12 (999 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

TAC is investigating a few paths. They thought the +/-800 Kbps ceiling we
are seeing was a bit low. I plan to try going to DES as well as turning CEF
off. CEF is currently on, someone provided some past experience where
disabling CEF actually helped CPU utilization on a simple two interface
router with IPSec/GRE.
Thanks to all for the feedback.

On 9/21/05, Ted Mittelstaedt <tedm [at] toybox> wrote:
>
>
> what about switching to single DES not triple DES?
>
> Ted
>
> >-----Original Message-----
> >From: cisco-nsp-bounces [at] puck
> >[mailto:cisco-nsp-bounces [at] puck]On Behalf Of barney gumbo
> >Sent: Monday, September 19, 2005 11:59 AM
> >To: cisco-nsp [at] puck
> >Subject: [c-nsp] 3640 and 3DES IPSec
> >
> >
> >Can anyone provide info on realistic CPU utilization
> >expectations for a 3640
> >running NAT overload, CBAC, IPSec 3DES for encryption, GRE over
> >the IPSec,
> >with BGP as the routing protocol, with a single T1 to the
> >internet for the
> >IPSec transport?
> >
> >When there is approx 900 kbps in/out on the T1, CPU utilization
> >on a 3640 I
> >have is between 99-100%. Show proc cpu has the encryption
> >process using 75%
> >of the CPU consistently.
> >
> >The BGP process has approx 100 routes, it is used for internal
> >routing, not
> >peering with internet routers. There is nothing else
> >interesting happening
> >on the router, the only traffic being NAT'd is the IPSec/GRE
> >tunnel. CBAC
> >looks normal as well.
> >
> >I don't recall ever seeing this type of CPU utilization for
> >IPSec before. I
> >did some research and can't find any hard numbers. I know a basic VPN
> >accelerator module is supposed to be able to support approx 10
> >Mbps in/out
> >for 3DES IPSec, I hope a standard 3640 can support at least 1 Mbps.
> >
> >Can anyone provide any real world experience with throughput on
> >a 3640 with
> >the config and operations mentioned above?
> >_______________________________________________
> >cisco-nsp mailing list cisco-nsp [at] puck
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >--
> >Internal Virus Database is out-of-date.
> >Checked by AVG Anti-Virus.
> >Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date:
> >8/31/2005
> >
>


mahargk at gmail

Sep 21, 2005, 9:54 PM

Post #7 of 12 (1002 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

On 9/21/05, barney gumbo <barney.gumbo [at] gmail> wrote:
> CEF is currently on, someone provided some past experience where
> disabling CEF actually helped CPU utilization on a simple two interface
> router with IPSec/GRE.

Assuming this was true and they were running a reasonably recent
release, this would be bug behavior. Its a shame they didn't share
their tuning experiences with the rest of the list.


barney.gumbo at gmail

Sep 22, 2005, 8:42 AM

Post #8 of 12 (1003 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

In case anyone is interested, disabling IP CEF did not help, it made the
problem slightly worse. In fact, traffic which was generated during the test
(icmp echo-req / echo-reply) was all 1000 bytes long and enough was sent to
generate > 500kbps. With IP CEF disabled, CPU went to 99% before the
throughput reached 450kbps. The pings were through the router, not to/from
any router interface. If anything, I would think packets of the same size
would have been easier to handle. The router is running recent
12.2non-T-train code, I forget the exact dot version.

The comment about "someone provide past experience" was a conversation, not
an off-list reply. Nothing important or interesting has been missed.

On 9/22/05, Kevin Graham <mahargk [at] gmail> wrote:
>
> On 9/21/05, barney gumbo <barney.gumbo [at] gmail> wrote:
> > CEF is currently on, someone provided some past experience where
> > disabling CEF actually helped CPU utilization on a simple two interface
> > router with IPSec/GRE.
>
> Assuming this was true and they were running a reasonably recent
> release, this would be bug behavior. Its a shame they didn't share
> their tuning experiences with the rest of the list.
>


tedm at toybox

Sep 23, 2005, 1:53 AM

Post #9 of 12 (1002 views)
Permalink
RE: 3640 and 3DES IPSec [In reply to]

Oh come off it, there's been reports of problems with CEF for
years. And it hasn't gone away anytime soon, I had a new
load-balanced ip cef setup blow chunks running 12.2 IOS about
3-4 months ago on a 3620. I finally threw the config in the trash
and went to MPPP and it's run fine ever since.

The only time I've had CEF work right was on our 7206's running
12.2 and none of them are doing load balancing. And that only
happened in the last year or so, previously I'd get random reboots
on them when it was enabled.

Ted

>-----Original Message-----
>From: Kevin Graham [mailto:mahargk [at] gmail]
>Sent: Wednesday, September 21, 2005 9:55 PM
>To: barney gumbo
>Cc: Ted Mittelstaedt; cisco-nsp [at] puck
>Subject: Re: [c-nsp] 3640 and 3DES IPSec
>
>
>On 9/21/05, barney gumbo <barney.gumbo [at] gmail> wrote:
>> CEF is currently on, someone provided some past experience where
>> disabling CEF actually helped CPU utilization on a simple two
>interface
>> router with IPSec/GRE.
>
>Assuming this was true and they were running a reasonably recent
>release, this would be bug behavior. Its a shame they didn't share
>their tuning experiences with the rest of the list.
>
>--
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date:
>8/31/2005
>


tim at colt

Sep 23, 2005, 2:09 AM

Post #10 of 12 (1013 views)
Permalink
RE: 3640 and 3DES IPSec [In reply to]

> Oh come off it, there's been reports of problems with CEF for
> years. And it hasn't gone away anytime soon, I had a new
> load-balanced ip cef setup blow chunks running 12.2 IOS about
> 3-4 months ago on a 3620. I finally threw the config in the trash
> and went to MPPP and it's run fine ever since.
>
> The only time I've had CEF work right was on our 7206's running
> 12.2 and none of them are doing load balancing. And that only
> happened in the last year or so, previously I'd get random reboots
> on them when it was enabled.

Are you mixing up "CEF" and "CEF load-sharing"? Running routers with "no ip
cef" is generally about as much fun as being fed into the bacon slicer
feet-first.

FWIW, I much prefer MLPPP over CEF load-sharing too, where the MLPPP support
on a platform is solid. But that's for the ease of provisioning /
management / monitoring and QoS sanity you get from having a single L3
interface rather than due to any brokenisms in CEF.

Regards,
Tim.

--
____________ Tim Franklin e: tim [at] colt
\C/\O/\L/\T/ Product Engineering Manager w: www.colt.net
V V V V Managed Data Services t: +44 20 7863 5714
Data | Voice | Managed Services f: +44 20 7863 5876


tedm at toybox

Sep 24, 2005, 1:15 AM

Post #11 of 12 (1007 views)
Permalink
RE: 3640 and 3DES IPSec [In reply to]

>-----Original Message-----
>From: Tim Franklin [mailto:tim [at] colt]
>Sent: Friday, September 23, 2005 2:10 AM
>To: 'Ted Mittelstaedt'; 'Kevin Graham'; 'barney gumbo'
>Cc: cisco-nsp [at] puck
>Subject: RE: [c-nsp] 3640 and 3DES IPSec
>
>
>> Oh come off it, there's been reports of problems with CEF for
>> years. And it hasn't gone away anytime soon, I had a new
>> load-balanced ip cef setup blow chunks running 12.2 IOS about
>> 3-4 months ago on a 3620. I finally threw the config in the trash
>> and went to MPPP and it's run fine ever since.
>>
>> The only time I've had CEF work right was on our 7206's running
>> 12.2 and none of them are doing load balancing. And that only
>> happened in the last year or so, previously I'd get random reboots
>> on them when it was enabled.
>
>Are you mixing up "CEF" and "CEF load-sharing"?

yes. It was just an example. The router I had blow chunks ran fine
with ip cef before trying the load balancing horseshit. Of course it was
running 12.2 I have had trouble with regular ip cef on 12.1 and earlier
IOS trains. I was using that as an example to illustrate that cef hasn't
been fully debugged yet. They have fixed the obvious stuff like regular
packet forwarding, but the load balancing code in cef is still shakey.

It's crazy since cef has been around for years and a number of versions,
but I have always had problems with it even with textbook plain jane
configs until the latest IOS trains, basically 12.2 But a lot of the
routers
we are responsible for are older ones like 1600's that have restricted
ram that pretty much tops them out at 12.0 That's slowly changing but
it's not really possible to convince a customer that the router they have
been using and that is purring away in the corner without trouble
suddenly
needs to be replaced.

Ted


reuben-cisco-nsp at reub

Sep 24, 2005, 1:53 AM

Post #12 of 12 (1004 views)
Permalink
Re: 3640 and 3DES IPSec [In reply to]

On 24/09/2005 8:15 p.m., Ted Mittelstaedt wrote:
>
>> -----Original Message-----
>> From: Tim Franklin [mailto:tim [at] colt]
>> Sent: Friday, September 23, 2005 2:10 AM
>> To: 'Ted Mittelstaedt'; 'Kevin Graham'; 'barney gumbo'
>> Cc: cisco-nsp [at] puck
>> Subject: RE: [c-nsp] 3640 and 3DES IPSec
>>
>>
>>> Oh come off it, there's been reports of problems with CEF for
>>> years. And it hasn't gone away anytime soon, I had a new
>>> load-balanced ip cef setup blow chunks running 12.2 IOS about
>>> 3-4 months ago on a 3620. I finally threw the config in the trash
>>> and went to MPPP and it's run fine ever since.
>>>
>>> The only time I've had CEF work right was on our 7206's running
>>> 12.2 and none of them are doing load balancing. And that only
>>> happened in the last year or so, previously I'd get random reboots
>>> on them when it was enabled.
>> Are you mixing up "CEF" and "CEF load-sharing"?
>
> yes. It was just an example. The router I had blow chunks ran fine
> with ip cef before trying the load balancing horseshit. Of course it was
> running 12.2 I have had trouble with regular ip cef on 12.1 and earlier
> IOS trains. I was using that as an example to illustrate that cef hasn't
> been fully debugged yet. They have fixed the obvious stuff like regular
> packet forwarding, but the load balancing code in cef is still shakey.

I agree. I have found that upon calling the TAC with what often appears to be
a bug or issue with things like IPSec, NAT or WCCP, turning CEF off at least
on the smaller platforms is one of the first things I get asked to try. That
is probably quite telling - if CEF was rarely implicated one would expect it
would hardly ever be suggested.

My understanding is also that CEF (or in fact any sort of fast switching) is
useless on a router which is doing Firewall Inspection, due to the fact that
inspection must be done at interrupt level. If I'm wrong someone please
correct me........but my understanding is that it is one of the main
limitations of using a router as a stateful inspected firewall :(

reuben

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.