<br><br><div class="gmail_quote">On Thu, May 8, 2008 at 12:04 PM, Tom Storey <<a href="mailto:tom@snnap.net">tom@snnap.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
As for the NPE-G1, typically Ive seen around 4000 sessions terminated<br>
before the CPU really starts getting bogged down. Thats with an ACL<br>
and rate-limit per user.<br>
<div><div></div></div></blockquote><div><br>I can confirm having seen this kind of figure on the G1. The limit really appears to be CPU and is effected not only by the number of tunnels but by the bandwidth and packet rate per tunnel. This means that the type of user and application can have a big impact. Also certain features, like cache-flow use significant extra CPU and thus reduce the max tunnels.<br>
<br>Due to the fact that in this application the box appears to be primarily CPU bound we have found the amount of tunnels / traffic scales with the CPU speed, i.e as you go from NPE400 to G1 and then G2 the number of tunnels ( assuming the same bandwidth and packet rate per client) scales proportionally to the increase in CPU speed.<br>
<br>We had little success with the MPF features available on the G1.<br>(<a href="http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/MPF123T7.html">http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/MPF123T7.html</a>)<br>
Although it seemed to address CPU load to some extent it introduced various other forwarding issues.<br><br>Due to the variables involved there seems to be very little firm documentation on the subject of actual number of tunnels.<br>
<br>Regards<br>Neil<br><br></div></div>