Routing RIP Traffic over Faster Interfaces

Problem

You want to force RIP to route traffic over a faster physical link even if using that link has more hops than a slower link.

Solution

Use the following command to make the path through the slower interface less preferable:

	[edit protocols rip]
	aviva@RouterA# set group alpha-rip-group neighbor se-0/0/3.0 meTRic-in 2

 

Discussion

By default, each directly connected neighbor in a RIP network has a metric value of 1. If there are two equal-cost routes to a destination, RIP considers them equivalent and uses one or the other at any given time. You cannot control RIP's choice of paths. If all the links on your network are the same speed, the path taken by RIP traffic is not an issue and you can leave the default metric values unchanged. However, if one of the paths includes a slower or faster link, you probably want to route the RIP traffic along the faster path. In our example, all routers are linked with faster Ethernet interfaces except for one, which has a slower serial link (see Figure 10-1).

Figure 10-1. Topology for controlling RIP traffic

If you are controlling the path taken by RIP traffic from RouterA to RouterD, you want to make sure it never goes through RouterB but always goes through RouterE and RouterF. If you do not change the default metric configuration, RIP traffic can go along either path. You can check the path it has chosen at this moment, which is the path through RouterB:

	aviva@RouterA> traceroute 192.168.24.1
	traceroute to 192.168.24.1 (192.168.24.1), 30 hops max, 40 byte packets
	1 10.0.21.2 (10.0.21.2) 23.712 ms 29.928 ms 31.495 ms
	2 10.0.22.2 (10.0.22.2) 49.921 ms 68.857 ms 100.153 ms
	3 192.168.24.1 (192.168.24.1) 100.107 ms 100.417 ms 99.953 ms

To control the path selected between RouterA and RouterD, you set the inbound metric on RouterA's serial interface to 2. Whenever RouterA receives a route on the se-0/0/3 interface, it sets the metric in that route to 2:

	aviva@RouterA> show rip neighbor
	 Source Destination Send Receive In
	Neighbor State Address Address Mode Mode Met
	-------- ----- ------- ----------- ---- ------- ---
	fe-0/0/1.0 Up 10.0.15.2 224.0.0.9 mcast	both 1
	se-0/0/3.0 Up 10.0.21.1 224.0.0.9 mcast both 2

You use the traceroute command again to see that you are forcing traffic through RouterE:

	aviva@RouterA> traceroute 192.168.24.1
	traceroute to 192.168.24.1 (192.168.24.1), 30 hops max, 40 byte packets
	1 10.0.15.1 (10.0.15.1) 20.245 ms 11.334 ms 17.559 ms
	2 10.0.13.2 (10.0.13.2) 19.916 ms 19.534 ms 18.065 ms
	3 192.168.24.1 (192.168.24.1) 21.769 ms 29.599 ms 19.960 ms

You check the routing table to see that the route to RouterD through RouterB has a metric of 4, while the route through RouterE has a metric of 3:

	aviva@RouterA> show route table inet.0
	10.0.29.0/24 *[RIP/100] 00:16:27, metric 4, tag 0
	to 10.0.15.1 via fe-0/0/1.0
	 > to 10.0.21.2 via se-0/0/3.0
	10.0.31.0/24 *[RIP/100] 02:56:55, metric 3, tag 0
	 > to 10.0.15.1 via fe-0/0/1.0

Changing the inbound metric on a router's interface modifies only how the local router, RouterA, sends traffic. It has no effect on how any remote routers control their traffic flow. You can look in the routing table of RouterD to see that when it sends traffic to RouterA, the two paths (through RouterC and RouterF) both have a metric value of 3, which is the value you expect because RouterA is three hops away from RouterD:

	aviva@RouterD> show route table inet.0
	10.0.15.0/24 *[RIP/100] 03:39:30, metric 3, tag 0
	 > to 10.0.31.2 via t1-0/0/2.0
	10.0.21.0/24 *[RIP/100] 03:41:18, metric 3, tag 0
	 > to 10.0.29.1 via fe-0/0/1.0



Router Configuration and File Management

Basic Router Security and Access Control

IPSec

SNMP

Logging

NTP

Router Interfaces

IP Routing

Routing Policy and Firewall Filters

RIP

IS-IS

OSPF

BGP

MPLS

VPNs

IP Multicast



JUNOS Cookbook
Junos Cookbook (Cookbooks (OReilly))
ISBN: 0596100140
EAN: 2147483647
Year: 2007
Pages: 290
Authors: Aviva Garrett

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net