There are a lot of ways to reduce or optimize control plane traffic overhead, which can be especially useful on big platforms or aggregation devices. 2 configurations I almost had experience using were HSRP MGO and IP helper redundancy.
Multi Group Optimization is an HSRP feature where you select a master interface and bind "slave" (follow) interfaces onto it. The following interfaces will use the same state (Active/Standby) as the master and will not be exchanging any hello packets. A short Cisco documentation
The mistake: Believing what is configurable on a Cisco router will also work.
Months ago we had a C4500 (fixed 1U) platform hosting a high amount of SVI gateways (about 1300). All these interfaces were in HSRP groups and using the default 3 10 timers, which the C4500 isn't made to handle. The CPU usage was topping from the shear amount of HSRP control plane traffic. To improve the situation we had some C6840 ready to put up and also use the HSRP Follow feature to reduce the control traffic. I configure the new HSRP for the SVI, put it up in a lab to test and it doesn't work. The SVI accepts the configuration, but also warns that "hsrp named group is on a different major interface". Turns out that, despite being configurable on other kind of interfaces, the follow feature is basically only made for subinterfaces. A major interface is an SVI and a physical interface, which makes a minor interface a subinterface. Cisco's documentation even uses different physical interfaces in their examples, but their support team (which I was communicating with during this) stated:
The HSRP "follow" feature will only work on dot1q sub-interfaces associated with the same parent physical interface
They also explained there were some technicalities and there'd be a chance for incompabitble behaviour, if using it between physical interfaces was allowed. However, since 2013 they had been working on a solution for VRRP.
The short ending is that we don't use the follow feature, because we don't have a L2 segment on this paltform for subinterfaces to work with HSRP across. We increased the timers for HSRP to get less CPU usage, having the most important networks with the lowest timer. Hopefully we'll figure out a proper solution.
What has been learned: How important a lab environment is. This could easily have been rushed through and we'd stand there with the 6840 running, but it'd never work, simply because the configuration was available on the interfaces.
IP Helper Redundancy
This feature blends nicely with HSRP Follow, as it uses the same HSRP master interface to decide which is the "active" IP helper. The issue is, when there are 2 interfaces with IP helper and both forward DHCP requests. Most DHCP servers should be able to handle this, but our issue is double logging. It's annoying, takes up log space and our DHCP doesn't have an inherent way to filter duplicate requests.
The mistake: not being up to date with IOS releases when buying equipment. Turns out the redundancy feature was removed from IOS 15 in one of the early releases. It's an aggregation feature and it's probably Cisco's intention to push those kind of features onto the ASR, where the feature is available.
What has been learned: Read and understand Cisco's documentation..