DHCPv6 IA_PD relaying works with 12.2SRE2

Monday, December 13, 2010 06:45 +0100

DHCPv6 IA_PD relaying works with 12.2SRE2

Last week I ran numerous lab tests while preparing router configurations for the Building IPv6 Service Provider Core webinar. One of the fantastic test results: DHCPv6 relaying works correctly on a 7200 running 12.2(33)SRE2, even when the client requests IA_PD option.

Some of the limitations I’ve described in the “DHCPv6 relaying: another trouble spot?” remain (PE router reload is still an issue and you cannot retain DHCPv6 relay bindings when a PPPoE session is disconnected because the associated virtual interface is deleted), but I would say Cisco got as far as they can within the current technological (DHCPv6) and architectural (virtual access interfaces) constraints.

After enabling DHCPv6 relay debugging on the PE-router, you can see relayed requests and static routes installed after the response from the DHCP server carrying IA_PD option is relayed back to the client:

PE-A#debug ipv6 dhcp relay 
   IPv6 DHCP relay debugging is on
PE-A#
IPv6 DHCP_RELAY: Relaying SOLICIT from FE80::C802:8FF:FEA7:6 on
  FastEthernet0/0.200
IPv6 DHCP_RELAY: Packet forwarded to FEC0::CCCC:4
IPv6 DHCP_RELAY: Relaying RELAY-REPLY from FEC0:1:1:13::2 on 
  Serial1/0
IPv6 DHCP_RELAY: Packet forwarded to FE80::C802:8FF:FEA7:6 via 
  FastEthernet0/0.200
PE-A#
IPv6 DHCP_RELAY: Relaying REQUEST from FE80::C802:8FF:FEA7:6 on 
  FastEthernet0/0.200
IPv6 DHCP_RELAY: Packet forwarded to FEC0::CCCC:4
IPv6 DHCP_RELAY: Relaying RELAY-REPLY from FEC0:1:1:13::2 on 
  Serial1/0
IPv6 DHCP_RELAY: Route added: FEC0:1:2310::/56 via 
  FE80::C802:8FF:FEA7:6 dist 1 iaid 00080001 lifetime 2592000
IPv6 DHCP_RELAY: Packet forwarded to FE80::C802:8FF:FEA7:6 via 
  FastEthernet0/0.200

You can inspect the relayed bindings stored by the PE-router with the show ipv6 dhcp relay binding command and the associated static routes with the show ipv6 route interface name command:

PE-A#show ipv6 dhcp relay bind
Prefix: FEC0:1:2310::/56 (FastEthernet0/0.200)
  DUID: 00030001CA0208A70008
  IAID: 524289
  lifetime: 2592000
  expiration: 12:27:39 UTC Jan 10 2011
PE-A#show ipv6 route int fa0/0.200
[ ... standard header ... ]
C   FEC0:1:2301::/64 [0/0]
     via FastEthernet0/0.200, directly connected
L   FEC0:1:2301::1/128 [0/0]
     via FastEthernet0/0.200, receive
S   FEC0:1:2310::/56 [1/0]
     via FE80::C802:8FF:FEA7:6, FastEthernet0/0.200

But wait, it gets better: even if the interface goes down, the relay bindings are retained until they expire ... and the static routes to the delegated prefixes get reinstated once the interface state changes to up. It can’t get any better than that, can it?

%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, 
  changed state to down
IPv6 DHCP_RELAY: Static route removed: FEC0:1:2310::/56 
  via FE80::C802:8FF:FEA7:6
PE-A#
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, 
  changed state to up
IPv6 DHCP_RELAY: Static route added: FEC0:1:2310::/56 via 
  FE80::C802:8FF:FEA7:6

Recent posts in the same categories

DHCP

IPv6

workshop

6 comments:

plapukhov 13 December 2010 17:16

Hey, wait a sec, FEC0:: ? Hasn't this range been deprecated like 6 years ago? :-D

Ivan Pepelnjak 13 December 2010 17:20

Adapting to change is hard for the sclerotic old-timers, more so if they have to live in damp towers ... :-P

Pelle 14 December 2010 09:23

Most of this works fine on SRD4 as well. The only exception[0] (AFAICS) is that the command "show ipv6 dhcp relay bindings" doesn't exist.

SRD4#sh ver
Cisco IOS Software, 7200 Software (C7200P-ADVIPSERVICESK9-M), Version 12.2(33)SRD4, RELEASE SOFTWARE (fc2)

SRD4#sh run int gi0/2.601
interface GigabitEthernet0/2.601
encapsulation dot1Q 601
ipv6 address FD00:8C0:4701:601::1/64
ipv6 enable
ipv6 mtu 1500
ipv6 dhcp relay destination FD00:8C0:199::199
end

SRD4#debug ipv6 dhcp relay
IPv6 DHCP relay debugging is on

SRD4#
Dec 14 08:50:55.194: IPv6 DHCP_RELAY: Relaying SOLICIT from FD00:8C0:4701:601::30 on GigabitEthernet0/2.601
Dec 14 08:50:55.194: IPv6 DHCP_RELAY: Packet forwarded to FD00:8C0:199::199
Dec 14 08:50:55.194: IPv6 DHCP_RELAY: Relaying RELAY-REPLY from FD00:8C0:1::20 on GigabitEthernet0/1
Dec 14 08:50:55.194: IPv6 DHCP_RELAY: Packet forwarded to FD00:8C0:4701:601::30 via GigabitEthernet0/2.601
Dec 14 08:50:56.370: IPv6 DHCP_RELAY: Relaying REQUEST from FD00:8C0:4701:601::30 on GigabitEthernet0/2.601
Dec 14 08:50:56.370: IPv6 DHCP_RELAY: Packet forwarded to FD00:8C0:199::199
Dec 14 08:50:56.370: IPv6 DHCP_RELAY: Relaying RELAY-REPLY from FD00:8C0:1::20 on GigabitEthernet0/1
Dec 14 08:50:56.370: IPv6 DHCP_RELAY: Route added: FD00:8C0:474F::/56 via FD00:8C0:4701:601::30 dist 1 iaid 000A0001 lifetime 43200
Dec 14 08:50:56.370: IPv6 DHCP_RELAY: Packet forwarded to FD00:8C0:4701:601::30 via GigabitEthernet0/2.601

SRD4#sh ipv6 dhcp ?
binding DHCP bindings
database DHCP binding database
interface DHCPv6 interface information
pool DHCPv6 pool statistics
| Output modifiers
<cr>

SRD4#sh ipv6 dhcp binding
SRD4#

SRD4#show ipv6 route interface gi0/2.601
S FD00:8C0:2100::3:30/128 [1/0], tag 26000
via FD00:8C0:4701:601::30, GigabitEthernet0/2.601
C FD00:8C0:4701:601::/64 [0/0]
via GigabitEthernet0/2.601, directly connected
L FD00:8C0:4701:601::1/128 [0/0]
via GigabitEthernet0/2.601, receive
S FD00:8C0:474F::/56 [1/0]
via FD00:8C0:4701:601::30, GigabitEthernet0/2.601

Dec 14 08:58:20.536: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
Dec 14 08:58:20.536: IPv6 DHCP_RELAY: Static route removed: FD00:8C0:474F::/56 via FD00:8C0:4701:601::30
Dec 14 08:58:31.885: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
Dec 14 08:58:32.885: IPv6 DHCP_RELAY: Static route added: FD00:8C0:474F::/56 via FD00:8C0:4701:601::30

SRD4#ping FD00:8C0:474F:1:219:AAFF:FE85:9980
Sending 5, 100-byte ICMP Echos to FD00:8C0:474F:1:219:AAFF:FE85:9980, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
SRD4#

[0] You are using link-local addresses on the PE-CE link. Unfortunately my dhcp-server (ISC 4.1.1) doesn't support that (at least I haven't been able to configure it).
</cr>

Frank Bulk 14 December 2010 15:20

I labbed this last week Wednesday on a 7609 with an RSP720C and 67xx line cards (no ES+ or ES20) using the Advanced IP Services feature set and got identical results.

Frank

Frank Bulk 16 December 2010 00:51

It appears I may need to take back what I said. When I performed my test, I had not replicated my existing environment.

This works:
interface GigabitEthernet8/1
description Testing IPv6 CPE
no ip address
ipv6 address 2607:FE28:1000::1/56
ipv6 enable
ipv6 nd managed-config-flag
ipv6 dhcp relay destination 2607:FE28:0:1000::7
end

This doesn’t:
interface Vlan99
no ip address
ipv6 address 2607:FE28:1000::1/56
ipv6 enable
ipv6 nd managed-config-flag
ipv6 dhcp relay destination 2607:FE28:0:1000::7
ipv6 dhcp relay source-interface Vlan99
end

interface GigabitEthernet8/1
description Testing IPv6 CPE
switchport
switchport access vlan 99
switchport mode access
end

“debug ipv6 dhcp” and “debug ipv6 dhcp relay” doesn’t show anything using the SVI approach.

If anyone has any ideas why, let me know.

Frank Bulk 28 January 2011 16:55

Six weeks after the case was opened with Cisco, the bug that was opened earlier this week on my issue was closed.

The short of it is that "ipv6 multicast-routing" needs to be enabled in order for DHCPv6-relay to operate on a SVI.

From Cisco's mouth:
Since IPv6 SOLICIT packets are multicast packets, when it arrives on a routed port it is
forwarded to the RP because of the Flood index set.
But the same is not true for SVI interface since this can lead to potential DoS attack if all
the flood index packets are sent to RP , this will kill the RP.
So when we enable IPv6 multicast, the router is added as a mrouter port and hence the
SOLICIT message reaches the RP.

I've asked that the Cisco documentation on DHCPv6 relay be updated to reflect this information.

Frank

Add comment