In part 1 we looked at the basics of configuring RIP on Junos. In part 2 we are going to look at authentication, changing metric values, and changing the preference for RIP routes.
Lab Setup
The lab setup is the same as it was for part 1.
A couple of things to note with the lab:
- To make the following examples a bit clearer, the link between R4 and R5 has been shut down.
- A mix of vSRX, vMX, and vQFX devices are used. This is done solely to show that the configuration is the same across devices.
- Each device has a loopback address in the 172.16.0.x range, where x is the router number.
- Each vSRX has been put into packet mode, so it will act as a router.
- This is done with the ‘set security forwarding-options family mpls mode packet-based’ command. You may need to delete the security policies stanza for this to commit. Depending on the version you may also need to reboot the device for packet mode to take effect.
- R1 and R4 will be configured with two groups under RIP, instead of just one.
RIP Authentication
The authentication for RIP can be none, simple, or md5. The default is none.
The configuration is in two parts. The first is to set the authentication type and the second is to set the authentication key. These can be set at either the protocol level under ‘edit protocols rip’ or under the neighbor, they cannot be set at the group level.
First, on R1, for the interface facing R4, we can set the authentication to simple with a password of Juniper.
[edit]
lab@vsrx-R1# set protocols rip group my-group-2 neighbor ge-0/0/1.0 authentication-type simple
[edit]
lab@vsrx-R1# set protocols rip group my-group-2 neighbor ge-0/0/1.0 authentication-key Juniper
[edit]
lab@vsrx-R1# show protocols rip
group my-group-1 {
export my-rip-export;
neighbor ge-0/0/0.0;
}
group my-group-2 {
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type simple;
authentication-key "$9$1lVESl8X-24ZKM4ZUjPf1Rh"; ## SECRET-DATA
}
}
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1>After waiting several minutes, we can now check the RIP statistics on R4.
lab@vmx-R4> show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
0 0 0 0
ge-0/0/1.0: 0 routes learned; 2 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 125 11 2
Triggered Updates Sent 3 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 129 10 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 15 10 2
RIP Requests Received 1 0 0
RIP Requests Ignored 0 0 0
RIP Update Acks Received 0 0 0
ge-0/0/0.0: 0 routes learned; 3 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 102 0 0
Triggered Updates Sent 2 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 104 0 0
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
RIP Update Acks Received 0 0 0
lab@vmx-R4>Further, if we look at the messages log, we can see entries about invalid authentication.
lab@vmx-R4> show log messages | last 10
Jan 20 03:19:34 vmx-R4 mgd[10180]: UI_COMMIT_COMPLETED: : commit complete
Jan 20 03:19:34 vmx-R4 mgd[10180]: UI_DBASE_LOGOUT_EVENT: User 'lab' exiting configuration mode
Jan 20 03:19:34 vmx-R4 mib2d[8675]: SNMP_TRAP_LINK_DOWN: ifIndex 527, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/0/0
Jan 20 03:23:50 vmx-R4 rpd[8772]: RPD_RIP_AUTH_REQUEST: Request with invalid authentication from 10.100.3.1 (ge-0/0/1.0)
Jan 20 03:23:54 vmx-R4 rpd[8772]: RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 10.100.3.1 (ge-0/0/1.0)
Jan 20 03:24:17 vmx-R4 rpd[8772]: RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 10.100.3.1 (ge-0/0/1.0)
Jan 20 03:26:12 vmx-R4 last message repeated 4 times
Jan 20 03:29:32 vmx-R4 last message repeated 7 times
Jan 20 03:30:00 vmx-R4 rpd[8772]: RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 10.100.3.1 (ge-0/0/1.0)
Jan 20 03:30:27 vmx-R4 rpd[8772]: RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 10.100.3.1 (ge-0/0/1.0)
lab@vmx-R4>And finally, if we look at the routing table we can see there are no RIP routes. It did take several minutes for the RIP routes to disappear from the table.
lab@vmx-R4> show route
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 04:35:48
> via fxp0.0
10.0.0.24/32 *[Local/0] 04:35:48
Local via fxp0.0
10.100.3.0/24 *[Direct/0] 01:02:32
> via ge-0/0/1.0
10.100.3.2/32 *[Local/0] 01:02:32
Local via ge-0/0/1.0
10.100.5.1/32 *[Local/0] 00:13:25
Reject
172.16.0.4/32 *[Direct/0] 01:02:32
> via lo0.0
224.0.0.9/32 *[RIP/100] 01:02:32, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 04:35:48
MultiRecv
lab@vmx-R4>We can now set the authentication type and key on R4 for the interface facing R1. If we give it the wrong password we will see more authentication failures and the same log message.
If we finally set the authentication key to match R1, we again see RIP routes in the routing table.
The R4 config and route table now look as follows:
lab@vmx-R4> show configuration protocols rip
group my-group-1 {
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type simple;
authentication-key "$9$d7w2oDi.z39JG39ApREdbs"; ## SECRET-DATA
}
}
group my-group-2 {
export my-rip-export;
neighbor ge-0/0/0.0;
}
lab@vmx-R4> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:01:22, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:01:22, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:01:22, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:01:22, metric 4, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:01:22, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:01:22, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:01:22, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:01:22, metric 4, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:01:22, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:01:22, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>If we set R1 to use md5 authentication and leave R4 using simple authentication then we see similar counters incrementing and error messages in the log file as we did when R1 was using simple authentication and R4 had no authentication set.
Adjusting RIP Metrics
There are two ways of adjusting RIP metrics on Junos:
- Using metric-in or metric-out commands
- Using policy statements
Metric In and Out Commands
The metric-in command adds to the existing metric when a route is received. It can be set at the protocols rip level or under the neighbor statement.
The metric-out command adds to the metric when we advertise local routes. It can only be set at the group level.
To show this, let’s start on R1 and set metric in on the neighbor facing R2.
We should check the RIP routes on R1 first before we make any changes.
lab@vsrx-R1> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:08:38, metric 2, tag 0
to 10.100.1.2 via ge-0/0/0.0
> to 10.100.3.2 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 05:13:27, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:37:06, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 05:13:27, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 05:13:27, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 05:13:23, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 00:08:38, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:34:59, metric 4, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:14:16, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>Now we can set the metric-in statement.
[edit]
lab@vsrx-R1# set protocols rip group my-group-1 neighbor ge-0/0/0.0 metric-in 5
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1> show configuration protocols rip
group my-group-1 {
export my-rip-export;
neighbor ge-0/0/0.0 {
metric-in 5;
}
}
group my-group-2 {
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
}
lab@vsrx-R1>Checking the RIP routes again on R1, we can see they all increased their metric by five.
lab@vsrx-R1> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:00:43, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:00:43, metric 6, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:00:43, metric 7, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 00:00:43, metric 6, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 00:00:43, metric 6, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 00:00:43, metric 7, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 00:11:25, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:00:43, metric 8, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:00:48, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>Now it’s time to look at the metric out command. We will apply this on R1 for the group which includes R4. Before we make any changes, let’s check the routing table on R4.
lab@vmx-R4> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:14:42, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:14:42, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:03:58, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:03:58, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:03:58, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:14:42, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:03:58, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:03:58, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:03:58, metric 9, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:14:47, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>The change on R1 is quite simple.
[edit]
lab@vsrx-R1# set protocols rip group my-group-2 metric-out 4
[edit]
lab@vsrx-R1# show protocols rip
group my-group-1 {
export my-rip-export;
neighbor ge-0/0/0.0 {
metric-in 5;
}
}
group my-group-2 {
metric-out 4;
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
}
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1>If we look at the output on R4, it isn’t perhaps what you might expect.
lab@vmx-R4> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:27:53, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:27:53, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:33:55, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:33:55, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:33:55, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:27:53, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:33:55, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:33:55, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:33:55, metric 9, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:44:44, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>The routes that are originated from R1 itself have been incremented. That is 10.100.1.0/24 and 172.16.0.1. Most of the other routes however are the same.
Let’s now try something a bit different. We can deactivate my-group-1 and move the ge-0/0/0 interface into my-group-2 and again add the metric-in command.
The config for R1 now looks like this:
[edit]
lab@vsrx-R1# show protocols
rip {
inactive: group my-group-1 {
export my-rip-export;
neighbor ge-0/0/0.0 {
metric-in 5;
}
}
group my-group-2 {
metric-out 4;
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
neighbor ge-0/0/0.0 {
metric-in 5;
}
}
}
[edit]
lab@vsrx-R1#On R4, the routing table still looks the same.
lab@vmx-R4> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:36:37, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:36:37, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:04:34, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:04:34, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:04:34, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:36:37, metric 5, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:04:34, metric 7, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:04:34, metric 8, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:04:34, metric 9, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:53:28, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>After some further experimenting, it appears that the metric-out statement is setting the default metric of local routes exported into the RIP protocol, not the metric of routes already learned by RIP.
So when metric-out was set on R1, it affected routes on R1 that were exported into RIP, but not routes it learned via RIP from R2.
Using Policy To Adjust RIP Metrics
The other approach to setting RIP metrics is to use policy statements. These allow us to be more selective in what routes we impact, rather than metric-in which affects all routes. We can choose to either set the metric to a specific value or to add or subtract from the existing value.
To show this in action we will filter on the R2, R3, and R5 loopback addresses and use the different methods to change them. The specific routes will be matched using route filters.
We will be performing this on R1.
This is the updated configuration. We apply an import policy to the my-group-1 group under protocols rip. The policy will:
- Match 172.16.0.2 and set the metric to 10
- Match 172.16.0.3 and add 5 to the metric
- Match 172.16.0.5 and subtract 3 from the metric.
- Note that none of the first terms have a terminating action. To make the default action of accepting RIP routes more obvious, a final term accepting all routes has been set.
[edit]
lab@vsrx-R1# show protocols rip
group my-group-1 {
export my-rip-export;
import rip-metric-update;
neighbor ge-0/0/0.0;
}
group my-group-2 {
export my-rip-export;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
}
[edit]
lab@vsrx-R1# show policy-options policy-statement rip-metric-update
term set-metric {
from {
route-filter 172.16.0.2/32 exact;
}
then {
metric 10;
}
}
term add-metric {
from {
route-filter 172.16.0.3/32 exact;
}
then {
metric add 5;
}
}
term subtract-metric {
from {
route-filter 172.16.0.5/32 exact;
}
then {
metric subtract 3;
}
}
term final {
then accept;
}
[edit]
lab@vsrx-R1#Here is the routing table on R1 before the import policy is applied:
[edit]
lab@vsrx-R1# run show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:14:09, metric 2, tag 0
to 10.100.1.2 via ge-0/0/0.0
> to 10.100.3.2 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:14:09, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:14:09, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 00:14:09, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 00:14:09, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 00:14:09, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 00:23:45, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:14:09, metric 4, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:14:09, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
lab@vsrx-R1#And here is the routing table after the config was committed.
lab@vsrx-R1> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:15:05, metric 2, tag 0
to 10.100.1.2 via ge-0/0/0.0
> to 10.100.3.2 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:15:05, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:15:05, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 00:15:05, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 00:00:28, metric 10, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 00:00:28, metric 8, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 00:24:41, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:00:28, metric 1, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:00:33, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>As you can see, the import policy has modified the metric of the three routes we specified.
On R1, we can also change the routing policy applied to the RIP group my-group-2 to affect routes advertised to R4.
The relevant config is shown below.
[edit]
lab@vsrx-R1# show protocols rip
group my-group-1 {
export my-rip-export;
import rip-metric-update;
neighbor ge-0/0/0.0;
}
group my-group-2 {
export export-to-r4;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
}
[edit]
lab@vsrx-R1# show policy-options policy-statement export-to-r4
term direct-routes {
from protocol direct;
then accept;
}
term rip-routes {
from protocol rip;
then {
metric add 9;
accept;
}
}
[edit]
lab@vsrx-R1#The R4 routing table looks like this before the above change is committed on R1.
lab@vmx-R4> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:33:35, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:33:35, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:28:55, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:36:29, metric 4, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:28:55, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:33:35, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:12:15, metric 11, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:12:15, metric 9, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:12:15, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:36:37, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>After the commit and waiting several minutes, the routing table on R4 now looks like this:
lab@vmx-R4> show route protocol rip
inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:36:50, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:36:50, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:02:19, metric 12, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:02:19, metric 13, tag 0
> to 10.100.3.1 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:02:19, metric 12, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:36:50, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:02:19, metric 11, tag 0
> to 10.100.3.1 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 00:39:52, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vmx-R4>Some of the routes had disappeared, notably 172.16.0.2 and 172.16.0.3. What happened?
Let’s look back at the /32 routes learned via RIP on R1.
lab@vsrx-R1> show route protocol rip | match /32
172.16.0.2/32 *[RIP/100] 00:17:56, metric 10, tag 0
172.16.0.3/32 *[RIP/100] 00:17:56, metric 8, tag 0
172.16.0.4/32 *[RIP/100] 00:42:09, metric 2, tag 0
172.16.0.5/32 *[RIP/100] 00:17:56, metric 1, tag 0
224.0.0.9/32 *[RIP/100] 00:04:46, metric 1
lab@vsrx-R1> You may recall that the maximum metric for RIP is 15. The value of 16 is considered an infinite metric and unreachable. Since our export policy adds nine to the existing metric, that makes 172.16.0.2 and 172.16.0.3 unreachable.
If we look at what R1 is advertising, it doesn’t advertise those two routes.
lab@vsrx-R1> show route advertising-protocol rip 10.100.3.1
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 00:45:43
> via fxp0.0
[RIP/100] 00:36:06, metric 2, tag 0
to 10.100.1.2 via ge-0/0/0.0
> to 10.100.3.2 via ge-0/0/1.0
10.100.1.0/24 *[Direct/0] 00:45:43
> via ge-0/0/0.0
10.100.2.0/24 *[RIP/100] 00:36:06, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:36:06, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 00:36:06, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.1/32 *[Direct/0] 00:45:43
> via lo0.0
172.16.0.5/32 *[RIP/100] 00:21:29, metric 1, tag 0
> to 10.100.1.2 via ge-0/0/0.0
lab@vsrx-R1>This example highlights the need to consider the consequences of adjusting the metrics, and ensuring you understand what the impact will be on the network.
Changing RIP Route Preference
Route preference is the tie-breaker when the same route is learned via two different protocols, which protocol’s route should be preferred. On Junos, the default preference for RIP routes is 100.
This can be changed under the RIP group configuration, as shown on R1 below. Again – RIP is a slower protocol, so you may have to wait for the next RIP update before the preference values change.
The preference for a specific route could also be changed using policy.
lab@vsrx-R1> edit
Entering configuration mode
[edit]
lab@vsrx-R1# set protocols rip group my-group-1 preference 70
[edit]
lab@vsrx-R1# show protocols rip
group my-group-1 {
preference 70;
export my-rip-export;
import rip-metric-update;
neighbor ge-0/0/0.0;
}
group my-group-2 {
export export-to-r4;
neighbor ge-0/0/1.0 {
authentication-type md5;
authentication-key "$9$SYUlv8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA
}
}
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:00:12, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.2.0/24 *[RIP/100] 04:47:13, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 04:47:13, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 04:47:13, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 04:32:36, metric 10, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 04:32:36, metric 8, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 04:56:49, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 04:32:36, metric 1, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:00:12, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1> show route protocol rip
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/70] 00:00:13, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.2.0/24 *[RIP/70] 00:00:13, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/70] 00:00:13, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
169.254.0.0/24 *[RIP/70] 00:00:13, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/70] 00:00:13, metric 10, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/70] 00:00:13, metric 8, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 04:57:19, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/70] 00:00:13, metric 1, tag 0
> to 10.100.1.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:00:42, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>Now that you’ve worked with RIP, you may like to look at configuring RIPng for IPv6 routes.