JonZu Groups

ALL From_NJ says:

For sure … that was one of my first thought. Since the ipv6 addresses are really v4 addresses, I consulted the ipv4 routing table in both directions. There is only a single path to each loopback and physical address

Roy, I appreciate your response. Any thoughts on additional debugs or show commands?

Lejoe says:

Hi Andrew,

On R3, the static route

ipv6 route 2001:1:1:1::/64 Tunnel0 should be removed.

It cannot derive the destination ipv4 address in the above case. Looking forward to your comments.

Lejoe

On Tue, Sep 29, 2009 at 2:36 PM, ALL From_NJ wrote: > Ok, problem found, I only noticed it when I was going to copy my configs > into this mail and send them to you all. Here are my configs, I will not > say yet what the problem is, but it is found in my configs (usually the case > …). > > Andrew > > PS – any other comments are most welcome!!! > > ~~~~~~~~ > > R1: > > ipv6 unicast-routing > ! > interface Tunnel0 > no ip address > no ip redirects > ipv6 address 2002:101:101::1/64 > tunnel source Loopback0 > tunnel mode ipv6ip 6to4 > ! > interface Loopback0 > ip address 1.1.1.1 255.255.255.255 > ipv6 address 2001:1:1:1::1/64 > ipv6 rip 1 enable > ! > ipv6 route 2002::/16 Tunnel0 > ipv6 route 2001:3:3:3::3/128 2002:303:303::3 > ! > > > R3 is across the frame cloud. Here are the configs from R3: > > ipv6 unicast-routing > ! > interface Loopback0 > ip address 3.3.3.3 255.255.255.0 > ipv6 address 2001:3:3:3::3/64 > ipv6 rip 1 enable > ! > interface Tunnel0 > no ip address > no ip redirects > ipv6 address 2002:303:303::3/64 > tunnel source Loopback0 > tunnel mode ipv6ip 6to4 > ! > ipv6 route 2001:1:1:1::/64 2002:101:101::1 > ipv6 route 2001:1:1:1::/64 Tunnel0 > ipv6 route 2002::/16 Tunnel0 > > > > > > > On Tue, Sep 29, 2009 at 12:27 AM, ALL From_NJ wrote: > >> For sure … that was one of my first thought. Since the ipv6 addresses >> are really v4 addresses, I consulted the ipv4 routing table in both >> directions. There is only a single path to each loopback and physical >> address >> >> Roy, I appreciate your response. Any thoughts on additional debugs or show >> commands? >> >> >> >> On Tue, Sep 29, 2009 at 12:18 AM, Roy Waterman wrote: >> >>> Hi Andrew >>> >>> So you’ve verified that there is no equal cost load balancing going on? >>> >>> Regards >>> Roy >>> >>> 2009/9/29 ALL From_NJ >>> >>>> Hey team, >>>> >>>> Got this working tonight, auto ipv6 tunnels. >>>> >>>> Divin provided me this link: >>>> >>>> http://ardenpackeer.com/routing-protocols/tutorial-ipv6-tunnels-part-2-automatic-6to4-tunnels/ >>>> < -- this helped me much. >>>> >>>> Conceptually it helped me to consider this a ‘hack’ or ‘cheat’. Kind of >>>> neat in some ways too I guess … by defining the IPv4 address as part of >>>> the IPv6 address, you are really telling the router to find the remote >>>> peer >>>> by it’s IPv4 address. Of course … the IPv4 routing table needs to be >>>> right before this will work … >>>> >>>> Any who … my question is related to ping. Has anyone else seen 50% >>>> ping >>>> timeout when using auto tunnels? I get all responses to other frame >>>> relay >>>> ipv6 peers or Ethernet peers etc … . Here is the output, kind of looks >>>> like a pacing issue, but the fact that other pings work 100% of the time >>>> does not make sense. >>>> >>>> R1(config)#do ping 2001:3:3:3::3 sou 2001:1:1:1::1 re 10 >>>> >>>> Sending 10, 100-byte ICMP Echos to 2001:3:3:3::3, timeout is 2 seconds: >>>> Packet sent with a source address of 2001:1:1:1::1 >>>> !.!.!.!.!. >>>> Success rate is 50 percent (5/10), round-trip min/avg/max = 32/32/36 ms >>>> >>>> I have static routes going to the remote tunnel peer. >>>> >>>> Trace works just fine, no timeouts, single hop. I tried it with and >>>> without >>>> ipv6 cef. I also did a debug ipv6 pack det and debug ipv6 icmp … >>>> nothing >>>> out of the ordinary … >>>> >>>> Any thoughts? Seen this? >>>> >>>> — >>>> Andrew Lee Lissitz >>>> all.from.nj@gmail.com >>>> >>>> >>>> >>>> _______________________________________________________________________ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> — >>> Regards >>> Roy >>> >> >> >> >> — >> Andrew Lee Lissitz >> all.from.nj@gmail.com >> > > > > — > Andrew Lee Lissitz > all.from.nj@gmail.com > > > > _______________________________________________________________________

Nick Matthews says:

For what it’s worth, there’s also an IPv6 bug like this:

CSCsh63881 – “alternate ping success with NAT-PT and CEF enabled”

While no IPv6 PT in this example, it’s still out there. (Workaround is disable CEF, and it isn’t fixed in any code yet).

-nick

On Tue, Sep 29, 2009 at 1:48 AM, Roy Waterman wrote: > Hi Andrew > > By equal cost load balancing I was referring to the situation you had with > your config with the router trying load balance but one of the static routes > is dodgy > Just as a rule, as Scott Morris likes to say, think like the router. > Things become a lot clearer that way, at least, until the router behaves in > unexpected ways! > > Glad you resolved the issue. > > 2009/9/29 ALL From_NJ > >> Hey team, >> >> Got this working tonight, auto ipv6 tunnels. >> >> Divin provided me this link: >> >> http://ardenpackeer.com/routing-protocols/tutorial-ipv6-tunnels-part-2-automatic-6to4-tunnels/ >> < -- this helped me much. >> >> Conceptually it helped me to consider this a ‘hack’ or ‘cheat’. Kind of >> neat in some ways too I guess … by defining the IPv4 address as part of >> the IPv6 address, you are really telling the router to find the remote peer >> by it’s IPv4 address. Of course … the IPv4 routing table needs to be >> right before this will work … >> >> Any who … my question is related to ping. Has anyone else seen 50% ping >> timeout when using auto tunnels? I get all responses to other frame relay >> ipv6 peers or Ethernet peers etc … . Here is the output, kind of looks >> like a pacing issue, but the fact that other pings work 100% of the time >> does not make sense. >> >> R1(config)#do ping 2001:3:3:3::3 sou 2001:1:1:1::1 re 10 >> >> Sending 10, 100-byte ICMP Echos to 2001:3:3:3::3, timeout is 2 seconds: >> Packet sent with a source address of 2001:1:1:1::1 >> !.!.!.!.!. >> Success rate is 50 percent (5/10), round-trip min/avg/max = 32/32/36 ms >> >> I have static routes going to the remote tunnel peer. >> >> Trace works just fine, no timeouts, single hop. I tried it with and >> without >> ipv6 cef. I also did a debug ipv6 pack det and debug ipv6 icmp … nothing >> out of the ordinary … >> >> Any thoughts? Seen this? >> >> — >> Andrew Lee Lissitz >> all.from.nj@gmail.com >> >> >> >> _______________________________________________________________________ >> >> >> >> >> >> >> >> > > > — > Regards > Roy > > > > _______________________________________________________________________

ALL From_NJ says:

Cool, thanks Nick

On Tue, Sep 29, 2009 at 11:00 AM, Nick Matthews wrote: