Knowledge Search


×
 

[EX/MX] Route learned from external BGP overwrites existing aggregate route and prevents IGP from exporting it

  [KB34709] Show Article Properties


Summary:

This article describes a pitfall for IGP routing with aggregate route whose preference is modified.

Putting higher preference value to aggregate route could make unexpected route overwrite happen in case aggregate route is configured on the router connecting to AS external router which is usually not under control.
Symptoms:

In this scenario, OSPF is used for IGP routing and aggregate route is configured on the router which has external BGP session.

R1 and R2/R4 are your routers. R3 is peering router, so it's not controllable. R2/R4 can learn specific routes via BGP, but R1 receives only short prefix route. Then R2/R4 has aggregate discard route with preference 254.

Example topology:
+------------------------+
|            R3          |
|         3.3.3.3        |
+----+--------------+----+
     |              |
     |bgp           |bgp
     |              |
+----+----+    +----+----+  ^
|    R2   |    |    R4   |  |
| 2.2.2.2 +----+ 4.4.4.4 |  + aggregate discard
+----+----+    +----+----+    1/8, 2/8. 3/8...
     |              |
     |ospf          |ospf   <-- export aggregate
     |              |
+----+--------------+----+
|            R1          |
|         1.1.1.1        |
+------------------------+

Initial state, R1 can communicate with R3.

lab@R1> ping 3.3.3.3 source 1.1.1.1 rapid
Jun 17 20:53:52
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!!!
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.512/5.599/14.257/4.403 ms

lab@R1> show route table inet.0 match-prefix */8         
inet.0: 18 destinations, 19 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.0.0/8          *[OSPF/150] 00:04:53, metric 0, tag 4444
                    > to 192.168.1.2 via ge-0/0/1.0
2.0.0.0/8          *[OSPF/150] 00:04:53, metric 0, tag 4444
                    > to 192.168.1.2 via ge-0/0/1.0
3.0.0.0/8          *[OSPF/150] 00:01:16, metric 0, tag 2222
                    > to 192.168.1.2 via ge-0/0/1.0

At this condition, if R3 mistakenly leaks same prefix route into R2/R4, R1's route abruptly disappears.

lab@R1> show route table inet.0 match-prefix */8              
inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.0.0/8          *[OSPF/150] 00:06:01, metric 0, tag 4444
                    > to 192.168.1.2 via ge-0/0/1.0
2.0.0.0/8          *[OSPF/150] 00:06:01, metric 0, tag 4444
                    > to 192.168.1.2 via ge-0/0/1.0

lab@R1> show route table inet.0 3/8 extensive   
lab@R1>

lab@R1> ping 3.3.3.3 source 1.1.1.1 rapid
Jun 17 20:54:34
PING 3.3.3.3 (3.3.3.3): 56 data bytes
ping: sendto: No route to host
.ping: sendto: No route to host
.ping: sendto: No route to host
.ping: sendto: No route to host
.ping: sendto: No route to host
.
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

The log is seen if traceoptions is configured. But it's on either R2 or R4.

lab@R4> show log ospf.log | match "Jun 17 20:54:2"
Jun 17 20:54:25.168546 LSA Extern 3.0.0.0 2.2.2.2 flood state Idle -> Idle, new LSA
Jun 17 20:54:25.168657 OSPF LSA Extern 3.0.0.0 2.2.2.2 from 192.168.0.2, LSA changed from its last instance
Jun 17 20:54:25.168665 LSA Extern 3.0.0.0 2.2.2.2 flood state Idle -> Standby send, flooding
Jun 17 20:54:25.168673 Updating LSA Extern 3.0.0.0 2.2.2.2 (flood state Standby send)
Jun 17 20:54:25.168789 LSA Extern 3.0.0.0 2.2.2.2 flood state Standby send -> Wait nbr ack, not queued
Jun 17 20:54:25.168792 OSPF flooding restarted, depth 1, rexmit 0
Jun 17 20:54:25.168827 OSPF LSA Extern 3.0.0.0 2.2.2.2 on no ge-0/0/0.0 area 0.0.0.0 rexmit lists, no flood
Jun 17 20:54:25.168835 OSPF LSA Extern 3.0.0.0 2.2.2.2 flooding on ge-0/0/2.0 area 0.0.0.0: HIGH prio
Jun 17 20:54:25.168861 OSPF LSA Extern 3.0.0.0 2.2.2.2 FLOODED on ge-0/0/2.0 area 0.0.0.0
Jun 17 20:54:25.170773 LSA Extern 3.0.0.0 2.2.2.2 flood state Wait nbr ack -> Idle, not queued
Jun 17 20:54:25.376713 CHANGE   3.0.0.0/8           nhid 576 gw 192.168.4.3     BGP      pref 170/-101 metric  ge-0/0/4.0 <Active Ext>  as 65001
Jun 17 20:54:25.376764 CHANGE   3.0.0.0/8           nhid 618 gw 192.168.0.2     OSPF     pref 150/0 metric 0/0 ge-0/0/0.0 <Delete Int Ext>
Jun 17 20:54:25.376928 rt_close: 1/1 route proto OSPF from
Jun 17 20:54:25.376928
Jun 17 20:54:25.377354 Starting flash processing for topology default
Jun 17 20:54:25.377393 Finished flash processing for topology default

R4 shows below. BGP is preferred but no export policy is configured via BGP. This is the cause.

lab@R4> show route table inet.0 match-prefix */8
inet.0: 21 destinations, 23 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.0.0/8          *[Aggregate/254] 00:08:23
                      Discard
2.0.0.0/8          *[Aggregate/254] 00:08:23
                      Discard
3.0.0.0/8          *[BGP/170] 00:01:13, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 192.168.4.3 via ge-0/0/4.0
                    [Aggregate/254] 00:08:23
                      Discard

Solution:

This issue comes from inappropriate configuration. Avoid this issue by setting the correct policies. The easiest workaround is to set the preference of aggregate route prior to BGP 170.

lab@R4# set routing-options aggregate route 3.0.0.0/8 preference 169

lab@R4> show route table inet.0 match-prefix */8                    
inet.0: 21 destinations, 23 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.0.0/8          *[Aggregate/254] 00:15:58
                      Discard
2.0.0.0/8          *[Aggregate/254] 00:15:58
                      Discard
3.0.0.0/8          *[Aggregate/169] 00:00:12
                      Discard
                    [BGP/170] 00:03:40, localpref 100
                      AS path: 65001 I, validation-state: unverified
                    > to 192.168.4.3 via ge-0/0/4.0

lab@R1> ping 3.3.3.3 source 1.1.1.1 rapid                     
Jun 17 21:04:13
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!!!
--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.953/3.735/5.644/0.972 ms

Related Links: