Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Controlling Static Routes in Routing and Forwarding Tables

Understanding Static Route Control in Routing and Forwarding Tables

You can control the importation of static routes into the routing and forwarding tables in a number of ways. Primary ways include assigning one or more of the following attributes to the route:

• retain—Keeps the route in the forwarding table after the routing process shuts down or the device reboots.
• no-readvertise—Prevents the route from being readvertised to other routing protocols.
• passive—Rejects traffic destined for the route.

This topic includes the following sections:

• Route Retention
• Readvertisement Prevention
• Forced Rejection of Passive Route Traffic

Route Retention

By default, static routes are not retained in the forwarding table when the routing process shuts down. When the routing process starts up again, any routes configured as static routes must be added to the forwarding table again. To avoid this latency, routes can be flagged as retain, so that they are kept in the forwarding table even after the routing process shuts down. Retention ensures that the routes are always in the forwarding table, even immediately after a system reboot.

Readvertisement Prevention

Static routes are eligible for readvertisement by other routing protocols by default. In a stub area where you might not want to readvertise these static routes under any circumstances, you can flag the static routes as no-readvertise.

Forced Rejection of Passive Route Traffic

Generally, only active routes are included in the routing and forwarding tables. If a static route's next-hop address is unreachable, the route is marked passive, and it is not included in the routing or forwarding tables. To force a route to be included in the routing tables regardless of next-hop reachability, you can flag the route as passive. If a route is flagged passive and its next-hop address is unreachable, the route is included in the routing table, and all traffic destined for the route is rejected.

Example: Preventing a Static Route from Being Readvertised

This example shows how to prevent a static route from being readvertised into OSPF, thereby preventing the route from appearing in the routing and forwarding tables.

• Requirements
• Overview
• Configuration
• Verification

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

This example shows how to configure a routing policy that readvertises static routes into OSPF, with the exception of one static route that is not readvertised because it is tagged with the no-readvertise statement.

Figure 1 shows the sample network.

Figure 1: Customer Routes Connected to a Service Provider

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the interface to Device B.
   [edit interfaces fe-1/2/0 unit 4]user@A# set description A->Buser@A# set family inet address 10.0.2.2/30
2. Configure OSPF to form an OSPF peer relationship with Device B.
   [edit protocols ospf area 0.0.0.0]user@A# set interface fe-1/2/0.4

Step-by-Step Procedure

1. Configure the interfaces to Device A and Device C.
   [edit interfaces]user@B# set fe-1/2/0 unit 3 description B->Auser@B# set fe-1/2/0 unit 3 family inet address 10.0.2.1/30user@B# set fe-1/2/1 unit 6 description B->Cuser@B# set fe-1/2/1 unit 6 family inet address 10.0.3.1/30
2. Configure one or more static routes and the autonomous system (AS) number.
   [edit routing-options]user@B# set static route 0.0.0.0/0 next-hop 10.0.3.2user@B# set static route 192.168.0.0/24 next-hop 10.0.3.2user@B# set autonomous-system 17
3. Configure the routing policy.

   This policy exports static routes from the routing table into OSPF.

   [edit policy-options policy-statement send-static]user@B# set from protocol staticuser@B# set then accept
4. Include the no-readvertise statement to prevent the 192.168.0.0/24 route from being exported into OSPF.
   [edit routing-options]user@B# set static route 192.168.0.0/24 no-readvertise
5. Configure the routing protocols.

   The BGP configuration forms an external BGP (EBGP) peer relationship with Device C.

   The OSPF configuration forms an OSPF peer relationship with Device A and applies the send-static routing policy.

   [edit protocols]user@B# set bgp group ext type externaluser@B# set bgp group ext peer-as 23user@B# set bgp group ext neighbor 10.0.3.2user@B# set ospf export send-staticuser@B# set ospf area 0.0.0.0 interface fe-1/2/0.3

Step-by-Step Procedure

1. Create the interface to Device B, and configure the loopback interface.
   [edit interfaces ]user@C# set fe-1/2/0 unit 7 description B->Cuser@C# set fe-1/2/0 unit 7 family inet address 10.0.3.2/30user@C# set lo0 unit 5 family inet address 192.168.0.1/32
2. Configure the EBGP peering session with Device B.
   [edit protocols bgp group ext]user@C# set type externaluser@C# set peer-as 17user@C# set neighbor 10.0.3.1
3. Configure the AS number.
   [edit routing-options]user@C# set autonomous-system 23

Results

Confirm your configuration by issuing the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Routing Table

Purpose

Make sure that the no-readvertise statement is working.

Action

1. On Device A, run the show route protocol ospf command to make sure that the 192.168.0.0/24 route does not appear in Device A’s routing table.
   user@A> show route protocols ospf

   inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
   + = Active Route, - = Last Active, * = Both
   
   0.0.0.0/0          *[OSPF/150] 00:03:15, metric 0, tag 0
                       > to 10.0.2.1 via fe-1/2/0.4
   224.0.0.5/32       *[OSPF/10] 00:04:07, metric 1
                         MultiRecv
   

2. On Device B, deactivate the no-readvertise statement.
   user@B# deactivate routing-options static route 192.168.0.0/24 no-readvertise
3. On Device A, rerun the show route protocol ospf command to make sure that the 192.168.0.0/24 route appears in Device A’s routing table.
   user@A> show route protocols ospf

   inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
   + = Active Route, - = Last Active, * = Both
   
   0.0.0.0/0          *[OSPF/150] 00:04:24, metric 0, tag 0
                       > to 10.0.2.1 via fe-1/2/0.4
   192.168.0.0/24     *[OSPF/150] 00:00:15, metric 0, tag 0
                       > to 10.0.2.1 via fe-1/2/0.4
   224.0.0.5/32       *[OSPF/10] 00:05:16, metric 1
                         MultiRecv
   

Meaning

The no-readvertise statement is working as expected.