Symptom
When you apply "ipv4 bgp policy propagation input qos-group destination" to the interface that is receiving incoming dhcp packets it breaks dhcp relay.
We stop seeing matches on the lpts entry for the dhcp packets and the packets are not properly punted to the RSP for dhcp relay packet processing.
If there is not a input service-policy applied to the interface then the issue is not seen.
For QPPB + QOS policy with QOS group, the packet has to do a loopback though the np
And we add a loopback header to the packet with some qppb information.
If the lpts hit or ifib punt happens after the loopback then the loopback
header is not taken into account in software and this causes packet to be dropped.
Conditions
This is seen only on trident based linecards on interfaces where dhcp relay and qppb are both configured. The issue is not seen when dhcp relay and qppb are configured on the ingress interface but there is not a input service policy applied to the interface.
Workaround
To work around, the packet has to be punted before the loopback.
In this case, we can ask customer to add to have source ip-precedence in qppb
ipv4 bgp policy propagation input ip-precedence source qos-group destination
When we have source ip-prec, we are suppose to take ip-prec from source prefix and
update the packet ip-prec. But if the customer doesn't have any BGP table policy
for all the packets coming, this will zero the ip-prec value in the packets.
How this fixes the problem, when we have source qppb configured, we check if the
Packet is BOOTP (dhcp packets) then we don't apply the QPPB/loopback. Since loopback is not
there the dhcp packet gets punted/lpts hit happens.
Another workaround :
Configure uRPF under the interface
ipv4 verify unicast source reachable-via any
This also, checks if packet is BOOTP then it doesn't loopback the packet.
