10-04-2007 03:08 AM - edited 03-05-2019 06:52 PM
Hello,
I added a static IP/MAC entry on a 6500 MSFC2 daughter card (IOS) but now no longer need it, and wont to remove it. However it wont let me remove it from the config... I can't reload this switch as its a core switch and would have service impact.
6500 code: c6msfc2-dsv-mz.121-26.E6.bin
PORR6501#sh run | in 10.1.163
arp 10.1.163.39 0014.c25e.0c82 ARPA
PORR6501(config)#no arp 10.1.163.39 0014.c25e.0c82 ARPA
PORR6501(config)#
PORR6501#sh run | in 10.1.163
arp 10.1.163.39 0014.c25e.0c82 ARPA
Any ideas how to remove this? As a side point, I have another 6500 running the same code, and this removed the ARPA entry without any problems.
rgds
Phil
Solved! Go to Solution.
10-04-2007 06:27 AM
Phil,
Looks like you are running into bug id CSCsa98860.
If a static ARP entry is added to a configuration using the arp ip-address mac-address arpa command, then the entry cannot be deleted from the configuration when you use the no arp ip-address mac-address arpa command. This problem occurs when the address of the static entry that belongs to a subnet is configured on a routed interface as secondary. This problem is resolved in Release 12.1(27b)E. (CSCsa98860)
So, the fix is a code upgrade. As a workaround you can try this. Create a routed interface , configure a bogus primary IP Address. Then set a secondary IP Address with the same subnet as the arp entry. After that, try deleting the arp entries.
Example workaround:
switch(config)#in lo100
switch(config-if)#ip add 99.99.99.99 255.255.255.255
switch(config-if)#ip add 10.1.163.39 255.255.255.0 secondary
switch(config-if)#exit
switch(config)#no arp 10.1.163.39 0014.c25e.0c82 ARPA
I hope it helps.
Regards,
Arul
** Please rate all helpful posts **
10-04-2007 06:27 AM
Phil,
Looks like you are running into bug id CSCsa98860.
If a static ARP entry is added to a configuration using the arp ip-address mac-address arpa command, then the entry cannot be deleted from the configuration when you use the no arp ip-address mac-address arpa command. This problem occurs when the address of the static entry that belongs to a subnet is configured on a routed interface as secondary. This problem is resolved in Release 12.1(27b)E. (CSCsa98860)
So, the fix is a code upgrade. As a workaround you can try this. Create a routed interface , configure a bogus primary IP Address. Then set a secondary IP Address with the same subnet as the arp entry. After that, try deleting the arp entries.
Example workaround:
switch(config)#in lo100
switch(config-if)#ip add 99.99.99.99 255.255.255.255
switch(config-if)#ip add 10.1.163.39 255.255.255.0 secondary
switch(config-if)#exit
switch(config)#no arp 10.1.163.39 0014.c25e.0c82 ARPA
I hope it helps.
Regards,
Arul
** Please rate all helpful posts **
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide