cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11417
Views
20
Helpful
22
Replies

Comcast 6RD configuration?

glgersc
Level 1
Level 1

Hi,

I have a new 881 router loaded with the latest 15.1.3T software, and I'm trying to get it connected to the Comcast 6RD IPv6 routers.  (I'm on a Comcast cable modem.)

I've been trying to follow the directions from these links:

http://docwiki.cisco.com/wiki/6rd_Configuration_Example
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel.html

I am getting a delegated prefix from Comcast, so I know I'm connecting to their BR routers.

RouterA-new#sho tun 6rd pref 69.252.80.66 tu6
Interface: Tunnel6
Destination: 69.252.80.66
6RD Prefix: 2001:55C:45FC:5042::

But, that doesn't seem to be properly following the general-prefix on the tunnel (it's missing the ::45FC:5042::):

RouterA-new#sho ipv int brie tun 6
Tunnel6                    [up/up]
    FE80::A14:DE01
    2001:55C:A14:DE01::A14:DE01

I think the problem is just some stupid wrong/missing config in my tunnel setup.  Or an ipv6 noob issue.  This is the current state of what I have so far, cobbled from the links above, and with several shotgun troubleshooting tweaks:

ipv6 general-prefix Comcast6RD 6rd Tunnel6


interface Tunnel6
description Comcast 6RD IPv6 tunnel.
no ip address
no ip redirects
ipv6 address Comcast6RD ::/64 eui-64
ipv6 enable
tunnel source Vlan1
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66

interface Vlan1
description Inside$FW_INSIDE$
ip address 10.20.222.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security in-zone
ip tcp adjust-mss 1452
ipv6 enable

I've tried putting the ipv6 address on the Vlan1 interface, as in the docwiki link, but then I get the overlapping address error listed in the link.  But, when I try just putting the 'ipv6 enable' command on the tunnel, then I don't get any 2001:55C:: addresses assigned.

Feb 28 04:16:38.622: %IPV6_ADDRESS-3-ADDRESS_CFG: 2001:55C:A14:DE01::/64 can not be configured on Vlan1, 2001:55C:A14:DE01::/64 is overlapping with 2001:55C:A14:DE01::/128 on Tunnel6

So, does anyone have a working 6RD config for Comcast?  Or can you point out what I'm doing wrong?

Thanks.

1 Accepted Solution

Accepted Solutions

Hi, Greg:

I think the problem is with your default v6 route - "ipv6 route ::/0 Tunnel6". You are basically telling the CE that everything is directly connected to the 6rd network, so it assumes whatever comes after the 6rd prefix is the embedded ipv4 address for the destination. Could you try to remove this line, and replace it with "ipv6 route ::/0 Tunnel6  2001:55C:45FC:5042::"? This should tell the CE to send everything else to the BR instead. Give it a try and see if that helps any.

You are correct that by not configuring "tunnel 6rd ipv4 prefix-len", it defaults to a prefix length of 0, which means the CE ipv4 addresses cannot be aggregated and therefore all 32 bits will be used. So with a 6rd prefix of 32 bits and 32 bits of ipv4, your delegated prefix is 64 bits (longest allowed by the 6rd spec), which implies you won't be able to subnet within that delegated prefix.

Hope this helps.

Thanks,

Wen

View solution in original post

22 Replies 22

Andrew Yourtchenko
Cisco Employee
Cisco Employee

Can you try  removing the "ipv6 address Comcast6RD ::/64 eui-64" from the tunnel interface and putting that precise config line under "Vlan1" interface ?

In my lab that configures the inner ethernet interface with the right IPv6 address.

Phillip Remaker
Cisco Employee
Cisco Employee

Be aware also that Comcast 6rd is planned to be shut down at the end of June, see http://comcast6.net/

Phillip Remaker
Cisco Employee
Cisco Employee

I think the magic to remove the IPv6 address from the tunnel interface, at least for now.  The 6rd code will insert the appropriate /128 into routing.  As Andrew noted, you want the /64 set up on the (v)LAN interface.

glgersc
Level 1
Level 1

Hi,

OK, I've moved the 'ipv6 address Comcast6RD  ::/64 eui-64' command to the internal Vlan1 interface.  That did not  work before.  But, after bouncing the tunnel interface, it finally came  to life and I have usable ipv6 address.  RA is spreading it to my  Windows boxes on the internal lan.

However, there is still a problem.  The  6RD prefix I'm getting does not appear to be valid.  And I am unable to  get any ipv6 connectivity beyond my router.

This is the prefix I'm getting:  2001:55C:A14:DE01::/64

I  don't think the bolded :A14:DE01: local bit is correct.  That matches  my internal 10.20.222.1 address.  Based on bits I've read, that part is  supposed to match my outside DHCP address.  In my case, 24.118.231.197

So, where is the internal :A14:DE01: coming from?  Why  isn't the 6RD tunnel prefix properly reflecting my outside address?  I  really doubt the internal will route back to me properly.

I have all of the current ipv6 related config below.  Also the output of the 'show tunnel 6rd tunnel6' command.

Any thoughts?

Thx,

Greg

btw,  Yes, I read that Comcast will be closing their 6RD trial in a few  months.  But until then, based on what I've read, 6RD is better behaved  than 6to4, so I thought I would start my ipv6 experimenting with that  first.

------------------------------------

ipv6 general-prefix Comcast6RD 6rd Tunnel6
ipv6 unicast-routing
ipv6 cef

interface Tunnel6
  description Comcast 6RD IPv6 tunnel.
  ip address 10.20.6.1 255.255.255.0
  no ip redirects
  ipv6 enable
  tunnel source Vlan1
  tunnel mode ipv6ip 6rd
  tunnel 6rd prefix 2001:55C::/32
  tunnel 6rd br 69.252.80.66

interface FastEthernet4
  description Internet-Outside$FW_OUTSIDE$
  ip address dhcp client-id FastEthernet4
  ip access-group FirstPass in
  ip nat outside
  ip virtual-reassembly in
  load-interval 30
  duplex auto
  speed auto
!
interface Vlan1
  description Inside$FW_INSIDE$
  ip address 10.20.222.1 255.255.255.0
  ip flow ingress
  ip nat inside
  ip virtual-reassembly in
  ip tcp adjust-mss 1452
  ipv6 address Comcast6RD ::/64 eui-64
  ipv6 enable

ipv6 route 2001:55C::/32 Tunnel6
ipv6 route ::/0 Tunnel6

-----------------

RouterA-new#show tunnel 6rd tunnel6
Interface Tunnel6:
   Tunnel Source: 10.20.222.1
   6RD: Operational, V6 Prefix: 2001:55C::/32
        V4 Prefix, Length: 0, Value: 0.0.0.0
        V4 Suffix, Length: 0, Value: 0.0.0.0
        Border Relay address: 69.252.80.66
   General Prefix: 2001:55C:A14:DE01::/64

---------------------

RouterA-new#show ipv6 interface brief
 
Tunnel6                    [up/up]
     FE80::A14:DE01
Vlan1                      [up/up]
     FE80::523D:E5FF:FE98:E0CE
     2001:55C:A14:DE01:523D:E5FF:FE98:E0CE

--------------

glgersc
Level 1
Level 1

Hmm, OK, after reviewing my config, I decided to point the
tunnel source to the outside interface.  So, the Tunnel6 interface now looks like this:

interface Tunnel6
description Comcast 6RD IPv6 tunnel.
ip address 10.20.6.1 255.255.255.0
no ip redirects
ipv6 enable
tunnel source FastEthernet4
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66
end

That seems screwy, as any tunnels I've done before would point to the inside interface.  (But my tunnel experience is weak.)

I now get an outside public IP referenced prefix for my ipv6 address.

RouterA-new#sho tunnel 6rd tun6
Interface Tunnel6:
  Tunnel Source: 24.118.231.197
  6RD: Operational, V6 Prefix: 2001:55C::/32
       V4 Prefix, Length: 0, Value: 0.0.0.0
       V4 Suffix, Length: 0, Value: 0.0.0.0
       Border Relay address: 69.252.80.66
  General Prefix: 2001:55C:1876:E7C5::/64

But it still doesn't work. No connectivity beyond the router.

I've also removed all firewall config and screening ACL's to make sure I don't have any issue there.  (Temporarily.)

I'm not finding any useful configuration examples on the Internet.  Everything seems to be lab based, using 10.x addresses, and not reflective of any actual deployment.  Comcast or otherwise.

Anyone have any other thoughts?  And again, has anyone had any luck getting 6RD to work on any Cisco router, in a typical home NAT DHCP deployment, with Comcast?

Thx,

Greg

I have 6rd running on my Linux server through a Comcast Business Internet connection.  The first hop router, however, is a Cisco ASA.  I had to put in specific rules to permit protocol 41 to be passed through the ASA.  Depending on what device is performing the NAT in your network, it might not permit protocol 41 or perhaps not NAT it.  Additionally, you need to have some route(s) that point to the tunnel as the destination for your IPv6 traffic.

Here is an example of 6rd set up to use a DHCP address for the tunnel source:

ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0
interface Dialer0
ip address dhcp  ! (10.0.0.10)
!
interface Tunnel0
tunnel source Dialer0
tunnel mode ipv6ip 6rd
tunnel 6rd ipv4 prefix-len 8
tunnel 6rd prefix 2001:db80::/28
tunnel 6rd br
ipv6 address DELEGATED_PREFIX ::/128 anycast
!
interface Ethernet0
ipv6 address DELEGATED_PREFIX ::/64 eui-64
!
ipv6 route 2001:db80::/28 Tunnel0
ipv6 route ::/0 Tunnel0, 2001:db80:a000:0010::
ipv6 route 2001:db80:0:A00::/52 Null0

Note there is a caveat in IOS today where it would reject overlapping  IPv6 addresses as configured above, ie., a /128 on the tunnel and /64  on the LAN interface, with the %IPV6_ADDRESS-3-ADDRESS_CFG error.  The workaround is to remove the IPv6 address configuration from the  Tunnel interface and use the command ipv6 enable to have a  link-local ipv6 address assigned to the Tunnel.

Hi,

Yes your tunnel source interface should be pointing to your WAN interface.

Do you have the correct ipv6 static routes configured? With 6rd, you'd typically want to have a default route, as well as the 6rd connected network pointing to the tunnel interface. If you are running pings from behind the 6rd router, you could also enable egress netflow on the FastE4 interface to see if ip protocol 41 traffic is leaving the router (it will show up as protocol 29 in hex). That will give you some ideas on whether the problem is with this router, or somewhere further upstream.

Thanks,

Wen

glgersc
Level 1
Level 1

OK, the correct answer is that the tunnel interface should be linked to the outside interface, as Wen pointed out.  And as he also pointed out, it's time to actually look at the outside interface and see what's going on.  So, I rearranged some things, and have a sniffer on the outside interface.

The first thing I figured out is that I need to work on my ZFW rules/config.  But for testing, I've been disabling the ZFW config all along anyway, and it still didn't work.

The sniffer pointed out something really odd.

Here is the tunnel config:

interface Tunnel6
description Comcast 6RD IPv6 tunnel.
ip address 10.20.6.1 255.255.255.0
no ip redirects
ipv6 enable
tunnel source FastEthernet4
tunnel mode ipv6ip 6rd
tunnel 6rd prefix 2001:55C::/32
tunnel 6rd br 69.252.80.66
end

Notice the 6rd br address.  This is the IP for 6rd.comcast.net

And here is the output of the 'sho tun 6rd' command:
RouterA-new#sho tun 6rd tu6
Interface Tunnel6:
  Tunnel Source: 24.118.231.197
  6RD: Operational, V6 Prefix: 2001:55C::/32
       V4 Prefix, Length: 0, Value: 0.0.0.0
       V4 Suffix, Length: 0, Value: 0.0.0.0
       Border Relay address: 69.252.80.66
  General Prefix: 2001:55C:1876:E7C5::/64

The tunnel source and border relay address all show up properly configured.  And the prefix shows the proper hex conversion of the outside ipv4 address into the 3rd and 4th section of the ipv6 address.  (Hmm, what do you call an 'octet' in ipv6?)  So everything should be good.

But, this is what the sniffer shows leaving the outside interface:

  The ipv4 destination address is 128.15.0.0.   What the heck?

As Wen predicted, you can see that this is an 'ipv6 in v4' packet, on protocol 0x29 (41).  So the encapsulation is correct.  And the embedded ipv6 addresses and the rest of the ethernet and tcp protocol for this SYN packet are also correct.

So what is going on with the 128.15.0.0 destination address?  Where could it possibly be getting that IP from?

Anyone have any ideas?

Thx,

Greg

Hi, Greg:

Well 128.15.0.0 is 0x800f:0000 which is your ipv4 address after the 6rd prefix in your ipv6 destination address you are trying to get to . So it looks like the CE is treating this destination network as directly connected to 6rd. Could you send us your ipv6 routing table (show ipv6 route)?

Thanks,

Wen

glgersc
Level 1
Level 1

Wen, excellent observation.  And it is tracking for other destinations.  This is what I get when I ping other destinations:

2001:4860:8888::55          136.136.0.0

2001:4810::110                 (nothing)

2001:4860:8888:4444::55    136.136.68.68

As you noticed, in each case, the ipv4 tunnel destination is the 3rd and 4th 'octet' of the ipv6 destination.

This is the output of my 'sho ipv6 route':

RouterA-new#sho ipv6 route
IPv6 Routing Table - default - 5 entries

S   ::/0 [1/0]
     via Tunnel6, directly connected
S   2001:55C::/32 [1/0]
     via Tunnel6, directly connected
C   2001:55C:1876:E7C5::/64 [0/0]
     via Vlan1, directly connected
L   2001:55C:1876:E7C5:523D:E5FF:FE98:E0CE/128 [0/0]
     via Vlan1, receive
L   FF00::/8 [0/0]
     via Null0, receive

These are the actual static routes in the config:

ipv6 route 2001:55C::/32 Tunnel6
ipv6 route ::/0 Tunnel6

I'm confused how the ipv6 routes might be affecting the ipv4 destination tunnel address, but maybe that's just one of the ipv6 things I have yet to learn.

I was also a bit confused by the static ipv6 routes in the CE portion of this reference:

http://docwiki.cisco.com/wiki/6rd_Configuration_Example

...and didn't implement all of the examples.  So maybe I'm missing something there.

I'm also wondering if maybe the 'tunnel 6rd ipv4 prefix-len' command might have something to do with it.  The Comcast directions say to set the "IPv4 Mask Length =0".  So I left the 'tunnel 6rd ipv4 prefix-len' command at it's default 0 setting.  Could that be related?

Hi, Greg:

I think the problem is with your default v6 route - "ipv6 route ::/0 Tunnel6". You are basically telling the CE that everything is directly connected to the 6rd network, so it assumes whatever comes after the 6rd prefix is the embedded ipv4 address for the destination. Could you try to remove this line, and replace it with "ipv6 route ::/0 Tunnel6  2001:55C:45FC:5042::"? This should tell the CE to send everything else to the BR instead. Give it a try and see if that helps any.

You are correct that by not configuring "tunnel 6rd ipv4 prefix-len", it defaults to a prefix length of 0, which means the CE ipv4 addresses cannot be aggregated and therefore all 32 bits will be used. So with a 6rd prefix of 32 bits and 32 bits of ipv4, your delegated prefix is 64 bits (longest allowed by the 6rd spec), which implies you won't be able to subnet within that delegated prefix.

Hope this helps.

Thanks,

Wen

glgersc
Level 1
Level 1

Eureka!

Wen, I was hoping to get this posted before you replied.  I was feeling proud of myself that I finally figured out what you were referring to, and I had the fix before you posted it.  What was missing was the next hop on the default route.

ipv6 route ::/0 Tunnel6 2001:55C:45FC:5042::

That's the magic line that fixed it.  '45FC:5042' being the hex equivalent of the destination of the tunnel: 69.252.80.66   aka 6rd.comcast.net

This is the resulting routing table:

RouterA-new#sho ipv6 route
IPv6 Routing Table - default - 4 entries

S   ::/0 [1/0]
     via 2001:55C:45FC:5042::, Tunnel6
C   2001:55C:1876:E7C5::/64 [0/0]
     via Vlan1, directly connected
L   2001:55C:1876:E7C5:523D:E5FF:FE98:E0CE/128 [0/0]
     via Vlan1, receive
L   FF00::/8 [0/0]
     via Null0, receive

To get the fix, I also went back to the docwiki link are looked at the examples again.  There are some typos in there, like a comma in the route config, that were confusing.  And some of the addresses are wrong as well.  But, with Wen's tip, I finally figured out that the default ipv6 route to the tunnel needed a next hop, which was the far side of the tunnel.

I probably still have some tuning to do (MTU, etc.), and I still need to figure out how to get the zone based firewall rules to apply to the tunnel and the IPV6 traffic.  (No NAT for basic protection on ipv6.)  When I get a fully proven config, and I'm sure I've cleaned the cruft out, I'll post a complete config here.

Thanks to all who provided useful tips, especially Wen.

Hi, Greg:

I'm glad you figured it out .

I've removed the comma in the example config. If you can tell me which addresses in that configuration are still wrong, I can help correct those as well. Note the example uses a somewhat not-so-intuitive prefix combination (28 bit 6rd and 8 bit ipv4), so the addresses do look a little stange at first glance. The current configuration in that example is slightly different from what the original author had initially, and I may have missed a couple things when I corrected it to make the prefixes more consistent.

Also, there is currently a problem with ZBF interoperating with ipv6 tunnels in the classification engine. If you see traffic dropped from self to the outside zone for the ipv4 tunnel traffic, try disable CEF.

Thanks,

Wen

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: