Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Examples: Controlling Traffic with Metrics in a RIP Network

    Understanding Traffic Control with Metrics in a RIP Network

    To tune a RIP network and control traffic flowing through the network, you increase or decrease the cost of the paths through the network. RIP provides two ways to modify the path cost: an incoming metric and an outgoing metric, which are each set to 1 by default. These metrics are attributes that manually specify the cost of any route advertised through a host. By increasing or decreasing the metrics—and thus the cost—of links throughout the network, you can control packet transmission across the network.

    The incoming metric modifies the cost of an individual segment when a route across the segment is imported into the routing table. For example, if you set the incoming metric on the segment to 3, the individual segment cost along the link is changed from 1 to 3. The increased cost affects all route calculations through that link. Other routes that were previously excluded because of a high hop count might now be selected into the router's forwarding table.

    The outgoing metric modifies the path cost for all the routes advertised out a particular interface. Unlike the incoming metric, the outgoing metric modifies the routes that other routers are learning and thereby controls the way they send traffic.

    If an exported route was learned from a member of the same RIP group, the metric associated with that route is the normal RIP metric. For example, a RIP route with a metric of 5 learned from a neighbor configured with an incoming metric of 2 is advertised with a combined metric of 7 when advertised to neighbors in the same group. However, if this route was learned from a RIP neighbor in a different group or from a different protocol, the route is advertised with the metric value configured in the outgoing metric for that group.

    You might want to increase the metric of routes to decrease the likelihood that a particular route is selected and installed in the routing table. This process is sometimes referred to as route poisoning. Some reasons that you might want to poison a route are that the route is relatively expensive to use, or it has relatively low bandwidth.

    A route with a higher metric than another route becomes the active route only when the lower-metric route becomes unavailable. In this way, the higher-metric route serves as a backup path.

    One way to increase the metric of imported routes is to configure an import policy. Another way is to include the metric-in statement in the RIP neighbor configuration. One way to increase the metric of export routes is to configure an export policy. Another way is to include the metric-out statement in the RIP neighbor configuration.

    Example: Controlling Traffic in a RIP Network with an Incoming Metric

    This example shows how to control traffic with an incoming metric.

    Requirements

    Before you begin, define RIP groups, and add interfaces to the groups. Then configure a routing policy to export directly connected routes and routes learned through the RIP routing exchanges. See Example: Configuring a Basic RIP Network.

    Overview

    In this example, routes to Router D are received by Router A across both of its RIP-enabled interfaces as shown in Figure 1. Because the route through Router B and the route through Router C have the same number of hops, both routes are imported into the forwarding table. However, because the T3 link from Router B to Router D has a higher bandwidth than the T1 link from Router C to Router D, you want traffic to flow from Router A through Router B to Router D.

    Figure 1: Controlling Traffic in a RIP Network with the Incoming Metric

    Controlling
Traffic in a RIP Network with the Incoming Metric

    To force this flow, you can modify the route metrics as they are imported into Router A's routing table. By setting the incoming metric on the interface from Router A to Router C, you modify the metric on all routes received through that interface. Setting the incoming route metric on Router A changes only the routes in Router A's routing table, and affects only how Router A sends traffic to Router D. Router D's route selection is based on its own routing table, which, by default, includes no adjusted metric values.

    In the example, Router C receives a route advertisement from Router D and readvertises the route to Router A. When Router A receives the route, it applies the incoming metric on the interface. Instead of incrementing the metric by 1 (the default), Router A increments it by 3 (the configured incoming metric), giving the route from Router A to Router D through Router C a total path metric of 4. Because the route through Router B has a metric of 2, it becomes the preferred route for all traffic from Router A to Router D.

    This example uses a RIP group called alpha 1 on interface g3–0/0/0.

    Configuration

    Step-by-Step Procedure

    To control traffic with an incoming metric:

    1. Enable RIP on the interface.
      [edit protocols rip]user@host# set group alpha1 neighbor ge-0/0/0
    2. Set the incoming metric.
      [edit protocols rip]user@host# set metric-in 3
    3. If you are done configuring the device, commit the configuration.
      [edit]user@host# commit

    Verification

    To verify that the configuration is working properly, enter the show route protocols rip command.

    Example: Controlling Traffic in a RIP Network with an Outgoing Metric

    This example shows how to control traffic with an outgoing metric.

    Requirements

    Before you begin:

    • Define RIP groups, and add interfaces to the groups. Then configure a routing policy to export directly connected routes and routes learned through RIP routing exchanges. See Example: Configuring a Basic RIP Network.

    Overview

    In this example, each route from Router A to Router D has two hops as shown in Figure 2. However, because the link from Router A to Router B in the RIP group has a higher bandwidth than the link from Router A to Router C in RIP group Alpha 1, you want traffic from Router D to Router A to flow through Router B. To control the way Router D sends traffic to Router A, you can alter the routes that Router D receives by configuring the outgoing metric on Router A's interfaces in the Alpha 1 RIP group.

    Figure 2: Controlling Traffic in a RIP Network with the Outgoing Metric

    Controlling
Traffic in a RIP Network with the Outgoing Metric

    If the outgoing metric for the Alpha 1 RIP group—the A-to-C link—is changed to 3, Router D calculates the total path metric from Router A through Router C as 4. In contrast, the unchanged default total path metric to Router A through Router B in the RIP group is 2. The fact that Router A's interfaces belong to two different RIP groups allows you to configure two different outgoing metrics on its interfaces, because you configure path metrics at the group level.

    By configuring the outgoing metric, you control the way Router A sends traffic to Router D. By configuring the outgoing metric on the same router, you control the way Router D sends traffic to Router A.

    This example uses an outgoing metric of 3.

    Configuration

    Step-by-Step Procedure

    To control traffic with an outgoing metric:

    1. Set the outgoing metric.
      [edit protocols rip group alpha1]user@host# set metric-out 3
    2. If you are done configuring the device, commit the configuration.
      [edit]user@host# commit

    Verification

    To verify that the configuration is working properly, enter the show protocols rip command.

    Example: Configuring the Metric Value Added to Imported RIP Routes

    This example shows how to change the default metric to be added to incoming routes to control the route selection process.

    Requirements

    No special configuration beyond device initialization is required before configuring this example.

    Overview

    Normally, when multiple routes are available, RIP selects the route with the lowest hop count. Changing the default metric enables you to control the route selection process such that a route with a higher hop count can be preferred over of a route with a lower hop count.

    Figure 3 shows the topology used in this example.

    Figure 3: RIP Incoming Metrics Network Topology

    RIP Incoming Metrics Network
Topology

    Device R1 has two potential paths to reach 172.16.2.2/32. The default behavior is to send traffic out the 0.1/30 interface facing Device R2. Suppose, though, that the path through Device R3 is less expensive to use or has higher bandwidth links. This example shows how to use the metric-in statement to ensure that Device R1 uses the path through Device R3 to reach 172.16.2.2/32. CLI Quick Configuration shows the configuration for all of the devices in Figure 3. The section Step-by-Step Procedure describes the steps on Device R1.

    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.

    Device R1

    set interfaces fe-1/2/0 unit 1 description to-R2set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30set interfaces ge-1/2/1 unit 10 description to-R3set interfaces ge-1/2/1 unit 10 family inet address 10.0.0.10/30set interfaces lo0 unit 1 family inet address 172.16.0.1/32set interfaces lo0 unit 1 family inet address 192.168.1.1/32set protocols rip group primary export advertise-routes-through-ripset protocols rip group primary neighbor ge-1/2/1.10set protocols rip group secondary export advertise-routes-through-ripset protocols rip group secondary neighbor fe-1/2/0.1 metric-in 4set policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then accept

    Device R2

    set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30set interfaces ge-1/2/1 unit 5 family inet address 10.0.0.5/30set interfaces lo0 unit 2 family inet address 192.168.2.2/32set interfaces lo0 unit 2 family inet address 172.16.2.2/32set protocols rip group rip-group export advertise-routes-through-ripset protocols rip group rip-group neighbor fe-1/2/0.2set protocols rip group rip-group neighbor ge-1/2/1.5set policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then accept

    Device R3

    set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30set interfaces ge-1/2/1 unit 9 family inet address 10.0.0.9/30set interfaces lo0 unit 3 family inet address 192.168.3.3/32set interfaces lo0 unit 3 family inet address 172.16.3.3/32set protocols rip group rip-group export advertise-routes-through-ripset protocols rip group rip-group neighbor fe-1/2/0.6set protocols rip group rip-group neighbor ge-1/2/1.9set policy-options policy-statement advertise-routes-through-rip term 1 from protocol directset policy-options policy-statement advertise-routes-through-rip term 1 from protocol ripset policy-options policy-statement advertise-routes-through-rip term 1 then accept

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure a RIP metrics:

    1. Configure the network interfaces.
      [edit interfaces]user@R1# set fe-1/2/0 unit 1 description to-R2user@R1# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
      user@R1# set ge-1/2/1 unit 10 description to-R3user@R1# set ge-1/2/1 unit 10 family inet address 10.0.0.10/30
      user@R1# set lo0 unit 1 family inet address 172.16.0.1/32user@R1# set lo0 unit 1 family inet address 192.168.1.1/32
    2. Create the RIP groups and add the interfaces.

      To configure RIP in Junos OS, you must configure one or more groups that contain the interfaces on which RIP is enabled. You do not need to enable RIP on the loopback interface.

      For the interface that is facing Device R2, the metric-in 4 setting causes this route to be less likely to be chosen as the active route.

      [edit protocols rip]user@R1# set group primary neighbor ge-1/2/1.10user@R1# set group secondary neighbor fe-1/2/0.1 metric-in 4
    3. Create the routing policy to advertise both direct and RIP-learned routes.
      [edit policy-options policy-statement advertise-routes-through-rip term 1]user@R1# set from protocol directuser@R1# set from protocol ripuser@R1# set then accept
    4. Apply the routing policy.

      In Junos OS, you can only apply RIP export policies at the group level.

      [edit protocols rip]user@R1# set group primary export advertise-routes-through-ripuser@R1# set group secondary export advertise-routes-through-rip

    Results

    From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show policy-options commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    user@R1# show interfaces
    fe-1/2/0 {unit 1 {description to-R2;family inet {address 10.0.0.1/30;}}}
    ge-1/2/1 {unit 10 {description to-R3;family inet {address 10.0.0.10/30;}}}
    lo0 {unit 1 {family inet {address 172.16.0.1/32;address 192.168.1.1/32;}}}
    user@R1# show protocols
    rip {group primary {export advertise-routes-through-rip;neighbor ge-1/2/1.10;}group secondary {export advertise-routes-through-rip;neighbor fe-1/2/0.1 {metric-in 4;}}}
    user@R1# show policy-options
    policy-statement advertise-routes-through-rip {term 1 {from protocol [ direct rip ];then accept;}}

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

    Verification

    Confirm that the configuration is working properly.

    Verifying That the Expected Route Is Active

    Purpose

    Make sure that to reach 172.16.2.2/32, Device R1 uses the path through Device R3.

    Action

    From operational mode, enter the show route 172.16.2.2 command.

    user@R1> show route 172.16.2.2
    inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    172.16.2.2/32      *[RIP/100] 00:15:46, metric 3, tag 0
                        > to 10.0.0.9 via ge-1/2/1.10
    

    Meaning

    The to 10.0.0.9 via ge-1/2/1.10 output shows that Device R1 uses the path through Device R3 to reach 172.16.2.2/32. The metric for this route is 3.

    Removing the metric-in Statement

    Purpose

    Delete or deactivate the metric-in statement to see what happens to the 172.16.2.2/32 route.

    Action

    1. From configuration mode, deactivate the metric-in statement.
      [edit protocols rip group secondary neighbor fe-1/2/0.1]user@R1# deactivate metric-inuser@R1# commit
    2. From operational mode, enter the show route 172.16.2.2 command.
      user@R1> show route 172.16.2.2
      inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
      + = Active Route, - = Last Active, * = Both
      
      172.16.2.2/32      *[RIP/100] 00:00:06, metric 2, tag 0
                          > to 10.0.0.2 via fe-1/2/0.1
      

    Meaning

    The to 10.0.0.2 via fe-1/2/0.1 output shows that Device R1 uses the path through Device R2 to reach 172.16.2.2/32. The metric for this route is 2.

    Modified: 2016-06-15