Although any new implementation of RIP typically does not get implemented with RIP version 1 due to its limitations, it is useful to understand RIP version 1 implementations to integrate a new device into an existing, legacy RIP version 1 network. RIP version 1 (also referred to as RIPv1 or RIP-1) has a serious limitation in that it is a “classful” routing protocol: because RIPv1 route updates do not have a subnet mask associated with them, the receiving gateway has to rely on the archaic classification of the IPv4 address space into Class A, B, and C networks to establish a network mask for the received route update.

RIPv1 messages are typically transmitted at the network broadcast address 255.255.255.255. RIPv1 update messages consist of simple RIP entries that provide two pieces of information to a receiving gateway: the destination IPv4 address and the metric. An update message can include up to 25 RIP entries. Because RIP entries do not come with an associated mask, the receiving gateway has to classify the route using classful boundaries.

RIP Version 2 (also referred to as RIPv2 or RIP-2) adds useful extensions to RIP version 1 while maintaining the same RIP UDP datagram structure. These extensions include support for subnet masks, route tags, explicit next hops, and neighbor authentication.

Because RIPv2 route entries include subnet masks, RIPv2 implementations can support classless interdomain routing (CIDR), sometimes referred to as classless routing. For instance, a RIPv2 message with a route entry such as 192.168.100.0 and a subnet mask of 255.255.255.248 is interpreted as the 192.168.100.0/29 subnet, whereas RIPv1 gateways, due to the absence of subnet masks in the route entry, would interpret this as 192.168.100.0/24.

To reduce the load of processing a broadcast packet on all the devices in a virtual local area network (VLAN) or subnet, RIPv2 devices typically send their messages to the 224.0.0.9 multicast address. This is in contrast to RIPv1 gateways, which broadcast RIP messages on the 255.255.255.255 network broadcast address.

RIP neighbor authentication via Message Digest 5 (MD5) keys is defined in RFC 2082.

The metric, or cost, of a destination route is the primary mechanism used by RIP-speaking devices to determine whether a given route from a neighbor should be installed in the routing table or discarded if a better (lower-cost) route already exists in the RIP database. Most modern RIP implementations provide a mechanism to prevent routing loops from forming if a RIP gateway advertises a route learned from a neighbor right back to the same neighbor. Two well-established techniques for RIP routing-loop prevention are split-horizon and poison-reverse. The split-horizon method ensures that a route learned on an interface is never advertised back on the same interface. The split-horizon with poison-reverse adds an extra protection mechanism by sending back the received RIP route with a metric of infinity (16).

ScreenOS has a full-featured implementation of RIP, supporting RIPv1 and RIPv2. ScreenOS firewalls run RIP within the context of a Virtual Router (VR). As discussed in Chapter 4, ScreenOS assigns a route preference to the different types of routes in a VR. Route preference becomes relevant in the context of installing the best route in the routing table when there are multiple route entries for the same destination, learned from different routing protocols. Lower route preference routes are preferred over those with higher preference. ScreenOS assigns a default route preference of 100 to RIP routes, making them less preferred to OSPF, the External Border Gateway Protocol (EBGP), and connected routes, but more preferred over OSPF External Type2 or Internal BGP (IBGP) routes.

All RIP-enabled interfaces in ScreenOS are assigned a default metric of 1, which you can modify. The default RIP loop-prevention method used by the ScreenOS RIP implementation is split-horizon.

You want to enable RIP on an interface on a ScreenOS firewall to advertise and receive routes from a peer device.

Figure 15-1 shows the extfw firewall gateway and its interfaces in the context of RIP configuration.

First, make sure you have correctly assigned the interface zone, IP address, and mode on the interface that will run RIP:

	extfw-> set interface bgroup0 zone Trust
	extfw-> set interface bgroup0 ip 192.168.4.1/24
	extfw->set interface bgroup0 nat

Figure 15-1. RIP configuration

You can replace the bgroup0 interface in the preceding code with the particular interface on the ScreenOS firewall on which you are enabling RIP.

Next, define the router ID and enable RIP. You must define the router ID for RIP to come up correctly:

	extfw-> set vr trust-vr
	extfw(trust-vr)-> set router-id 192.168.4.1
	extfw(trust-vr)-> set protocol rip
	extfw(trust-vr/rip)-> set enable
	extfw(trust-vr/rip)-> exit
	extfw(trust-vr)-> exit
	extfw->

Finally, enable RIP at the interface level:

	extfw-> set interface bgroup0 protocol rip enable

You can replace the bgroup0 keyword with the interface name on the ScreenOS firewall on which you are enabling RIP. The configuration shown here enables RIP on the trust-vr virtual router on the firewall and permits it to receive all RIP route advertisements on the bgroup0 interface. Furthermore, this configuration will advertise the 192.168.4.0/24 network as well as any other networks on other RIP-enabled interfaces on this firewall to RIP neighbors.

As discussed in the Introduction to this chapter, RIP is a simple routing protocol that you can quickly enable in a network to provide dynamic rerouting around failed network links, propagate routes to new networks, and bias traffic to specific paths.

ScreenOS uses several default parameters when RIP is enabled using the minimal configuration shown in this recipe’s solution. These default parameters include the following:

You can view these parameters and other configuration settings on the RIP instance running in the defined VR as follows:

	extfw-> get vrouter trust-vr protocol rip
	VR: trust-vr
	------------------------------------------------------------------
	State: enabled
	Version: 2
	Default metric for routes redistributed into RIP: 10
	Maximum neighbors per interface: 16
	Not validating neighbor in same subnet: disabled
	Next RIP update scheduled after: 30 sec
	Maximum number of Alternate routes per prefix: 0
	Advertising default route: disabled
	Default routes learnt by RIP will be accepted
	Incoming routes filter and offset-metric: not configured
	Outgoing routes filter and offset-metric: not configured
	Update packet threshold is not configured
	Total number of RIP interfaces created on vr(trust-vr): 1

	Update| Invalid|    Flush| DC Retransmit| DC Poll| Hold Down
	(Timers in seconds)
	-------------------------------------------------------------
	    30|     180|      120|             5|     180|      90

	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	Passive - I
	       Demand Circuit - D
	Interface   IP-Prefix        Admin    State    Flags   NbrCnt Metric
	 Ver-Rx/Tx
	-------------------------------------------------------------
	bgroup0     192.168.4.1/24   enabled  enabled    S         0      1
	   2/2
	extfw->

The output from get vrouter trust-vr protocol rip also displays the interfaces in the trust-vr on which the RIP protocol is enabled. The default routing-loop prevention method for RIP on ScreenOS is split-horizon, indicated with the S flag in the preceding code.

Another mechanism for verifying that RIP is enabled in a VR is to check for the R flag in the get vrouter output:

	extfw-> get vrouter
	* indicates default vrouter
	A - AutoExport, R - RIP, N- NHRP, O - OSPF, B - BGP, P - PIM

	   ID Name             Vsys       Owner     Routes  MRoutes   Flags
	    1 untrust-vr       Root       shared     0/max  0/max
	*   2 trust-vr         Root       shared     9/max  0/max     R
	total 2 vrouters shown and 0 of them defined by user
	extfw->

You can view the RIP neighbors for a given RIP instance on ScreenOS as follows:

	extfw-> get vrouter trust-vr protocol rip neighbors
	VR: trust-vr
	-----------------------------------------------------------------
	Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U,
	Poll - P,
	        Demand Circuit Init - I
	Neighbors on interface bgroup0
	-------------------------------------------------------------------
	IpAddress     Version  Age      Expires    BadPackets BadRoutes Flags
	-------------------------------------------------------------------
	192.168.4.30  2        00:00:17 00:03:00            0         0 U
	extfw->

The Age parameter shows the duration since the neighbor has been in an Up state. The Expires parameter displays the duration for which this neighbor will remain up if no more updates are received from it. Note that sometimes a RIP neighbor may not be sending out any RIP routes to the ScreenOS firewall. Furthermore, because RIP does not employ a formal keepalive/Hello protocol and RIP request messages are rarely implemented, ScreenOS will remove a RIP neighbor from the neighbor list if no routes are received from it. In several instances, however, such as a physical link failure, an active neighbor that is sending RIP route updates every 30 seconds is immediately removed from the list of neighbors.

You can view the RIP database as follows:

	extfw-> get vrouter trust-vr protocol rip database
	VR: trust-vr
	-----------------------------------------------------------------
	Total database entry: 1
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix             Nexthop     Ifp     Cost Flags   Source
	------------------------------------------------------------------
	     1 192.168.4.0/24     0.0.0.0     n/a        0 I       -
	extfw->

To verify the router ID of the RIP instance on the VR, type the following:

	extfw-> get vrouter trust-vr router-id
	vrouter trust-vr router-id for BGP and OSPF is 192.168.4.1
	extfw->

Finally, if you would like to remove the entire instance of RIP on a VR and its associated interfaces, you can use the unset command:

	extfw-> unset vrouter trust-vr protocol rip
	deleting RIP instance, are you sure? y/[n] y
	extfw->

Recipe 15.2

You want to advertise the default route to your RIP neighbors.

This solution builds on Recipe 15.1 by adding the ability to advertise the default route. In this scenario, the default route is statically configured to point out the Untrust ethernet0/0 interface, and is redistributed into RIP to be advertised over the bgroup0 interface:

	extfw-> set vrouter trust-vr
	extfw(trust-vr)-> set router-id 192.168.4.1
	extfw(trust-vr)-> set protocol rip
	extfw(trust-vr/rip)-> set enable
	extfw(trust-vr/rip)-> exit
	extfw(trust-vr)-> exit
	extfw-> set interface bgroup0 protocol rip enable
	extfw->set vrouter trust-vr protocol rip advertise-def-route metric 10

You can verify the RIP database on the advertising router to make sure the default route, 0.0.0.0/0, is installed as follows:

	extfw-> get vrouter trust-vr protocol rip database
	VR: trust-vr
	------------------------------------------------------------------
	Total database entry: 2
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix                Nexthop     Ifp   Cost Flags   Source
	------------------------------------------------------------------
	     2 0.0.0.0/0             0.0.0.0     n/a     10 RD      -
	     1 192.168.4.0/24        0.0.0.0     n/a     0  I       -
	extfw->

The default route is installed in extfw’s RIP database to be advertised at a metric of 10. The RIP gateway that receives this route assigns it a RIP metric of 10 plus the interface metric of the interface on which this route is received. Hence, when this default route is received on a ScreenOS firewall with an interface metric of 3 (set interface ethernet0/0 protocol rip metric 3), the resultant default route has a metric of 13, which you can verify as follows:

	ssg5-serial-> get route

	IPv4 Dest-Routes for <untrust-vr> (0 entries)
	------------------------------------------------------------------
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2


	IPv4 Dest-Routes for <trust-vr> (6 entries)
	------------------------------------------------------------------
	   ID          IP-Prefix    Interface       Gateway   P Pref     Mtr
	  Vsys
	------------------------------------------------------------------
	*   6          0.0.0.0/0      eth0/0   192.168.4.1  R   100      13
	     Root
	*   2    192.168.4.30/32      eth0/0       0.0.0.0  H     0       0
	     Root
	    4    192.168.30.1/32      bgroup0      0.0.0.0  H     0       0
	     Root
	    3    192.168.30.0/24      bgroup0      0.0.0.0  C     0       0
	     Root
	    1     192.168.4.0/24       eth0/0      0.0.0.0  C     0       0
	     Root
	    5     192.168.1.0/24      eth0/0   192.168.4.1  R   100       4
	     Root

	ssg5-serial->

Recipe 15.1

You want to enable neighbor authentication for a RIP neighbor.

You can enable clear text authentication for a RIP neighbor as follows:

	extfw-> set interface bgroup0 protocol rip authentication password
	testpassword

You can replace the testpassword with a clear text password of your choice.

You can enable MD5 authentication for a RIP neighbor as follows:

	extfw-> set interface bgroup0 protocol rip authentication md5
	AN_EASY_MD5_KEY

You can replace the MD5 key AN_EASY_MD5_KEY with any string of up to 16 characters.

RIP authentication is configured in ScreenOS at the interface level. Hence, as indicated in this recipe’s solution, the authentication password is specified in the context of an interface, and not in the VR context.

Clear text authentication was introduced in RIP version 2. However, because clear text authentication transmits the clear text password in the RIP message, it is open to snooping attacks.

The MD5 RIP authentication mechanism, defined in RFC 2082, is more secure than clear text authentication, as it does not send a clear text password in each RIP message. Instead, the MD5 authentication mechanism computes a “hash” on a message using the predefined MD5 key. The resultant computation, which is a 16-byte MD5 “digest,” is transmitted in the RIP message along with the key ID and a sequence number.

You can associate multiple MD5 keys with an interface, with one active key at any time. In ScreenOS, when a single MD5 key is defined on an interface without the key-id attribute, it is automatically assigned a key ID of 0. You can configure and define additional MD5 keys as the active key as follows:

	extfw-> set interface bgroup0 protocol rip authentication md5
	ONE_MORE_EZ_KEY key-id 1
	extfw->set interface bgroup0 protocol rip authentication
	active-md5-key-id 1

To disable RIP authentication on an interface, use the following unset command on the specific interface:

	extfw-> unset interface bgroup0 protocol rip authentication

Recipe 15.9

You want to have an interface on a ScreenOS device learn routes via RIP, but not advertise any routes.

A ScreenOS firewall interface that already has RIP enabled on it (see Recipe 15.1) can be further qualified as a passive interface so that it does not advertise any routes as follows:

	ssg5-serial-> set interface ethernet0/0 protocol rip passive-mode

You can replace the ethernet0/0 interface with any other interface name on which you want to run RIP in passive mode.

In ScreenOS, a passive-mode RIP interface sees RIP neighbors and receives RIP updates but does not advertise any routes to RIP neighbors. When an interface is configured to be passive, you can verify that the interface is still seeing RIP neighbors as follows:

	ssg5-serial-> get vrouter trust-vr protocol rip neighbor
	VR: trust-vr
	------------------------------------------------------------------
	Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U,
	Poll - P, Demand Circuit Init - I
	Neighbors on interface ethernet0/0
	------------------------------------------------------------------
	IpAddress       Version  Age          Expires      BadPackets
	BadRoutes Flags
	------------------------------------------------------------------
	192.168.4.1     2        02:02:12     00:02:47              0
	        0 U
	Neighbors on interface bgroup0
	------------------------------------------------------------------
	IpAddress       Version  Age          Expires      BadPackets
	BadRoutes Flags
	------------------------------------------------------------------
	ssg5-serial->

The Neighbors on interface ethernet0/0 section shows a valid neighbor.

RIP does not have a Hello mechanism, and RIP neighbor lists are built based on receiving RESPONSE messages. Hence, a RIP gateway on the other end of the passive interface would not add the ssg5-serial firewall to its RIP neighbor list. If an interface is made passive at a later stage following initial configuration while it has been advertising routes, the neighbor explicitly removes this neighbor from its neighbor list following the expiration of the hold timers:

	extfw-> get log event
	Total event entries = 757
	Date       Time     Module Level  Type Description
	2007-06-10 17:11:15 system info  00544 RIP neighbor 192.168.4.30 in
	                                           virtual router trust-vr
	                                           removed.

However, if multiple interfaces are connecting from the ssg5-serial firewall to a RIP neighbor and only one of them is in passive mode, the ssg5-serial will remain in the active neighbor list unless all the interfaces are made passive.

To bring a ScreenOS interface out of passive mode into its regular, active operation mode where it advertises RIP routes, configure the following:

	ssg5-serial-> unset interface ethernet0/0 protocol rip passive-mode

The Introduction section to this chapter

You want to adjust RIP timers on a ScreenOS firewall to be different from the default values.

To achieve faster convergence, you can adjust the invalid and flush timers in the ScreenOS RIP implementation downward:

	extfw-> set vrouter trust-vr protocol rip invalid-timer 90
	extfw->set vrouter trust-vr protocol rip flush-timer 60

Thus, the duration for a stale route to be removed from a ScreenOS firewall’s routing table is reduced to as low as 180 seconds from the default value of at least 300 seconds. Note that the update and hold-down timers are kept at their default values.

Invalid, flush, and hold timers are implemented in most modern RIP implementations to prevent routing loops and flapping routes. These timers are relevant in scenarios where there is a “silent” failure—for example, a RIP neighbor that was advertising the routes goes down, but the local physical interface on which the routes were being received is still up. If a local physical interface on which RIP routes are being learned goes down, the associated routes are immediately invalidated and purged from the routing table.

The default values for the various RIP timers relevant to convergence, excluding demand-circuit environments, in ScreenOS are as follows:

You can view the configured values for the various RIP timers in ScreenOS via the get vrouter <vr-name> protocol rip command. The following output shows the default values of the timers before the modifications made in this recipe’s solution:

	extfw-> get vrouter trust-vr protocol rip
	VR: trust-vr
	------------------------------------------------------------------
	State: enabled
	Version: 2
	Default metric for routes redistributed into RIP: 10
	Maximum neighbors per interface: 16
	Not validating neighbor in same subnet: disabled
	Next RIP update scheduled after: 7 sec
	<Additional_Output_Truncated>

	Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down
	(Timers in seconds)
	------------------------------------------------------------------
	    30|     180|   120|             5|     180|      90

	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	 Passive - I Demand Circuit - D
	Interface   IP-Prefix       Admin    State    Flags   NbrCnt Metric
	 Ver-Rx/Tx
	------------------------------------------------------------------
	bgroup0     192.168.4.1/24   enabled enabled  S            1      1
	   2/2
	eth0/0      192.168.1.6/24   enabled enabled  S            0      1
	   2/2
	   extfw->

You can achieve faster convergence in a RIP environment by tuning the various timers downward. As illustrated in this recipe’s solution, the update and flush timers are reduced while the update and hold-down timers are kept at their default values. Because the RIP update timer is globally defined at 30 seconds and can send out a large number of routes that neighboring RIP devices need to process, it is not recommended to tweak this value lower than 30 seconds. Similarly, because the hold-down timer has to be at least three times the update timer, the default value of 90 seconds is not modified. The invalid and flush timers are indeed revised downward in this solution to achieve faster convergence.

Following the modifications to the update and flush timers per the solution, the timers’ values are reflected in the protocol settings:

	extfw-> get vrouter trust-vr protocol rip
	VR: trust-vr
	-------------------------------------------------------------------
	State: enabled
	Version: 2
	Default metric for routes redistributed into RIP: 10
	Maximum neighbors per interface: 16
	Not validating neighbor in same subnet: disabled
	Next RIP update scheduled after: 17 sec
	<Additional_Output_Truncated>

	Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down
	(Timers in seconds)
	-------------------------------------------------------------------
	   30|      90|     60|             5|     180|      90

	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	 Passive - I Demand Circuit - D
	Interface   IP-Prefix        Admin     State    Flags   NbrCnt Metric
	 Ver-Rx/Tx
	-------------------------------------------------------------------
	bgroup0     192.168.4.1/24   enabled   enabled  S            1      1
	   2/2
	eth0/0      192.168.1.6/24   enabled   enabled  S            0      1
	   2/2
	extfw->

With the new invalid and flush timers in effect, the following output dumps from a ScreenOS firewall illustrate the sequence of invalidation, hold-down, and purging of a route.

In steady state, when a ScreenOS firewall is receiving routes from its RIP neighbors and there are no failures, the timer queue awaits an event to invalidate the routes. You can view this as follows:

	extfw-> get vrouter trust-vr protocol rip timer
	VR: trust-vr 
	-------------------------------------------------------------------

	Pending route timer events in queue
	Info                 Event           State Res     Interval     Remain
	 TID Callback Argument E-queue Cookie
	6: 192.168.30.0/24   1/INVALID        aoto 1s         90000      71962
	  89 0051995c 04b48ba0 032573a0 00 0009d788 0008be6e
	extfw->

The route is identified, awaiting an INVALID event. The invalid timer, Interval,is seen here as 90,000 msec (90 seconds), per the configuration in this recipe’s solution.

Also, the 90-second invalid timer is reflected in the neighbor list, with an Expires value of 1 minute and 30 seconds:

	extfw-> get vrouter trust-vr protocol rip neighbor
	VR: trust-vr
	-------------------------------------------------------------------
	Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U,
	 Poll - P, Demand Circuit Init - I
	Neighbors on interface bgroup0
	-------------------------------------------------------------------
	IpAddress       Version  Age        Expires   BadPackets BadRoutes
	 Flags
	-------------------------------------------------------------------
	192.168.4.30    2        00:12:32   00:01:30           0         0
	 U
	Neighbors on interface ethernet0/0
	-------------------------------------------------------------------
	IpAddress       Version  Age        Expires   BadPackets BadRoutes
	 Flags
	-------------------------------------------------------------------
	extfw->

Now, as indicated in Figure 15-2, when the ssg5-serial firewall stops advertising the 192.168.30.0/24 route by converting its advertising interface to passive mode, the Remain field starts to decrement.

Figure 15-2. RIP timers

	extfw-> get vrouter trust-vr protocol rip timer
	VR: trust-vr
	------------------------------------------------------------------

	Pending route timer events in queue
	Info                 Event           State Res      Interval   Remain
	 TID Callback Argument  E-queue Cookie
	6: 192.168.30.0/24   1/INVALID        aoto 1s          90000    20580
	  89 0051995c 04b48ba0 032573a0 00 00105f68 00100f04
	extfw->

Following 90 seconds without an update, the route enters hold-down:

	extfw-> get vrouter trust-vr protocol rip timer
	VR: trust-vr
	---------------------------------------------------------------------

	Pending route timer events in queue
	Info                 Event           State Res      Interval       Remain
	 TID Callback Argument  E-queue Cookie
	7: 192.168.30.0/24   2/HOLDOWN        aoto 1s          90000       89048
	  89 0051995c 04b48ba0 032573a0 00 0011bef8 00106320
	extfw->

Furthermore, the RIP database also marks this route as being in hold-down state. While in hold-down state, the route is still in the routing table and can be actively used.

	extfw-> get vrouter trust-vr protocol rip database
	VR: trust-vr
	-------------------------------------------------------------------
	Total database entry: 4
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix                Nexthop        Ifp     Cost Flags
	  Source
	-------------------------------------------------------------------
	     5 0.0.0.0/0             0.0.0.0        n/a       10 RD
	 -
	     15 192.168.30.0/24      192.168.4.30   bgroup0    2 MRH
	192.168.4.30
	    3 192.168.4.0/24         0.0.0.0        n/a        0 I
	-
	    4 192.168.1.0/24         0.0.0.0        n/a        0 I
	-
	extfw->

Following 90 seconds in hold-down without an update, the route is removed from the routing table and awaits the expiration of the flush timer for it to be purged. The PURGE event, thus, is triggered:

	extfw-> get vrouter trust-vr protocol rip timer
	VR: trust-vr
	-------------------------------------------------------------------

	Pending route timer events in queue
	Info                 Event           State Res      Interval  Remain
	 TID Callback Argument  E-queue Cookie
	9: 192.168.30.0/24   3/PURGE          aoto 1s          60000   54047
	  89 0051995c 04b48ba0 032573a0 00 0012a958 0011d639
	extfw->

In this state, when the route is waiting to be flushed, it is marked unreachable in the RIP database but can no longer be actively used:

	extfw-> get vrouter trust-vr protocol rip database
	VR: trust-vr
	-------------------------------------------------------------------
	Total database entry: 4
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix                Nexthop        Ifp     Cost Flags
	  Source
	-------------------------------------------------------------------
	     5 0.0.0.0/0             0.0.0.0        n/a       10 RD
	  -
	     17 192.168.30.0/24      192.168.4.30   bgroup0   16 RU
	  192.168.4.30
	     3 192.168.4.0/24        0.0.0.0        n/a        0 I
	-
	     4 192.168.1.0/24        0.0.0.0        n/a        0 I
	-
	extfw->

Following 60 seconds in the PURGE state, the route is completely flushed and purged from the RIP database and the device.

Hence, the convergence interval for a route to be rendered unusable in a ScreenOS firewall is the sum of the invalid timer and the hold-down timer. Although the flush timer is relevant to removing the route from the RIP database, once the flush timer is triggered with the PURGE event, the route is no longer usable.

You can adjust the various convergence timers to be higher than the default ScreenOS values to delay the route convergence interval, using the same configuration commands discussed earlier in this recipe.

The Introduction section to this chapter

You want to modify the metric of a RIP interface to influence route path selection.

You can modify the metric associated with a ScreenOS firewall interface that already has RIP enabled on it (refer to Recipe 15.1 to enable RIP on a firewall interface) as follows:

	ssg5-serial-> set interface ethernet0/0 protocol rip metric 3

You can replace the ethernet0/0 interface in the preceding configuration with any other interface whose RIP metric needs to be modified.

As discussed in this chapter’s Introduction, RIP metrics are used to compute the distance to a destination route. Each RIP route destination has a metric associated with it. RIP metrics range from 1 to 16. When two or more RIP routes with dissimilar metrics are compared, the lower metric is preferred. A metric of 16 indicates that the destination route is unreachable. When a RIP gateway receives a route on an interface from a neighbor, it computes the metric associated with the route by adding the received metric to the interface’s metric. The default metric associated with all RIP interfaces in ScreenOS is 1. However, as described in this recipe’s solution, you can modify this metric to a higher value.

For this recipe’s solution, all RIP routes learned via the ethernet0/0 interface will have a metric of three hops added to the received metric before being installed in the RIP database. Increasing the RIP metric associated with an interface typically causes routes learned via that interface to be less preferred to those learned on another interface. This is relevant in scenarios where you could have two interfaces on a ScreenOS firewall that are learning RIP routes, where you would like to have one of the interfaces used as the primary path and the other interface as a backup, failover path. In such a scenario, you would assign a higher interface metric to the backup interface.

The Introduction section to this chapter

You want to redistribute static routes into RIP.

Follow these steps to redistribute a static route into RIP:

Figure 15-3 illustrates an environment where the extfw firewall is running RIP on its bgroup0 interface and static routes on its e0/0 interface. All interfaces on extfw are in the trust-vr.

Figure 15-3. Static-to-RIP redistribution

Hence, to redistribute the 192.168.7.0/24 and 172.16.0.0/16 static routes on the extfw ScreenOS firewall into RIP, the following configuration is required:

	extfw-> set vrouter trust-vr route 192.168.7.0/24 gateway 192.168.1.1
	extfw-> set vrouter trust-vr route 172.16.0.0/16 gateway 192.168.1.1
	extfw->
	extfw-> set vrouter trust-vr access-list 30 permit ip 192.168.7.0/24 1
	extfw-> set vrouter trust-vr access-list 30 permit ip 172.16.0.0/16 2
	extfw->
	extfw-> set vrouter trust-vr route-map name Static_to_RIP permit 1
	extfw-> set vrouter trust-vr route-map Static_to_RIP 1 match ip 30
	extfw-> set vrouter trust-vr route-map Static_to_RIP 1 metric 3
	extfw->
	extfw-> set vrouter trust-vr protocol rip redistribute route-map
	Static_to_RIP protocol static
	extfw->

You may need to redistribute static routes into RIP in several scenarios. When you define the access list to identify the various subnets that you would like to redistribute into RIP, make sure you use a unique access-list number and assign each included subnet a distinct sequence number. You can verify the access-list entries as follows:

	extfw-> get vrouter trust-vr access-list
	IPv4 Access Lists
	------------------------------------------------
	Access list (30)
	----------------
	        Sequence 1: 192.168.7.0/24              -> Permit
	        Sequence 2: 172.16.0.0/16               -> Permit
	IPv6 Access Lists
	------------------------------------------------
	extfw->

You need to explicitly define each route-map stanza in ScreenOS with a name keyword before it can have entries associated with it. Hence, the first statement in the preceding route-map definition specifies the name of the route map, the route-map type (permit or deny), and the sequence number of the route map. Following this, the entries associated with this permit sequence—for example, to match access-list 30 subnets and assign them a RIP metric of 3—are defined. Note that if the metric is not explicitly defined in the route map, a default RIP metric of 10 is assigned to the redistributed route. You can verify the route map’s definition in ScreenOS accordingly:

	extfw-> get vrouter trust-vr route-map Static_to_RIP
	Route-map (Static_to_RIP)
	----------------------
	        Entry (1) - Action (permit)
	        ---------------------------
	                Match Fields
	                ------------
	                ip-address:             30 (access-list)

	                Set Fields
	                ----------
	                metric:                 3


	extfw->

The redistribute configuration statement is defined in the context of the trust-vr’s RIP protocol section, specifying the route map that identifies the subnets and associated RIP metrics. Following the route map, the source protocol for the redistribution is specified. In this context, the source is static.

On the receiving ssg5-serial gateway, you can view the RIP routes as follows:

	ssg5-serial-> get vrouter trust-vr route protocol rip
	H: Host C: Connected S: Static A: Auto-Exported 
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 7/max entries

	   ID          IP-Prefix      Interface          Gateway   P Pref
	   Mtr     Vsys
	-----------------------------------------------------------------
	*   6     192.168.7.0/24         eth0/0     192.168.4.1   R  100
	     6     Root
	*   7      172.16.0.0/16         eth0/0     192.168.4.1   R  100
	     6     Root

	ssg5-serial->

Recipe 15.8

You want to redistribute a set of OSPF routes into RIP.

Follow these steps to redistribute a set of OSPF routes into RIP:

Figure 15-4 illustrates an environment where the ssg5-serial firewall is running OSPF on its ethernet0/0 interface and RIP on its bgroup0 interface. All interfaces on ssg5-serial are in the trust-vr.

Figure 15-4. OSPF-to-RIP redistribution

To redistribute all the OSPF routes in the trust-vr on the ssg5-serial ScreenOS firewall into RIP, the following configuration is required:

	ssg5-serial-> set vr trust-vr access-list 60 permit ip 0.0.0.0/0 1
	ssg5-serial->
	ssg5-serial-> set vrouter trust-vr route-map name OSPF_to_RIP permit 1
	ssg5-serial-> set vrouter trust route-map OSPF_to_RIP 1 match ip 60
	ssg5-serial-> set vrouter trust-vr route-map OSPF_to_RIP 1 metric 3
	ssg5-serial->
	ssg5-serial-> set vrouter trust-vr protocol rip redistribute route-map
	OSPF_to_RIP protocol ospf
	ssg5-serial->

The access-list 60 defined in this recipe’s solution is a match-all list that matches all instances of OSPF routes in the trust-vr. If you would like to specify the particular OSPF routes that need to be redistributed into RIP, the access-list entries can be more granular. (Recipe 15.7 specifies a more granular access list that specifies particular static routes that are redistributed into RIP.)

You can view the current set of OSPF routes on ssg5-serial as follows:

	ssg5-serial-> get vrouter trust-vr route protocol ospf
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 6/max entries

	   ID          IP-Prefix      Interface         Gateway   P Pref
	    Mtr     Vsys
	-------------------------------------------------------------------
	*   7     192.168.2.0/24         eth0/0     192.168.4.1   O   60
	      2     Root
	*   5     192.168.1.0/24         eth0/0     192.168.4.1   O   60
	      2     Root

	ssg5-serial->

These routes are redistributed into RIP, installed in the RIP database on ssg5-serial, and advertised to ssg5-serial’s RIP neighbors:

	sg5-serial-> get vrouter trust-vr protocol rip database
	VR: trust-vr
	------------------------------------------------------------------
	Total database entry: 4
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix               Nexthop        Ifp   Cost Flags   Source
	------------------------------------------------------------------
	    16 192.168.30.0/24      0.0.0.0        n/a      0 I       - 
	     3 192.168.4.0/24       0.0.0.0        n/a      0 I       -
	    19 192.168.2.0/24       192.168.4.1    n/a      3 I       -
	    18 192.168.1.0/24       192.168.4.1    n/a      3 I       -
	ssg5-serial->

One of the RIP neighbors, Internal_FW, learns these redistributed and other RIP routes. You can view its RIP routes accordingly:

	Internal_FW-> get vrouter trust-vr route protocol rip
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 9/max entries

	   ID          IP-Prefix      Interface         Gateway    P Pref
	  Mtr     Vsys
	-----------------------------------------------------------------
	*  12     192.168.4.0/24        untrust    192.168.30.1    R 100
	    2 Root
	*  16     192.168.2.0/24        untrust    192.168.30.1    R 100
	    4 Root
	*  15     192.168.1.0/24        untrust    192.168.30.1    R 100
	    4 Root

	Internal_FW->

The two RIP routes learned in the preceding code that are redistributed from OSPF are seen to have a RIP metric of 4 on Internal_FW, which is the sum of the advertised metric of the redistributed route, 3, plus the interface metric of the receiving interface on Internal_FW, 1, for a total of 4.

Recipe 15.7

You want to filter the RIP routes received by a ScreenOS security gateway.

Follow these steps to filter the RIP routes received by a ScreenOS security gateway:

Figure 15-5 illustrates an environment where the ssg5-serial firewall is advertising four RIP routes on its bgroup0 RIP-enabled segment. The Internal_FW gateway has an inbound RIP filter that only installs the 172.16.0.0/16 route into the routing table, dropping all of the other routes it receives in the update.

Figure 15-5. Filtering inbound RIP routes

To filter out all the inbound RIP routes except 172.16.0.0/16 on the Internal_FW ScreenOS gateway, the following configuration is required:

	Internal_FW-> set vrouter trust-vr access-list 83 permit ip
	172.16.0.0/16 1
	Internal_FW->
	Internal_FW-> set vrouter trust-vr route-map name Permit_Only_172_16
	permit 1
	Internal_FW-> set vrouter trust-vr route-map Permit_Only_172_16 1
	match ip 83
	Internal_FW->
	Internal_FW-> set vrouter trust-vr protocol rip route-map
	Permit_Only_172_16 in
	Internal_FW->

RIP offers the ability to filter routes to control traffic paths.

In the absence of inbound route filters, all of the RIP updates received on an interface are installed in the routing table and RIP timers are reset. Here is a debug output illustrating the routes received by Internal_FW (see Figure 15-5) before the inbound route filter is installed:

	Internal_FW-> clear dbuf
	Internal_FW-> debug rip recv
	Internal_FW-> get dbuf stream
	## 2007-06-30 13:15:04 : rip: [rx] RIP packet on interface untrust,
	 vr (trust-vr)
	## 2007-06-30 13:15:04 : rip: update on ifp untrust from 192.168.30.1,
	 RIP port 520
	## 2007-06-30 13:15:04 : rip: [rx] 192.168.4.0/24, nhop 192.168.30.1,
	 metric 2, tag 0.0.0.0
	## 2007-06-30 13:15:04 : rip: resetting timer for existing route
	## 2007-06-30 13:15:04 : rip: [rx] 192.168.1.0/24, nhop 192.168.30.1,
	 metric 4, tag 0.0.0.0
	## 2007-06-30 13:15:04 : rip: resetting timer for existing route
	## 2007-06-30 13:15:04 : rip: [rx] 192.168.2.0/24, nhop 192.168.30.1,
	 metric 4, tag 0.0.0.0
	## 2007-06-30 13:15:04 : rip: resetting timer for existing route
	## 2007-06-30 13:15:04 : rip: [rx] 172.16.0.0/16, nhop 192.168.30.1,
	 metric 4, tag 0.0.0.0
	## 2007-06-30 13:15:04 : rip: resetting timer for existing route

Following the configuration of the inbound RIP route filter that only permits the 172.16.0.0/16 route, the following debug output verifies that the ScreenOS gateway drops inbound updates that do not match the inbound route filter:

	Internal_FW-> clear dbuf
	Internal_FW-> debug rip recv
	Internal_FW-> get dbuf stream
	## 2007-06-30 13:38:04 : rip: [rx] RIP packet on interface untrust,
	 vr (trust-vr)
	## 2007-06-30 13:38:04 : rip: update on ifp untrust from 192.168.30.1,
	 RIP port 520
	## 2007-06-30 13:38:04 : rip: update 192.168.4.0/24 not allowed with
	 route-map Permit_Only_172_16
	## 2007-06-30 13:38:04 : rip: update 192.168.1.0/24 not allowed with
	 route-map Permit_Only_172_16
	## 2007-06-30 13:38:04 : rip: [rx] 172.16.0.0/16, nhop 192.168.30.1,
	 metric 4, tag 0.0.0.0
	## 2007-06-30 13:38:04 : rip: resetting timer for existing route
	## 2007-06-30 13:38:04 : rip: update 192.168.2.0/24 not allowed with
	 route-map Permit_Only_172_16
	Internal_FW->undebug all

You can see the received, filtered RIP route on the Internal_FW as follows:

	Internal_FW-> get vrouter trust-vr route protocol rip
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 7/max entries

	   ID          IP-Prefix    Interface       Gateway   P Pref    Mtr
	     Vsys
	-------------------------------------------------------------------
	*   7      172.16.0.0/16      untrust  192.168.30.1   R  100      4
	     Root

	Internal_FW->

Recipe 15.7; Recipe 15.8

You want to reduce the number of RIP routes being advertised by a ScreenOS security gateway by using summary routes.

You can enable summary routes on an interface in ScreenOS to summarize route announcements. The following solution will generate a summarized 172.16.0.0/16 RIP route announcement instead of announcing the two component routes, 172.16.1.0/24 and 172.16.2.0/24:

	ssg5-serial-> set vrouter trust-vr protocol rip summary-ip
	172.16.0.0/16
	ssg5-serial->set interface bgroup0 protocol rip summary-enable

The summary route is announced to RIP neighbors on the bgroup0 interface of the ssg5-serial gateway.

In addition to enabling the summary route for the 172.16.0.0/16 network, it’s recommended to create a null route on ssg5-serial to prevent routing loops:

	ssg5-serial-> set vrouter trust-vr route 172.16.0.0/16 interface null
	preference 255 metric 65535

Figure 15-6 shows the ssg5-serial gateway advertising the summary route on its bgroup0 RIP-enabled interface.

Figure 15-6. Summary routes

The summarized route is advertised only on the interfaces that have summary-enable configured. On other interfaces, all the individual component routes get advertised. This recipe’s solution generates the summary route from the component routes, which you can view in the ssg5-serial gateway’s RIP database:

	ssg5-serial-> get vrouter trust-vr protocol rip database prefix
	172.16.0.0/16
	VR: trust-vr
	-----------------------------------------------------------------
	Flags: Added in Multipath - M, RIP - R, Redistributed - I,
	       Default (advertised) - D, Permanent - P, Summary - S,
	       Unreachable - U, Hold - H
	DBID   Prefix              Nexthop      Ifp     Cost Flags   Source
	-----------------------------------------------------------------
	     9 172.16.0.0/16       0.0.0.0      n/a      3 RS      -
	ssg5-serial->

The RIP database output shows the 172.16.0.0/16 route with the S (Summary) and R (advertised by RIP) flags.

You can view the summarized RIP route on the Internal_FW gateway that receives the RIP updates from ssg5-serial as follows:

	Internal_FW-> get vrouter trust-vr route protocol rip
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 7/max entries

	   ID          IP-Prefix  Interface        Gateway   P Pref    Mtr
	     Vsys
	----------------------------------------------------------------
	*   7      172.16.0.0/16    untrust   192.168.30.1   R 100       4
	     Root

	Internal_FW->

You should use summary routes with caution, as they can potentially cause routing loops. An example of such a scenario is where ssg5-serial has a static default route pointing to Internal_FW and it sends a summary route to Internal_FW for 172.16.0.0/16 on its bgroup0 interface. Now, if Internal_FW sends traffic destined for 172.16.7.0/24 to ssg5-serial by virtue of the RIP summary announcement, ssg5-serial will send the traffic right back to Internal_FW following the static default route because it does not have a specific route to 172.16.7.0/24. Thus, a routing loop is formed. Hence, the null route to the summary destination, defined in this recipe’s solution, has a more specific bit-bucket destination that prevents routing loops from forming.

The Introduction to this chapter

You want to configure a ScreenOS gateway to use RIP version 1 as follows.

You can configure a ScreenOS gateway to strictly use RIP version 1:

	ssg5-serial-> set vrouter trust-vr protocol rip version v1

This setting globally configures RIP version 1 on all RIP-enabled interfaces on the ScreenOS gateway.

Also, you can selectively enable RIP version 1 on specific interfaces to send or receive RIP v1 updates:

	ssg5-serial-> set interface bgroup0 protocol rip send-version v1
	ssg5-serial->set interface bgroup0 protocol rip receive-version v1

Furthermore, you can configure ScreenOS gateways to send updates using RIP v1 as well as RIP v2:

	ssg5-serial-> set interface bgroup0 protocol rip send-version v1v2

Although RIP version 1 is not commonly used in today’s networks, you may need to rely on RIP Version 1 in a few pockets of legacy networks.

A ScreenOS gateway with RIP version 1 configured globally uses RIP v1 to send and receive packets on all RIP-enabled interfaces, as seen here:

	ssg5-serial-> get vrouter trust-vr protocol rip
	VR: trust-vr
	-----------------------------------------------------------------
	State: enabled
	Version: 1
	Default metric for routes redistributed into RIP: 10
	Maximum neighbors per interface: 16
	Not validating neighbor in same subnet: disabled
	Next RIP update scheduled after: 5 sec
	Maximum number of Alternate routes per prefix: 0
	Advertising default route: disabled
	Default routes learnt by RIP will be accepted
	Incoming routes filter and offset-metric: not configured
	Outgoing routes filter and offset-metric: not configured
	Update packet threshold is not configured
	Total number of RIP interfaces created on vr(trust-vr): 2

	Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down (Timers
	in seconds) 
	-------------------------------------------------------------
	    30|     180|     120|             5|     180|      90

	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	Passive - I
	       Demand Circuit - D
	Interface  IP-Prefix        Admin    State    Flags  NbrCnt Metric
	Ver-Rx/Tx
	-------------------------------------------------------------
	eth0/0     192.168.4.30/24  enabled  enabled  P           1      3
	   1/1
	bgroup0    192.168.30.1/24  enabled  enabled  S           0      1
	   1/1
	ssg5-serial->

ScreenOS gateways that are not enabled to receive RIP v1 updates reject those updates, seen here where the Internal_FW gateway receives a RIP v1 update from ssg5-serial on its untrust interface that is configured for RIPv2 send/receive:

	Internal_FW-> clear dbuf
	Internal_FW-> debug rip recv
	Internal_FW-> get dbuf stream
	## 2007-06-30 16:52:47 : rip: [rx] RIP packet on interface untrust,
	 vr (trust-vr)
	## 2007-06-30 16:52:47 : rip: pkt ignored on ifp untrust from
	192.168.30.1 is V1
	Internal_FW->

Next, when ssg5-serial is configured to send updates via v1v2:

	ssg5-serial-> get vrouter trust-vr protocol rip interface
	VR: trust-vr
	-----------------------------------------------------------------
	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	Passive - I
	       Demand Circuit - D
	Interface  IP-Prefix        Admin    State    Flags  NbrCnt Metric
	 Ver-Rx/Tx
	-----------------------------------------------------------------
	eth0/0     192.168.4.30/24  enabled  enabled  P           0      3
	   1/1
	bgroup0    192.168.30.1/24  enabled  enabled  S           0      1
	   1/v1v2
	ssg5-serial->

Hence, the Internal_FW gateway accepts these updates:

	Internal_FW-> clear dbuf
	Internal_FW-> debug rip recv
	Internal_FW-> get dbuf stream
	## 2007-06-30 17:09:04 : rip: [rx] RIP packet on interface untrust,
	  vr (trust-vr)
	## 2007-06-30 17:09:04 : rip: update on ifp untrust from 192.168.30.1,
	 RIP port 520
	## 2007-06-30 17:09:04 : rip: [rx] 192.168.4.0/24, nhop 192.168.30.1,
	 metric 2, tag 0.0.0.0
	## 2007-06-30 17:09:04 : rip: resetting timer for existing route
	Internal_FW->undebug all

As indicated here, the RIP route is accepted by the untrust interface on Internal_FW that is configured to receive only RIP v2 routes:

	Internal_FW-> get vrouter trust-vr protocol rip interface
	VR: trust-vr
	------------------------------------------------------------------
	Flags: Split Horizon - S, Split Horizon with Poison Reverse - P,
	Passive - I
	       Demand Circuit - D
	Interface IP-Prefix    Admin  State   Flags NbrCnt Metric Ver-Rx/Tx
	------------------------------------------------------------------
	untrust   192.168.30.30/24 enabled enabled S     1      1       2/2
	Internal_FW->

The route gets installed in the routing table on Internal_FW:

	Internal_FW-> get vrouter trust-vr route protocol rip
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2

	Total 7/max entries

	  ID IP-Prefix      Interface  Gateway        P Pref  Mtr   Vsys
	---------------------------------------------------------------
	* 14 192.168.4.0/24 untrust    192.168.30.1   R  100   2     Root

	Internal_FW->

The Introduction to this chapter; Recipe 15.1

You have enabled RIP on an interface on a ScreenOS firewall, but are not receiving any routes from your peer device.

There can be several reasons why you may not be receiving routes from a peer device. First, you should ensure that the ScreenOS firewall can see the peer device:

	extfw-> get vrouter trust-vr protocol rip neighbors
	VR: trust-vr
	-----------------------------------------------------------------
	Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U,
	Poll - P,
	        Demand Circuit Init - I
	Neighbors on interface bgroup0
	-----------------------------------------------------------------
	IpAddress       Version  Age         Expires       BadPackets
	BadRoutes Flags
	-----------------------------------------------------------------
	192.168.4.30    2        00:00:17    00:03:00               0
	        0 U
	extfw->

If this output does not show any neighbors on the interface on which routes are expected from the peer, make sure there is no RIP authentication mismatch. You can verify an authentication mismatch by running a debug:

	ssg5-serial-> clear dbuf
	ssg5-serial-> debug rip rec
	ssg5-serial-> get dbuf stream
	## 2007-06-30 15:01:01 : rip: [rx] RIP packet on interface
	 ethernet0/0, vr (trust-vr)
	## 2007-06-30 15:01:01 : rip: received md5 authentication packet
	## 2007-06-30 15:01:01 :    pkt length: 124, key length: 124, seq
	num: 11
	## 2007-06-30 15:01:01 : rip: failed authentication, discard
	ssg5-serial->undebug all

A successful RIP update packet with no authentication mismatch, on the other hand, looks as follows in the debug output:

	ssg5-serial-> clear dbuf
	ssg5-serial-> debug rip recv
	ssg5-serial-> get dbuf stream
	## 2007-06-30 15:09:07 : rip: received md5 authentication packet
	## 2007-06-30 15:09:07 :    pkt length: 124, key length: 124, seq num:
	 27
	## 2007-06-30 15:09:07 :    md5 auth ok
	## 2007-06-30 15:09:07 : rip: update on ifp ethernet0/0 from
	192.168.4.1, RIP port 520
	## 2007-06-30 15:09:07 : rip: [rx] 172.16.1.0/24, nhop 192.168.4.1,
	 metric 6, tag 0.0.0.0
	## 2007-06-30 15:09:07 : rip: resetting timer for existing route
	## 2007-06-30 15:09:07 : rip: [rx] 172.16.3.0/24, nhop 192.168.4.1,
	 metric 6, tag 0.0.0.0
	## 2007-06-30 15:09:07 : rip: resetting timer for existing route
	## 2007-06-30 15:09:07 : rip: [rx] 192.168.7.0/24, nhop 192.168.4.1,
	 metric 6, tag 0.0.0.0
	## 2007-06-30 15:09:07 : rip: resetting timer for existing route
	## 2007-06-30 15:09:07 : rip: [rx] 172.16.0.0/16, nhop 192.168.4.1,
	metric 6, tag 0.0.0.0
	ssg5-serial->undebug all

If the neighbor was previously up, but is no longer reachable, review the ScreenOS event log to check for messages related to the specific RIP neighbor:

	ssg5-serial-> get log event
	Total event entries = 1 
	Date       Time     Module Level Type Description
	2007-06-10 11:49:13 system info 00544RIP neighbor 192.168.4.1 in
	                                    virtual router trust-vr removed

In addition to running the get and debug commands in the solution above, make sure there are no incorrectly configured route maps that would suppress the route.

After reviewing RIP authentication and route maps to ensure that they do not reveal any reasons for you not receiving routes from a peer, you can execute a debug to check the messages coming from the neighbor:

	extfw-> clear dbuf
	extfw->debug rip recv

After waiting for at least 30 seconds to ensure that at least one RIP update cycle gets executed, you can check the debug buffer to see whether the neighbor is receiving any updates:

	extfw-> get dbuf stream
	## 2007-05-28 01:09:20 : rip: [rx] RIP packet on interface bgroup0,
	 vr (trust-vr)
	## 2007-05-28 01:09:20 : rip: update on ifp bgroup0 from
	 192.168.4.30, RIP port 520
	## 2007-05-28 01:09:20 : rip: [rx] 192.168.30.0/24, nhop
	 192.168.4.30, metric 2, tag 0
	## 2007-05-28 01:09:20 : rip: resetting timer for existing route
	extfw->

The output shows the route being received from the neighbor. If messages such as these are not seen from the peer device that is supposed to be sending routes, you should verify the configuration on the peer device.

After viewing the debug buffer, you should disable the debug command:

	extfw-> undebug rip recv

If additional debugs are running, you can disable all of them:

	extfw-> undebug all

Finally, while the ScreenOS firewall is receiving route updates from the peer RIP gateway, the computed RIP metric may be 16 or higher:

	extfw-> get dbuf stream
	## 2007-05-28 01:54:57 : rip: [rx] 192.168.1.0/24, nhop 192.168.4.30,
	metric 16, tag 0
	## 2007-05-28 01:54:57 :rip: ignore update, metric infinite

The Introduction to this chapter