OK, that’s enough of an IGP overview. There’s little doubt that the router-jockey readers of this book are chomping at the bit to start routing some packets! Let’s demonstrate basic RIP configuration and operational mode commands that assist in troubleshooting a RIP operation in a JUNOS software environment.
Figure 4-3 depicts the topology for the Cisco Systems/IOS to Juniper Networks/JUNOS software RIP integration scenario. It shows the existing Beer-Co RIP network, which currently consists of two Cisco Systems 2600 series routers running IOS version 12.3(15b) and interconnected by a serial link. Beer-Co is expanding its widget operation and plans to add two additional locations. Despite the existing infrastructure, the CIO has opted to become a multivendor shop, and a decision has been made to deploy two Juniper Networks J-series routers. The existing (and planned) IP addressing is shown and contains a mix of subnetted class A and class C addresses (just to keep things interesting). Each router’s loopback address is also shown, along with a simulated customer network that is instantiated via a static route (labs commonly use a static route to represent a customer network for purposes of reducing equipment requirements). Note that the last digit of each router’s loopback address is tied numerically to that router’s simulated customer network to help ease requirements on the reader’s memory.
As a reminder, recall that in this lab, each router’s Fast Ethernet
interface is tied to a virtual LAN (VLAN) switch, and VLAN tags are used
to establish links between communicating routers. The subinterface/logical
unit of each interface match the associated VLAN tag value, which is also
shown in the figure. You may assume that all router interface properties
are correctly configured to permit communication with directly attached
neighbors. The following code snippets show the Fast Ethernet interface
configuration at Cisco router Malt and
Juniper router Ale.
Malt’s FastEthernet0/1 interface and subinterface
configuration:
interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.69 encapsulation dot1Q 69 ip address 192.168.1.1 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain test no snmp trap link-status
Ale’s fe-0/0/0 interface and logical unit
configuration:
[fe-0/0/0 {
vlan-tagging;
unit 69 {
description Ale-to_Malt;
vlan-id 69;
family inet {
address 192.168.1.2/30;
}
}
unit 1121 {
description Ale-to_Lager;
vlan-id 1121;
family inet {
address 10.10.129.1/24;
}
}
}Before adding the new RIP routers, it makes sense to first inspect
the related RIP configuration in the Cisco platform to get a feel for
what RIP configuration tasks will be needed on the Juniper Networks
boxes. The RIP-related configuration parts from router Malt are shown, along with some inline comment
as to what each part is doing:
Malt#show run
Building configuration...
. . .
!
key chain test
key 1
key-string jncie
. . .The key chain configuration is used to provide authentication to
various routing protocols, ostensibly RIP, in this example. The named
key chain has a single key that is numbered as 1 using a key value of jncie. Key chains provide the ability to
rotate the current key, based on start and end times (which are not
specified in this example). As of this writing, JUNOS software supports
authentication key chains only for the Label Distribution Protocol
(LDP), OSPF, and BGP. RIP supports a single password-MD5 key, which is
good for us because that is just what’s needed here:
interface FastEthernet0/1.69 encapsulation dot1Q 69 ip address 192.168.1.1 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain test no snmp trap link-status ! . . .
The two subinterface-level IP rip
authentication statements configure RIP authentication for
messages sent out, or received from, the related interface. The commands
specify the associated key chain and authentication approach, which
again is MD5 in this example:
router rip version 2 redistribute connected redistribute static route-map TAGGING network 10.0.0.0 network 192.168.1.0 distribute-list 3 out static no auto-summary . . .
This portion of the configuration actually enables the RIP
process. Things begin with the specification that RIP version 2 is to be
run. Considering the VLSM in effect, this is a very good choice. The
network statements, which are assumed
to fall on classful boundaries, define the set of interfaces on which
RIP should operate. Rather than listing interfaces directly by name,
they are indirectly identified through the interface’s IP address.
Notice the two forms of route redistribution in effect. The redistribute connected and redistribute static statements, the latter
with an associated route map, serve to redistribute connected and static
routes, respectively. A distribution list could also have been used to
control the routes advertised into RIP. The connected routes will catch
the router’s serial, Fast Ethernet, and loopback interface subnets. You
will have to wait and see what static route redistribution is doing when
you inspect the related route map.
The no-auto-summary statement
disables the default (Cisco) behavior of automatically summarizing at
classful network boundaries. When combined with RIP version 2, which
conveys a network mask, VLSM/CIDR is supported.
ip route 0.0.0.0 0.0.0.0 Null0 ip route 200.0.100.0 255.255.255.0 Null0 ! access-list 3 permit 200.0.100.0 access-list 4 permit 0.0.0.0 !
Tip
The whole classful addressing concept is totally alien to a
Juniper Networks router, as the boxes were designed in an era well
after the concept of class-based addressing had come and gone. To help
illustrate this point, JUNOS software has no need for an ip classless statement as always seen in
IOS, and consistently uses CIDR /
notation for prefix lengths.
This portion of the configuration defines two static routes: the
former is a default route and the latter is the simulated customer
network associated with Malt. Both
are pointed to null0 as a next hop,
which means that any traffic that longest-matches either of these two
routes will be discarded.
This may strike the reader as odd, so some additional explanation
is warranted. The assumption is that the real customer network will be
assigned a mask longer than the /24 used by the static route that
currently represents it—for example, a /28. Therefore, packets actually
sent to hosts within the customer network will longest-match against the
customer network interface route (longest-match rules), and are thereby
spared the ignominious treatment of a one-way trip to null0 land. If, on the other hand, the
customer network interface is down, these packets are discarded as they
now longest-match against the static route—meanwhile, the presence of
the static route is preventing route churn in the rest of the network
because it’s always being advertised in RIP. This stability comes with
the downside that, during a customer network interface outage, other
routers in the RIP domain have a false belief that hosts on the customer
network are still reachable, and the resultant traffic is forwarded over
the enterprise network only to be discarded by the last hop. This
technique is somewhat common in service provider networks, because
control plane stability is generally more important than the network
bandwidth that is wasted by forwarding packets across a network only to
shunt them to null0.
In the RIP scenario, the two Cisco routers are attached to some other network cloud. Rather than run a routing protocol or define numerous static routes, the administrator relies on a default route to direct matching traffic into this cloud. The dotted lines on the drawing represent that this cloud is not part of the actual test bed.
Also, note the two related IP access control lists (ACLs), each matching on one of the two static routes. These ACLs are in turn referenced by the route map:
route-map TAGGING permit 10 match ip address 3 set metric 3 ! route-map TAGGING permit 20 match ip address 4 set tag 100 . . . End
The TAGGING route map first
matches against ACL 3 and sets the outgoing metric to 3 for matching
prefixes (the simulated customer network route in this case). The
default metric would be 1, so this action simulates a network that is
two router hops farther away than it actually is. This might be done to
cause another source of this route to be preferred (the lower hop count
wins), or, perhaps, to limit the scope of stations that can reach this
network (recall that in RIP, 16 means you cannot get there). Like it or
not, this is an example of how route maps are used in IOS to alter route
attributes, perhaps just to keep the scenario interesting.
The permit 20 statement evokes
ACL 4, which matches the default route for purposes of setting a route
tag. In this example, the tag happens to be based on the router’s
loopback address. It’s common to tag routes that are redistributed for
purposes of tracking down the source of the route when troubleshooting,
or for use in policy matching based on tag values. This is especially
important when performing mutual route redistribution, which is a
process prone to routing loops when route filtering precautions are not
exercised.
A quick look at the state of the IP route table at router
Malt is performed before any
modifications are made. This will serve as the network baseline for
future comparison:
Malt#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user s
tatic route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
R 200.0.200.0/24 [120/3] via 10.1.254.2, 00:00:03, Serial0/0
S 200.0.100.0/24 is directly connected, Null0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.128.100/32 is directly connected, Loopback0
R 10.10.128.200/32 [120/1] via 10.1.254.2, 00:00:03, Serial0/0
C 10.1.254.0/24 is directly connected, Serial0/0
C 10.1.254.2/32 is directly connected, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, FastEthernet0/1.69
192.168.2.0/30 is subnetted, 1 subnets
R 192.168.2.0 [120/1] via 10.1.254.2, 00:00:04, Serial0/0
S* 0.0.0.0/0 is directly connected, Null0No real surprises here. Malt
has several directly connected routes, in the form of its FA 0/1.69, loopback 0, and serial 0/0 interfaces. And the two locally defined
static routes, 0.0.0.0 and 200.0.0.100, are both pointing to null0. Lo and behold, Malt has learned three routes via RIP:
Barley’s FA 0/1.70 route (192.168.2.0), its loopback
interface route (10.10.128.200), and the simulated customer route
(200.0.200.0). Note that the customer route received from Barley demonstrates the effects of the route
map. This route’s received hop count is 3 whereas the other two routes
advertised by Barley were received
with the default value of 1. The hop count/metric is displayed just
after the administrative distance, which for RIP is 120. Here is a
summary view of the RIP routes at Barley:
Barley#show ip route rip
R 200.0.100.0/24 [120/3] via 10.1.254.1, 00:00:14, Serial0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
R 10.10.128.100/32 [120/1] via 10.1.254.1, 00:00:14, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
R 192.168.1.0 [120/1] via 10.1.254.1, 00:00:14, Serial0/0With Barley displaying the
same type and number of routes, baseline operation is
confirmed.
The operational aspects of the RIP network design, as determined through analysis of the legacy RIP configuration, are as follows:
RIPv2 (without auto-summarization).
Defaults are in place for update, hold down, and route timeout timers.
MD5 authentication is in effect using key ID 1 with string
jncie.Direct networks are being redistributed.
The static route representing an attached customer network is redistributed with an artificially escalated hop count of 3.
Based on the analysis of the IOS RIP configuration, we know what
needs to be done at Ale and Lager. To help mitigate any operational
impacts, it is decided to first bring up the RIP peerings between
Ale and Lager before attaching them to the existing
RIP backbone.
The configuration begins with the definition of the static route
that simulates an attached customer network. The configuration steps
for Ale are:
lab@Ale>configureEntering configuration mode [edit] lab@Ale#edit routing-options[edit routing-options] lab@Ale#set static route 200.0.1/24 discard[edit routing-options] lab@Ale#showstatic { route 200.0.1.0/24 discard; }
With the static route defined, the change is committed and the
result confirmed (while still in configuration mode). In this example,
traffic matching the static route is directed to a discard next hop,
which means that no responses will be generated for matching traffic—a
true black hole from which nothing will escape. Another option would
be reject, which generates an
Internet Control Message Protocol (ICMP) error reporting that the
destination is unreachable. This creates functionality similar to
IOS’s null0, in that matching
traffic will generate host unreachable error messages. The reject option can assist in troubleshooting,
but it consumes router resources in the form of message generation,
which can be an issue during a large-scale denial of service (DoS)
attack, making discard the
preferred target for such a route:
[edit routing-options] lab@Ale#commitcommit complete [edit routing-options] lab@Ale#run show route protocol staticinet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 200.0.1.0/24 *[Static/5] 00:00:37Discard
The RIP configuration is now added to Ale. Start by moving to the RIP
configuration hierarchy, where the general options are
shown:
[edit routing-options] lab@Ale#top edit protocols rip[edit protocols rip] lab@Ale#set ?Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups authentication-key Authentication key (password) authentication-type Authentication type check-zero Check reserved fields on incoming RIPv2 packets > graceful-restart RIP graceful restart options > group Instance configuration holddown Hold-down time (10..180 seconds) + import Import policy message-size Number of route entries per update message (25..255) metric-in Metric value to add to incoming routes (1..15) no-check-zero Don't check reserved fields on incoming RIPv2 packets > receive Configure RIP receive options > rib-group Routing table group for importing RIP routes route-timeout Delay before routes time out (30..360 seconds) > send Configure RIP send options > traceoptions Trace options for RIP update-interval Interval between regular route updates (10..60 seconds) [edit protocols rip] lab@Ale#set
It should be apparent that many aspects of RIP are configurable
within JUNOS software. Some options are global, such as the
authentication key/type or import/export policy, which means they
apply to all groups (unless negated by a more specific group setting,
if available). Other parameters can be specified only at a subsequent
hierarchy. For example, a neighbor can be defined only within a group.
You can quickly explore the options available under send and receive using the command-line interface’s
(CLI’s) ? help utility:
[edit protocols rip] lab@Ale#set send ?Possible completions: broadcast Broadcast RIPv2 packets (RIPv1 compatible) multicast Multicast RIPv2 packets none Do not send RIP updates version-1 Broadcast RIPv1 packets [edit protocols rip] lab@Ale#set receive ?Possible completions: both Accept both RIPv1 and RIPv2 packets none Do not receive RIP packets version-1 Accept RIPv1 packets only version-2 Accept only RIPv2 packets
It’s apparent from the display that the send and receive settings globally control the RIP version and whether multicast (default for v2) or broadcast packets are sent. It just so happens that these same settings can also be specified on a per-neighbor (interface) basis—recall that in JUNOS software, the more-specific group-level configuration hierarchy settings override the less-specific global values. Let’s take a quick look at the options available under a group, which is where you can define neighbors (interfaces) that run RIP:
[edit protocols rip]
lab@Ale#set group rip ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> bfd-liveness-detection Bidirectional Forwarding Detection options
+ export Export policy
+ import Import policy
metric-out Default metric of exported routes (1..15)
> neighbor Neighbor configuration
preference Preference of routes learned by this group
route-timeout Delay before routes time out (30..360 seconds)
update-interval Interval between regular route updates (10..60 seconds)
| Pipe through a commandConfiguration options found at the neighbor level include the
import or export keyword, which is used to apply
routing policy to receive or transmit route updates, respectively.
Note that when applied at the neighbor level, any globally defined
import or export policies are negated. The router runs
either the global or the group policy, never
both, and the router always chooses the most specific application—a
neighbor level is more specific than a global level, of course. You
may recall that policy is used to control route exchange and alter
route attributes. The global preference for routes learned from a
particular neighbor can also be configured here. Note that in JUNOS
software, the concept of global preference is equivalent to that of
IOS’s administrative distance—this value is altered to make a source
of routing information more (lower value) or less (higher value)
preferred.
Tip
The terminology of groups and neighbors may seem a bit confusing at first, given the way RIP is configured in IOS. JUNOS software is optimized when routing peers with similar export policy are placed into the same group. As a result, even if you have only one peer, that neighbor needs to belong to a RIP group. Also, the term neighbor here actually means interface, given that RIP messages are not unicast to specific machines, but instead are broadcast or multicast to all RIP speakers on a given link. This means that specifying a single neighbor in the form of a multiaccess interface results in RIP communications with all RIP-capable routers on that LAN segment.
Ale’s RIP stanza is now
configured in accordance with the RIP design guideline discovered
when analyzing the legacy RIP configuration. Recall that the plan is
to first establish RIP peerings between Ale and Lager before trying route exchanges to the
Cisco routers (see Figure 4-3). Here is the
resulting RIP stanza, along with the set commands used to create it courtesy of
the display set function in the
CLI:
[edit protocols rip] lab@Ale#showsend multicast; receive version-2; authentication-type md5; authentication-key "$9$cf3rK84oGiHm-VgJ"; ## SECRET-DATA group rip { inactive: neighbor fe-0/0/0.69; neighbor fe-0/0/0.1121; } [edit protocols rip] lab@Ale#show | display setset protocols rip send multicast set protocols rip receive version-2 set protocols rip authentication-type md5 set protocols rip authentication-key "$9$cf3rK84oGiHm-VgJ" deactivate protocols rip group rip neighbor fe-0/0/0.69 set protocols rip group rip neighbor fe-0/0/0.1121
The global send multicast
statement ensures that we will only speak to RIPv2 nodes, as RIPv1
routers will not see multicast updates. The receive version-2 ensures that we process
only multicast updates, thereby configuring the router for
RIPv2-only operation. The authentication settings specify a (now
ciphered) text string of jncie
and indicates that MD5-based authentication should be used.
Tip
JUNOS software always encrypts passwords; IOS requires that the password encryption service be enabled for the same functionality.
Lastly, notice the two neighbor statements that identify what
interfaces RIP should run on. Note that the link to Malt is currently deactivated (inactive),
which means that portion of the configuration will be ignored. This
will result in Ale running RIP
only on the fe-0/0/0.1121
interface to Lager. Once RIP has
been confirmed between Ale and
Lager, this link will be
activated to enable RIP exchanges with the Cisco routers.
The one part of Ale’s
configuration yet to be addressed is the redistribution into RIP of
its connected and simulated customer static routes. Recall that in
JUNOS software, control over what routes enter and leave the route
table and the modification of attributes associated with these
routes, is controlled by routing policy. Here is an example of the
JUNOS route policy needed to match the Cisco router’s redistribution
of connected (direct) routes and the route map function that sets
the metric on a redistributed static route:
[edit policy-options policy-statement rip_export] lab@Ale#showterm 1 { from protocol direct; then accept; } term 2 { from { protocol static; route-filter 200.0.1.0/24 exact; } then { metric 3; accept; } } [edit policy-options policy-statement rip_export] lab@Ale#show | display setset policy-options policy-statement rip_export term 1 from protocol direct set policy-options policy-statement rip_export term 1 then accept set policy-options policy-statement rip_export term 2 from protocol static set policy-options policy-statement rip_export term 2 from route-filter 200.0.1.0/24 exact set policy-options policy-statement rip_export term 2 then metric 3 set policy-options policy-statement rip_export term 2 then accept
The newly created RIP policy is applied to the RIP group
(alternatively, it could be applied globally in this example) as
export, where it will control the
exchange of routes that are advertised into RIP. The default RIP
import policy, which is to accept RIP routes, is left
unaltered.
[edit] lab@Ale#set protocols rip group rip export rip_export[edit] lab@Ale#show protocols ripsend multicast; receive version-2; authentication-type md5; authentication-key "$9$cf3rK84oGiHm-VgJ"; ## SECRET-DATA group rip {export rip_export;inactive: neighbor fe-0/0/0.69; neighbor fe-0/0/0.1121; }
You may assume that a compatible RIP policy configuration has
been added to Lager and that the
changes are committed.
With the RIP and related static route/policy configuration in
place at Ale and Lager, the operation of RIP can be confirmed.
Start with the confirmation that RIPv2 is running, and that it is doing
so on the expected interfaces:
lab@Ale>show rip neighborSource Destination Send Receive In Neighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --- fe-0/0/0.1121 Up 10.10.129.1 224.0.0.9 mcast v2 only1
The output of the show rip
neighbor command confirms that Ale is set for v2 operation, and that RIP is
running on its link to Lager. The Up
status indicates that the interface is operational, but not that any
particular neighbor has been detected. The In Met column displays the
metric value that will be added to any route updates received over the
associated interfaces; by default, each received update has its metric
incremented by one before being placed into the route table.
The general RIP statistics confirm that updates are being sent and
received, that no errors are occurring, and that in the case of Ale, three routes have been learned via RIP,
indicating that RIP is operating correctly between Ale and Lager:
lab@Ale>show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
3 0 0 0
fe-0/0/0.1121: 3 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 25 11 2
Triggered Updates Sent 1 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 17 11 2
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 1 0 0
RIP Requests Received 1 0 0
RIP Requests Ignored 0 0 0And now we confirm the presence of RIP routes in Ale’s route table:
lab@Ale>show route protocol rip
inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.2/32 *[RIP/100] 00:09:54, metric 2, tag 0
> to 10.10.129.2 via fe-0/0/0.1121
192.168.2.0/30 *[RIP/100] 00:09:54, metric 2, tag 0
> to 10.10.129.2 via fe-0/0/0.1121
200.0.2.0/24 *[RIP/100] 00:09:54, metric 4, tag 0
> to 10.10.129.2 via fe-0/0/0.1121
224.0.0.9/32 *[RIP/100] 00:10:57, metric 1
MultiRecvAle’s route table contains the
expected RIP routes, considering that RIP is not yet enabled to Malt and Barley. Notice that Lager has advertised its directly connected
loopback interface (10.10.128.2) route to Ale. Also of note is that the JUNOS software
route table displays the local RIP cost, as opposed to the metric
received in the route update. This differs a bit from IOS, which
displays the received RIP metric rather than local cost (received + 1 by
default). The 200.0.0.2/24 static route defined at Lager has been injected into RIP with a metric
of 3 due to the action of its export policy—this route is installed in
Ale’s route table with a local cost
of 3 + 1, or 4. You’ll also see that the RIP global preference in JUNOS
software is 100.
A later section details additional operational mode commands that assist in debugging RIP operation. But right now, all seems to be working as expected, so there is not much to debug. Of course, things might change when tying into the Cisco portion of the network.
With RIP operation in the Juniper and Cisco domains confirmed,
it’s time to fire up RIP between the two vendors’ boxes to see what
happens. RIP is a simple protocol, so what could go wrong? Things start
with the activation of the RIP neighbor (interface) linking Ale to Malt. Similar steps are performed at Lager for its RIP interface to Barley:
lab@Ale>configureEntering configuration mode [edit] lab@Ale#activate protocols rip group rip neighbor fe-0/0/0.69[edit] lab@Ale#commitcommit complete
After a few minutes, RIP updates should have propagated. Let’s
start with a quick look at RIP statistics at router Lager, as any problems will likely manifest
in the form of an incrementing error counter:
[edit]
lab@Lager#run show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
10 0 0 0
fe-0/0/0.1121: 3 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 29 11 2
Triggered Updates Sent 1 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 29 10 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
fe-0/0/0.70: 7 routes learned; 3 routes advertised; timeout 180s;
update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 29 11 2
Triggered Updates Sent 1 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 31 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 0The RIP statistics indicate that all is normal. Lager is confirming that 10 routes have been
learned via RIP, with three coming from its link to Ale and the balance learned from its link to
Barley. Authentication is clearly
working, given the learned routes and no indication of message
discards or errors.
Next, confirm whether any RIP routes are present in the route
table of Lager:
[edit]
lab@Lager#run show route protocol rip
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[RIP/100] 00:16:35, metric 2, tag 200
> to 192.168.2.1 via fe-0/0/0.70
10.1.254.0/24 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.1.254.1/32 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.10.128.100/32 *[RIP/100] 00:16:35, metric 3, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.10.128.200/32 *[RIP/100] 00:16:35, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.10.128.1/32 *[RIP/100] 00:16:29, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
192.168.1.0/30 *[RIP/100] 00:16:29, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
200.0.1.0/24 *[RIP/100] 00:16:29, metric 4, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
200.0.100.0/24 *[RIP/100] 00:16:35, metric 5, tag 0
> to 192.168.2.1 via fe-0/0/0.70
200.0.200.0/24 *[RIP/100] 00:11:44, metric 4, tag 0
> to 192.168.2.1 via fe-0/0/0.70
224.0.0.9/32 *[RIP/100] 00:16:50, metric 1
MultiRecvRIP routes are present. The routes learned through RIP include
the serial link between Malt and
Barley (10.1.254.0/24 and
associated host routes), the two simulated customer networks
(200.0.100/24 and 200.0.200/24), and the RIP peering network for the
link between Malt and Ale (192.168.2.0/30). Also present are the
/32 routes for Malt’s and Barley’s loopback 0 interfaces
(10.10.128.100 and 10.10.128.200). The default route is present, and
it’s correctly pointing to neighbor Barley, given the metric should be less via
this path than forwarding through Ale to reach the default advertised by
Barley.
The RIP routes at Barley are
examined next:
Barley#show ip route rip
R 200.0.1.0/24 [120/4] via 10.1.254.1, 00:00:27, Serial0/0
R 200.0.2.0/24 [120/3] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
R 200.0.100.0/24 [120/3] via 10.1.254.1, 00:00:27, Serial0/0
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
R 10.10.128.100/32 [120/1] via 10.1.254.1, 00:00:27, Serial0/0
R 10.10.129.0/24 [120/1] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
R 10.10.128.1/32 [120/2] via 10.1.254.1, 00:00:27, Serial0/0
R 10.10.128.2/32 [120/1] via 192.168.2.2, 00:00:25, FastEthernet0/1.70
192.168.1.0/30 is subnetted, 1 subnets
R 192.168.1.0 [120/1] via 10.1.254.1, 00:00:27, Serial0/0The display confirms that RIP exchanges are working between the
Juniper Networks routers and the Cisco boxes; Barley has a RIP route for both of Ale’s and Lager’s simulated customer networks
(200.0.1/24 and 200.0.2/24) as well as the link between Ale and Lager (10.10.129.0/24), in addition to the
/32 loopback addresses assigned to Ale and Lager (10.10.128.1 and 10.10.128.2).
A traceroute is performed from Lager to the simulated network on Barley to validate the data plane and
resulting forwarding paths (the no-resolve switch ensures that the local
router does not waste time trying to perform reverse Domain Name
System [DNS] lookups on the resulting IP addresses in the event that
DNS is not configured in the lab):
[edit]
lab@Ale#run traceroute no-resolve 200.0.200.1
traceroute to 200.0.200.1 (200.0.200.1), 30 hops max, 40 byte packets
1 192.168.1.1 9.498 ms 9.705 ms 10.127 ms
2 10.1.254.2 19.700 ms 20.004 ms 20.073 ms
3 10.1.254.2 19.772 ms !H * 20.392 ms !HThe traceroute results are as expected; router Ale crossed two routers to reach the
simulated customer network, and as previously noted, the null0 action of the longest match resulted
in ICMP host unreachable messages, as indicated by the !H in the return. The results seem to
indicate that RIPv2 is working between JUNOS software and IOS.
Congratulations!
Actually, nothing in the realm of internetworking works the
first time. In fact, the results of that traceroute should have
gotten you thinking a bit. Given the RIP topology, Ale should have two
equal cost paths to the simulated customer network attached to
Barley. After all, it’s two hops
to reach Barley via Malt, but also two hops to reach Barley via Lager. Knowing that JUNOS software
automatically performs load balancing over as many as 16 equal cost
paths, you’d expect to see Ale
with two equal cost routes for the 200.0.200/24 route.
Unfortunately, previous displays confirm this is not the case. A
similar condition exists at Lager
with regard to the simulated customer route at Malt.
There are a few tools for troubleshooting this type of issue
in JUNOS software. One approach is protocol tracing, used to show
the RIP messages being sent and received, and the overall results of
RIP message processing. Tracing is similar to the IOS
debug feature. Given that RIP is a DV protocol,
you can also avail yourself of the show
route advertising-protocol and the show route receiving-protocol commands. As
their names imply, these commands display what routes the local
router is advertising out a given interface or what routes are being
received (learned) from a particular neighbor. The process begins at
router Lager:
[edit]
lab@Lager#run show route advertising-protocol rip ?
Possible completions:
<neighbor> IP address of neighbor (local for RIP and RIPng)The command syntax help string of ? is useful here because it reminds us
that for the RIP form of this command, you must specify the
local interface address; recall that RIP
generates broadcast or multicast updates to all neighbors on the
link, so unlike BGP, where a specific neighbor address is specified,
it’s the local IP address for RIP.
[edit]
lab@Lager#run show route advertising-protocol rip 10.10.129.2
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.2/32 *[Direct/0] 02:31:29
> via lo0.0
192.168.2.0/30 *[Direct/0] 02:31:29
> via fe-0/0/0.70
200.0.2.0/24 *[Static/5] 02:32:10
DiscardThe result leaves something to be desired—something such as a
route advertisement for the 200.0.200/24 route, that is! The
receiving-protocol form of the
command is used to confirm that whatever is wrong is at least
symmetrical:
lab@Lager#run show route receive-protocol rip ?
Possible completions:
<peer> IP address of neighborNote that for the receiving-protocol command, RIP requires
the specification of a specific neighbor IP
address, which in turn is reachable via a RIP-enabled interface (a
good way to look at this is to consider that transmitted updates are
sent to all neighbors, but received updates come from a specific
neighbor—a source IP address is never of the multicast/broadcast
form):
[edit]
lab@Lager#run show route receive-protocol rip 10.10.129.1
inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.128.1/32 *[RIP/100] 01:01:13, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
192.168.1.0/30 *[RIP/100] 01:01:13, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
200.0.1.0/24 *[RIP/100] 01:01:13, metric 4, tag 0
> to 10.10.129.1 via fe-0/0/0.1121The preceding output proves that, like Lager, Ale is not readvertising the 200.0.100/24
route learned from Malt. For
added verification, we configure RIP tracing at Ale.
[edit protocols rip]
lab@Ale#set traceoptions file rip_trace
[edit protocols rip]
lab@Ale# set traceoptions flag ?
Possible completions:
all Trace everything
auth Trace RIP authentication
error Trace RIP errors
expiration Trace RIP route expiration processing
general Trace general events
holddown Trace RIP hold-down processing
normal Trace normal events
packets Trace all RIP packets
policy Trace policy processing
request Trace RIP information packets
route Trace routing information
state Trace state transitions
task Trace routing protocol task processing
timer Trace routing protocol timer processing
trigger Trace RIP triggered updates
update Trace RIP update packets
[edit protocols rip]
lab@Ale# set traceoptions flag update detail
[edit protocols rip]
lab@Ale# commitTip
No one wants a tool he can’t use when he needs it. JUNOS software protocol tracing is much like Cisco Systems’ debug in that it’s a great way to gain insight into the operation of a given protocol, especially when things are not working. The upside is that you can deploy tracing on a Juniper Networks router, in a production network, with little to no operational impact—that is, the manual does not warn against using tracing, which is the case for debug in IOS. With that said, it is a best practice to enable tracing only when needed and only at the level of detail needed, and then to remove the tracing configuration when the job is done.
Also note that the Juniper Networks architecture cleanly separates the control and forwarding planes, which means that you can monitor interface traffic (tcpdump) or trace protocol operation only when it is sourced from or destined to the local router’s Routing Engine (RE). You cannot monitor or trace transit traffic unless a sampling configuration is used to sample/mirror such traffic out of a specific interface.
This example shows the RIP tracing options along with a sample
RIP tracing configuration. Here, traffic matching the update flag is written to a file called
rip_trace. Various other trace
flags exist and are useful when dealing with specific issues, such
as using the auth flag when you
suspect an authentication problem. The rip_trace file is monitored in real time
with the monitor start
command:
[edit protocols rip]
lab@Ale#run monitor start rip_trace
. . .
Aug 15 02:00:30.039884 Update job: sending 20 msgs; nbr: fe-0/0/0.1121;
group: rip; msgp: 0x876a000.
Aug 15 02:00:30.039916 nbr fe-0/0/0.1121; msgp 0x876a000.
Aug 15 02:00:30.039985 0.84.1.20/0x46c25e20: tag 3, nh
0.0.0.0, met 0.
Aug 15 02:00:30.040011 10.10.128.1/0xffffffff: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:30.040027 192.168.1.0/0xfffffffc: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:30.040041 200.0.1.0/0xffffff00: tag 0, nh
0.0.0.0, met 3.
Aug 15 02:00:30.040053 sending msg 0x876a004, 4 rtes
(needs MD5)
Aug 15 02:00:30.040691 Update job done for nbr fe-0/0/0.1121
group: rip
Aug 15 02:00:32.560426 received response: sender 10.10.129.2,
command 2, version 2, mbz: 0; 5 routes.
Aug 15 02:00:32.560579 10.10.128.2/0xffffffff: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:32.560645 192.168.2.0/0xfffffffc: tag 0, nh
0.0.0.0, met 1.
Aug 15 02:00:32.560694 200.0.2.0/0xffffff00: tag 0, nh
0.0.0.0, met 3.
*** monitor and syslog output disabled, press ESC-Q to enable ***You can enter the Esc-q key sequence to suspend trace output
to the screen while information is still being written to the trace
field. Pressing Esq-q again resumes output to the screen. It’s nice
to be able to enable tracing and suspend it on demand so that you
can read what has been painted to the screen, without having to type
something such as “undebug IP rip,” all while your screen is
overflowing with debug data. Use the monitor stop command to stop tailing the
logfile. The monitor list command
shows any logfiles that are being monitored.
The RIP tracing information relating to neighbor fe-0/0/0.1121 confirms the results of the
show route-advertising protocol
command; namely that Lager is not
readvertising routes that it learns via RIP to other RIP neighbors.
Having seen what there is to be seen, RIP tracing is diligently
removed:
[edit protocols rip] lab@Ale#delete traceoptions[edit protocols rip] lab@Ale#commitcommit complete
Think back to your knowledge of JUNOS software routing policy; you’ll recall that an export policy is the entity responsible for taking active routes from the route table and placing them into outgoing protocol updates. Because the problem route is in the route table, is active, and is confirmed as not being advertised to another RIP neighbor, it would seem to be a classic case of broken export policy. But why is our export broken?
In JUNOS software, all protocols have a default import and export
policy. The default import policy for RIP is to accept all (sane) RIP
routes, as you might expect. However, the default RIP export policy is
to advertise nothing; not even routes learned
through RIP! Put another way, and for whatever reason, the configuration
of RIP in JUNOS software is not a simple matter of router rip combined with a few network statements. You will almost always
want the RIP router to propagate routes learned via RIP; to do this you
will need to add explicit export policy.
You already have a RIP export policy in effect to advertise the direct (connected) and the simulated customer static routes. Therefore, a quick modification will put things right again in RIP land:
[edit policy-options policy-statement rip_export] lab@Ale#showterm 1 { from protocol direct; then accept; } term 2 { from { protocol static; route-filter 200.0.1.0/24 exact; } then { metric 3; accept; } } [edit policy-options policy-statement rip_export] lab@Ale#set term 3 from protocol rip[edit policy-options policy-statement rip_export] lab@Ale#set term 3 then accept[edit policy-options policy-statement rip_export] lab@Ale#showterm 1 { from protocol direct; then accept; } term 2 { from { protocol static; route-filter 200.0.1.0/24 exact; } then { metric 3; accept; } }term 3 {from protocol rip;then accept;}
A similar change is also made (and committed) to the export policy
at Lager. After a few minutes, the
results are confirmed:
[edit]
lab@Lager#run show route receive-protocol rip 10.10.129.1
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.254.2/32 *[RIP/100] 00:01:22, metric 3, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
10.10.128.100/32 *[RIP/100] 01:31:13, metric 3, tag 0
to 192.168.2.1 via fe-0/0/0.70
> to 10.10.129.1 via fe-0/0/0.1121
10.10.128.1/32 *[RIP/100] 01:31:07, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
192.168.1.0/30 *[RIP/100] 01:31:07, metric 2, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
200.0.1.0/24 *[RIP/100] 01:31:07, metric 4, tag 0
> to 10.10.129.1 via fe-0/0/0.1121
200.0.100.0/24 *[RIP/100] 01:31:13, metric 5, tag 0
> to 192.168.2.1 via fe-0/0/0.70
to 10.10.129.1 via fe-0/0/0.1121
_ _juniper_private1_ _.inet.0: 2 destinations, 2 routes (2 active,
0 holddown, 0 hidden)The show route-receiving protocol
rip command at Lager
confirms that Ale is now correctly
readvertising RIP routes learned from Malt. You can also see the effects of the
modified export policy in the show
route-advertising protocol rip command issued at Lager:
[edit]
lab@Lager#run show route advertising-protocol rip 10.10.129.2
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[RIP/100] 01:31:24, metric 2, tag 200
> to 192.168.2.1 via fe-0/0/0.70
10.1.254.0/24 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.1.254.1/32 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.10.128.200/32 *[RIP/100] 01:31:24, metric 2, tag 0
> to 192.168.2.1 via fe-0/0/0.70
10.10.128.2/32 *[Direct/0] 03:05:21
> via lo0.0
192.168.2.0/30 *[Direct/0] 03:05:21
> via fe-0/0/0.70
200.0.2.0/24 *[Static/5] 03:06:02
Discard
200.0.200.0/24 *[RIP/100] 01:26:33, metric 4, tag 0
> to 192.168.2.1 via fe-0/0/0.70Lager’s output confirms that it
too is now readvertising RIP learned routes. As a final verification,
the route table at Lager is inspected
for the customer network associated with Malt:
[edit]
lab@Lager#run show route 200.0.100.0
inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.0.100.0/24 *[RIP/100] 01:33:57, metric 5, tag 0
> to 192.168.2.1 via fe-0/0/0.70
to 10.10.129.1 via fe-0/0/0.1121The route’s presence with two forwarding next hops confirms the
earlier suspicion that there should be multiple equal cost paths for
some RIP destinations in this lab topology. From Lager’s there are now two equal cost paths to
200.0.100/24—one via Barley and the
other through Ale.
RIP really is a simple protocol, and configuring JUNOS software to interoperate with IOS for RIP was, for the most part, pretty straightforward. The most common problem you’ll encounter with this scenario is unfamiliarity with the default RIP export policy, which is not intuitive, to say the least. This section demonstrated basic RIP configuration and operational mode commands that assist in troubleshooting RIP operation in a JUNOS software environment.
The next section addresses ways to migrate a network from one IGP to another, a concept called IGP migration. Once again, now is an opportune time to take a break before moving on.
Get JUNOS Enterprise Routing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
