ICMP issue with ASR

Unanswered Question
Sep 22nd, 2010

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.

Thanks in advance.
REgards
Alex
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
rakhande Wed, 09/22/2010 - 10:57

Hi Alex,

Please share more details -

configuration, debugs (debug ip icmp), topology, etc.

Regards,

Rahul

alexc2010 Thu, 09/23/2010 - 02:52

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.

alexc2010 Thu, 09/23/2010 - 12:06

Hi Rahul,

Any suggestion?? Please help me this is very critical for me.

Thanks in advance.

Regards,

Alex.

alexc2010 Thu, 09/23/2010 - 12:48

All the related information I have sent to your email.

Please let me know your suggestion on the same.

Thanks

Alex,.

alexc2010 Fri, 09/24/2010 - 08:57

Hi Rahul,

Did you find anything missing in my config?

Thanks in advance.

regards

Alex.

alexc2010 Mon, 09/27/2010 - 05:05

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.

rakhande Mon, 09/27/2010 - 07:27

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

alexc2010 Mon, 09/27/2010 - 07:58

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.

rakhande Mon, 09/27/2010 - 08:19

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

alexc2010 Tue, 09/28/2010 - 01:04

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.

rakhande Thu, 10/21/2010 - 03:05

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.

Actions

This Discussion