Re: Running Routing Protocol over 6to4 Tunnels

Sorry for the typos, I just noticed I was typing "96:0e" while it
should have been "960e" of course. This is what happens sometimes when
you type out of your head :)

2010/6/12 Petr Lapukhov <petr_at_internetworkexpert.com>:
> Ladee,
>
> You can use static routes to route any IPv6 subnet across 6to4 tunnel.
> For example imagine you have R4 and R5 with Loopback0 addresses
> 150.14.4.4 and 150.14.5.5 with full IPv4 reachability between them.
> Both R4 and R5 are dual-stack, while intermediate routers are ipv4
> only. Let's assume that R5 has the prefixe 2001:150:14:5::/64 directly
> attached or learned via IGP and we want R4 to be able to reach it over
> the 6to4 tunnel. Here is how R's configuration may look like:
>
> interface Loopback0
> ip address 150.14.4.4 255.255.255.0
> !
> interface tunnel 0
> tunnel source Loopback0
> ipv6 address 2002:96:0e:404::4/64
> tunnel mode ipv6ip 6to4
> !
> ipv6 route 2002::/16 Tunnel0
> ipv6 route 2001:150:14:5::/64 2002:96:0E:505::5
>
> Here 2002:96:0E:505::5 is R5's 6to4 endpoint address derived from the
> loopback address 150.14.5.5.
>
> The way this static route works is that packets going to
> 2001:150:14:5::/64 will be encapsulated using IP header with the
> destionation IP address extracted from the next-hop 2002:96:0E:505::5
> i.e. 150.14.5.5. The reason being is the fact that 2002::/16 is routed
> across tunnel0 and recursive lookup for 2001:150:14::5/16 allows for
> construction of proper IPv4 encapsulation header. Of course, R5 - the
> destination, need to have the route 2001:150:14:5::/64 either directly
> connected or learned by some other means. Of course, dont forget that
> routing should be symmetric and R5 may have to be configured with
> similar static routes.
>
> As for BGP multihop, you need it because normally eBGP peers
> connecting across 6to4 tunnel appear to be on different IPv6 subents
> (due to different IPv4 sources) and therefore eBGP does not consider
> them to be directly conneted.
>
> Regards,
>
> Petr
>
> 2010/6/12 Ladee Geek <ladeegeek_at_gmail.com>:
>> THANK YOU - Bob and Petr for understanding exactly what I was getting at.
>>
>> I started out trying to use static routes across the tunnel to other 2002
>> addresses. A loopback for example with a 2002 address. I thought
>> the 2002::/16 static route out the tunnel should have made that work. When
>> that didn't work I thought I would try OSPF in an nmba mode so I had
>> neighbor statments that gave me a next-hop to build the dynamic tunnel
>> from. The problem was that the neigbor statments are link local, not
>> 2002:.
>>
>> So the dynamic point-to-multipoint 6to4 tunnel is only to create the
>> tunnel. There's no static way to reach other 2002:: addresses unless they
>> are tunnel endpoints? That's what I was originally trying to do.
>>
>> I knew I could use ISATAP with OSPF point-to-multipoint in NBMA.
>>
>> I just don't have any professional experience with v6. It's all been study
>> so the practical applications of these more esoteric tunnel types escape me.
>>
>>
>>
>> Petr -
>> I'm a little lost on the "dont forget eBGP multihop if you're running
>> external sessions." Are you reminding me because 6to4 uses loopbacks for
>> sources which are intern used for the tunnel addresses? So what "appears"
>> to be directly connected neighbors are really not. OR is there something
>> else?
>>
>>
>> You two are *great!!* Thank you so much for your time.
>>
>> r/
>> LG
>>
>>
>> On Fri, Jun 11, 2010 at 10:11 PM, Bob Sinclair <bob_at_bobsinclair.net> wrote:
>>
>>
>>> Ladee,
>>>
>>> The ipv6 6to4 tunnel does not support dynamic routing. This tunnel type
>>> embeds the IPv4 destination address in the ipv6 prefix. The next hop and
>>> neighbor addresses are always link-local addresses. Link local addresses
>>> must start FE80::/10. ISATAP tunnels support IGPs, because they embed the
>>> ipv4 address in the host portion. If you try ISATAP, make sure to allow
>>> the
>>> tunnel process to create the link-local address for you; do not hard code
>>> it.
>>>
>>> Here is a working configuration:
>>>
>>> interface Tunnel1
>>>
>>> no ip address
>>> no ip redirects
>>>
>>> ipv6 address 2001:45::/64 eui-64
>>>
>>> ipv6 ospf network point-to-multipoint non-broadcast
>>>
>>> ipv6 ospf neighbor FE80::5EFE:AC10:2D05
>>> ipv6 ospf 1 area 0
>>> tunnel source 172.16.45.4
>>> tunnel mode ipv6ip isatap
>>>
>>> Tunnel destination IP is 172.16.45.5
>>>
>>> Note local addresses on tunnel:
>>> show ipv6 interface:
>>>
>>> Tunnel1 is up, line protocol is up
>>> IPv6 is enabled, link-local address is FE80::5EFE:AC10:2D04
>>> Global unicast address(es):
>>> 2001:45::5EFE:AC10:2D04, subnet is 2001:45::/64 [EUI]
>>>
>>> HTH,
>>>
>>> Bob Sinclair
>>>
>>> > -----Original Message-----
>>> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> > Ladee Geek
>>> > Sent: Friday, June 11, 2010 6:12 PM
>>> > To: Cisco certification
>>> > Subject: Running Routing Protocol over 6to4 Tunnels
>>> >
>>>
>>> > I'm wrestling with running a routing protocol over 6to4 tunnels. I can
>>> > ping
>>> > from tunnel end point to end point, but can't get to any other
>>> > 2002::/16
>>> > addresses I've created. That was based on the static route 2002::/16
>>> > out
>>> > the tunnel interface. So I am trying a dynamic routing protocol, OSPF
>>> > in
>>> > p-mp nbma mode. I have configured the neighbor statement so there's a
>>> > next
>>> > hop address, but I don't get a neighbor relationship.
>>> >
>>> > When pining the other end of the tunnel I actually see icmp traffic.
>>> > But
>>> > when I ping another 2002 address I don't see anything. I have the
>>> > static
>>> > 2002::/16 tunnel 345.
>>> >
>>> > So my static didn't work and neither did a dynamic protocol to get to
>>> > 2002
>>> > addresses other than the tunnel end points.
>>> >
>>> > What am I missing?
>>> >
>>> >
>>> > Topology: R3, R4 and R5 are set up with 6-to-4 tunnels.
>>> >
>>> > *Rack1R3*(config-if)#do sh run int tun 345
>>> > Building configuration...
>>> > Current configuration : 267 bytes
>>> > !
>>> > interface Tunnel345
>>> > no ip address
>>> > no ip redirects
>>> > ipv6 address 2002:9B01:2503::/64 eui-64
>>> > ipv6 ospf network point-to-multipoint non-broadcast
>>> > ipv6 ospf neighbor FE80::9B01:9204
>>> > ipv6 ospf 1 area 345
>>> > tunnel source FastEthernet0/0
>>> > tunnel mode ipv6ip 6to4
>>> > *Rack1R3(config-if)#do pin 2002:9B01:3A05::9B01:3A05 - this is the
>>> > fastether
>>> > of R5*
>>> > **
>>> > Type escape sequence to abort.
>>> > Sending 5, 100-byte ICMP Echos to 2002:9B01:3A05::9B01:3A05, timeout is
>>> > 2
>>> > seconds:
>>> > !!!!!
>>> > Success rate is 100 percent (5/5), round-trip min/avg/max = 60/78/140
>>> > ms
>>> >
>>> > *Rack1R3(config)#do sirv | se 2002*
>>> > S 2002::/16 [1/0]
>>> > via Tunnel345, directly connected
>>> >
>>> >
>>> > *Rack1R5(config)#do sh run int tun 345
>>> > *Building configuration...
>>> > Current configuration : 156 bytes
>>> > !
>>> > interface Tunnel345
>>> > no ip address
>>> > no ip redirects
>>> > ipv6 address 2002:9B01:3A05::/64 eui-64
>>> > tunnel source FastEthernet0/0
>>> > tunnel mode ipv6ip 6to4
>>> > end
>>> > *Rack1R5(config)#do sh run int lo 105*
>>> > Building configuration...
>>> > Current configuration : 80 bytes
>>> > !
>>> > interface Loopback105
>>> > no ip address
>>> > ipv6 address 2002:9601:505:1::5/64
>>> >
>>> >
>>> > *Rack1R3(config)#do ping 2002:9601:505::1*
>>> > Type escape sequence to abort.
>>> > Sending 5, 100-byte ICMP Echos to 2002:9601:505::1, timeout is 2
>>> > seconds:
>>> > .....
>>> > Success rate is 0 percent (0/5)
>>> > Rack1R3(config)#
>>> >
>>> > *Rack1R5(config-if)#do shipv*
>>> > Loopback0 [up/up]
>>> > FE80::21A:6CFF:FE9F:9FA8
>>> > * 2002:9601:505::1
>>> > *
>>> > --
>>> > r/
>>> > LG
>>> >
>>> >
>>>
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > No virus found in this incoming message.
>>> > Checked by AVG - www.avg.com
>>> > Version: 9.0.829 / Virus Database: 271.1.1/2930 - Release Date:
>>> > 06/11/10 02:35:00
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> r/
>> LG
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Jun 12 2010 - 10:09:12 ART