Conditional default route advertising
A default route is helping you to send packets to a device when you don’t have specific routing information about the destination of the packets hoping that the device will know how to route the packets to the destination.
But it’s not always true. The device advertising the default route might not know how to route further the packets black-holing the traffic.
Let’s see what do I mean and you can overcome the problem.
Let’s discuss on a specific example using this diagram:
R1 is receiving the default route through OSPF from R2 and it’s expecting that R2 will know what to do with the packets further and route them properly to the next hop.
R2 will then forward the packets to the ISP router.
To keep this simple, R1 will use the default route to reach the Internet(we will use 1.1.1.6 to simulate the Internet):
[edit] root@r1# run show route 1.1.1.6 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:19:27, metric 0, tag 0 > to 10.10.0.2 via ge-0/0/1.0 [edit] root@r1# run ping 1.1.1.6 count 2 PING 1.1.1.6 (1.1.1.6): 56 data bytes 64 bytes from 1.1.1.6: icmp_seq=0 ttl=63 time=11.712 ms 64 bytes from 1.1.1.6: icmp_seq=1 ttl=63 time=20.410 ms --- 1.1.1.6 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 11.712/16.061/20.410/4.349 ms [edit] root@r1#
R2 has the 1.1.1.6/32 route through BGP:
[edit] root@r2# run show route 1.1.1.6 inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1.1.1.6/32 *[BGP/170] 00:16:44, localpref 100 AS path: 200 I, validation-state: unverified > to 10.10.6.6 via ge-0/0/3.0 [edit] root@r2#
R2 is exporting the default route in OSPF through a policy matching the aggregate route created:
[edit] root@r2# show protocols ospf export def-ospf; area 0.0.0.0 { interface lo0.0; interface ge-0/0/1.0; } [edit] root@r2# show policy-options policy-statement def-ospf term 1 { from { route-filter 0.0.0.0/0 exact; } then accept; } term 2 { then reject; } [edit] root@r2# show routing-options aggregate { route 0.0.0.0/0; } autonomous-system 100; [edit] root@r2#
This is the 0.0.0.0/0 route that is always present on R2:
[edit] root@r2# run show route 0.0.0.0 extensive | find Contributing Contributing Routes (6): 1.1.1.2/32 proto Direct 10.10.0.0/24 proto Direct 10.10.5.0/24 proto Direct 10.10.6.0/24 proto Direct 1.1.1.1/32 proto OSPF 1.1.1.6/32 proto BGP [edit] root@r2#
The problem with this design is that R2 will always generate the default route, even when it will be able to reach the Internet. If the BGP session with the ISP router will go down, the R2 will not have a route to 1.1.1.6, but R1 will still believe that R2 can route the packets to the Internet.
After BGP protocol was deactivated on R6, the BGP session on R2 shows as “Active” and R1 still believes that R2 can route the packets to the Internet:
[edit] root@r2# run show bgp summary Groups: 1 Peers: 1 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.10.6.6 200 74 74 0 1 4 Active [edit] root@r2#
There is no reachability between R1 and R6:
[edit] root@r1# run show route 1.1.1.6 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:30:42, metric 0, tag 0 > to 10.10.0.2 via ge-0/0/1.0 [edit] root@r1# run ping 1.1.1.6 count 2 PING 1.1.1.6 (1.1.1.6): 56 data bytes 36 bytes from 10.10.0.2: Destination Net Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 a970 0 0000 40 01 c527 10.10.0.1 1.1.1.6 36 bytes from 10.10.0.2: Destination Net Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 a973 0 0000 40 01 c524 10.10.0.1 1.1.1.6 ^C --- 1.1.1.6 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss [edit] root@r1#
The fix for this problem would be obviously to conditionally generate a default route in OSPF. If R2 can no longer reach the Internet destination, then there is no point of generating the default route.
The conditional default route advertising can be done using generated routes and this is how the configuration on R2 should look like this.
The generated routes are active only when there are one or more contributing routes.
This is the generated route to which the conditional policy “default-route” is attached:
[edit] root@r2# show routing-options generate { route 0.0.0.0/0 policy default-route; } autonomous-system 100; [edit] root@r2#
The attached policy makes sure that the route will be generated if the policy is true.
And this is the content of the conditional policy:
[edit] root@r2# show policy-options policy-statement default-route term 1 { from { protocol bgp; neighbor 10.10.6.6; } then accept; } term 2 { then reject; } [edit] root@r2#
The generated route will be created only if neighbor 10.10.6.6(ISP router) will be up. So let’s make a test. R2 has a BGP session with ISP router:
[edit] root@r2# run show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.10.6.6 200 12 12 0 2 3:49 1/1/1/0 0/0/0/0 [edit] root@r2#
And it will generate the 0.0.0.0/0 route:
[edit] root@r2# run show route 0.0.0.0 extensive | find Contributing Contributing Routes (1): 1.1.1.6/32 proto BGP [edit] root@r2#
R1 will use the default route received from R2 to send packets to Internet:
[edit] root@r1# run show route 1.1.1.6 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 00:04:04, metric 0, tag 0 > to 10.10.0.2 via ge-0/0/1.0 [edit] root@r1#
Once the BGP session between R1 and ISP is down, then the 0.0.0.0/0 will not be created anymore:
[edit] root@r2# run show bgp summary Groups: 1 Peers: 1 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.10.6.6 200 17 17 0 3 12 Active [edit] root@r2# run show route 0.0.0.0 extensive [edit] root@r2#
And it will not be advertised to R1:
[edit] root@r1# run show route 1.1.1.6 [edit] root@r1#
In this moment, R1 can use other routers to route the packets for whose destination it doesn’t have more specific information.
I hope you found this article interesting and now you should know how to avoid traffic black-holing caused by a device sending the default route although it cannot route packets further.
Paris ARAU
Latest posts by Paris ARAU (see all)
- Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
- Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
- Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
- Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
- Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018
Great article!
Thank you. Let me know if you would like to see articles on specific topics.
Thanks,
Paris
Hi Paris,
Good information!
Thank you,
Petru Gulian
http://www.gulian.ro