This article is a continuation of previous post about RIP Auto-Summarization and it's impact on discontiguous networks in Cisco networks, but this time from Juniper's perspective. Using the default auto-summary on Cisco devices can lead to routing loops in case of discontiguous networks, as shown in quiz 15.
As mentioned in the previous article, JunOS is not susceptible of such problem for the simple reason that there's no auto-summary command/option for RIP in Juniper world.
Another very important note is: according to the
Here is how the basic, minimum configuration looks like:
The use of groups and neighbor commands looks odd, but it provides freedom to apply different policies to different neighbors. It is very unlikely that RIP will be used for large scale networks, but could be used on edge where different groups appear useful.
Another oddness (at least for a Cisco oriented engineer) is the fact that the above configuration does not produce any exchange of routing information - as described above, the default export policy for RIP is reject all. If you want your RIP speaker to advertise routing information, you must configure routing policies: policy statements that will be applied as export policy under rip protocol, as shown below:
protocols {
rip {
group INTERNAL {
export RIP_EXPORT ;
neighbor em0.0;
neighbor em1.0;
}
}
}
policy-options {
policy-statement RIP_EXPORT {
term direct {
from protocol direct;
then accept;
}
term rip {
from protocol rip;
then accept;
}
}
}
Note-1: there are multiple ways of configuring policies (different policy-statements, or a single term, or using route filters, etc) - but it's outside the scope of this article
_Note-2: the export can be applied under different levels of hierarchy (rip, group, neighbor) _
As a side note about routing policies, the default import policy is "accept all", so unless you need to apply some granular import policy, all RIP routes will be imported (accepted).
The RIP routes in the routing table:
root@R3-BR>show route protocol rip inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.0/24 *[RIP/100] 00:12:14, metric 2, tag 0 > to 192.168.1.2 via em0.0 172.16.2.0/24 *[RIP/100] 00:12:17, metric 2, tag 0 > to 192.168.1.6 via em1.0 192.168.1.0/30 [RIP/100] 00:12:17, metric 3, tag 0 > to 192.168.1.6 via em1.0 192.168.1.4/30 [RIP/100] 00:12:14, metric 3, tag 0 > to 192.168.1.2 via em0.0 192.168.1.8/30 *[RIP/100] 00:12:17, metric 2, tag 0 to 192.168.1.2 via em0.0 > to 192.168.1.6 via em1.0 224.0.0.9/32 *[RIP/100] 00:12:26, metric 1 MultiRecv root@R3-BR>show route 192.168.1.0/30 extensive exact inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden) 192.168.1.0/30 (2 entries, 0 announced)Direct Preference: 0 Next hop type: Interface Next-hop reference count: 1 Next hop: via em0.0, selected State: <active int=""> Age: 12:29 Task: IF AS path: I RIP Preference: 100 Next hop type: Router, Next hop index: 549 Next-hop reference count: 4 Next hop: 192.168.1.6 via em1.0, selected State: <int>Inactive reason: Route Preference Age: 12:21 Metric: 3 Tag: 0 Task: RIPv2 AS path: I Route learned from 192.168.1.6 expires in 170 seconds
Some conclusions from the above output:
- RIP preference (the equivalent of Cisco's administrative distance) is 100
- active routes are only the ones marked with an asterisk *
- extensive output provides a lot of useful information, such as: status, inactive reason, time when was learned, etc
In order to verify the status of RIP, the following two commands may be used:
root@R3-BR>show rip neighbor Source Destination Send Receive In Neighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --- em0.0 Up 192.168.1.1 224.0.0.9 mcast both 1 em1.0 Up 192.168.1.5 224.0.0.9 mcast both 1 root@R3-BR>show rip statistics RIPv2 info: port 520; holddown 120s. rts learned rts held down rqsts dropped resps dropped 5 0 0 0 em0.0: 3 routes learned; 0 routes advertised; timeout 180s; update interval 30s Counter Total Last 5 min Last minute ------- ----------- ----------- ----------- Updates Sent 0 0 0 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 0RIPv2 Updates Received 15 10 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 …
In the end, as part of the troubleshooting, traceoptions will provide you all the debugging information that you might be interested in:
rip {
traceoptions {
file rip-debug;
flag update;
flag route;
}
}
!
!
root@R3-BR> show log rip-debug
Sep 12 17:49:57 R3-BR clear-log[1922]: logfile cleared
Sep 12 17:49:58.702387 received response: sender 192.168.1.2, command 2, version 2, mbz: 0; 4 routes.
Sep 12 17:49:58.702432 192.168.1.8/30: metric-in: 2, change: 2 -> 2; # gw: 2, pkt_upd_src 192.168.1.2, inx: 0, rte_upd_src 192.168.1.2
Sep 12 17:49:58.702446 192.168.1.4/30: metric-in: 3, change: 3 -> 3; # gw: 1, pkt_upd_src 192.168.1.2, inx: 0, rte_upd_src 192.168.1.2
Sep 12 17:49:58.702456 172.16.2.0/24: metric-in: 3, change: 2 -> 3; # gw: 1, pkt_upd_src 192.168.1.2, inx: 1, rte_upd_src 0.0.0.0
Sep 12 17:49:58.702465 172.16.1.0/24: metric-in: 2, change: 2 -> 2; # gw: 1, pkt_upd_src 192.168.1.2, inx: 0, rte_upd_src 192.168.1.2
Sep 12 17:50:04.827218 Preparing to send RIPv2 updates on nbr em1.0, group: INTERNAL.
Sep 12 17:50:14.936562 Preparing to send RIPv2 updates on nbr em0.0, group: INTERNAL.
Thanks for reading !
Costi is a network and security engineer with over 10 years of experience in multi-vendor environments. He holds a CCIE Routing and Switching certification and is currently pursuing same expert-level certifications in other areas. He believes that the best way to learn and understand networking topics is to challenge yourself to fix different problems, production-wise or lab-type exams. He also enjoys teaching networking and security technologies, whevever there is an opportunity for it.
Comments
comments powered by Disqus