[c-nsp] PIX ipv6 neighbour problem
Andrew Yourtchenko
ayourtch at cisco.com
Tue Oct 19 12:07:37 EDT 2010
Hi Andreas,
On Tue, 19 Oct 2010, Andreas Mueller wrote:
>
> Hello,
>
> my PIX515E is running PIX 8.0.4 with multiple contexts. In one of my contexts
> I would like to have IPv6 connectivity. The Interface is configured as
I silently assume but just to verify - no shared interface between the contexts ?
[snip]
> S ::/0 [0/0]
> via XXXX:YYYY:ZZZZ:1::d, inside
>
> when I tried to ping the IP (XXXX:YYYY:ZZZZ:1::e8) of the PIX on the inside
> interface from a linux box I get no responses.
> When I look at the output of the command "show ipv6 neighbours", started
> multiple times during the pings I get the following outputs:
>
> pix515e/s6ipv6# show ipv6 neigh
> IPv6 Address Age Link-layer Addr State Interface
> fe80::20a:b8ff:fefb:6d43 518 000a.b8fb.6d43 STALE inside
> fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside
>
> pix515e/s6ipv6# show ipv6 neigh
> IPv6 Address Age Link-layer Addr State Interface
> fe80::20a:b8ff:fefb:6d43 518 000a.b8fb.6d43 STALE inside
> XXXX:YYYY:ZZZZ:1::d 0 0021.85ca.6146 DELAY inside
> fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside
>
> pix515e/s6ipv6# show ipv6 neigh
> IPv6 Address Age Link-layer Addr State Interface
> fe80::20a:b8ff:fefb:6d43 519 000a.b8fb.6d43 STALE inside
> XXXX:YYYY:ZZZZ:1::d 0 0021.85ca.6146 PROBE inside
> fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside
>
> pix515e/s6ipv6# show ipv6 neigh
> IPv6 Address Age Link-layer Addr State Interface
> fe80::20a:b8ff:fefb:6d43 519 000a.b8fb.6d43 STALE inside
> fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside
Looks like we've already got the neighbor entry for <pref>:1::d, then tried to
send the NS to it and failed ?
>
> here is the output of the PIX-debugging:
>
>
> Oct 19 15:55:52 pix515e %PIX-7-609001: Built local-host
> identity:fe80::20e:cff:fe80:c80c
> Oct 19 15:55:52 pix515e %PIX-7-609001: Built local-host inside:ff02::1
> Oct 19 15:55:52 pix515e %PIX-6-302020: Built outbound ICMP connection for
> faddr ff02::1/0 gaddr fe80::20e:cff:fe80:c80c/0 laddr fe80::20e:cff:fe80:c80c/0
> Oct 19 15:55:52 pix515e %PIX-7-711001: ICMPv6-ND: Sending RA to ff02::1 on
> inside
> Oct 19 15:55:52 pix515e %PIX-7-711001: ICMPv6-ND: MTU = 1500
> Oct 19 15:55:52 pix515e %PIX-7-711001: IPV6: source fe80::20e:cff:fe80:c80c
> (local)
> Oct 19 15:55:52 pix515e %PIX-7-711001: dest ff02::1 (inside)
> Oct 19 15:55:52 pix515e %PIX-7-711001: traffic class 224, flow 0x0, len
> 72+0, prot 58, hops 255, originating
> Oct 19 15:55:52 pix515e %PIX-7-711001: IPv6: Sending on inside
> Oct 19 15:55:56 pix515e %PIX-6-302021: Teardown ICMP connection for faddr
> ff02::1/0 gaddr fe80::20e:cff:fe80:c80c/0 laddr fe80::20e:cff:fe80:c80c/0
> Oct 19 15:55:56 pix515e %PIX-7-609002: Teardown local-host
> identity:fe80::20e:cff:fe80:c80c duration 0:00:04
> Oct 19 15:55:56 pix515e %PIX-7-609002: Teardown local-host inside:ff02::1
> duration 0:00:04
>
Based on the timestamps, seems like the ICMP connection was built to send the RA
- so I do not see any traces of ND working here at all...
Give it a shot this way:
"debug ipv6 nd", "deb ipv6 icmp" then "clear ipv6 neigh", you should have
something like this when pinging from the linux box:
ASA(config)# clear ipv6 neigh
ASA(config)# deb ipv6 nd
ASA(config)# deb ipv6 icmp
ASA(config)# sh ipv6 neigh
ASA(config)# ICMPv6: Received ICMPv6 packet from
2002:c01d:cafe:1002:218:51ff:fef9:bceb, type 128
ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6-ND: DELETE -> INCMP: 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6-ND: Sending NS for 2002:c01d:cafe:1002:218:51ff:fef9:bceb on inside
ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type
136
ICMPv6-ND: Received NA for 2002:c01d:cafe:1002:218:51ff:fef9:bceb on inside from
2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6-ND: INCMP -> REACH: 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type
128
ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type
128
ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb
ICMPv6: Received ICMPv6 packet from fe80::218:51ff:fef9:bceb, type 135
ICMPv6-ND: Received NS for fe80::21e:7aff:fe36:6d37 on inside from
fe80::218:51ff:fef9:bceb
ICMPv6-ND: DELETE -> INCMP: fe80::218:51ff:fef9:bceb
ICMPv6-ND: INCMP -> STALE: fe80::218:51ff:fef9:bceb
ICMPv6-ND: Sending NA for fe80::21e:7aff:fe36:6d37 on inside
ICMPv6-ND: STALE -> DELAY: fe80::218:51ff:fef9:bceb
ICMPv6-ND: DELAY -> PROBE: fe80::218:51ff:fef9:bceb
ICMPv6-ND: Sending NS for fe80::218:51ff:fef9:bceb on inside
ICMPv6: Received ICMPv6 packet from fe80::218:51ff:fef9:bceb, type 136
ICMPv6-ND: Received NA for fe80::218:51ff:fef9:bceb on inside from fe80::218:51f
Also interesting thing would be to check in terms of packets:
On the PIX you should be able to do the capture the interesting traffic by this
capture:
ipv6 access-list foo permit icmp6 any any
capture cap int inside access-list foo
And then do "show capture" and compare with a tcpdump output on the linux box
to see where the packets are being lost - is it NS (neighbor solicitation) that
is being not sent/lost from either side, or is it NA (neighbor
advertisement) that is being not sent/lost.
cheers,
andrew
>
> the neighbour discovery is working well if I ping one linux-host from
> another.
>
>
> greetings and thanks for help,
>
>
> Andreas
>
>
>
> --
> Zentrum für Datenverarbeitung
> Abteilung Netze
> Tel: 07071-2970342
> Fax: 07071-295912
>
>
More information about the cisco-nsp
mailing list