The Routing Information Protocol (RIP) is an Interior Gateway Protocol (IGP) that has been used extensively in corporate and personal networking environments for the past two decades. RIP version 2, the current specification of RIP, is defined in RFC 2453. RIP was historically specified in RFC 1723 and RFC 1388, both of which are now obsolete. The primary reason for RIP’s wide adoption has been its simplicity and wide availability. Compared to other prevailing IGPs such as the Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) protocols, RIP is easier to implement. Also, given its simplicity, RIP has been more widely available on servers and general-purpose networking appliances when compared with other IGPs.
RIP is a distance-vector protocol based on the Bellman-Ford algorithm. Distance-vector protocols advertise the metric (or hop count) associated with a destination network to their neighboring routers. Unlike OSPF or IS-IS-speaking devices, RIP gateways do not maintain a link state database that is consistent across all the devices in an autonomous system. Instead, each device that runs RIP can send updates about the destinations that are directly defined on it or those that it has learned from neighbors.
RIP gateways rely on a single unit—the metric associated with a destination address—to make their best-path selection. Each RIP-speaking interface has a metric associated with it. When a RIP gateway receives a RIP route, it examines the metric of the received route, and adds its own interface metric to establish the aggregate metric for this destination route. RIP metrics can range from 1 to 15. A route with a computed metric of 16 or greater is considered unreachable and is not installed in the routing table.
There are two types of RIP messages: Request and Response. Although Request messages are used to solicit a response from a RIP neighbor to provide its routing table, they are rarely used in live networks. The bulk of RIP messages in a live network are unsolicited Response messages that are generated by RIP-speaking gateways every 30 seconds. The 30-second route update interval is a default value defined in RFC 2453 for RIP-speaking devices to announce their routing table to all their neighbors. RIP update messages consist of RIP entries which include, at a minimum, the destination network address and the metric of the route.
Unlike OSPF, which has its own IP number, RIP messages are encapsulated in User Datagram Protocol (UDP) datagrams on destination port 520. RIP update messages consist of between one and 25 RIP entries.
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
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/maxR
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 - INeighbors 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->
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->
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
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 - INeighbors 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:
Defines the frequency of RIP RESPONSE
messages with route entries: every 30 seconds.
Defines the duration that a ScreenOS device waits before marking a neighbor’s route as invalid: 180 seconds.
Defines the duration that a ScreenOS device waits before flushing a route after it has been invalidated: 120 seconds.
Defines the minimum duration that a route is held in the routing table to prevent flapping: 90 seconds. The hold timer’s minimum value has to be at least three times the update timer. Its maximum value can be the flush timer minus the update timer.
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.
The removal of a RIP route on a ScreenOS firewall is a three-step process that begins with the invalidation of a route when it is not received even once during the invalid timer interval. Following invalidation, the route enters hold-down for the duration of the hold-down interval. Following the expiration of the hold-down interval, the route is no longer usable. However, it still resides in the RIP database, waiting to be flushed, until the flush timer expires.
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 queueInfo 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.
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/242/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/243/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 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
Follow these steps to redistribute a static route into RIP:
Define the static route(s) in ScreenOS in a VR.
Define an access list to identify the static route(s) in that specific VR.
Define a route map to match the access-list entry in that specific VR and assign a RIP metric to it.
Apply the route map to the RIP instance in the specific VR, specifying redistribution from protocol static
.
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
.
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->
Follow these steps to redistribute a set of OSPF routes into RIP:
Define an access list to identify the OSPF route(s).
Define a route map to match the access-list route entries, and assign an OSPF metric and metric type to the redistributed routes.
Apply the route map to the RIP instance in the specific VR, specifying redistribution from OSPF.
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
.
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.
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.
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->
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.
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 MetricVer-Rx/Tx
------------------------------------------------------------- eth0/0 192.168.4.30/24 enabled enabled P 1 31/1
bgroup0 192.168.30.1/24 enabled enabled S 0 11/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 MetricVer-Rx/Tx
----------------------------------------------------------------- eth0/0 192.168.4.30/24 enabled enabled P 0 31/1
bgroup0 192.168.30.1/24 enabled enabled S 0 11/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 MetricVer-Rx/Tx
------------------------------------------------------------------ untrust 192.168.30.30/24 enabled enabled S 1 12/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 - INeighbors 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