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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
