Arp/mac address cache timeouts

Anybody know how long a mac address stays in a Cisco IOS arp cache when issuing "show ip arp"? How about a mac address in a CatOS switch when issuing "show cam dynamic". What constitutes the length of time an arp entry is cached?

Hello,
the default ARP timeout (show ip arp) is 14400 seconds, which equals 4 hours. The CAM default agingtime (show cam dynamic) is 300 seconds, which equals 5 minutes. That means that the ARP or CAM entry will stay in the cache for a minimum of 4 hours and 5 minutes, respectively...
Is that what you are asking ?
Regards,
GP

Similar Messages

WRE54Gv1 MAC Address Cache Timeout?

This question is geared towards someone from Linksys rather than the community.
Is there a MAC address timeout built into the WRE54Gv1 (firmware v1.06, Sep 30, 2005)? If so, what is it and is there a way to bypass it?
I'm using my WRE54Gv1 with a Squeezebox media player. The Squeezebox is "connected" 24/7 and allows me to stream music from my PC to my living room stereo via 802.11g.
I am having a problem that I have narrowed down to be some sort of a communication breakdown between the Squeezebox and the WRE54gv1. It works fine with a strong signal strength until the Squeezebox sits idle for a significant period of time. Then the Squeezebox seems to lose communication with the WRE54gv1 and attempts to talk directly to my router. The only way to sync the Squeezebox back to the WRE54gv1 is to powercycle the Squeezebox.
This really sounds like some sort of MAC cache problem but I have no visibility so I'm coming here for help.

I'm honestly not sure what you are saying. I know that the WRE54G is setup correctly as I get a very strong signal with two laptops and my Squeezebox when it is operating, and get almost no signal when it is not. To be honest, there are hardly any options to misconfigure.
Can you please elaborate on what - specifically - you believe may be setup incorrectly?
The Squeezebox has a very minimal network configuration as well. I give it an SSID, IP address, subnet mask and gateway and thats it. Its just like setting up a laptop.
I know for a fact that the Squeezebox is correctly talking through the WRE54G. What I do not know is why it stops talking to it and instead talks directly to the router instead. That is the problem that I am attempting to solve.

Force mapping to a specific MAC address a multicast IP address in ARP cache table with netsh

Hi all,
I would like to know if there is any solution (netsh option, registry entry, whatever...) to force mapping a given MAC address to a multicast IP address (224.x.y.z) in my ARP cache table.
I am doing the following:
netsh.exe interface ip add neighbors "Ethernet" "224.224.xxx.yyy"
"00-80-EE-UU-VV-WW"
But the entry in the ARP table is substitued by the calculated multicast MAC@ corresponding to my multicast IP@ :
netsh.exe interface ip show neighbors "Ethernet"
Interface 12 : Ethernet
Internet Address
Physical Address Type
224.0.0.22
01-00-5e-XX-YY-ZZ
static
224.224.yyy.zzz
01-00-5e-UU-VV-WW
static
(For information, calculation of the Multicast MAC Address is described in RFC1112§6.4 -> The MAC@ equals 01-00-5e + the last 23 digits of the multicast MAC Address)
My problem is that I'm not using an Ethernet network but an AFDX (used on Airbus A380, Boeing 787 Dreamliner, by the NASA...). This network topology is a deterministic Ethernet. The network must know accurately where each network packet is going. Thus...
the multicast MAC@ cannot be accepted and packet destinated to that MAC@ are not going anywhere.
So, I must match accurately my multicast IP@ to my MAC@ (00-80...).
It used to work with Windows XP (which was not doing any "magical" MAC@ substitution on multicast IP@), but since Windows Vista, netsh is doing the substitution described above. Is there any way to disable this substitution or force my IP
to MAC mapping in ARP table? And of course, I'm not using XP anymore ;)... but a tablet with Windows 8.1.
Thanks for any help.
Cheers,
Olivier.

Hi,
The article you pointed me to is just an explanation of what I said in my original post : "Multicast MAC Address is described in RFC1112§6.4".
But, as I said in my original post, this is true ONLY for Ethernet network. And I am NOT on an Ethernet network.
So MAC address automatic calculation for my IP address done by Windows/netsh/arp is wrong in my case. The calculation Windows is doing is correct ONLY for Ethernet network. Since I am not on Ethernet, I don't want these calculations, and I'm looking for
a solution to disable them.
So, the underlying question is : "Is Microsoft/netsh/arp able to handle other network's type than Ethernet ?"
Thanks,
Olivier Dupré.

ARP cache not adding MAC address

Hi,
We have a network in the company where visitors\customers can connect their PCs to pick up a IP address & access the internet via our cluster of Checkpoint firewalls. The problem we are having is that whenever somebody with a Mac tries to use this network they cannot access the internet although it works fine for all Windows based PCs. So to investigate I got hold of a IBook & made the following observations.
The gateway provided by the DHCP servers is a IP address (192.168.48.203) on a multicast mac address that represents both of the firewalls, which in turn have a physical address of 192.168.48.201 & 192.168.48.202 respectively. This is done to provide redundancy.
What happens on the IBook is that it picks up a DHCP address as well as the DNS & gateway address as supplied by the DHCP server, but then when you try to access the internet you have no joy. If you check the arp table you will then notice that the table have not been updated with the mac address of the 192.168.48.203 gateway. If you then manualy add the mac address of 192.168.48.203, using arp -s, it works fine or if you staticaly configure the IP address settings to use either 192.168.48.201 or 202 as gateways (which have unicast mac addresses) it also solves the problem & immediately updates the arp cache with the mac addresses of either of these two interfaces depending on which one you are using.
We put a sniffer on the network & could see that the mac address for 192.168.48.203 is being passed on to the IBook but for some reason it just does not update the arp cache with this details. Also tried this on some of the other networks we are running that uses the same concept & the same thing happens. As I mentioned no Windows hosts are having this problem & immediately updates their arp details to include the mac address of the .203 address.
On a Mac after obataining a DHCP address & running "netstat -r" you get the following:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.48.203 UGSc 5 5 en1
127 localhost UCS 0 0 lo0
localhost localhost UH 9 2477 lo0
169.254 link#5 UCS 0 0 en1
192.168.48/22 link#5 UCS 1 0 en1
192.168.48.203 link#5 UHRLW 4 30 en1
192.168.51.1 localhost UHS 0 1 lo0
Then after adding the mac address manualy it looks as follows & works fine:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.48.203 UGSc 26 6 en1
127 localhost UCS 0 0 lo0
localhost localhost UH 9 12353 lo0
169.254 link#5 UCS 0 0 en1
192.168.48/22 link#5 UCS 0 0 en1
192.168.48.203 1:0:5e:7c:0:48 UHLS 26 28 en1
192.168.51.1 localhost UHS
Any ideas why this is happening ?
Regards
IBook G4 Mac OS X (10.4.3)

Hi,
I am facing exactly the same problem here with an iMac G5. I have called the apple support and the conclusion was that they have no clue for that and we should wait for an update that will hopefully resolve this.
I was also aksing them if there was a way in the mac to set a static mac address for the gateway in the macintosh so I don't have to run the terminal and type the arp -s every time I start up. They said it is out of the kind of support they can provide... Do you have an idea on how to add a static ARP entry in the table ?
Thank you.

IP-4-ZERO_ADDR: Zero MAC address for ip in ARP cache

Could someone hlep me with this log message: IP-4-ZERO_ADDR: Zero MAC address for <ip> in ARP cache
It just started appearing in our Cisco 10012 CMTS, and all of the documentation is very vague as to what it is and how to fix it. I'm hoping someone else has seen the message and can help clarify it's meaning. Thanks in advance!

Your not the only one with these logs mess :
Jan 20 13:05:10: %IP-4-ZERO_ADDR: Zero MAC address for 10.100.xxx.69 in ARP cache
Jan 20 13:30:02: %IP-4-ZERO_ADDR: Zero MAC address for 10.100.xxx.69 in ARP cache
I thing the reason is that someone has a worm or something ping-flooding/scanning the network, check your arp table for incompletes.
What to do about it, disable icmp on the network maybe, for now we dont have a problem on the network but would be nice to fix this thing.
Martin
DK

Csm arp cache timeout issues

Hello all.
The arp cache timeout of the csm is normally 4 hours.
Now if we want to replace one of our servers we would need to wait 4 hours before the new servers mac address is learned if we keep the old ip-address.
I know we can manually flush one entry from the arp cache but is there a way for the csm to find out sooner if the mac address has changed?
I also know we can make the time shorter before the cache expires but what would be the consequences if we would put the timer to lets say 1000 seconds?
Would we then be flooding our network with arp requests all the time?
Finally I would expect that if an icmp request would fail because of the change of mac addres the csm would make an arp request to find out who has the ip I am trying to ping.
What is the procedure if the icmp request would fail?
Thank you.
Daniel Levi

I would not suggest using the manual method, since it is time consuming and also there is a good chance that the new ARP request may load the CSM. I would suggest that you wait for the arp cache timeout.

Arp aging time on router and mac address aging time on switches set close t

Hi,
appreciate some advice on the following:
what is the benefit of setting arp aging time on router and mac address aging time on switches close to each other?
Thanks,
Christina

Hi,
based on the below output, do you think implementing it will benefit? Thanks.
C2950#sh int fa0/43
FastEthernet0/43 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000d.5e11.4e2b (bia 000d.5e11.4e2b)
MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 7/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 933000 bits/sec, 149 packets/sec
5 minute output rate 2981000 bits/sec, 263 packets/sec
2819781393 packets input, 3782332886 bytes, 0 no buffer
Received 266693 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
4015025747 packets output, 2328228393 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
C2950#

ARP detstination mac-address 0000.0000.0000

Internet Router--->3550 Switch-->Nortel Contivity
63.169.164.134-->63.169.164.140--> 63.169.140.136
All the devices are having public IP addresses and are in Vlan 100.
Sometimes the Internet Router is not able to ping or connect to the Contivity where as the switch is able to access both the devices (Internet Rtr & Contivity).
While checking on the switch & Internet rtr i capture the following logs.
Switch#sh log
Mar 25 11:17:17.990 EDT: IP ARP: creating incomplete entry for IP address: 63.169.164.136 interface Vlan100
Mar 25 11:17:17.990 EDT: IP ARP: sent req src 63.169.164.140 0012.800b.a780,dst 63.169.164.136 0000.0000.0000 Vlan100
Internet RTR#sh log
Mar 25 11:17:17 EDT: IP ARP: rcvd req src 63.169.164.140 0012.800b.a780, dst 63.169.164.136 GigabitEthernet0/1
Mar 25 11:20:54 EDT: IP ARP: rcvd req src 63.169.164.138 0018.b964.66fc, dst 63.169.164.145 GigabitEthernet0/1
We have done a static ARPA entry in internet rtr for Contivity but still the issue remains same. The moment the issue persists again i tried to clear the arp on switch but it didn't make router to get reply from Contivity when i did the same clear arp-cache on internet rtr, it started getting communicate with Contivity.
I am not able to find the solution of this issue and the reason for that, now every time i have to do clear ip arp-cache on rtr whenever the issue comes down.
Also i want to understand the situation when a dest mac-address can be 0000.0000.0000.
Any help on this will be appreciated.
Thanks.

Bhupesh
If a router receives a packet to forward to a destination address which is on a local LAN but the destination IP address does not appear in the arp table then the router creates an incomplete entry in the ARP table (it is incomplete because the router does not have the destination MAC address and is attempting to learn it). The router creates the incomplete entry in the ARP table and sends an ARP request. If the router receives an ARP response then it puts the destination MAC address into the ARP table and the entry is now complete. If no ARP response is received the router will purge the incomplete entry. Note that the router can not forward the IP packet that caused the incomplete entry and the router will drop that IP packet.
In considering the problem with contivity I had been assuming that the problem was on rtr. But it occurs to me that it is quite possible (and even likely given the fact that you mention which is that in the problem the switch can still ping contivity ) that the problem is on contivity. I wonder if for some reason contivity gets an incorrect MAC for rtr? I suspect that clear arp on rtr fixes the problem because as it clears the arp table I believe that rtr will send a gratuitous arp which refreshes the ARP entry in contivity. In the time of the problem can you check the table in contivity?
HTH
Rick

ARP table not populating mac address for previously reachable IP address

Router has been online and working fine with one BGP neighbor for almost 2 years and no downtime. 2 weeks ago, added a 2nd BGP peer. Everything worked fine for 2 weeks, then all of a sudden yesterday the 2nd BGP peer is disconnected and does not come back. ISP checks and sees everything looks fine on their end. We cannot even ping each other now.
Upon investigation, the ARP table is not even populating the MAC address for the BGP peer IP anymore (same local subnet). Stays "incomplete" in the table no matter what we do, including clearing arp table, changing IP address, etc.
Plug a laptop directly into the 2nd BGP peer FE port and replicate the IP addressing. Laptop cannot ping Router, but Router CAN ping laptop. Check ARP table, but STILL no mac address assigned and now not even the ARP table showing "incomplete".
Thinking it could be the FE interface, switch to the 2nd FE interface and perform same laptop test, this time with arbitrary IP addressing. Now cannot ping each other, no MAC in ARP table.
End up rebooting the router and lo-and-behold, everything is working normally again. 2nd BGP peer peers up instantly.
I should also mention that the 1st BGP peer worked flawlessly throughout, taking all the Internet load and having no issues throughout.
Also, the FE ports for the 2nd BGP peer are on an HWIC FE card plugged into the router. The 1st BGP peer is plugged into the built-in GE interface. 2901 running: c2900-universalk9-mz.SPA.151-4.M4.bin
Lastly, no router resource issues, no error messages, no logs. Just the BGP peer disconnecting.
I have never, in 20 years working with Cisco routers seen something like this before. This is the most fundamental aspect of IP and Ethernet that was not working.
Has anyone ever seen this behavior before??
Here is the router config (IP's changed):
version 15.1
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service internal
service sequence-numbers
boot-start-marker
boot-end-marker
logging buffered 150000
aaa new-model
aaa authentication login LAUTHEN local
aaa authentication login TAUTHEN local group tacacs+ enable
aaa authorization console
aaa authorization exec LAUTHOR local if-authenticated
aaa authorization exec TAUTHOR local group tacacs+ if-authenticated
aaa session-id common
clock timezone PST -8 0
clock summer-time PDT recurring
no ipv6 cef
no ip source-route
ip cef
no ip domain lookup
multilink bundle-name authenticated
username ubiadmin privilege 15 secret 4 .JbeuWXuZvchrG0OL.5BftFtqrrEyxcnVHn5rIuCnTk
username umitsnoc01 privilege 15 secret 4 cUmoRUjey9O1x.wk9S.kleX.iAAhCwihupr6Z98p6OA
redundancy
ip ssh version 2
track 1 interface GigabitEthernet0/0 line-protocol
class-map match-any AutoQoS-VoIP-RTP-Trust
match access-group name SIP-Media-INBOUND
class-map match-any AutoQoS-VoIP-Control-Trust
match ip dscp cs3
match ip dscp af31
class-map match-any Customer-Voice
match access-group name Customer-VPNs
class-map match-any media
match access-group name SIP-Media
class-map match-any signaling
match access-group name SIP-Signaling
policy-map AutoQoS-Policy-Trust
class AutoQoS-VoIP-RTP-Trust
priority percent 70
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
policy-map queue
class signaling
bandwidth percent 5
class media
priority percent 50
class Customer-Voice
priority percent 40
class class-default
fair-queue
policy-map shape
class class-default
shape average 10000000
service-policy queue
interface Embedded-Service-Engine0/0
no ip address
shutdown
interface GigabitEthernet0/0
description BGP Peer 1
ip address 2.2.2.2 255.255.255.252
no ip redirects
ip flow ingress
ip flow egress
duplex auto
speed auto
service-policy output shape
interface GigabitEthernet0/1
description LAN
ip address 1.2.3.4 255.255.255.0
no ip redirects
ip flow ingress
ip flow egress
standby 255 ip 1.2.3.1
standby 255 priority 105
standby 255 preempt
standby 255 mac-address 1a2b.3c4d.5e6f
standby 255 track 1 decrement 10
duplex auto
speed auto
service-policy output AutoQoS-Policy-Trust
interface FastEthernet0/0/0
description BGP Peer 2
ip address 1.1.1.1 255.255.255.252
ip flow ingress
ip flow egress
duplex full
speed 100
service-policy output shape
interface FastEthernet0/0/1
no ip address
shutdown
duplex auto
speed auto
router bgp 7777
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 1.2.3.0 mask 255.255.255.0
neighbor 1.1.1.2 remote-as 5555
neighbor 1.1.1.2 update-source FastEthernet0/0/0
neighbor 1.1.1.2 prefix-list L3-DEFGW in
neighbor 1.1.1.2 route-map L3-LPREF-IN in
neighbor 2.2.2.1 remote-as 6666
neighbor 2.2.2.1 ebgp-multihop 2
neighbor 2.2.2.1 update-source GigabitEthernet0/0
neighbor 2.2.2.1 send-community
neighbor 2.2.2.1 prefix-list COLO-DEFGW in
neighbor 2.2.2.1 route-map COLO-LPREF-IN in
neighbor 2.2.2.1 route-map COLO-OUT out
ip forward-protocol nd
ip bgp-community new-format
ip as-path access-list 5 permit _5555_
ip as-path access-list 5 deny .*
ip as-path access-list 10 permit ^6666$
no ip http server
no ip http secure-server
ip flow-top-talkers
top 50
sort-by bytes
ip route 0.0.0.0 0.0.0.0 1.1.1.2 254 name L3
ip route 0.0.0.0 0.0.0.0 2.2.2.1 255 name COLO1
ip route 10.0.0.0 255.0.0.0 10.10.10.10 name FW_OUTSIDE
ip tacacs source-interface GigabitEthernet0/1
ip access-list standard SNMP_SOURCES
permit 12.12.12.0 0.0.0.255
deny any log
ip prefix-list L3-DEFGW seq 5 permit 0.0.0.0/0
ip prefix-list COLO-DEFGW seq 5 permit 0.0.0.0/0
ip prefix-list COLO-LPREF-OUT seq 5 permit 1.2.3.0/24
route-map COLO-LPREF-IN permit 5
match as-path 5
set local-preference 250
route-map COLO-LPREF-IN permit 10
set local-preference 150
route-map COLO-LPREF-IN permit 20
route-map COLO-OUT permit 10
match ip address prefix-list COLO-LPREF-OUT
set as-path prepend 7777 7777 7777
set community 29795:1004
route-map COLO-OUT permit 20
route-map L3-LPREF-IN permit 10
match as-path 10
set local-preference 200
route-map L3-LPREF-IN permit 20
set local-preference 150
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps vrrp
snmp-server enable traps flowmon
snmp-server enable traps transceiver all
snmp-server enable traps ds1
snmp-server enable traps call-home message-send-fail server-fail
snmp-server enable traps tty
snmp-server enable traps license
snmp-server enable traps envmon
snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop config
snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-up
snmp-server enable traps flash insertion removal
snmp-server enable traps mac-notification
snmp-server enable traps aaa_server
snmp-server enable traps cef resource-failure peer-state-change peer-fib-state-change inconsistency
snmp-server enable traps memory bufferpeak
snmp-server enable traps config-copy
snmp-server enable traps config
snmp-server enable traps config-ctid
snmp-server enable traps event-manager
snmp-server enable traps hsrp
snmp-server enable traps cpu threshold
snmp-server enable traps rsvp
snmp-server enable traps syslog
snmp-server enable traps vtp
snmp-server enable traps ipsla

When you were checking the ARP table was there an entry for Fast0/0/0?
HTH
Rick

Sh arp does not show mac address of IP --- ASA

Hi Everyone,
I can ping the IP from the ASA but when i do sh arp it does not show me mac address od that IP.
Need to know the reason behind this.
Regards
MAhesh

So your ASA should have a route on the inside interface to internal networks. The address of that next hop in the routing table is the one you should have in your arp table allowing you to reach non-directly-connected (subnet-wise) hosts within the scope of that route statement.
Think through the logic - ASA pings a host. It needs to determine proper egress interface. It checks and asks "Is it reachable via a directly connected interface (most preferred route)?" Answer no. "Do I have a route statement telling me how to get to it?" Answer yes (otherwise use default). OK - so ASA sends packet out egress interface defined in that route statement to the next hop as defined in route statement and waits for reply.

ACE How can we do a static arp to multicast mac address?

I have a architecture that uses ACE to do Firewall Load Balancing. I need to add a static map of a VIP IP to a multicast mac address (Microsoft servers with NLB in multicast mode). The ACE does not accept multicast mac address in the static arp statement, anybody knows why? Is there any other way to do that?
Regards,
Artur Pinto

Hi,
The ACE doesn't support multicast MAC addresses. This is a limitation impose by the hardware used on the boards. Syed has previously proposed a workaround at https://supportforums.cisco.com/message/464174#464174 . I don't know if that will be applicable in your case.
HTH
Cathy

Help required - mac address table, virtual pc/ip addressing issue

Hi, hope someone out there can help?
This is the scenario
SW1 (WS-C2960G-48TC-L) port gig0/1 has a PC connected to it with ip address 10.182.8.6 and a Virtual IP address 10.182.8.107
SW2 (WS-C2960-24TT-L) port gig 0/1 has a PC connected to it with ip address 10.182.8.106
The system is designed so that if there is an issue with the PC connected to SW1, the PC on SW2 will take over the Virtual IP address and continue working.
We have a couple of other PC's in different subnets to the above PC's that use the Virtual IP (VIP) address to communicate with the PC that is 'on line'.
Unfortunately, the vendors software doesn't currently gratuitously refresh the arp to advertise the change of mac address for the VIP.
Is there anyway we can get the 2 dcnsw to 'refresh' on a regular time period to capture when the VIP changes to the other PC?

Hi Stephen
Without meaning to sound rude, the software which uses a VIP is not very well designed if it is not capable of sending a Gratuitous ARP one the Active one fails.
The default ARP cache timeout is 4 hours so an ARP entry will remain in the table and once the timeout is up, the switch will send an ARP to check if the device is still alive and if not, remove the entry from the table.
You could look at reducing the ARP timeout on a per port basis:
#interface gi1/0/1
#arp timeout 60
This will change the ARP cache timeout to 60 seconds for that port but having not used this before, I am not 100% this will address your issue. I would not advise trying to change the global ARP cache timeout for a production switch as this will increase ARP traffic and could cause problems if reduced to a small value.

CSCsy35054 - NP1/2 UDP conns not updated when MAC address changes

We have a customer that appears to be experiencing this bug but with FWSM 4.1(15).
There is a Linux HA solution on one side of the FWSM and when a failover occurs the Linux HA sends a Gratuitous ARP which updates the FWSM ARP cache however not all connections are updated. If we sniff traffic exiting the FWSM we can see the destination MAC address for 'some' existing connections have the wrong MAC address (the old MAC address). The clients are constantly sending traffic (SIP) to the Linux server so the connection states are continually refreshed. If we manually clear the connections or let them time out by disconnecting one of the SIP clients for 30-minutes (the default SIP control channel session timeout) it recovers, however this isn't practical.
We have recommended introducing a layer-3 hop between the FWSM and the Linux HA devices as we suspect this will solve the problem (i.e. the destination MAC will be the L3 next-hop and not the Linux server itself). In looking at the issue we identified the behaviour as the same as that documented under BugID: CSCsy35054, however this says it appeared in 3.2(6) and was fixed in 3.2(12.1) & 4.0(5.4) however we are running 4.1(15) which is the latest release.
Any other ideas?
Andy

Well your configuration looks great to me... nothing is obviously standing out at least..
If the routers ping request makes it to your client, then the router must at least be able to arp for you.
Have you tried to ping the gateway from the WLC itself? (vlan 171 it appears)
I'm curious if the WLC even gets the ping through. 'show arp switch' on the WLC would show its arp table as well...
I'm not very proficient with the router debugging, but perhaps there is some kind of ARP debug you can run to verify if the ARP request is even coming out of the WLC from your client?
Again, the config looks go to me, so either this is a situation where a nice save config and reboot would come in handy (perhaps coupled with shutting down the interfaces and turning them back on)..... or something just isn't right....
Does this happen with the other vlans you have coming in to the WLC? Perhaps there is just something going on the router side where it isn't responding to the arp.... which comes back to the whole shutting down interfaces and/or rebooting. Obviously this isn't root-cause, but should at least provide sanity-check.

Switch learning mac addresses

In a video that I watched a few days ago someone explained a basic process of booting up a switch and how a switch learns mac addresses. He said something that I would like to discuss. I know... it is not important but want to clarify :)
PC1---SW1----PC2
PC1 wants to send sth to PC2. In the video it was said:
'a frame arrives at SW1 and SW1 learns the mac address of pc1 but it does not know the mac address of pc2 so it will flood this frame to all ports'
My uderstanding is that it all starts with an arp message: pc1 does not know the mac address and sends an arp and it will allow the switch to learn both mac addresses: pc1 and pc2. I am too lazy to do it in wireshark but did that in PT and that's what I saw as well. After the arp - switch learnt both macs and did not flood the frame.
Am I correct? I know it is not important but... ;-)

It may be possible that there was some aspect of the switch environment in the video that would change the behavior (perhaps something like a long timer for the ARP cache in the PC and a short MAC ageing timer on the switch). But in general you are correct. PC1 would send an ARP request as a broadcast, the switch would learn the MAC of PC1 and forward the ARP request. When PC2 sends its response to the ARP request the switch would learn the MAC of PC2 and forward the ARP response. So the switch should have both MAC addresses when data traffic begins to flow.
HTH
Rick

Sh mac-address command in Cisco RSP4

Hello guys,
Need your ideas on how to know to which port a device connected to using mac-address information on Cisco DLSw RSP4.
I did tried using command "sh mac-address add" but it is not recognized in this IOS.
See below outputs:
RSP-Core#sh ver
Cisco Internetwork Operating System Software
IOS (tm) RSP Software (RSP-DSV-M), Version 12.1(13), RELEASE SOFTWARE (fc3)
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Wed 30-Jan-02 13:58 by kellythw
Image text-base: 0x60010958, data-base: 0x61186000
cisco RSP4 (R5000) processor with 131072K/2072K bytes of memory. >>>>>>>>>
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
RSP-Core>sh ip arp tok 1/1/0
Protocol Address Age (min) Hardware Addr Type Interface
Internet 146.X.3.76 5 0060.9435.63e2 SNAP TokenRing1/1/0
Internet 146.X.3.77 5 4000.2030.2410 SNAP TokenRing1/1/0
RSP-Core#sh mac-address add ?
% Unrecognized command
RSP-Core#sh mac-

Interesting hardware you have there.
Is this perhaps a cat 5xxx with an RSM module?
In that case, the RSM is in fact a router blade.
The command "sh mac-adress " is only found on switches. This info is there already but you need to get it from the supervisor which will be running CatOS.
http://www.cisco.com/en/US/docs/switches/lan/catalyst5000/catos/4.5/configuration/guide/5000_cfg.html
regards,
Leo

Arp/mac address cache timeouts

Similar Messages

Maybe you are looking for