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 (register here or buy a recording). 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

6 comments:

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

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

    ReplyDelete
  3. 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>

    ReplyDelete
  4. 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

    ReplyDelete
  5. 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.

    ReplyDelete
  6. 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

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.