<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/12/2015 06:00,
      <a class="moz-txt-link-abbreviated" href="mailto:nog-request@bdnog.org">nog-request@bdnog.org</a> wrote:<br>
    </div>
    <blockquote cite="mid:mailman.0.1449468001.16375.nog@bdnog.org"
      type="cite">
      <div id="yui_3_16_0_1_1449379094983_11402" dir="ltr">For an
        Example: Suppose your gateway IP is 192.168.1.1, then you can
        implement Standard ACL on the switchport (from where your users
        are connected to)</div>
      <div id="yui_3_16_0_1_1449379094983_11403" dir="ltr"><br>
      </div>
      Switch(config)#access-list 1 deny host 192.168.1.1
      <div class="" id="yui_3_16_0_1_1449379094983_11601" dir="ltr"
        style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
        margin-right:0px; -qt-block-indent:0; text-indent:0px;">Switch(config)#access-list
        1 permit any </div>
      <div id="yui_3_16_0_1_1449379094983_11775" dir="ltr"><br>
      </div>
      <div class="" id="yui_3_16_0_1_1449379094983_11509" style="
        margin-top:0px; margin-bottom:0px; margin-left:0px;
        margin-right:0px; -qt-block-indent:0; text-indent:0px;">Switch(config)#interface
        fastEthernet 0/1</div>
      Switch(config-if)#ip access-group 1 in
      <div id="yui_3_16_0_1_1449379094983_10931" dir="ltr"><br>
      </div>
    </blockquote>
    I'm not sure that's going to help, unless it filters ARP responses
    as well as IP datagrams. That is: it will stop the person with
    address 192.168.1.1 from using the Internet, but it probably won't
    stop the breakage of the other users.<br>
    <br>
    Consider a packet which is going out from PC 192.168.1.100 to the
    Internet, say IP address 8.8.8.8.<br>
    <br>
    Neither of those packets has 192.168.1.1 as a source or destination
    address, so it won't be affected by the filter. However, the PC
    knows that its default gateway is 192.168.1.1, so will send an ARP
    request for 192.168.1.1 to learn the MAC address.<br>
    <br>
    Your router will respond, but so will the hijacker who has manually
    configured 192.168.1.1 as their IP address. Whichever response
    arrives first will be the one which is used, so it's just a race.<br>
    <br>
    If the hijacker's response arrives first, the PC will encapsulate
    their packet with the hijacker's MAC address and deliver it there
    instead of to the Internet. If the hijacker has IP forwarding
    enabled they may re-send it to the router (note that they will be
    able to sniff all outbound traffic!) But most likely the packet will
    be dropped on the floor and connectivity will be broken.<br>
    <br>
    So, to fix this problem properly you would have to do filtering of
    ARP responses; enforce that ARP responses for 192.168.1.1 which
    enter through a port other than the router's port are discarded. I
    believe the Cisco "IP address tracking" feature might be able to do
    that.<br>
    <br>
    However a simpler approach may be to *detect* the problem: for
    example by running a tool like arpwatch on that network segment.
    Then you have an Acceptable Usage Policy which says that the manual
    configuration of IP addresses is *forbidden* and will result in
    serious consequences (make use of your company's or university's
    existing disciplinary procedure)<br>
    <br>
    In my experience, the reason that people actually configure manual
    IP addresses is because the DHCP service is unreliable, and they are
    forced to do this to get work done. If that's the case, then the
    real solution is to make your DHCP service reliable.<br>
    <br>
    It's fine to have two DHCP servers for redundancy:<br>
    <br>
    interface Foo<br>
      ip helper-address 192.0.0.1<br>
      ip helper-address 192.0.2.2<br>
    <br>
    The simplest way to make this work is to give the two DHCP servers
    non-overlapping pools of addresses (e.g. 192.168.1.10-149 and
    192.168.1.150-249). This avoids then need to run DHCP clustering
    where the two servers are both aware of each other's allocations. 
    The user will receive two DHCP offers, will pick the first one and
    use that.<br>
    <br>
    Also it's better if your lease times are sufficiently large (say 12
    hours) so that once they have an address at the start of the day, it
    works all day. For that to work well you might need bigger subnets,
    say a /22 instead of a /24, especially with wireless, but that's not
    a problem if you are using private IP addresses.<br>
    <br>
    HTH,<br>
    <br>
    Brian.<br>
    <br>
  </body>
</html>