Aging implementation

Discussion in 'Cisco' started by syuga2012@gmail.com, Feb 14, 2009.

  1. Guest

    Hi Folks,

    I am trying to understand how arp table entries (just used ARP as an
    example case) are aged out from an implementation point of view. For
    e.g how the timers are implemented to do the job.

    Appreciate your help.

    Thanks,
    syuga
     
    , Feb 14, 2009
    #1
    1. Advertising

  2. bod43 Guest

    On 14 Feb, 08:21, "" <> wrote:
    > Hi Folks,
    >
    > I am trying to understand how arp table entries (just used ARP as an
    > example case) are aged out from an implementation point of view. For
    > e.g how the timers are implemented to do the job.


    If I was interested in this I would dig out some linux
    or similar source.
     
    bod43, Feb 14, 2009
    #2
    1. Advertising

  3. Thrill5 Guest

    <> wrote in message
    news:...
    > Hi Folks,
    >
    > I am trying to understand how arp table entries (just used ARP as an
    > example case) are aged out from an implementation point of view. For
    > e.g how the timers are implemented to do the job.
    >
    > Appreciate your help.
    >
    > Thanks,
    > syuga


    In IOS, there is a an ARP aging process that removes expired entries. I
    don't know specifically how this is implemented, but generically, IOS
    implements a scheduler, and processes are scheduled to run at specific
    intervals.
     
    Thrill5, Feb 14, 2009
    #3
  4. John Agosta Guest

    "Thrill5" <> wrote in message
    news:gn7a4n$9t7$...
    >
    > <> wrote in message
    > news:...
    >> Hi Folks,
    >>
    >> I am trying to understand how arp table entries (just used ARP as an
    >> example case) are aged out from an implementation point of view. For
    >> e.g how the timers are implemented to do the job.
    >>
    >> Appreciate your help.
    >>
    >> Thanks,
    >> syuga

    >
    > In IOS, there is a an ARP aging process that removes expired entries. I
    > don't know specifically how this is implemented, but generically, IOS
    > implements a scheduler, and processes are scheduled to run at specific
    > intervals.
    >



    ARP (and other) timers are usually adjustable by the admin with an arp
    timeout or similar command. I think the default is 5 minutes.
     
    John Agosta, Feb 15, 2009
    #4
  5. bod43 Guest

    On 15 Feb, 23:21, "John Agosta" <> wrote:
    > "Thrill5" <> wrote in message
    >
    > news:gn7a4n$9t7$...
    >
    >
    >
    >
    >
    >
    >
    > > <> wrote in message
    > >news:....
    > >> Hi Folks,

    >
    > >> I am trying to understand how arp table entries (just used ARP as an
    > >> example case) are aged out from an implementation point of view. For
    > >> e.g how the timers are implemented to do the job.

    >
    > >> Appreciate your help.

    >
    > >> Thanks,
    > >> syuga

    >
    > > In IOS, there is a an ARP aging process that removes expired entries.  I
    > > don't know specifically how this is implemented, but generically, IOS
    > > implements a scheduler, and processes are scheduled to run at specific
    > > intervals.

    >
    > ARP (and other) timers are usually adjustable by the admin with an arp
    > timeout or similar command. I think the default is 5 minutes.- Hide quoted text -


    By the way -
    On a cisco router I think the default is 14,400 seconds
    (4 hours) - from memory:)

    In other words almost forever.
     
    bod43, Feb 16, 2009
    #5
  6. Thrill5 Guest

    "bod43" <> wrote in message
    news:...
    On 15 Feb, 23:21, "John Agosta" <> wrote:
    > "Thrill5" <> wrote in message
    >
    > news:gn7a4n$9t7$...
    >
    >
    >
    >
    >
    >
    >
    > > <> wrote in message
    > >news:...
    > >> Hi Folks,

    >
    > >> I am trying to understand how arp table entries (just used ARP as an
    > >> example case) are aged out from an implementation point of view. For
    > >> e.g how the timers are implemented to do the job.

    >
    > >> Appreciate your help.

    >
    > >> Thanks,
    > >> syuga

    >
    > > In IOS, there is a an ARP aging process that removes expired entries. I
    > > don't know specifically how this is implemented, but generically, IOS
    > > implements a scheduler, and processes are scheduled to run at specific
    > > intervals.

    >
    > ARP (and other) timers are usually adjustable by the admin with an arp
    > timeout or similar command. I think the default is 5 minutes.- Hide quoted
    > text -


    -By the way -
    -On a cisco router I think the default is 14,400 seconds
    -(4 hours) - from memory:)
    -
    -In other words almost forever.

    Yes the default is 4 hours, but if you are running HSRP on a pair of
    switches, you need to change the default ARP timeout to 300 seconds to match
    the mac-address-table timeout (which is 300 seconds or 5 minutes) on each
    VLAN you are running HSRP. If switch A is the HSRP router, but switch B is
    the router used for the return traffic, switch B can flood the traffic out
    the VLAN as an unknown unicast. This can happen because the
    mac-address-table is only updated when traffic is RECEIVED. Since switch A
    is the default router (because it is the active HSRP router), switch B will
    not see any traffic from the client, and the mac-address-table entry will
    age out. By setting the ARP timeout to same value as the mac-address-table
    timeout, you will force switch B to ARP the client every 300 seconds. When
    switch B receives the ARP reply, it will update the ARP entry AND the
    mac-address-table, ensuring that the mac-address is known and keeping
    everything working properly. I would consider this a bug, with the bug fix
    as setting the ARP timeout to match the mac-address-table timeout whenever
    HSRP is enabled on a layer 3 VLAN. Cisco does not officially consider this
    bug. If you running HSRP and see lots of unknown unicast traffic on a
    VLAN, you are seeing this issue.
     
    Thrill5, Feb 16, 2009
    #6
  7. Thrill5 Guest

    "Phil Harrison" <> wrote in message
    news:2009021619574816807-ph@bcsorg...
    > On 2009-02-16 07:15:56 +0100, "Thrill5" <> said:
    >
    >>
    >> "bod43" <> wrote in message
    >> news:...
    >> On 15 Feb, 23:21, "John Agosta" <> wrote:
    >>> "Thrill5" <> wrote in message
    >>>
    >>> news:gn7a4n$9t7$...
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>> <> wrote in message
    >>>> news:...
    >>>>> Hi Folks,
    >>>
    >>>>> I am trying to understand how arp table entries (just used ARP as an
    >>>>> example case) are aged out from an implementation point of view. For
    >>>>> e.g how the timers are implemented to do the job.
    >>>
    >>>>> Appreciate your help.
    >>>
    >>>>> Thanks,
    >>>>> syuga
    >>>
    >>>> In IOS, there is a an ARP aging process that removes expired entries. I
    >>>> don't know specifically how this is implemented, but generically, IOS
    >>>> implements a scheduler, and processes are scheduled to run at specific
    >>>> intervals.
    >>>
    >>> ARP (and other) timers are usually adjustable by the admin with an arp
    >>> timeout or similar command. I think the default is 5 minutes.- Hide
    >>> quoted
    >>> text -

    >>
    >> -By the way -
    >> -On a cisco router I think the default is 14,400 seconds
    >> -(4 hours) - from memory:)
    >> -
    >> -In other words almost forever.
    >>
    >> Yes the default is 4 hours, but if you are running HSRP on a pair of
    >> switches, you need to change the default ARP timeout to 300 seconds to
    >> match
    >> the mac-address-table timeout (which is 300 seconds or 5 minutes) on each
    >> VLAN you are running HSRP. If switch A is the HSRP router, but switch B
    >> is
    >> the router used for the return traffic, switch B can flood the traffic
    >> out
    >> the VLAN as an unknown unicast. This can happen because the
    >> mac-address-table is only updated when traffic is RECEIVED. Since switch
    >> A
    >> is the default router (because it is the active HSRP router), switch B
    >> will
    >> not see any traffic from the client, and the mac-address-table entry will
    >> age out. By setting the ARP timeout to same value as the
    >> mac-address-table
    >> timeout, you will force switch B to ARP the client every 300 seconds.
    >> When
    >> switch B receives the ARP reply, it will update the ARP entry AND the
    >> mac-address-table, ensuring that the mac-address is known and keeping
    >> everything working properly. I would consider this a bug, with the bug
    >> fix
    >> as setting the ARP timeout to match the mac-address-table timeout
    >> whenever
    >> HSRP is enabled on a layer 3 VLAN. Cisco does not officially consider
    >> this
    >> bug. If you running HSRP and see lots of unknown unicast traffic on a
    >> VLAN, you are seeing this issue.

    >
    > Going somewhat OT, but..
    >
    > This only happens for traffic that is assymetrically routed on outgoing
    > and return path, typically if active HSRP instances are load-balanced
    > across the switches, which is quite common.
    >
    > However it is not at all a bug, simply how any switch functions with such
    > designs, and well documented at (Case Study #8):
    > http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml
    >
    > The
    > better solution is actually to increase CAM aging to match ARP timeout
    > rather than reducing ARP timeout, as the latter incurrs more time needed
    > processing ARP on network and endpoint CPUs.
    >
    > -Phil
    >

    The" well documented" part is why I consider this a bug. It is a known
    issue and should be addressed. A warning printed when enabling HSRP on a
    VLAN would also suffice as is done when you enable port-fast.

    ARP processing so low that it does make any noticable dent in CPU time even
    when set to 5 minutes on a very busy switch. Depending on who you talk to
    at Cisco, some recommend reducing the ARP timeout, and others recommend
    increasing the mac aging timer. I personally am in the reducing the ARP
    timeout camp.
     
    Thrill5, Feb 16, 2009
    #7
  8. bod43 Guest

    On 16 Feb, 19:45, "Thrill5" <> wrote:
    > "Phil Harrison" <> wrote in message
    >
    > news:2009021619574816807-ph@bcsorg...
    >
    >
    >
    > > On 2009-02-16 07:15:56 +0100, "Thrill5" <> said:

    >
    > >> "bod43" <> wrote in message
    > >>news:....
    > >> On 15 Feb, 23:21, "John Agosta" <> wrote:
    > >>> "Thrill5" <> wrote in message

    >
    > >>>news:gn7a4n$9t7$...

    >
    > >>>> <> wrote in message
    > >>>>news:...
    > >>>>> Hi Folks,

    >
    > >>>>> I am trying to understand how arp table entries (just used ARP as an
    > >>>>> example case) are aged out from an implementation point of view. For
    > >>>>> e.g how the timers are implemented to do the job.

    >
    > >>>>> Appreciate your help.

    >
    > >>>>> Thanks,
    > >>>>> syuga

    >
    > >>>> In IOS, there is a an ARP aging process that removes expired entries.. I
    > >>>> don't know specifically how this is implemented, but generically, IOS
    > >>>> implements a scheduler, and processes are scheduled to run at specific
    > >>>> intervals.

    >
    > >>> ARP (and other) timers are usually adjustable by the admin with an arp
    > >>> timeout or similar command. I think the default is 5 minutes.- Hide
    > >>> quoted
    > >>> text -

    >
    > >> -By the way -
    > >> -On a cisco router I think the default is 14,400 seconds
    > >> -(4 hours) - from memory:)
    > >> -
    > >> -In other words almost forever.

    >
    > >> Yes the default is 4 hours, but if you are running HSRP on a pair of
    > >> switches, you need to change the default ARP timeout to 300 seconds to
    > >> match
    > >> the mac-address-table timeout (which is 300 seconds or 5 minutes) on each
    > >> VLAN you are running HSRP.  If switch A is the HSRP router, but switch B
    > >> is
    > >> the router used for the return traffic, switch B can flood the traffic
    > >> out
    > >> the VLAN as an unknown unicast.  This can happen because the
    > >> mac-address-table is only updated when traffic is RECEIVED. Since switch
    > >> A
    > >> is the default router (because it is the active HSRP router), switch B
    > >> will
    > >> not see any traffic from the client, and the mac-address-table entry will
    > >> age out.  By setting the ARP timeout to same value as the
    > >> mac-address-table
    > >> timeout, you will force switch B to ARP the client every 300 seconds.
    > >> When
    > >> switch B receives the ARP reply, it will update the ARP entry AND the
    > >> mac-address-table, ensuring that the mac-address is known and keeping
    > >> everything working properly.  I would consider this a bug, with the bug
    > >> fix
    > >> as setting the ARP timeout to match the mac-address-table timeout
    > >> whenever
    > >> HSRP is enabled on a layer 3 VLAN.   Cisco does not officially consider
    > >> this
    > >> bug.   If you running HSRP and see lots of unknown unicast traffic on a
    > >> VLAN, you are seeing this issue.

    >
    > > Going somewhat OT, but..

    >
    > > This only happens for traffic that is assymetrically routed on outgoing
    > > and return path, typically if active HSRP instances are load-balanced
    > > across the switches, which is quite common.

    >
    > > However it is not at all a bug, simply how any switch functions with such
    > > designs, and well documented at (Case Study #8):
    > >http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note091...

    >
    > > The
    > > better solution is actually to increase CAM aging to match ARP timeout
    > > rather than reducing ARP timeout, as the latter incurrs more time needed
    > > processing ARP on network and endpoint CPUs.

    >
    > > -Phil

    >
    > The" well documented" part is why I consider this a bug.  It is a known
    > issue and should be addressed.  A warning printed when enabling HSRP on a
    > VLAN would also suffice as is done when you enable port-fast.
    >
    > ARP processing so low that it does make any noticable dent in CPU time even
    > when set to 5 minutes on a very busy switch.  Depending on who you talk to
    > at Cisco, some recommend reducing the ARP timeout, and others recommend
    > increasing the mac aging timer.  I personally am in the reducing the ARP
    > timeout camp.


    I used to design large LANs (10+ years ago) and this behaviour was
    not understood then. I was *horified* when I saw it documented. We
    had been building networks suceptible to this assymetric flow
    behaviour for years and no one had noticed:) :-((

    My preferred approach now would be to design the behaviour out
    completely by choosing the L2/L3 topology so it could not happen.

    One problem with the CAM ageing time method is that
    in the event of a STP Topology Change the aging time
    is set to a low value temporarily. Oh ... this applies to
    the arp one too.
     
    bod43, Feb 16, 2009
    #8
  9. Thrill5 Guest

    "bod43" <> wrote in message
    news:...
    On 16 Feb, 19:45, "Thrill5" <> wrote:
    > "Phil Harrison" <> wrote in message
    >
    > news:2009021619574816807-ph@bcsorg...
    >
    >
    >
    > > On 2009-02-16 07:15:56 +0100, "Thrill5" <> said:

    >
    > >> "bod43" <> wrote in message
    > >>news:...
    > >> On 15 Feb, 23:21, "John Agosta" <> wrote:
    > >>> "Thrill5" <> wrote in message

    >
    > >>>news:gn7a4n$9t7$...

    >
    > >>>> <> wrote in message
    > >>>>news:...
    > >>>>> Hi Folks,

    >
    > >>>>> I am trying to understand how arp table entries (just used ARP as an
    > >>>>> example case) are aged out from an implementation point of view. For
    > >>>>> e.g how the timers are implemented to do the job.

    >
    > >>>>> Appreciate your help.

    >
    > >>>>> Thanks,
    > >>>>> syuga

    >
    > >>>> In IOS, there is a an ARP aging process that removes expired entries.
    > >>>> I
    > >>>> don't know specifically how this is implemented, but generically, IOS
    > >>>> implements a scheduler, and processes are scheduled to run at
    > >>>> specific
    > >>>> intervals.

    >
    > >>> ARP (and other) timers are usually adjustable by the admin with an arp
    > >>> timeout or similar command. I think the default is 5 minutes.- Hide
    > >>> quoted
    > >>> text -

    >
    > >> -By the way -
    > >> -On a cisco router I think the default is 14,400 seconds
    > >> -(4 hours) - from memory:)
    > >> -
    > >> -In other words almost forever.

    >
    > >> Yes the default is 4 hours, but if you are running HSRP on a pair of
    > >> switches, you need to change the default ARP timeout to 300 seconds to
    > >> match
    > >> the mac-address-table timeout (which is 300 seconds or 5 minutes) on
    > >> each
    > >> VLAN you are running HSRP. If switch A is the HSRP router, but switch B
    > >> is
    > >> the router used for the return traffic, switch B can flood the traffic
    > >> out
    > >> the VLAN as an unknown unicast. This can happen because the
    > >> mac-address-table is only updated when traffic is RECEIVED. Since
    > >> switch
    > >> A
    > >> is the default router (because it is the active HSRP router), switch B
    > >> will
    > >> not see any traffic from the client, and the mac-address-table entry
    > >> will
    > >> age out. By setting the ARP timeout to same value as the
    > >> mac-address-table
    > >> timeout, you will force switch B to ARP the client every 300 seconds.
    > >> When
    > >> switch B receives the ARP reply, it will update the ARP entry AND the
    > >> mac-address-table, ensuring that the mac-address is known and keeping
    > >> everything working properly. I would consider this a bug, with the bug
    > >> fix
    > >> as setting the ARP timeout to match the mac-address-table timeout
    > >> whenever
    > >> HSRP is enabled on a layer 3 VLAN. Cisco does not officially consider
    > >> this
    > >> bug. If you running HSRP and see lots of unknown unicast traffic on a
    > >> VLAN, you are seeing this issue.

    >
    > > Going somewhat OT, but..

    >
    > > This only happens for traffic that is assymetrically routed on outgoing
    > > and return path, typically if active HSRP instances are load-balanced
    > > across the switches, which is quite common.

    >
    > > However it is not at all a bug, simply how any switch functions with
    > > such
    > > designs, and well documented at (Case Study #8):
    > >http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note091...

    >
    > > The
    > > better solution is actually to increase CAM aging to match ARP timeout
    > > rather than reducing ARP timeout, as the latter incurrs more time needed
    > > processing ARP on network and endpoint CPUs.

    >
    > > -Phil

    >
    > The" well documented" part is why I consider this a bug. It is a known
    > issue and should be addressed. A warning printed when enabling HSRP on a
    > VLAN would also suffice as is done when you enable port-fast.
    >
    > ARP processing so low that it does make any noticable dent in CPU time
    > even
    > when set to 5 minutes on a very busy switch. Depending on who you talk to
    > at Cisco, some recommend reducing the ARP timeout, and others recommend
    > increasing the mac aging timer. I personally am in the reducing the ARP
    > timeout camp.


    -I used to design large LANs (10+ years ago) and this behaviour was
    -not understood then. I was *horified* when I saw it documented. We
    -had been building networks suceptible to this assymetric flow
    -behaviour for years and no one had noticed:) :-((

    Ditto!!!

    -My preferred approach now would be to design the behaviour out
    -completely by choosing the L2/L3 topology so it could not happen.

    I've designed many large LAN's and data centers, and my standard solution is
    to set the arp timeout to 300 on each VLAN interface. I've been doing this
    for at least 5 years and have not seen any ill effects.

    -One problem with the CAM ageing time method is that
    -in the event of a STP Topology Change the aging time
    -is set to a low value temporarily. Oh ... this applies to
    -the arp one too.
     
    Thrill5, Feb 17, 2009
    #9
  10. Jens Haase Guest

    Thrill5 wrote:
    > I've designed many large LAN's and data centers, and my standard solution is
    > to set the arp timeout to 300 on each VLAN interface. I've been doing this
    > for at least 5 years and have not seen any ill effects.
    >


    I have seen massive problems with this setting on a pair of distribution
    routers (Cat 6500 SUP2 MSFC2). They had around 4k phones and 5k
    workstations connected and the MSFC was not able to keep up with
    processing all the arp replies. This resulted in incomplete arp entries
    and ultimativly in packet loss.

    I personally of the opinion that if you follow current best practices
    for network design you do not need to align the mac aging and arp timer.

    Jens
     
    Jens Haase, Feb 18, 2009
    #10
  11. bod43 Guest

    On 18 Feb, 08:56, Jens Haase <> wrote:
    > Thrill5 wrote:
    > > I've designed many large LAN's and data centers, and my standard solution is
    > > to set the arp timeout to 300 on each VLAN interface.  I've been doing this
    > > for at least 5 years and have not seen any ill effects.

    > I personally of the opinion that if you follow current best practices
    > for network design you do not need to align the mac aging and arp timer.


    Me too. Design the issue right out of your network.


    Surprising that 30 ARPs per sec was too much for msfc
    though. Of course msfc was a software router, so maybe it was busy
    with other things.
     
    bod43, Feb 18, 2009
    #11
  12. Jens Haase Guest

    bod43 wrote:
    >
    > Surprising that 30 ARPs per sec was too much for msfc
    > though. Of course msfc was a software router, so maybe it was busy
    > with other things.
    >

    To be precise it is 60 ARPs per sec because the Cisco implementation
    sends an unicast arp request to the end device after reaching 50% of the
    configured timer.

    But you are right there was other traffic that had an impact on the
    MSFC. The key point however was that the problems vanished after
    configuring the Cisco default ARP timer of 4 hours.

    Jens
     
    Jens Haase, Feb 18, 2009
    #12
  13. bod43 Guest

    On 18 Feb, 21:12, Jens Haase <> wrote:
    > bod43 wrote:
    >
    > > Surprising that 30 ARPs per sec was too much for msfc
    > > though. Of course msfc was a software router, so maybe it was busy
    > > with other things.

    >
    > To be precise it is 60 ARPs per sec because the Cisco implementation
    > sends an unicast arp request to the end device after reaching 50% of the
    >   configured timer.


    Ah, that's interesting, never noticed that - but never needed to;)

    Thanks.
     
    bod43, Feb 18, 2009
    #13
  14. Thrill5 Guest

    "Jens Haase" <> wrote in message
    news:...
    > bod43 wrote:
    >>
    >> Surprising that 30 ARPs per sec was too much for msfc
    >> though. Of course msfc was a software router, so maybe it was busy
    >> with other things.
    >>

    > To be precise it is 60 ARPs per sec because the Cisco implementation sends
    > an unicast arp request to the end device after reaching 50% of the
    > configured timer.
    >
    > But you are right there was other traffic that had an impact on the MSFC.
    > The key point however was that the problems vanished after configuring the
    > Cisco default ARP timer of 4 hours.
    >
    > Jens


    Where did you find out this information, as that would be a non standard
    implementation and extremely unusual. What happens if when after only 50%
    of timer has expired and there is no reply to the ARP? How often does it
    then keep retrying? Are you sure your not thinking of DHCP?
     
    Thrill5, Feb 19, 2009
    #14
  15. Thrill5 Guest

    "Aaron Leonard" <> wrote in message
    news:...
    >
    > ~ >> Surprising that 30 ARPs per sec was too much for msfc
    > ~ >> though. Of course msfc was a software router, so maybe it was busy
    > ~ >> with other things.
    > ~ >>
    > ~ > To be precise it is 60 ARPs per sec because the Cisco implementation
    > sends
    > ~ > an unicast arp request to the end device after reaching 50% of the
    > ~ > configured timer.
    > ~ >
    > ~ > But you are right there was other traffic that had an impact on the
    > MSFC.
    > ~ > The key point however was that the problems vanished after configuring
    > the
    > ~ > Cisco default ARP timer of 4 hours.
    > ~ >
    > ~ > Jens
    > ~
    > ~ Where did you find out this information, as that would be a non standard
    > ~ implementation and extremely unusual.
    >
    > Tis true, tho. Cuts down on the broadcast volume
    >
    > ~ What happens if when after only 50%
    > ~ of timer has expired and there is no reply to the ARP?
    >
    > The ARP entry remains valid nonetheless. Then when the entry times out,
    > it
    > is removed from the cache, and the IOS device will need to send out a new
    > broadcast ARP the next time it needs to send a unicast IP packet to this
    > destination.
    >
    > ~ How often does it then keep retrying?
    >
    > You can see how it works (with a 60-second ARP timeout) below.
    >
    > Cheers,
    >
    > Aaron
    >
    > ---
    >
    > tucson-3640(config-if)#arp timeout 60
    > tucson-3640(config-if)#end
    > tucson-3640#
    > Feb 19 13:28:29.803 -0700: %SYS-5-CONFIG_I: Configured from console by
    > console
    > tucson-3640#
    > tucson-3640#ping 10.95.42.134
    >
    > Type escape sequence to abort.
    > Sending 5, 100-byte ICMP Echos to 10.95.42.134, timeout is 2 seconds:
    >
    > Feb 19 13:28:57.751 -0700: IP ARP: creating incomplete entry for IP
    > address: 10.95.42.134 interface FastEthernet0/0
    > Feb 19 13:28:57.751 -0700: IP ARP: sent req src 10.95.42.135
    > 0001.9696.a240,
    > dst 10.95.42.134 0000.0000.0000 FastEthernet0/0
    > Feb 19 13:28:57.755 -0700: IP ARP: rcvd rep src 10.95.42.134
    > 0010.7b11.9a41, dst
    > 10.95.42.135 FastEthernet0/0.!!!!
    > Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
    > tucson-3640#show arp
    > Protocol Address Age (min) Hardware Addr Type Interface
    > Internet 10.95.42.135 - 0001.9696.a240 ARPA
    > FastEthernet0/0
    > Internet 10.95.42.134 0 0010.7b11.9a41 ARPA
    > FastEthernet0/0
    > Internet 10.95.42.129 0 0014.6a3e.a9d9 ARPA
    > FastEthernet0/0
    > tucson-3640#
    > Feb 19 13:29:42.063 -0700: IP ARP: sent req src 10.95.42.135
    > 0001.9696.a240,
    > dst 10.95.42.134 0010.7b11.9a41 FastEthernet0/0
    > tucson-3640#show arp
    > Protocol Address Age (min) Hardware Addr Type Interface
    > Internet 10.95.42.135 - 0001.9696.a240 ARPA
    > FastEthernet0/0
    > Internet 10.95.42.134 1 0010.7b11.9a41 ARPA
    > FastEthernet0/0
    > Internet 10.95.42.129 0 0014.6a3e.a9d9 ARPA
    > FastEthernet0/0
    > tucson-3640#
    > Feb 19 13:30:42.064 -0700: IP ARP: sent req src 10.95.42.135
    > 0001.9696.a240,
    > dst 10.95.42.134 0010.7b11.9a41 FastEthernet0/0
    > tucson-3640#show arp
    > Protocol Address Age (min) Hardware Addr Type Interface
    > Internet 10.95.42.135 - 0001.9696.a240 ARPA
    > FastEthernet0/0
    > Internet 10.95.42.129 0 0014.6a3e.a9d9 ARPA
    > FastEthernet0/0


    In this example with the ARP time out set to 60 seconds, it re-ARPed in 60
    seconds, not in the 30 seconds (or half the ARP timeout) as specified by the
    other poster. This is how I thought it worked until the other poster said
    that it re-ARP in half the ARP timeout, but your debug shows that it only
    re-ARPs after the ARP timeout has expired.
     
    Thrill5, Feb 20, 2009
    #15
  16. Sam Wilson Guest

    In article <gnih2l$38n$>,
    "Thrill5" <> wrote:

    > Where did you find out this information, as that would be a non standard
    > implementation and extremely unusual. ...


    The use of the term "standard" for any implementation of ARP seems to be
    pretty suspect. Even though RFCs 826 and 1122 are both Internet
    Standards, they're neither complete nor prescriptive about the right way
    to do ARP. In fact it's amazing that ARP works as well as it does. :)

    Sam
     
    Sam Wilson, Feb 20, 2009
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan

    Address Aging Issue

    Dan, Jan 21, 2004, in forum: Cisco
    Replies:
    4
    Views:
    1,144
    Christoph Gartmann
    Jan 22, 2004
  2. Martin Bilgrav

    C6000 MAC aging problem

    Martin Bilgrav, Dec 1, 2005, in forum: Cisco
    Replies:
    2
    Views:
    4,091
    Martin Bilgrav
    Dec 2, 2005
  3. Karl Engel

    XP on an aging PIII?

    Karl Engel, Aug 12, 2005, in forum: Computer Support
    Replies:
    10
    Views:
    840
    kenny
    Aug 14, 2005
  4. Dave L

    CMOS image aging

    Dave L, Apr 11, 2005, in forum: Digital Photography
    Replies:
    2
    Views:
    404
    Don Stauffer
    Apr 18, 2005
  5. BD

    Question: Artificially aging digital photos

    BD, Jul 11, 2005, in forum: Digital Photography
    Replies:
    8
    Views:
    386
    male1960
    Jul 15, 2005
Loading...

Share This Page