<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
While I know its taboo to go all 'vendor specific' on this list, the
Acme does this quite well.<br>
<br>
You can protect your feature server by configuring
max-register-burst-rate on the session-agents and protect the SBC
with proper acl settings on the access side of the SBC.<br>
<br>
There is likely not much that can be done for race conditions on reg
floods your own configs are causing due to improper timer settings,
but a properly configured SBC should be able to handle a
registration flood caused by a flapping BGP peer.<br>
<br>
Christian Pena<br>
<br>
Ujjval Karihaloo wrote:
<blockquote
cite="mid:EB7435A0AAA8874F845F4A88F1B399240665A8714E@EXMBXCLUS01.citservers.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);">ACME DDOS BCP clearly says it has not been tested
for REGISTRATION floods. Any SBC out there that can
withstand a REG flood?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size: 11pt;
font-family: "Calibri","sans-serif";
color: rgb(31, 73, 125);">UK</span><span style="font-size:
11pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size: 11pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);"><o:p> </o:p></span></p>
<div>
<div style="border-right: medium none; border-width: 1pt
medium medium; border-style: solid none none; border-color:
rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color;
padding: 3pt 0in 0in;">
<p class="MsoNormal"><b><span style="font-size: 10pt;
font-family:
"Tahoma","sans-serif";">From:</span></b><span
style="font-size: 10pt; font-family:
"Tahoma","sans-serif";">
anorexicpoodle [<a class="moz-txt-link-freetext" href="mailto:anorexicpoodle@gmail.com">mailto:anorexicpoodle@gmail.com</a>] <br>
<b>Sent:</b> Wednesday, February 23, 2011 4:40 PM<br>
<b>To:</b> Ujjval Karihaloo<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>
<b>Subject:</b> Re: [VoiceOps] ACMEs SIP Dynamic HNT<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I use AHNT extensively and it works
extremely well. It is critical to note that if the device
doesnt respect the expires= parameter than almost no nat
traversal on the SBC will work. <br>
<br>
Some gotchas: <br>
<br>
1: If you aren't careful about tuning your timers you can
quickly overwhelm the CPU of the SBC with a large subscriber
base. <br>
<br>
2: Understand your endpoint and network behavioral patterns.
Because HNT(or AHNT) on any level creates a disparity between
the public UA and the UA in the softswitch it is possible to
inadvertently create registration storms with poor timer and
cache settings. This will cripple and SBC faster than you
could think. The more common scenario I have seen is endpoints
are on a 45 second registration timer, and an equally short
grace period. You experience some kind of BGP issue with a
peer causing all your HNT endpoints via that BGP session to go
dead for 180 seconds (bgp failure timer). This means their
public UA is removed from the SD but their softswitch
registration remains (if you aren't using authentication you
could use forced unregistration but thats a whole different
can of worms). When that BGP session is re-established those
devices will come at you in a flood. Each of those registers
MUST be challenged by the softswitch. If this flood is large
enough it can edge out other traffic creating more
retransmissions etc and overall getting quite ugly. There are
protections in the SD for this but they are reactionary and
don't apply well to this sort of traffic. <br>
<br>
3: Watch your SD CPU usage like a hawk. On the access side
this will be the single limiting factor for how far you can
strech a pair of SD's<br>
<br>
4: Early registration makes AHNT much less effective. IF you
have devices that regularly send early registrations this will
dramatically hinder the AHNT nat discovery algorithms ability
to detect the right timer. Many devices attempting to be
clever will re-register at 50% of the expires= value. This
really hurts AHNT. <br>
<br>
<br>
-anorexicpoodle<br>
<br>
<br>
<br>
On Wed, 2011-02-23 at 15:12 -0800, Ujjval Karihaloo wrote: <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom: 12pt;">Hi Guys:<br>
<br>
<br>
<br>
We have not used the ACMEs SIP Dynamic HNT feature, where
the ACME sends OPTIONS msgs to individual endpoints on its
Access side and adjusts their expires times as per individual
Firewalls that they are behind.<br>
<br>
<br>
<br>
While it sounds cool, I was wondering if folks have noticed
issues with using it given that some endpoints out there don’t
even honor the Expires header from REGISTRARs and as the ACME
determines the correct NAT interval automatically, it may
leave some endpoints de-registers for small intervals (as per
ACME ACLI guide).<br>
<br>
<br>
<br>
Thx for your input<br>
<br>
<br>
<br>
UK<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<pre><o:p> </o:p></pre>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>VoiceOps mailing list<o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
</body>
</html>