User might experience the traffic drop on these routes.
Before policy statement change.
root@lab-router> show route 2.2.2.0/25
inet.0: 76 destinations, 98 routes (76 active, 0 holddown, 0 hidden)
Limit/Threshold: 2000000/1700000 destinations
+ = Active Route, - = Last Active, * = Both
2.2.2.0/25 *[BGP/170] 00:16:39, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 2.1.4.2 via forwarding-nexthop of type List with 4 gateway
> to 2.1.4.3 via forwarding-nexthop of type List with 4 gateway
> to 2.1.4.4 via forwarding-nexthop of type List with 4 gateway
> to 2.1.4.5 via forwarding-nexthop of type List with 4 gateway
After policy statement change on DUT.
Inet.0: 76 destinations, 98 routes (76 active, 0 holddown, 0 hidden)
20.20.20.0/25 *[BGP/170] 00:00:57, localpref 100, from 1.1.1.1<<<<<< Route age got refreshed for this prefix.
•If rib-group leak import policy for static routes gets added/deleted/changed or refreshed (w/o change), RPD evaluates or re-evaluates this policy and flashes all static routes (in primary and secondary rib).
•DTM observes “inet.0” table for any forwarding route update notification. When any update flashes from inet.0 to DTM, DTM will consider the following event.
1.Forwarding route add
2.Forwarding route change
3.Forwarding route deleted
•DTM do the forwarding route eligibility check for received flashed route.
•DTM module is handling this flash event incorrectly when route is having “discard” nexthop. This route is considered as “Forwarding route deleted” via DTM. Further DTM schedules a route update job and initiate the tunnel migration. In this process DTM go for tunnel recreation which cause tunnel to flap.
•
•Due to tunnel flap all dependent service routes structure recreated which cause service routes also to flap and traffic drops.
Workarround:
Exclude static discard route (1.1.1.1/32) that is used as PNH for BGP Service prefixes with Dynamic IPIP Tunnel Attributes from conditional policy.
For example: to have "then next-policy" term for 1.1.1.132 before the term with the condition.
As a best practice, we recommend to keep the number of dependent routes for conditions as low as possible.