|
Cisco 1801 tunnel interface "outside" ping fails
![[gb]](/s/countries/gb.gif) Shadow Hawkins on Monday, 01 September 2014 19:06:00
Hi guys,
I have a Cisco 1801 setup with a tunnel (T153713 - gblon02) where my tunnel1 interface has IPv6 2a01:348:6:799::2
My clients are configured on Vlan9 using prefix 2a01:348:6:8799::/64 and neighbour discovery enabled, with DHCPv6 issuing out DNS settings to the devices.
Dynamically assigned hosts can access the IPv6 internet perfectly fine.
I have a statically configured host 2a01:348:6:8799::250 and from there I can access another IPv6 native host on the internet inboudn and outbound.
I can ping in and out of the client prefix successfully.
Unfortunately, I (and the tunnel broker) cannot ping6 the 2a01:348:6:799::2 interface of the router.
Inside to router vl9:
$ ping6 2a01:348:6:8799::1
PING 2a01:348:6:8799::1(2a01:348:6:8799::1) 56 data bytes
64 bytes from 2a01:348:6:8799::1: icmp_seq=1 ttl=64 time=1.02 ms
64 bytes from 2a01:348:6:8799::1: icmp_seq=2 ttl=64 time=0.852 ms
Inside to router tunnel1:
$ ping6 2a01:348:6:799::2
PING 2a01:348:6:799::2(2a01:348:6:799::2) 56 data bytes
64 bytes from 2a01:348:6:799::2: icmp_seq=1 ttl=64 time=0.971 ms
64 bytes from 2a01:348:6:799::2: icmp_seq=2 ttl=64 time=0.906 ms
outside to vl9 host:
$ ping6 2a01:348:6:8799::250
PING 2a01:348:6:8799::250(2a01:348:6:8799::250) 56 data bytes
64 bytes from 2a01:348:6:8799::250: icmp_seq=1 ttl=53 time=18.7 ms
64 bytes from 2a01:348:6:8799::250: icmp_seq=2 ttl=53 time=15.0 ms
outside to router tunnel1:
$ ping6 2a01:348:6:799::2
PING 2a01:348:6:799::2(2a01:348:6:799::2) 56 data bytes
^C
--- 2a01:348:6:799::2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
Tunnel1 config:
#sh run int tun1
Building configuration...
Current configuration : 311 bytes
!
interface Tunnel1
description SixXS Tunnel
no ip address
ipv6 address 2A01:348:6:799::2/64
ipv6 enable
ipv6 traffic-filter ipv6-internet-in in
ipv6 mtu 1280
ipv6 inspect v6-CBAC-IN-OUT out
ipv6 virtual-reassembly
tunnel source FastEthernet0
tunnel destination 77.75.104.126
tunnel mode ipv6ip
end
tunnel1 traffic filter:
#sh ipv6 access-list ipv6-internet-in
IPv6 access list ipv6-internet-in
permit icmp any any log (98 matches) sequence 1
permit icmp any any time-exceeded sequence 10
permit icmp any any packet-too-big sequence 20
permit icmp any any echo-request (1775 matches) sequence 30
permit icmp any any echo-reply (5 matches) sequence 40
permit tcp host 2A00:1C10:3:634:0:2:7401:249 host 2A01:348:6:8799::250 eq 22 (55 matches) sequence 50
ipv6 CBAC config:
#sh run | i v6-CBAC-IN-OUT
ipv6 inspect name v6-CBAC-IN-OUT tcp
ipv6 inspect name v6-CBAC-IN-OUT ftp
ipv6 inspect name v6-CBAC-IN-OUT udp
ipv6 inspect name v6-CBAC-IN-OUT icmp
ipv6 routing table:
1#sh ipv6 route
IPv6 Routing Table - Default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via Tunnel1, directly connected
C 2A01:348:6:799::/64 [0/0]
via Tunnel1, directly connected
L 2A01:348:6:799::2/128 [0/0]
via Tunnel1, receive
C 2A01:348:6:8799::/64 [0/0]
via Vlan9, directly connected
L 2A01:348:6:8799::1/128 [0/0]
via Vlan9, receive
L FF00::/8 [0/0]
via Null0, receive
debug ipv6 icmp output
vl9 host to tunnel1
*Sep 1 19:00:44.164: ICMPv6: Received echo request, Src=2A01:348:6:8799::250, Dst=2A01:348:6:799::2
*Sep 1 19:00:44.164: ICMPv6: Sent echo reply, Src=2A01:348:6:799::2, Dst=2A01:348:6:8799::250
outside to tunnel1
*Sep 1 19:02:10.084: ICMPv6: Received echo request, Src=2A00:1C10:3:634:0:2:7401:249, Dst=2A01:348:6:799::2
*Sep 1 19:02:10.084: ICMPv6: Sent echo reply, Src=2A01:348:6:799::2, Dst=2A00:1C10:3:634:0:2:7401:249
I cant for the life of me see why the tunnel interface wont respond to ping from the outside?? It appears to be responding properly. Proto 41 looks ok too:
90 permit 41 any any log (1053988 matches)
Any other debugging info that would be useful to you guys? Sounds a lot like a problem reported by another user on gblon3?
At the moment my tunnel is working, but it will be disabled shortly due to the ping responses failing.
Thanks,
jd
Cisco 1801 tunnel interface "outside" ping fails
I have a Cisco 1801 setup
What is the IOS version that is running on it?
There are various editions out there that have had broken IP inspection.
permit icmp any any echo-request (1775 matches) sequence 30 permit icmp any any echo-reply (5 matches) sequence 40
1775 incoming ICMP Echo Requests and only 5 Echo Replies. Looks like something is off there...
Though that might be because you have " ipv6 traffic-filter ipv6-internet-in in" which only does inbound queries. Is outbound filtered maybe or does it do state tracking?
ipv6 inspect v6-CBAC-IN-OUT out
What are the contents and default policies of those rules?
*Sep 1 19:02:10.084: ICMPv6: Sent echo reply, Src=2A01:348:6:799::2, Dst=2A00:1C10:3:634:0:2:7401:249
So, that ping is successful I assume? That is that your remote host receives it too?
Sounds a lot like a problem reported by another user on gblon3?
Which problem? I am not aware of any problems with gblon03 or any other PoP. Note that they all run the exact same code, thus if one PoP is affected, all of them would be and a lot of users would notice.
(unless there are routing issues or funny filters somewhere which of course would only affect one PoP/ISP/path)
At the moment my tunnel is working, but it will be disabled shortly due to the ping responses failing.
Please note that it is 2a01:348:6:799::1 pinging you.
Do you receive any of that traffic? A log rule would help identify that.
Pings are done every minute, thus in under a minute you should see one arrive and be answered.
The Live Tunnel status in the tunnel details also should show when these pings are sent and received.
Cisco 1801 tunnel interface "outside" ping fails
Shadow Hawkins on Monday, 01 September 2014 21:15:39What is the IOS version that is running on it? #sh ver
Cisco IOS Software, C180X Software (C180X-ADVENTERPRISEK9-M), Version 12.4(24)T8, RELEASE SOFTWARE (fc1)
I did wonder about this, but i will look into that bug id further - thx for the heads up.
1775 incoming ICMP Echo Requests and only 5 Echo Replies. Looks like something is off there...
Agreed, but as you can see from the debugs, I am receiving the ICMP6 packet, and generating what appears to be a valid return one.
Though that might be because you have " ipv6 traffic-filter ipv6-internet-in in" which only does inbound queries. Is outbound filtered maybe or does it do state tracking?
Outbound is managed by CBAC. There is no explicit access-list for outbound.
What are the contents and default policies of those rules?
Theyre basically as the paste earlier. Outbound traffic egressing the tunnel1 interface will have a reflexive entry added by CBAC for the timer period configured by default.
#sh ipv6 inspect name v6-CBAC-IN-OUT
Inspection name v6-CBAC-IN-OUT
tcp alert is on audit-trail is off timeout 3600
ftp alert is on audit-trail is off timeout 3600
udp alert is on audit-trail is off timeout 30
icmp alert is on audit-trail is off timeout 10
*Sep 1 19:02:10.084: ICMPv6: Sent echo reply, Src=2A01:348:6:799::2, Dst=2A00:1C10:3:634:0:2:7401:249 So, that ping is successful I assume? That is that your remote host receives it too?
It is not. There are no valid responses to the Tunnel interfaces from outside, but there is no issue within the LAN.
Which problem? I am not aware of any problems with gblon03 or any other PoP. Note that they all run the exact same code, thus if one PoP is affected, all of them would be and a lot of users would notice. (unless there are routing issues or funny filters somewhere which of course would only affect one PoP/ISP/path)
Sorry, I couldn't find the ticket again, but history to the rescue! here
Please note that it is 2a01:348:6:799::1 pinging you. Do you receive any of that traffic? A log rule would help identify that.
I see the same output as I do on the internal pings on the ICMP6 debugs. Packet request, and seemingly valid response generated.
I think it has to be inspection, since the OS is generating valid replies, they just never make out out the tunnel interface.
The Live Tunnel status in the tunnel details also should show when these pings are sent and received.
Live tunnel stats show the tunnel is up, but no response to ping from the 799::1 source.
Cisco 1801 tunnel interface "outside" ping fails
> > *Sep 1 19:02:10.084: ICMPv6: Sent echo reply, Src=2A01:348:6:799::2, Dst=2A00:1C10:3:634:0:2:7401:249 > So, that ping is successful I assume? That is that your remote host receives it too? > It is not. There are no valid responses to the Tunnel interfaces from outside, but there is no issue within the LAN.
Sounds to me like your host is not allowing any ICMP outbound then. Definitely check that IOS version and other bug reports like that.
Sorry, I couldn't find the ticket again, but history to the rescue! here
That person had a problem on his Cisco box.
There was nothing wrong with the PoP.
Live tunnel stats show the tunnel is up,
The "up" in the Live Tunnel stats indicates that the tunnel is configured and is running. Similar to what IOS shows when checking for interface state. Normally, with standard Ethernet interfaces there is a notion of 'up' and 'down' when the cable is plugged in properly or not; tunnels do not have such a notion (unless the tunneling protocol specifies a standardized method for testing that, which neither proto-41 or AYIYA does).
It does not mean in any way that the ping test is succeeding. Check the "Latency Pkt Sent" and "Latency Pkt Recv" for that; these have to be the same number for it all to be fine.
Cisco 1801 tunnel interface "outside" ping fails
Shadow Hawkins on Friday, 05 September 2014 22:11:59
I have since resolved this situation.
Turns out it was the NAT config on my IPv4 setup.
Havign spent days on this, I found a guy who found that disabling his PBR NAT setup on his Dual WAN, the problem went away.
no ip nat outside on the Fa0 interface got the pings to function, but that obviously broke IPv4.
That led me to look at the overload statement:
BEFORE
ip nat inside source list INET-NAT interface FastEthernet0 overload
!
ip access-list standard INET-NAT
permit any
AFTER
ip nat inside source list INET-NAT interface FastEthernet0 overload
!
ip access-list standard INET-NAT
permit 192.168.99.0 0.0.0.255 ! inside range 1
permit 10.32.165.0 0.0.0.127 ! inside range 2
It would appear that the ICMPv6 packets were being matched by the IPv4 overload statement, since I was using a blanket standard ACL, not subnet specific ones for the IPv4 NAT matching.
Thanks and hope it helps someone else.
jd
Cisco 1801 tunnel interface "outside" ping fails
Thus basically what was happening is that every packet was being NATted and thus as the source address did not match that of the PoP anymore it was being dropped.
Strange that that only affected the ICMPv6 packets though.
|
![[ch]](/s/countries/ch.gif)
on Monday, 01 September 2014 19:57:51
Posting is only allowed when you are