I'm in the early stages of dual-stack deployment on our cable network. At this stage of testing, there are only IPv6 static routes in place and no DHCPv6 server has been configured. So far subnetting and routing hasn't been too much trouble.
When I configure an IPv6 capable router and connect it to any D3.0 modem, connectivity is fine. I can ping out from any client autoconfigured by the router. From the CMTS, I can also ping the router's WAN IP and the aforementioned clients from the delegated prefix.
Everything seems to work except the cpe list of the respective cable modem never displays any IPv6 information. Cases where I statically assign v4 addressing to a CPE the IP address always registers with the modem and can be viewed by "show cable modem MAC cpe".
On the modem in question "show cable modem MAC ipv6 cpe" returns empty MAC address and IP address fields.
I've tested this on a SB6121 and Arris CM820 with latest firmware on both. Same results on each.
CMTS is a uBR 10k running SCE6
My bundle looks like so:
interface Bundle1
ip address SNIP secondary
ip address SNIP secondary
ip address SNIP
ip access-group cable_in in
cable arp filter request-send 3 2
cable arp filter reply-accept 3 2
cable source-verify
cable dhcp-giaddr policy
cable helper-address SNIP
ipv6 address XXXX:XXXX:CAB1:E::1/64
ipv6 enable
ipv6 nd prefix default no-advertise
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 nd ra interval 5
I have the following single route:
ipv6 route XXXX:XXXX:EA57:6900::/64 XXXX:XXXX:CAB1:E::8879
Must DHCPv6 come into play for proper IPv6 cpe pair identification?
Some config option CMTS or modem side I'm overlooking?
I've come across this information in the documentation:
Provisioning Restrictions for IPv6 on Cable
The following areas of IPv6 provisioning are not supported on the Cisco CMTS routers:
•Preregistration downstream service ID (DSID) notification
•Bonded-Downstream Channel Descriptor (B-DCD) messages
•Multiple DHCPv6 IPv6 addresses per CM or CPE
•Static IP address assignment for CPEs
•Stateless address auto-configuration (SLAAC) address assignment
--------------------------------------------------------------------------------
Note In Cisco IOS Release 12.2(33)SCC and later, static IPv6 addressing for CPE is supported using Source Address Verification (SAV). For more information about SAV, see the Source Address verification section in the DOCSIS 3.0 Security Specification guide.
Presently our plan is to hand out up to /56 delegations via DHCP. Under certain circumstances I'd like to allocate /48 networks or /56, /60, /64 outside of our DHCP prefixes without having to resort to reservations. Given the size of our subscriber base I'm comfortable supplying these network by way of static routes. Am I to understand that I must look into SAV to make this operate as I expect?
Update to the update:
This issue appears as an open caveat up through SCF3 with no listing in the resolved area. My only guess is that this is still not supported at this time.
Another update:
I came across the following Cisco caveat
CSCtq00940
The show cable modem ipv6 command output does not list static IPv6 CPEs.
description: This is observed when source address verification (SAV), IPv6
subinterface and bundle interface are configured. Note that SAV functionality works fine.
The doc also states:
1st Found-In
12.2SC
Fixed-In
12.2(32.8)SCF
I've since flashed and reloaded with SCF4 and implemented the following SAV in the global config
cable source-verify enable-sav-static
!
cable source-verify group STATIC-PREFIXES
prefix XXXX:XXXX:cab1:e::/64
prefix XXXX:XXXX:ea57:6900::/64
upon doing this the static IPv6 CPE is still not seen, though the addresses continue to route.
We have ran IPv6 for approx 2 years. Recently turned it off due to traffic levels increasing (eg YouTube) and we couldn't count it because Cisco has not implemented Netflow for IPv6 grrr. IPDR no use either as it lacks the ability to support unmetering of nominated sources.
Anyway, I can tell you that there have been heaps of IPv6 fixes / features added in each new IOS revision/train. I certainly wouldn't try running SCC, you would want to be on something pretty recent like SCF4 or SCG3.
From what I remember that IPv6 CPE output was busted even in the very latest IOS. We had asked Cisco about it, but never really got a good answer.
Apart from that though, things were working for us pretty well. We had ISC DHCPd setup to do the DHCPv6 including prefix delegations.
Thanks for the reply.
And I thought we were exceedingly late to begin public deployment. It looks like Cisco still has some work to do on the IPv6 side.
I think everyone is still working the bugs out of IPv6 - many of the recent firmware fixes in cable modems (regardless of manufacturer) have been fixes for IPv6 related issues.
So, I've refocused my efforts on getting DHCPv6 working.
Utilizing Network Registrar 8.1.2 the CPE's WAN gets assigned a /128 from a /64 pool and if requested, delegated up to a /56 in a best-fit manner from a /40 pool I allocated. "show MAC ipv6 cpe" populates the WAN IP successfully!
I am however running into an issue with the CPE never getting a default route/gateway. If I set one manually everything works fine.
I know this isn't a function of the DHCPv6 server and I'm having some trouble tracking down the communication issue between CPE and CMTS.
The lack of a default route is experienced on all types of CPEs I've tested (IPv6 capable home routers and Win7 clients). Even when connected to either Motorola and Arris D3 modems.
Any suggestions?
Wireshark shows I'm receiving neighbor solicitations for the link-local address of my cable bundle. I can even ping the link-local of the bundle from the CPE, but still a default route is never committed. I see no other NAs other than my CPE following a solicitation from the CMTS.
Could this be an issue with my DHCP setup? Does it make sense that if the full DHCP request isn't completing then the client won't assign the default gateway?
Edit: Working through this in my head...
I now see my clients are sending router solicitations, but the CMTS is not replying with router advertisements or something is preventing me from receiving them.
Hi, Cisco CMTS will never answer a Neighbor Solicitation (NS) with a Router Advertisement (RA) for Neighbor Discovery (ND). We talking here from a Unicast conversation. For Cisco and Arris CMTS you have to configure Multicast operation for RA. Then the CMTS will sends periodically RA. I will post you just the ND configuration from a CMTS how it works by us. This configuration has be done in the bundle interface:
configuration terminal
interface Bundle1
no cable nd
ipv6 address FE80::1 link-local
ipv6 enable
ipv6 nd prefix default no-advertise
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 nd ra interval 5
ipv6 nd ra lifetime 120
end
Here just a few comments:
ipv6 address FE80::1 link-local
We take as Link-Local fe80::1. This will help to find easily discovery the Link-Local-Address of the CMTS in the traceroutes. If you don't want this, then remove this line.
ipv6 nd prefix default no-advertise
In a DOCSIS environment DHCPv6 should be used and to prevent SLAAC on CM/CPE side you must remove Prefix Announcement of configured IPv6-Prefixes
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
Set the M and the O flag to force DHCPv6 operation behind the CMTS
So the differences between your configuration and my are the lines:
no cable nd
ipv6 nd ra lifetime 120
The no cable nd should be needed for the dhcpv6 source verify stuff..
Another hint: It could be possible that you have to restart the bundle/cable interfaces with shutdown/no shutdown... It's a long time ago since activating IPv6 on our CMTSes :)
2nd Hint: please show us the output from the command:
show ipv6 interface bundle 1
Herer is a example from a CMTS in our lab:
cmts-1#show ipv6 interface bundle 1
Bundle1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::1
No Virtual link-local address(es):
Description: "Bundle Interface"
Global unicast address(es):
2001:DB8::1, subnet is 2001:DB8::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 5 seconds
ND router advertisements live for 120 seconds
ND advertised default router preference is Medium
Hosts use DHCP to obtain routable addresses.
Hosts use DHCP to obtain other configuration.
Best regards,
wittmann
Thanks for your reply. Here's information from my bundle config, ipv6 int bundle and ND debug I ran.
I haven't tried a shut / no shut of the Bundle and will give that a go Monday morning.
interface Bundle1
ip address xxx.xxx.xxx.xxx 255.255.255.248 secondary
ip address xxx.xxx.xxx.xxx 255.255.255.248 secondary
ip address 172.16.0.1 255.255.128.0
cable arp filter request-send 3 2
cable arp filter reply-accept 3 2
cable source-verify
cable dhcp-giaddr policy
cable helper-address xxx.xxx.xxx.xxx
ipv6 address xxxx:xxxx:CAB1:E::1/64
ipv6 enable
ipv6 nd prefix default no-advertise
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 nd ra interval 5
ipv6 dhcp relay destination xxxx:xxxx:E01:1337::69
Lab-UBR#sh ipv6 int Bundle1
Bundle1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::6AEF:BDFF:FEF0:CMTS
No Virtual link-local address(es):
Global unicast address(es):
xxxx:xxxx:CAB1:E::1, subnet is xxxx:xxxx:CAB1:E::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FFF0:CMTS
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 5 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use DHCP to obtain routable addresses.
Hosts use DHCP to obtain other configuration.
From ND debug
Mar 8 21:38:31.342: ICMPv6-ND: Request to send RA for FE80::6AEF:BDFF:FEF0:CMTS
Mar 8 21:38:31.342: ICMPv6-ND: Sending RA from FE80::6AEF:BDFF:FEF0:CMTS to FF02::1 on Bundle1
Mar 8 21:38:31.342: ICMPv6-ND: Managed address configuration
Mar 8 21:38:31.342: ICMPv6-ND: Other stateful configuration
Mar 8 21:38:31.342: ICMPv6-ND: MTU = 1500
Mar 8 21:38:36.342: ICMPv6-ND: Request to send RA for FE80::6AEF:BDFF:FEF0:CMTS
Mar 8 21:38:36.342: ICMPv6-ND: Sending RA from FE80::6AEF:BDFF:FEF0:CMTS to FF02::1 on Bundle1
Mar 8 21:38:36.342: ICMPv6-ND: Managed address configuration
Mar 8 21:38:36.342: ICMPv6-ND: Other stateful configuration
Mar 8 21:38:36.342: ICMPv6-ND: MTU = 1500
Sample of periodic RAs being sent (captured in debug)
Mar 8 21:32:32.832: ICMPv6-ND: Request to send RA for FE80::6AEF:BDFF:FEF0:CMTS
Mar 8 21:32:32.832: ICMPv6-ND: Sending RA from FE80::6AEF:BDFF:FEF0:CMTS to FF02::1 on Bundle1
I activate
debug ipv6 nd
and in periodic times I see this output beside other NS-Stuff:
Mar 10 13:59:34: ICMPv6-ND: Sending RA from FE80::1 to FF02::1 on Bundle1
Mar 10 13:59:34: ICMPv6-ND: Managed address configuration
Mar 10 13:59:34: ICMPv6-ND: Other stateful configuration
Mar 10 13:59:34: ICMPv6-ND: MTU = 1500
Note the FE80::1 is different for your CMTS. Your debug seems identical.
So I guess Multicast RA on RF-Side should working.
Best regards,
wittmann
Do you know if the RAs could be filtered at the RF interface or by the cable modem? I'm not aware of anything I have set that could be doing this.
It looks like the bundle is generating the RAs, I just need to figure out why the CPE never sees/detects them.
Normaly the Multicast RA goes through every D3.0 CM by default. It's possible to deny any IPv6-Traffic via Ethertype in the LLC-Filter located in the config file of the CM. But this is not done by default. I hope you have no configuration in the config file from your cable modems ;)
By D2.0 CM without IPv6 Support no Multicast traffic will go from RF to CMCI/CPE side (known by Multicast MAC Addresses) by default.
But our latest information is, that you use D3.0 cable modem. So Multicast RA from CMTS should arrive your CPE. The destination for this Multicast RA is the Multicast All Nodes Address: FF02::1
On other CMTS you have also to activate Multicast DSID Forwarding but on Cisco CMTS this is on by default.
Best regards,
wittmann
It was suggested to me that this could be a limitation of the PRE2's we have installed. We're not due to upgrade to PRE4's until early Fall, so I'll try rolling back IOS versions to see if that makes a difference.
Ok, this makes sense. We never have IPv6 tried with PRE2. We upgrade first all our D3.0/IPv6 CMTS to PRE4 because first on PRE4 the forwarding of IPv6 is done in hardware.
Best regards,
wittmann