RIPv2
224.0.0.9 UDP port 520
No hello, RIPv2 relies on the regular full routing updates instead
Update interval 30 seconds
Full updates each interval. For on-demand circuits, allows RIPv2 to
send full updates once, and then remain silent until changes occur, per
RFC 2091
When route changes – triggered update.
Auth: plain-text + MD5
Route tags
Next-hop field
Timers:
Update 30 s
Invalid after timer per route default 180 s
Holddown timer begins after a route has been declared invalid; default 180 s. The router starts advertising that route as unreachable, does not accept any updated information, and does not modify the routing table entry for that route.
Flushed after timer per route default 240 seconds; If the updates about the route from its next hop cease to be received and the Flushed after timer reaches its limit, the router removes the route from the routing table entirely.
The default timer setting actually does not allow the Holddown timer to completely expire. As a result, the effective Holddown period is only 60 seconds.
router rip timers basic update invalid holddown flush
The RIP packet format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| |
~ RIP Entry (20) ~
| |
+---------------+---------------+---------------+---------------+
RIP Entry :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | route tag (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next-hop addr (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
A RIP message consists of a 4B-long header containing the command field (set to 1 for
Request, 2 for Response) and the version field (2 for RIPv2). The remaining two octets
are unused. The remainder of the message consists of routing entries, with each routing
entry occupying 20 octets in total. At most 25 routing entries can be placed into a single
RIP message. Each routing entry contains the address family identifier identifying the
format of the address information carried in the routing entry (only the value 2, IPv4—
also known as AF_INET—is commonly supported), route tag, and the route itself—its
address, netmask, recommended next hop, and metric.
A Request message is used to ask a neighbor to send a partial or a full RIP update immediately,
rather than waiting for the Update timer to expire, speeding the convergence. A
full RIP update is requested by a Request message containing exactly one routing entry
with the address family ID set to 0 and metric set to 16. Otherwise, if a Request message
lists one or more particular networks, only the update on these networks is requested.
RIPv2 increments the metric when sending updates; RIPng and EIGRP increment metrics when receiving updates.
RIPv2 uses autosummarization at classful network boundaries by default.
Cisco IOS enables the RIPv2 (and EIGRP) authentication process on a per-interface basis
interface Fa0/1
ip rip authentication key-chain name
ip rip authentication mode { text | md5 }
When authentication is enabled, the maximum number of prefixes that can be advertised
in a RIPv2 message is reduced by 1 to a value of 24. The first route entry in each RIPv2
message would be carrying 20 bytes of authentication data.
RIPNg
FF02::9 UDP port 521
No multiproto capability, so no address-family field.
Version field set to 1
Packet format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry 1 (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry N (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Table Entry:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 prefix (16) ~
| |
+---------------------------------------------------------------+
| route tag (2) | prefix len (1)| metric (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The number of route entries in a RIPng message is limited only by the IPv6 MTU on the link, and the protocol itself poses no limitations on their count.
A next-hop RTE is identified by 0xFF in the metric field. The IPv6 prefix field contains the IPv6 address of the next-hop. The route-tag and prefix-len fields are set to 0.
- Authentication or encryption by IPsec is not supported.
- Split Horizon can be activated or deactivated only on a per-process basis
- Passive interfaces are not supported.
- Static (manual) neighbors cannot be configured (no neighbor command).
- Per-process offset lists are not supported.
- Multiple RIPng processes can be run on a router
- Route Poisoning, as an enhancement of the Split Horizon mechanism, can be activated
on a per-process basis. - Interfaces can be configured with a metric-offset value
- The default route can be originated on a per-interface basis, including an option of
suppressing all other updates over that interface.
