403
network connected to that device is considered to be unreachable. However, the route of
that layer3 switch will be kept in the route table for another 120 seconds before deletion.
As layer3 switches running RIP built route table with second hand information, infinite
count may occur. For a network running RIP routing protocol, when an RIP route
becomes unreachable, the neighboring RIP layer3 switch will not send route update
packets at once, instead, it waits until the update interval timeout (every 30 seconds) and
sends the update packets containing that route. If before it receives the updated packet,
its neighbors send packets containing the information about the failed neighbor, “infinite
count” will be resulted. In other words, the route of unreachable layer3 switch will be
selected with the metrics increasing progressively. This greatly affects the route selection
and route aggregation time.
To avoid “infinite count”, RIP provides mechanism such as “split horizon” and
“triggered update” to solve route loop. “Split horizon” is done by avoiding sending to a
gateway routes leaned from that gateway. There are two split horizon methods: “simple
split horizon” and “poison reverse split horizon”. Simple split horizon deletes from the
route to be sent to the neighbor gateways the routes learnt from the neighbor gateways;
poison reverse split horizon not only deletes the abovementioned routes, but set the
costs of those routes to infinite. “Triggering update” mechanism defines whenever route
metric changed by the gateway, the gateway advertise the update packets immediately,
regardless of the 30 second update timer status.
There two versions of RIP, version 1 and version 2. RFC1058 introduces RIP-I
protocol, RFC2453 introduces RIP-II, which is compatible with RFC1723 and RFC1388.
RIP-I updates packets by packets broadcast, subnet mask and authentication is not
supported. Some fields in the RIP-I packets are not used and are required to be all 0’s;
for this reason, such all 0's fields should be checked when using RIP-I, the RIP-I packets
should be discarded if such fields are non-zero. RIP-II is a more improved version than
RIP-I. RIP-II sends route update packets by multicast packets (multicast address is
224.0.0.9). Subnet mask field and RIP authentication filed (simple plaintext password and
MD5 password authentication are supported), and support variable length subnet mask.
RIP-II used some of the zero field of RIP-I and require no zero field verification. ES4700
series layer3 switches send RIP-II packets in multicast by default, both RIP-I and RIP-II
packets will be accepted.
Each layer3 switch running RIP has a route database, which contains all route entries
for reachable destination, and route table is built based on this database. When a RIP
layer3 switch sent route update packets to its neighbor devices, the complete route table
is included in the packets. Therefore, in a large network, routing data to be transferred
and processed for each layer3 switch is quite large, causing degraded network
performance.