09-22-2010 08:41 AM - edited 03-04-2019 09:51 AM
Hi,
I have CiscoASR1006 device and the issue is ASR device is dropping all the ICMP destination unreachable messages,
I have accesslist and it is permited ip hosts any on both inside and outside.But still no luck.
Any suggestion would be appriciated.
09-22-2010 10:57 AM
Hi Alex,
Please share more details -
configuration, debugs (debug ip icmp), topology, etc.
Regards,
Rahul
09-23-2010 02:52 AM
HI Rahul,
Thanks for the reply.
I want the ICMP unreachable packets to be forwarded from outside (public internet) to my inside clients of ASR router.
I have double check my configuration and made sure that the ICMP unreachable messages is allowed and forwarded on the Accesslist and policy.
Let me know your id I can forward the show tech as it is bit confidential hence canot be uploaded on internet.
Thanks
Alex.
09-23-2010 12:06 PM
Hi Rahul,
Any suggestion?? Please help me this is very critical for me.
Thanks in advance.
Regards,
Alex.
09-23-2010 12:25 PM
Hi Alex,
You may forward the file to rakhande@cisco.com
Though it would be great if you could post the related part of configuration here.
Also, were you able to gather debugs and what messages were noticed when icmp was dropped?
Regards,
Rahul
09-23-2010 12:48 PM
All the related information I have sent to your email.
Please let me know your suggestion on the same.
Thanks
Alex,.
09-24-2010 08:57 AM
Hi Rahul,
Did you find anything missing in my config?
Thanks in advance.
regards
Alex.
09-27-2010 05:05 AM
Hi Rahul,
I am waiting for your update on this. I will be very thankfull if you could spare some time on this and update me.
Thanks
Alex.
09-27-2010 07:27 AM
Hi Alex,
Sorry for the delay, have been stuck on other issues.
On analyzing the details, it is clear that the issue is a bug. There are few related bugs (some fixed, some not) but for more analysis a follow up with the ASR BU would be required, more so since this is fairly new IOS. Would it be possible to open a TAC case and then the engineer can reach out to BU for more details.
Did you notice similar issue on XNE and XNF versions of code?
Also, could you try packets of different sizes - larger and smaller?
Apologies for not being too helpful, this would definitely need more time to analyze.
Regards,
Rahul
09-27-2010 07:58 AM
Hi Rahul,
Thanks for the update. I understand the TAC engineer wil be busy no issue I am in the same field hence understand the situation out there.
I can log a cisco tac case not an issue. I was thinking if you could provide me/refer me the bug number ?so that I can refer to my seniour and log a tac case saying that we need to involve escalation team.
Thanks
Alex.
09-27-2010 08:19 AM
CSCti45572 is an internal bug related to this. So it is not possible to share more details on this.
CSCsu90063 is external but was fixed in XNB02 version so its fix should be available in 15.0(1)S that you having. To confirm and analyze further we need BU follow up.
Regards,
Rahul
09-28-2010 01:04 AM
I have asked my collegue to log a case with cisco.
I will email you the TAC ref to your email address as it is not advisable to put the TAC case ref on internet which is refered globally.hope you understand :-).
Thanks
Alex.
09-28-2010 01:27 AM
Thanks Alex.
I have taken the case
10-21-2010 03:05 AM
Hello Alex,
We had worked on the TAC case with the BU and with the workaround, the issue was resolved.
A summary -
We were able to recreate the issue in the lab, just added "log drop-packets" under the parameter-map InsideOutsideParameter. Looks like all unreachables are getting blocked, we just tried a basic destination/host unreachable here by an extended ping.
UUT-4RU(config-cmap)#do sh plat hard qfp ac sta drop
-------------------------------------------------------------------------
Global Drop Stats Packets Octets
-------------------------------------------------------------------------
FirewallL4 70 5180
UUT-4RU(config-cmap)#
The feedback from the Firewall team regarding this was that in the currently released versions of firewall, all ICMP messages are dropped. (except for responses to pings or traceroute) In the latest released version, ICMP messages are now allowed to pass. Note: there must be a class in the policy to match the icmp packets in order to enable this functionality.
So, we tried a PASS action under the inspect for icmp traffic and then we could see the unreachable message passing through.
An example of this would be -
policy-map type inspect ccp-permit-icmpreply
no class type inspect ccp-icmp-access
class type inspect ICMP
pass
class type inspect ccp-icmp-access
inspect
To summarize, the behavior is an expected one on ASR in the IOS version.
The workaround is to use PASS action for the icmp traffic.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: