Task 9.1 Link-local addresses reachability

Hello,

I am not able to ping link-local address of any spoke from spoke unless I enable "ipv6 unicast-routing on hub router (R5).

 

Link-local address are not routable and should stay only on local segment/link. However in order to reach for example R2 from R1 using link-local address

fe80::2 packet will go in and out the same frame-relay multipoint interface s1/0 on R5. Unfortunately ONLY with "ipv6 unicast-routing" enabled on R5 ping is forwarded.

Verified on 3725 running 12.4(15)T7 on R5.

 

Any clue?

Tom

Comments

  • I am experiencing the same issue you are.  Did you ever find an answer as to why this is the case.  I thought we should be able to ping link local addressing without having to enable ipv6 unicast routing.  I can ping the hub but not from spoke to spoke unless ipv6 unicast routing is enabled on R5.  If you know why please share.  If you notice in the soluiton they only ping from R5 to all the spokes and not from spoke to spoke so maybe this is what is supposed to happen but they just didn't mention it. 

     

    Wil

  • Tom,

    This is very similar to the situation in the 5-day Boot Camp v.4 Day 4 Lab - the command "no ip routing" was present in the initial configs for a couple of the routers, and frame-relay refused to work. Activating "debug frame-relay packet" showed encapsulation failure.

    I haven't tried it, but it is probably similar with IPv6 over frame-relay, where the layer-3 to layer-2 resolution actually requires ipv6 unicast-routing.

    Hello,

    I am not able to ping link-local address of any spoke from spoke unless I enable "ipv6 unicast-routing on hub router (R5).

     Link-local address are not routable and should stay only on local segment/link. However in order to reach for example R2 from R1 using link-local address

    fe80::2 packet will go in and out the same frame-relay multipoint interface s1/0 on R5. Unfortunately ONLY with "ipv6 unicast-routing" enabled on R5 ping is forwarded.

    Verified on 3725 running 12.4(15)T7 on R5.

     Any clue?

    Tom


  • Hello Tom,


    as Darrell said, IPv6 routing i not enabled by default. If not enabled, you will be able to ping link local addresses but not beyong and that's why you cannot ping from spoke to spoke but hub to spoke works!!!! Always do ipv6 unicast-routing first then do your configurations. You can waste a lot of time and points in a lab by not enabling IPv6 unicat routing.


    HTH

  • Hello,

    I've run into the same problem today. Luckily, I had read earlier the RFC4291 - IPv6 Addressing Architecutre (took me two hours...), and in the section 2.5.6 "Link-local IPv6 Unicast Addresses" it is stated:

    "Routers must not forward any packets with Link-Local source or destination address to other links."

    I think that the output from "debug ipv6 packet" on R5 is rather funny:

    IPV6: source FE80::1 (Serial1/0)
          dest FE80::2 (Serial1/0)
          traffic class 0, flow 0x0, len 100+4, prot 58, hops 64, not a router?

    Anyway, after enabling ipv6 unicast-routing on R5 only (the others don't needed since it's hub and spoke), it started to work.

    R1#ping fe80::2 repeat 1
    Output Interface: Serial0/0           
    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to FE80::2, timeout is 2 seconds:
    Packet sent with a source address of FE80::1
    !
    Success rate is 100 percent (1/1), round-trip min/avg/max = 280/280/280 ms
    R1#

     

    R5(config)#ipv6 unicast-routing
    R5(config)#
    *Jul 18 19:26:20.063: IPV6: source FE80::5 (local)
    *Jul 18 19:26:20.067:       dest FF02::16 (Serial1/0)
    *Jul 18 19:26:20.071:       traffic class 224, flow 0x0, len 76+0, prot 0, hops 1, originating
    *Jul 18 19:26:20.075: IPv6-Fwd: Sending on Serial1/0
    *Jul 18 19:26:21.047: IPV6: source FE80::5 (local)
    *Jul 18 19:26:21.051:       dest FF02::16 (Serial1/0)
    *Jul 18 19:26:21.051:       traffic class 224, flow 0x0, len 76+0, prot 0, hops 1, originating
    *Jul 18 19:26:21.055: IPv6-Fwd: Sending on Serial1/0

    I was wondering what the FF02::16 address might be, and it's

    FF02:0:0:0:0:0:0:16    All MLDv2-capable routers          [RFC3810]

    (http://www.iana.org/assignments/ipv6-multicast-addresses/)

    According to the RFC 3810:

    Multicast Listener Discovery Protocol (MLDv2). MLD is used by an
    IPv6 router to discover the presence of multicast listeners on
    directly attached links, and to discover which multicast addresses
    are of interest to those neighboring nodes.

    R5(config)#
    *Jul 18 19:26:42.563: IPV6: source FE80::1 (Serial1/0)
    *Jul 18 19:26:42.563:       dest FE80::2 (Serial1/0)
    *Jul 18 19:26:42.567:       traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding
    *Jul 18 19:26:42.579: IPV6: source FE80::5 (local)
    *Jul 18 19:26:42.579:       dest FE80::1 (Serial1/0)
    *Jul 18 19:26:42.583:       traffic class 224, flow 0x0, len 192+0, prot 58, hops 255, originating
    *Jul 18 19:26:42.587: IPv6-Fwd: Sending on Serial1/0
    *Jul 18 19:26:42.735: IPV6: source FE80::2 (Serial1/0)
    *Jul 18 19:26:42.735:       dest FE80::1 (Serial1/0)
    *Jul 18 19:26:42.739:       traffic class 0, flow 0x0, len 100+4, prot 58, hops 63, forwarding
    R5(config)#
    *Jul 18 19:26:42.743: IPV6: source FE80::5 (local)
    *Jul 18 19:26:42.743:       dest FE80::2 (Serial1/0)
    *Jul 18 19:26:42.743:       traffic class 224, flow 0x0, len 192+0, prot 58, hops 255, originating
    *Jul 18 19:26:42.743: IPv6-Fwd: Sending on Serial1/0

    Perhaps the solution in the lab workbook should include the enabling of ipv6 unicast-routing on R5, along with brief explanation in the note.

    I also have a question, maybe someone is able to clarify:

    What would be the meaning of "originating" in the debug?

    *Jul 18 19:26:42.579: IPV6: source FE80::5 (local)
    *Jul 18
    19:26:42.579:       dest FE80::1 (Serial1/0)
    *Jul 18
    19:26:42.583:       traffic class 224, flow 0x0, len 192+0, prot 58,
    hops 255, originating

    Thanks,

    Vlad

  • Hi,

    I thought this was more to do with routers not listening to FF02::2 unless ipv6 unicast-routing is configured..........

    Regards,

    Chris

  • Hi, i'm also not able to ping either spokes or hub in 9.1 task...

    R5 config and spokes similar ( same config from solution)

    ipv6 unicast-routing
     ipv6 address FE80::5 link-local
     frame-relay map ipv6 FE0::1 501 broadcast
     frame-relay map ipv6 FE0::2 502 broadcast
     frame-relay map ipv6 FE0::3 503 broadcast
     frame-relay map ipv6 FE0::4 504 broadcast

     

     

    debug picked up encap failed warning :

    *Mar  1 05:48:00.158: IPv6: SAS picked source FE80::5 for FE80::2 (Serial0/0)
    *Mar  1 05:48:00.170: ICMPv6: Sending echo request to FE80::2
    *Mar  1 05:48:00.174: IPV6: source FE80::5 (local)
    *Mar  1 05:48:00.174:       dest FE80::2 (Serial0/0)
    *Mar  1 05:48:00.178:       traffic class 0, flow 0x0, len 100+0, prot 58, hops 64, originating
    *Mar  1 05:48:00.182: IPv6: Encapsulation failed
    *Mar  1 05:48:00.182: IPv6: Resolving next hop FE80::2 on interface Serial0/0.
    *Mar  1 05:48:02.194: ICMPv6: Sending echo request to FE80::2
    *Mar  1 05:48:02.198: IPV6: source FE80::5 (local)
    *Mar  1 05:48:02.202:       dest FE80::2 (Serial0/0)
    *Mar  1 05:48:02.202:       traffic class 0, flow 0x0, len 100+0, prot 58, hops 64, originating
    *Mar  1 05:48:02.206: IPv6: Encapsulation failed

     

    Any tips for me ?

    Thanks !

  •  

    Hi,

    Your maps use FE0. It should be FE80.

     

    HTH,

    Bassam

  • R5 config and spokes similar ( same config from solution)

    ipv6 unicast-routing
     ipv6 address FE80::5 link-local
     frame-relay map ipv6 FE0::1 501 broadcast
     frame-relay map ipv6 FE0::2 502 broadcast
     frame-relay map ipv6 FE0::3 503 broadcast
     frame-relay map ipv6 FE0::4 504 broadcast

    It looks like you missed "8" on link-local address, you have assigned correct link-local address but when you mapping you missed it!!, FE80:: prefix has been reseved for link-local address, which has a link level scope. So you should change your frame-relay mapping to like:

    frame-relay map ipv6 FE80::C802:15FF:FE9C:0 103
     frame-relay map ipv6 FE80::C801:3FF:FE40:0 102

    Good Luck

  • thanks for catching that :)

  • Unsobill,

    What's the IPv6 address format for Link-local? ;-)


    > ipv6 unicast-routing
    >  ipv6 address FE80::5 link-local
    >  frame-relay map ipv6 FE0::1 501 broadcast
    >  frame-relay map ipv6 FE0::2 502 broadcast
    >  frame-relay map ipv6 FE0::3 503 broadcast
    >  frame-relay map ipv6 FE0::4 504 broadcast

    Regards,
    David Sudjiman
  • I'd like to bring this topic up again. Why do we need to enable unicast routing at R5?

    When I configured I was able to get Hub to spoke comms working. When I ran my debugs on spokes I didnt experience encaps failures, so I then moved to R5 where I saw the not a router message. This just threw me off, and I found a CCNP Route book saying you need to enable unicast routing, but not really info behind the thought process.

    So my understanding is that link-local are non-routable and valid on a per interface basis on the router (so a router can apply the same link-local to multiple interfaces). Given that the frame-relay is a non-broadcast environment, this is the only feasible reason. So R5 needs to "route the packets" when it's more like it's switching it from R2 to R1 (for example). I'm assuming that if R5 wasn't in the picture, and their were DLCIs connecting each spoke then this wouldn't have been an issue, assuming you have the frame-relay mappings in place.

    Also the solution guide doesnt discuss enabling unicast-routing on R5.

    Help?

  • So R5 needs to "route the packets" when it's more like it's switching it from R2 to R1 (for example).

     

    Given that R5 is switching from R2 to R1 based on a Layer 3 information, which is the IPv6 address of the destination, then enabling IPv6 unicast routing is a must.

     

    Just my 2 cents.

     

Sign In or Register to comment.