Re: IPV6 Duplicate Address Detection(DAD)

Hi Andrew,

  Thank you very much .....Totally missed the concept that the link-local
address doesn't have the /64 ...Thanks for highlighting the same
......Tested and found out that,when the link local address has duplicate
address detection,the ipv6 interface would be stalled and that means no
processing of ipv6 on the interface but if the global addresses are detected
with duplicate address the interface will still process ipv6 .Please correct
me if my understanding is wrong .

R1#sh ipv6 interface
FastEthernet0/0 is up, line protocol is up
  *IPv6 is stalled,* link-local address is *FE80::1 [DUP]*

Once again thank you very much andrew

Regards
Anantha Subramanian Natarajan

On Fri, Sep 18, 2009 at 8:46 AM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:

> Ok cool. I would suggest to start over and clear your configs. For this
> testing, you do not need anything but a common segment between 2 routers.
>
> You might want to turn this on --> debug ipv6 nd (see a lot of output when
> you no shut the interface, great for learning)
>
> For the link local address, type this instead on both routers:
>
> interface xyz
> shut
> ipv6 add fe80::1 link-local
> no shut
>
> Once you add the same link local on both routers and type no shut, you will
> see the problem manifest itself.
>
> Notice the link local address does not have the concept of a /64 bit masks
> ... it is not global, but link local.
>
> HTH,
>
> Andrew
>
>
>
>
>
> On Fri, Sep 18, 2009 at 7:53 AM, Anantha Subramanian Natarajan <
> anantha.natarajan_at_gravitant.com> wrote:
>
>> Hi Andrew,
>>
>> Thank you very much for the time and the explanation.So you mean if the
>> link local address is been detected on a link having duplicate address will
>> not causes the interface to be in stalled (ipv6 processing disabled).Very
>> good info and thank you very much.
>>
>> I had chance to lab it with duplicate global address on the link and the
>> output showed as below which clarified my earlier question oh how to
>> differentiate DAD on link local or global ipv6 address.It seems if there is
>> a DAD with global ipv6 address,it will just indicate DUP as below and the
>> ipv6 interface will not have any issue as you mentioned which is logical as
>> there can be many global ipv6 addresses per link.
>>
>> FastEthernet0/0 is up, line protocol is up
>> IPv6 is enabled, link-local address is FE80::C001:16FF:FEC4:0
>> Global unicast address(es):
>> 2001::1, subnet is *2001::/64 [DUP]*
>> **
>> But I couldn't able to create Duplicate addresses for link-local ,I was
>> under impression that I would be able to create link local by using the
>> command ipv6 address FE80::1/64 link-local manually but while I type it ,it
>> didn't give me an option for link-local,I am using dynamips,I am sure
>> missing something.Kindly correct me .
>>
>> Andrew I am hoping that if the link-local has Duplicate address,the ipv6
>> interface should go into stalled state and thus no ipv6 processing.I just
>> want to reconfirm with you, that you created duplicate address for the link
>> local address but still that interface was up and working fine.Kinly let me
>> know
>>
>> Thank you very much for the help.
>>
>> Regards
>> Anantha Subramanian Natarajan
>>
>> * *
>>
>>
>> On Thu, Sep 17, 2009 at 11:01 PM, ALL From_NJ <all.from.nj_at_gmail.com>wrote:
>>
>>> Good evening team,
>>>
>>> Anantha, dup global addresses will not create any issues with the
>>> interface coming up or with the control protocol traffic. Team, ... keep me
>>> honest here. ;-)
>>>
>>> In a lab test I just did, I configured two routers on the same segment to
>>> have dup global addresses and unique link local. I then added some loops to
>>> one of these and configured OSPF on everything.
>>>
>>> I then configured IPv6 and OSPF on another router from another segment;
>>> one hop away. Since everything is associated with link local, there was not
>>> any problems with connectivity, routing updates and or pings. I could get
>>> to the loops on the correct router, and at first it appeared that dups did
>>> not matter much at all.
>>>
>>> Interesting to lab this out and understand where a routing loop can
>>> occur. Since clients get their addresses from DHCP or autoconfig, having
>>> dups in your network could cause two segments in different parts of the
>>> network to have an identity crisis / overlapping address space.
>>>
>>> Apart from this, no worries. Have a great night,
>>>
>>> Andrew
>>>
>>>
>>>
>>> On Thu, Sep 17, 2009 at 11:00 PM, Anantha Subramanian Natarajan <
>>> anantha.natarajan_at_gravitant.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Would like to confirm about the IPV6 Duplicate Address Detection(DAD),
>>>> DAD
>>>> would detect duplicate addresses ,if exist for both link local address
>>>> and
>>>> global ipv6 unique address on a link.Is that right ?..If so,in the below
>>>> show output,if it mentions ipv6 is stalled,I am understanding that a
>>>> duplicate link local address is been detected on the link and ipv6
>>>> processing on the interface is disabled.Please correct me if I am wrong
>>>> on
>>>> this.
>>>>
>>>> My question is ,if DAD detects duplicate address on the global ipv6
>>>> address
>>>> on the link,does that also will lead to stalled interface,if so,how we
>>>> can
>>>> distinguish between link local and global ipv6 duplicate address
>>>> detection.
>>>>
>>>> Kindly help me to understand the above.
>>>>
>>>> Router# show ipv6 interface ethernet 0
>>>> Ethernet0 is up, line protocol is up
>>>> *IPv6 is stalled*, link-local address is FE80::1
>>>>
>>>> Thank you very much for the help
>>>>
>>>> Regards
>>>> Anantha Subramanian Natarajan
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrew Lee Lissitz
>>> all.from.nj_at_gmail.com
>>>
>>
>>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com

Blogs and organic groups at http://www.ccie.net
Received on Fri Sep 18 2009 - 09:11:27 ART