In this post, we’re going to walk through the process for configuring RIP on Junos-based devices.
There are a couple of key points to remember:
- RIP configuration uses groups
- We specify what interfaces to run RIP on
- The default import policy for RIP is to import all RIP routes
- The default export policy for RIP is to reject all routes, including those learned via RIP. We will need to add a policy to advertise RIP routes.
Lab Setup
The following diagram details the lab.
A couple of things to note with the lab:
- 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 Configuration
Router R1
We will configure the following:
- Interfaces
- RIP protocol with two groups
- Routing policy to advertise both direct and RIP routes
There are a couple of things worth noting with the below configuration.
- When specifying the IP Address for loopback 0 (lo0), the /32 could have been left off. If no mask is specified a /32 is assumed
- When configuring the neighbors under RIP we specify the interfaces in two different ways. For the first interface, we do not specify the logical unit, so Junos assumes we mean unit 0. For the second interface, we do specify the logical unit, which in this case is 0 anyway. This is important when dealing with interfaces with multiple logical units.
lab@vsrx-R1> edit
Entering configuration mode
[edit]
lab@vsrx-R1# set interfaces lo0 unit 0 family inet address 172.16.0.1/32
[edit]
lab@vsrx-R1# set interfaces ge-0/0/0 unit 0 family inet address 10.100.1.1/24
[edit]
lab@vsrx-R1# set interfaces ge-0/0/1 unit 0 family inet address 10.100.3.1/24
[edit]
lab@vsrx-R1# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol rip
[edit]
lab@vsrx-R1# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol direct
[edit]
lab@vsrx-R1# set policy-options policy-statement my-rip-export term export-rip-and-direct then accept
[edit]
lab@vsrx-R1# set protocols rip group my-group-1 neighbor ge-0/0/0
[edit]
lab@vsrx-R1# set protocols rip group my-group-2 neighbor ge-0/0/1.0
[edit]
lab@vsrx-R1# set protocols rip group my-group-1 export my-rip-export
[edit]
lab@vsrx-R1# set protocols rip group my-group-2 export my-rip-export
[edit]
lab@vsrx-R1# show | compare
[edit interfaces]
+ ge-0/0/0 {
+ unit 0 {
+ family inet {
+ address 10.100.1.1/24;
+ }
+ }
+ }
+ ge-0/0/1 {
+ unit 0 {
+ family inet {
+ address 10.100.3.1/24;
+ }
+ }
+ }
+ lo0 {
+ unit 0 {
+ family inet {
+ address 172.16.0.1/32;
+ }
+ }
+ }
[edit]
+ policy-options {
+ policy-statement my-rip-export {
+ term export-rip-and-direct {
+ from protocol [ rip direct ];
+ then accept;
+ }
+ }
+ }
+ 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;
+ }
+ }
+ }
[edit]
lab@vsrx-R1# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R1> Router R2
We will configure the following:
- Interfaces
- RIP protocol with one group
- Routing policy to advertise both direct and RIP routes
{master:0}
lab@vqfx-R2> edit
Entering configuration mode
{master:0}[edit]
lab@vqfx-R2# set interfaces lo0 unit 0 family inet address 172.16.0.2
{master:0}[edit]
lab@vqfx-R2# set interfaces xe-0/0/0 unit 0 family inet address 10.100.1.2/24
{master:0}[edit]
lab@vqfx-R2# set interfaces xe-0/0/1 unit 0 family inet address 10.100.2.1/24
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol rip
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol direct
{master:0}[edit]
lab@vqfx-R2# set policy-options policy-statement my-rip-export term export-rip-and-direct then accept
{master:0}[edit]
lab@vqfx-R2# set protocols rip group my-group-1 neighbor xe-0/0/0
{master:0}[edit]
lab@vqfx-R2# set protocols rip group my-group-1 neighbor xe-0/0/1
{master:0}[edit]
lab@vqfx-R2# set protocols rip group my-group-1 export my-rip-export
{master:0}[edit]
lab@vqfx-R2# show | compare
[edit interfaces]
+ xe-0/0/0 {
+ unit 0 {
+ family inet {
+ address 10.100.1.2/24;
+ }
+ }
+ }
+ xe-0/0/1 {
+ unit 0 {
+ family inet {
+ address 10.100.2.1/24;
+ }
+ }
+ }
+ lo0 {
+ unit 0 {
+ family inet {
+ address 172.16.0.2/32;
+ }
+ }
+ }
[edit]
+ policy-options {
+ policy-statement my-rip-export {
+ term export-rip-and-direct {
+ from protocol [ rip direct ];
+ then accept;
+ }
+ }
+ }
[edit protocols]
+ rip {
+ group my-group-1 {
+ export my-rip-export;
+ neighbor xe-0/0/0.0;
+ neighbor xe-0/0/1.0;
+ }
+ }
{master:0}[edit]
lab@vqfx-R2# commit and-quit
configuration check succeeds
commit complete
Exiting configuration mode
{master:0}
lab@vqfx-R2>Now that we have at least two routers configured, we can do a quick check to ensure things are working as expected. First, we can check RIP neighbors.
{master:0}
lab@vqfx-R2> show rip neighbor
Local Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
xe-0/0/0.0 Up 10.100.1.2 224.0.0.9 mcast both 1
xe-0/0/1.0 Up 10.100.2.1 224.0.0.9 mcast both 1
{master:0}
lab@vqfx-R2>The output for this command is a bit misleading. The ‘Local State’ Field is only talking about the state of the interface. It does not mean that we have a neighbor on that interface. At this stage, we haven’t configured R3 yet, so R2 can’t have a neighbor on interface xe-0/0/1.0. This can be seen when we look at the statistics. We only see received updates on xe-0/0/0.0, not xe-0/0/1.0.
{master:0}
lab@vqfx-R2> show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
3 0 0 0
xe-0/0/0.0: 3 routes learned; 4 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 29 11 2
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 30 11 2
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
xe-0/0/1.0: 0 routes learned; 6 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 30 11 2
Triggered Updates Sent 0 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 0 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
{master:0}
lab@vqfx-R2>We can also check what RIP routes we have learned.
{master:0}
lab@vqfx-R2> show route protocol rip
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:15:34, metric 2, tag 0
> to 10.100.1.1 via xe-0/0/0.0
10.100.3.0/24 *[RIP/100] 00:15:34, metric 2, tag 0
> to 10.100.1.1 via xe-0/0/0.0
172.16.0.1/32 *[RIP/100] 00:15:34, metric 2, tag 0
> to 10.100.1.1 via xe-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:22:11, metric 1
MultiRecv
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
{master:0}
lab@vqfx-R2>The portion that is [RIP/100] tells us the protocol is RIP, and the preference for this route is 100, which is the default for RIP routes.
Things look good so far, so let’s move on to R3.
Router R3
We will configure the following:
- Interfaces
- RIP protocol with one group
- Routing policy to advertise both direct and RIP routes
lab@vsrx-R3> edit
Entering configuration mode
[edit]
lab@vsrx-R3# set interfaces lo0 unit 0 family inet address 172.16.0.3
[edit]
lab@vsrx-R3# set interfaces ge-0/0/0 unit 0 family inet address 10.100.2.2/24
[edit]
lab@vsrx-R3# set interfaces ge-0/0/1 unit 0 family inet address 10.100.4.1/24
[edit]
lab@vsrx-R3# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol rip
[edit]
lab@vsrx-R3# set policy-options policy-statement my-rip-export term export-rip-and-direct from protocol direct
[edit]
lab@vsrx-R3# set policy-options policy-statement my-rip-export term export-rip-and-direct then accept
[edit]
lab@vsrx-R3# set protocols rip group my-group-1 neighbor ge-0/0/0
[edit]
lab@vsrx-R3# set protocols rip group my-group-1 neighbor ge-0/0/1
[edit]
lab@vsrx-R3# set protocols rip group my-group-1 export my-rip-export
[edit]
lab@vsrx-R3# commit and-quit
commit complete
Exiting configuration mode
lab@vsrx-R3>Router R4
We will configure the following:
- Interfaces
- RIP protocol with two groups
- Routing policy to advertise both direct and RIP routes
Since the configuration is almost the same as the other devices, I’ll just show the ‘show | compare’ before the commit.
[edit]
lab@vmx-R4# show | compare
[edit interfaces]
+ ge-0/0/0 {
+ unit 0 {
+ family inet {
+ address 10.100.5.1/24;
+ }
+ }
+ }
+ ge-0/0/1 {
+ unit 0 {
+ family inet {
+ address 10.100.3.2/24;
+ }
+ }
+ }
+ lo0 {
+ unit 0 {
+ family inet {
+ address 172.16.0.4/32;
+ }
+ }
+ }
[edit]
+ policy-options {
+ policy-statement my-rip-export {
+ term export-rip-and-direct {
+ from protocol [ rip direct ];
+ then accept;
+ }
+ }
+ }
[edit protocols]
+ rip {
+ group my-group-1 {
+ export my-rip-export;
+ neighbor ge-0/0/1.0;
+ }
+ group my-group-2 {
+ export my-rip-export;
+ neighbor ge-0/0/0.0;
+ }
+ }
[edit]
lab@vmx-R4#Router R5
We will configure the following:
- Interfaces
- RIP protocol with one group
- Routing policy to advertise both direct and RIP routes
Again, I’ll just show the ‘show | compare’ before the commit.
[edit]
lab@vmx-R5# show | compare
[edit interfaces]
+ ge-0/0/0 {
+ unit 0 {
+ family inet {
+ address 10.100.5.2/24;
+ }
+ }
+ }
+ ge-0/0/1 {
+ unit 0 {
+ family inet {
+ address 10.100.4.2/24;
+ }
+ }
+ }
+ lo0 {
+ unit 0 {
+ family inet {
+ address 172.16.0.5/32;
+ }
+ }
+ }
[edit]
+ policy-options {
+ policy-statement my-rip-export {
+ term export-rip-and-direct {
+ from protocol [ rip direct ];
+ then accept;
+ }
+ }
+ }
[edit protocols]
+ rip {
+ group my-group-1 {
+ export my-rip-export;
+ neighbor ge-0/0/0.0;
+ neighbor ge-0/0/1.0;
+ }
+ }
[edit]
lab@vmx-R5#Verifying RIP Operation
Now that RIP is configured, how do we verify it is working as expected? The following looks at R1.
We can look at RIP neighbors and RIP statistics. As noted earlier, the RIP neighbors output can be slightly misleading as it does not show you whether a neighbor is up on an interface, only that the local state of the interface is up.
When looking at the statistics we are mainly looking for the updates sent and received counters to increment over time.
lab@vsrx-R1> show rip neighbor
Local Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-0/0/0.0 Up 10.100.1.1 224.0.0.9 mcast both 1
ge-0/0/1.0 Up 10.100.3.1 224.0.0.9 mcast both 1
lab@vsrx-R1> show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
9 0 0 0
ge-0/0/0.0: 6 routes learned; 6 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 139 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 69 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 1 0 0
RIP Requests Ignored 0 0 0
RIP Update Acks Received 0 0 0
ge-0/0/1.0: 5 routes learned; 7 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 139 11 3
Triggered Updates Sent 6 1 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 17 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 1 0 0
RIP Requests Ignored 0 0 0
RIP Update Acks Received 0 0 0
lab@vsrx-R1>Next, we can look at the routing table. Since we are only interested in RIP routes, we can specify that with the show route command. We should see all the link nets and the loopback addresses of the other routers.
lab@vsrx-R1> show route protocol rip
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:09:11, 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:32:58, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:06:18, metric 3, 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.5.0/24 *[RIP/100] 00:09:11, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 00:33:01, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 00:33:01, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 00:13:56, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.4/32 *[RIP/100] 00:09:11, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:06:18, metric 3, tag 0
> to 10.100.3.2 via ge-0/0/1.0
224.0.0.9/32 *[RIP/100] 01:07:41, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>There are a few things worth noting from the above output.
We have a route for 224.0.0.9/32. That is so we can receive the RIP updates that are multicasted to that address.
Also, we have two equal paths to the 10.100.4.0/24 network between R3 and R5. Since we do not have load balancing enabled at this stage, Junos will randomly select which of the two paths is used for forwarding traffic to that destination network.
To further prove our routing is working, we can ping from the loopback of R1 to the loopback of R3 like so:
lab@vsrx-R1> ping 172.16.0.3 source 172.16.0.1 count 5
PING 172.16.0.3 (172.16.0.3): 56 data bytes
64 bytes from 172.16.0.3: icmp_seq=0 ttl=63 time=106.771 ms
64 bytes from 172.16.0.3: icmp_seq=1 ttl=63 time=106.515 ms
64 bytes from 172.16.0.3: icmp_seq=2 ttl=63 time=106.525 ms
64 bytes from 172.16.0.3: icmp_seq=3 ttl=63 time=106.942 ms
64 bytes from 172.16.0.3: icmp_seq=4 ttl=63 time=111.928 ms
--- 172.16.0.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 106.515/107.736/111.928/2.102 ms
lab@vsrx-R1>Finally, we can show what routes we are sending to or receiving from a particular neighbor.
To see what routes we are receiving, we specify the neighbor who is sending the updates to us.
lab@vsrx-R1> show route receive-protocol rip 10.100.1.2
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 [RIP/100] 00:44:08, 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] 01:07:55, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
10.100.4.0/24 *[RIP/100] 00:41:15, metric 3, tag 0
to 10.100.1.2 via ge-0/0/0.0
> to 10.100.3.2 via ge-0/0/1.0
169.254.0.0/24 *[RIP/100] 01:07:58, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.2/32 *[RIP/100] 01:07:58, metric 2, tag 0
> to 10.100.1.2 via ge-0/0/0.0
172.16.0.3/32 *[RIP/100] 00:48:53, metric 3, tag 0
> to 10.100.1.2 via ge-0/0/0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vsrx-R1>To show what routes we are advertising, we specify our own address.
lab@vsrx-R1> show route advertising-protocol rip 10.100.1.1
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[Direct/0] 02:07:03
> via fxp0.0
[RIP/100] 00:47:18, 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.3.0/24 *[Direct/0] 01:45:48
> via ge-0/0/1.0
10.100.5.0/24 *[RIP/100] 00:47:18, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.1/32 *[Direct/0] 01:45:48
> via lo0.0
172.16.0.4/32 *[RIP/100] 00:47:18, metric 2, tag 0
> to 10.100.3.2 via ge-0/0/1.0
172.16.0.5/32 *[RIP/100] 00:44:25, metric 3, tag 0
> to 10.100.3.2 via ge-0/0/1.0
lab@vsrx-R1>This might seem a bit confusing at first. Why do we look at received routes by specifying the advertiser’s address, and look at the routes we are sending by specifying our own address?
This comes down to how RIP works. RIP doesn’t establish a neighbor relationship or adjacency like other protocols.
On one interface, we could receive RIP updates from several different routers. So we need to specify which particular router we want to show the updates from.
Similarly, when we send an update out an interface we don’t send it to one specific router, we send it to all RIP routers listening on that network. So we only need to specify the interface address we are sending from.
RIP and Routing Instances
We may need to configure RIP under a routing instance. The configuration is almost the same, except it is configured under the routing instance.
We can modify R5 to show this in action. We create a new routing instance of type virtual-router and put the relevant interfaces into the routing instance. We then add RIP. It looks like this:
routing-instances {
my-routing-instance {
protocols {
rip {
group my-group-1 {
export my-rip-export;
neighbor ge-0/0/1.0;
}
group my-group-2 {
export my-rip-export;
neighbor ge-0/0/0.0;
}
}
}
instance-type virtual-router;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface lo0.0;
}
}We can run the same show commands as before, but we need to add the ‘instance’ option and specify what routing instance we want to look at.
lab@vmx-R4> show rip neighbor instance my-routing-instance
Local Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-0/0/1.0 Up 10.100.3.2 224.0.0.9 mcast both 1
ge-0/0/0.0 Up 10.100.5.1 224.0.0.9 mcast both 1
lab@vmx-R4> show rip statistics instance my-routing-instance
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
9 0 0 0
ge-0/0/1.0: 6 routes learned; 5 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 8 8 2
Triggered Updates Sent 2 2 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 9 9 2
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
ge-0/0/0.0: 5 routes learned; 6 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 8 8 2
Triggered Updates Sent 2 2 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 9 8 2
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 0To view the routing table for our routing instance, we can either run a ‘show route’ and look through the output for the table we want, or specify the table in the show route command. In this case, the table we are interested in is my-routing-instance.inet.0
lab@vmx-R4> show route table my-routing-instance.inet.0
my-routing-instance.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[RIP/100] 00:04:35, metric 2, tag 0
to 10.100.5.2 via ge-0/0/0.0
> to 10.100.3.1 via ge-0/0/1.0
10.100.1.0/24 *[RIP/100] 00:04:52, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
10.100.2.0/24 *[RIP/100] 00:04:35, metric 3, tag 0
to 10.100.5.2 via ge-0/0/0.0
> to 10.100.3.1 via ge-0/0/1.0
10.100.3.0/24 *[Direct/0] 00:04:52
> via ge-0/0/1.0
10.100.3.2/32 *[Local/0] 00:04:52
Local via ge-0/0/1.0
10.100.4.0/24 *[RIP/100] 00:04:35, metric 2, tag 0
> to 10.100.5.2 via ge-0/0/0.0
10.100.5.0/24 *[Direct/0] 00:04:52
> via ge-0/0/0.0
10.100.5.1/32 *[Local/0] 00:04:52
Local via ge-0/0/0.0
169.254.0.0/24 *[RIP/100] 00:04:52, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.1/32 *[RIP/100] 00:04:52, metric 2, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.2/32 *[RIP/100] 00:04:52, metric 3, tag 0
> to 10.100.3.1 via ge-0/0/1.0
172.16.0.3/32 *[RIP/100] 00:04:35, metric 3, tag 0
> to 10.100.5.2 via ge-0/0/0.0
172.16.0.4/32 *[Direct/0] 00:04:52
> via lo0.0
172.16.0.5/32 *[RIP/100] 00:04:35, metric 2, tag 0
> to 10.100.5.2 via ge-0/0/0.0
224.0.0.9/32 *[RIP/100] 00:04:52, metric 1
MultiRecvConclusions
Configuring RIP is a simple process on Junos, but you do need to remember to add an export policy to advertise RIP routes to other RIP routers.
In part 2 we will look at authentication, changing the metric values, and changing the route preference value for RIP.