RIPv1 is defined in RFC 1058, and operates on UDP port 520.
RIP uses only hop count as its metric, with a maximum of 15 (a metric of 16 indicates unreachability).
Upon initialization, RIP routers issue requests for routes from neighbors. Neighbors issue responses
containing their full routing tables.
Routers broadcast their entire table to the link-local broadcast address of 255.255.255.255 every 30 seconds (on average; a small jitter is included to prevent simultaneous flooding).
RIP Timers
Update (30 seconds) - How often routes are advertised (+/- a small random delay)
Invalid (180 seconds) - How long a received route will stay in the routing table without being
received again, before being marked as invalid.
Flush (240 seconds) - 60 seconds longer than the invalid timer; invalid routes will be flushed
from the table when this timer is reached.
Holddown (180 seconds) - Routes will be kept in the table for this time before being replaced
by an advertisement with a higher metric.
An offset list can be implemented to artificially increase the metric for certain routes:
offset-list <ACL> {in | out} <offset> <interface>
Use distribute-list to filter routes update:
distribute-list <ACL> {in | out} <interface>
When debugging RIP:
*Mar 1 00:15:42.943: RIP: sending v1 update to 255.255.255.255 via Loopback0 (2.2.2.2)
*Mar 1 00:15:42.943: RIP: build update entries
*Mar 1 00:15:42.943: network 1.0.0.0 metric 2
*Mar 1 00:15:42.947: network 10.0.0.0 metric 1 <<< this means the network is directly connected (by using network command under rip process)
*Mar 1 00:18:21.435: RIP: sending v2 update to 224.0.0.9 via Loopback0 (2.2.2.2)
*Mar 1 00:18:21.439: RIP: build update entries
*Mar 1 00:18:21.439: 1.1.1.1/32 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:18:21.443: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0 <<< this means the network is directly connected (by using network command under rip process)
Ref: http://media.packetlife.net/media/library/29/Routing_TCP-IP_Vol_1_Notes.pdf
No comments:
Post a Comment