O'Reilly logo

JUNOS Enterprise Routing by Harry Reynolds, Doug Marschke

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

RIP Deployment Scenario

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.

RIP topology

Figure 4-3. RIP topology

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;
        }
    }
}

Existing RIP Configuration

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.

Baseline operation

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, Null0

No 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/0

With Barley displaying the same type and number of routes, baseline operation is confirmed.

Summary of RIP Requirements

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.

Enter Juniper Networks

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.

Configure static routes

The configuration begins with the definition of the static route that simulates an attached customer network. The configuration steps for Ale are:

lab@Ale>configure
Entering 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# show
static {
    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#commit
commit complete

[edit routing-options]
lab@Ale# run show route protocol static

inet.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

Configure RIP

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 command

Configuration 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 configuration

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#show
send 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 set
set 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#show
term 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 set
set 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 rip
send 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.

Confirm RIP Operation: Ale and Lager

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 neighbor
                     Source       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            0

And 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
                      MultiRecv

Ale’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.

Confirm RIP: Juniper Networks to Cisco Systems Integration

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>configure
Entering configuration mode

[edit]
lab@Ale# activate protocols rip group rip neighbor fe-0/0/0.69

[edit]
lab@Ale# commit
commit complete

Confirm route exchange

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            0

The 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
                      MultiRecv

RIP 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/0

The 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).

Confirm forwarding path

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 !H

The 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!

RIP troubleshooting scenario

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
                      Discard

The 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 neighbor

Note 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.1121

The 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# commit

Tip

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# commit
commit complete

The Problem

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#show
term 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# show
term 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.70

Lager’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.1121

The 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 Deployment Summary

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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required