<!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>