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:

 

cond_def_route

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.

 

The following two tabs change content below.

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

This post currently has 3 responses

Leave a Reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: