[c-nsp] PIX ipv6 neighbour problem

[Andreas Mueller]

	Hello,

thanks for your hint concerning the shared interfaces. When I disabled 
the interface in other contexts, the neighbour-discovery started working 
again. The Problem occured due to a no "mac-address auto" in the config. 
When I changed this to "mac-address auto" the neighour discovery works 
in all contexts with shared interfaces.

	thanks for help,

		Andreas

On 10/19/2010 06:07 PM, Andrew Yourtchenko wrote:
> 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
>>
>>


-- 
Zentrum für Datenverarbeitung
Abteilung Netze
Tel: 07071-2970342
Fax: 07071-295912