IPv6 Deployment Series Part 8: Optimization

RYAN HARRIS | Sr. Network Engineer 

This blog post is part of a series detailing the various parts of planning and deploying IPv6 for enterprise networks. It is meant as a primer for the network engineer or architect to understand the various concepts they may be unaware of when developing their IPv6 production design.   

If you have not read the previous posts, I would highly recommend that you start at the beginning:    

• Part 1 – Hierarchical Subnetting Design   
• Part 2 – Routing Design   
• Part 3 – OSPFv3  
• Part 4 – Security  
• Part 5 – Transitional Client Addressing  
• Part 6 – SLAAC vs DHCPv6  
• Part 7 – Internet Connectivity 

Optimizing Neighbor Discovery 

Beyond the change to a much larger address space, one of the largest changes that came with IPv6 is the move from ARP and DHCP to ICMPv6. The move to ICMPv6 comes with a unique set of constraints. ARP is, generally speaking, an afterthought in most IPv4 networks with little to no regard for how it functions.  

By default, some routing platforms ignore unsolicited neighbor advertisements (NA). In contrast, unsolicited ARP messages are generally learned by all routers on a network segment. This behavior can be a problem with networks that are using first hop redundancy protocols such as HSRP and VRRP. Because the passive router in those networks ignores those unsolicited NAs, when a passive router becomes active, it can cause an influx of neighbor solicitation (NS) packets while the now active router builds it neighbor discovery cache. 

Cisco implements a change in this behavior with the command “ipv6 nd na glean” to allow for routers to learn from these unsolicited NAs. 

On large networks, managing the neighbor discovery cache can decrease CPU usage and reduce network overheads. By default, on Cisco routers, the reachability time of a neighbor in the neighbor discovery table is 30 seconds (represented as 30000 milliseconds). Increasing the reachability time of endpoints in the neighbor discovery table can increase the efficiency of the network. Cisco implements this change with the command “ipv6 nd reachable-time [milliseconds]”. I would recommend you increase the reachability time from the default of 30 seconds to 10 minutes with the command “ipv6 nd reachable-time 600000” when using a FHRP or if there’s only a single gateway on the subnet. 

Wireless 

On large wireless networks where there are hundreds of connected endpoints, every time a new device joins, it sends a router solicitation (RS) message to the all-routers multicast group. On some platforms, the router advertisement (RA) response to these requests is sent back using the all-nodes multicast group rather than as a unicast packet. As you can imagine, this can become quite chatty in a large environment and can even affect the ability for some devices to properly sleep, which could decrease battery life. 

There are a couple of solutions to resolve this issue. Cisco wireless controllers have the ability to implement an RA throttle policy which will place limits on the number of RA packets in a given period as well as convert solicited router advertisements from the all-nodes multicast group to a unicast packet for the endpoint that sent the router solicitation. You can refer to Cisco’s documentation on configuring RA throttle policies for the 9800 platform. 

The Cisco Nexus platform does not respond to RS packets with a multicast RA but rather implement a unicast response by default. However, the IOS-XE platforms do respond to the all-nodes multicast group, and you can change this behavior one of two ways: 

• ipv6 nd ra solicited unicast – changes the response to an RS packet to unicast 
• ipv6 nd ra suppress – Disables periodic RA transmission to the all-nodes multicast group 

First Hop Redundancy 

First hop redundancy protocols (FHRP) are protocols that allow for one or more routers to share a virtual IP address so that clients on a network segment can take an alternate path out of the network in the event of the primary default gateway losing connectivity. You might be familiar with this concept as implemented by the Hot Standby Routing Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP). 

As originally developed, these protocols use a virtual MAC address to respond to ARP requests for the IP address of the default gateway. In IPv6, these FHRPs use the ICMP ND protocol rather than ARP to respond to clients. 

HSRPv1 vs HSRPv2 

While the functionality of HSRPv1 and HSRPv2 is largely similar, there have been several changes to make the protocol a little more usable and correct a couple of issues present in the original protocol. 

HSRPv1 lacked the ability to advertise and learn timers. If the timers were configured differently between its peers, instability could occur. HSRPv2 introduces the ability to advertise and learn timers from a peer router, which should eliminate this configuration pitfall. 

HSRPv2 increases the number of group numbers from 256 possible choices to 4096. It’s common for network engineers to match the HSRP group number to the VLAN ID for configuration simplicity. However, this was an issue if using VLAN IDs higher than 255. 

HSRPv2 moves to a TLV (Type, Length, Value) format like we’ve seen in a few other protocols (IS-IS, OSPFv3, MP-BGP, etc.) to make the protocol more extensible for future changes. The perk of this is that in the future, if there’s ever a need to add support for a different protocol or adapt HSRP for different purposes, there’s no need to rewrite the protocol to adapt it to different protocols, but rather an update to the code to add support for the new TLV. 

In addition to the above changes, there are changes to the packet such as new 6-byte identifier field used to add a unique value (usually the interface MAC address) that can be used to identify the sending router. Additionally, the new multicast address avoids an overlap with the Cisco Group Management Protocol, although the actual value of this change is likely limited due to IGMP mostly supplanting CGMPs use. 

RouterA(config)#int f0/0 

RouterA(config-if)#standby version 2 

RouterA(config-if)#standby 1 ipv6 autoconfig 

RouterA(config-if)#standby 1 timers msec 300 1 

RouterA(config-if)#standby 1 priority 110 

RouterA(config-if)#standby 1 preempt 

RouterA(config-if)#^Z 

RouterA#show standby 

FastEthernet0/0 – Group 1 (version 2) 

  State is Active 

    2 state changes, last state change 00:07:46 

  Virtual IP address is FE80::5:73FF:FEA0:1 

  Active virtual MAC address is 0005.73a0.0001 

    Local virtual MAC address is 0005.73a0.0001 (v2 IPv6 default) 

  Hello time 300 msec, hold time 1 sec 

    Next hello sent in 0.212 secs 

  Preemption enabled 

  Active router is local 

  Standby router is unknown 

  Priority 110 (configured 110) 

  Group name is “hsrp-Fa0/0-1” (default) 

IPv6 Redirects  

The ICMP Redirect mechanism was meant to optimize forwarding of traffic in multi-point network segments, however with the evolution of higher data speeds and affordable ASIC based routing platforms, the needs for this optimization have decreased. 

The ICMP redirect message is intended to let a router on a network segment inform a host on the same network segment of a more optimal path out of the network. The ICMP redirect feature is enabled by default on most routing platforms, however, there are scenarios in which this functionality could negatively impact production traffic and control plane stability. 

ICMPv6 carried forward the redirect message from the legacy IPv4 protocol, and functionality remains the same. It’s recommended that redirects are disabled for both IPv4 and IPv6 networks. 

Disable IPv6 redirects with the command “no ipv6 redirects”. 

RouterA(config)#int f0/0 

RouterA(config-if)#no ipv6 redirects 

You can verify that redirects are disabled with the output below: 

RouterA#show ipv6 interface fastethernet0/0 

FastEthernet0/0 is up, line protocol is up 

  IPv6 is enabled, link-local address is FE80::C001:ABFF:FE0C:0 

  No Virtual link-local address(es): 

  Global unicast address(es): 

    2001:DB8:1:0:C001:ABFF:FE0C:0, subnet is 2001:DB8:1::/64 [EUI] 

  Joined group address(es): 

    FF02::1 

    FF02::2 

    FF02::1:FF0C:0 

  MTU is 1500 bytes 

  ICMP error messages limited to one every 100 milliseconds 

  ICMP redirects are disabled 

  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 200 seconds 

  ND router advertisements live for 1800 seconds 

  ND advertised default router preference is Medium 

  Hosts use stateless autoconfig for addresses. 

Unicast Reverse Path Forwarding 

Unicast Reverse Path Forwarding (uRPF for short) is a security and routing feature used to protect a network against forwarding traffic that may be incorrectly using an asynchronous path through the network or from a malicious host spoofing network traffic. 

The uRPF feature checks a packet’s source IP address and ingress interface against the routing table to determine if it was received from the correct interface. For example, if the source IP address of a packet received on interface GigabitEthernet0/1 is 2001:DB8::ABC, but the routing table is configured to forward the network 2001:DB8::/64 out interface GigabitEthernet0/2, the packet will be dropped. 

This logic is the same used for loop detection in multicast networks, applied to unicast routing. 

RouterA(config)#int f0/0 

RouterA(config-if)#ipv6 verify unicast source reachable-via rx allow-default