This article describes a scenario in which an aggregate route in the vrf routing-instance may flap when contributing routes from the remote PE device flap, resulting in a service impact.
The article also provides a workaround to avoid the flaps.
Setup Topology

Setup Details for Above Topology
-
R1, R2, R3, R4, R5, and R6 are MPLS Provider Edge (PE)/core routers that simulate an ISP network.
-
R1-CE, CE1, and CE2 are L3VPN Customer Edge (CE) devices.
-
R1, R4, and R6 are in the same vrf instance, which is called test.
-
CE1 and CE2 are sending the same set of prefixes to their directly connected PEs (R4 and R6, respectively).
-
R4 and R6 send the prefixes in inet-vpn through the BGP Route Reflector to R1.
-
R1 receives the prefixes from the bgp.l3vpn.0 table and installs them into the test.inet.0
VRF table.
-
R1 aggregates the routes into 100.0.0.0/24 and sends the aggregate route to R1-CE through BGP.
Related Output
Route aggregation on R1
R1#set routing-instances test routing-options aggregate route 100.0.0.0/24
Routes in R1
R1>show route 100.0.0.0/24 table test |match bgp
test.inet.0: 13 destinations, 43 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.0.0.0/24 *[Aggregate/130] 11:19:46
Reject
100.0.0.2/32 *[BGP/170] 11:23:15, localpref 100, from 2.2.2.2
[BGP/170] 11:23:15, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.3/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.4/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.5/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.6/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.7/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.8/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.9/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
100.0.0.10/32 *[BGP/170] 11:27:05, localpref 100, from 2.2.2.2
[BGP/170] 11:27:05, localpref 100, from 3.3.3.3
[BGP/170] 11:27:03, localpref 100, from 2.2.2.2
[BGP/170] 11:27:03, localpref 100, from 3.3.3.3
Simulating contributing route flap
CE1#set routing-options static route 100.0.0.5/32 reject
#commit
CE2#set routing-options static route 100.0.0.5/32 reject
#commit
CE1#delete routing-options static route 100.0.0.5/32 reject
CE1#commit
CE2#delete routing-options static route 100.0.0.5/32 reject
CE2#commit
Aggregate route age refresh
R1>show route protocol aggregate
test.inet.0: 12 destinations, 41 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.0.0.0/24 *[Aggregate/130] 00:00:24
Reject
(From R1 BGP traceoption) R1 sending BGP update/refresh to R1-CE
Sep 4 12:11:21.347830 BGP SEND 100.0.0.5/32
Sep 4 12:11:21.350654 BGP SEND 100.0.0.0/24
Route flap seen on R1-CE, which causes a service impact
R1-CE>show route 100.0.0.0/24 exact
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.0.0.0/24 *[BGP/170] 00:00:01, localpref 100
AS path: 65000 {65001 65002} I, validation-state: unverified
> to 19.0.0.1 via lt-0/0/0.91
When resolving contributing routes from a different table, if contributing routes flap even as other valid contributing routes exist, the aggregate route flaps.
If the aggregate route flaps when being exported into other protocols such as BGP/OSPF, the protocols also flap and cause a service impact.
PR1457955 tracks this problem.
Meanwhile, to work around the issue, perform route aggregation on the first PE itself. In our example, R4 and R6 will aggregate the prefixes to 100.0.0.0/24 and send it to R1.
- Aggregate the route on R4 and R6:
R4#set routing-instances test routing-options aggregate route 100.0.0.0/24
R6#set routing-instances test routing-options aggregate route 100.0.0.0/24
-
By modifying the vrf-export policy, R4 and R6 send the aggregated route 100.0.0.0/24 to R1 via BGP:
R4>show route advertising-protocol bgp 2.2.2.2
test.inet.0: 9 destinations, 22 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.0.0.0/24 Self 100 65002 I
R6>show route advertising-protocol bgp 2.2.2.2
test.inet.0: 9 destinations, 22 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.0.0.0/24 Self 100 65002 I
-
R1 receives 100.0.0.0/24 as the BGP route from bgp.l3vpn.0 and installs in the test.inet.0 table:
R1>show route 100.0.0.0/24 table test |match bgp
test.inet.0: 13 destinations, 43 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.0.0.0/24 *[BGP/170] 21:23:15, localpref 100, from 2.2.2.2
[BGP/170] 21:23:15, localpref 100, from 3.3.3.3
[BGP/170] 21:27:03, localpref 100, from 2.2.2.2
[BGP/170] 21:27:03, localpref 100, from 3.3.3.3
Note: Performing the same steps to flap contributing routes on CE1 and CE2 does not cause any impact on R1 and R1-CE.