RIP Updates

A number of times I've come across these questions in workbooks.

- RIP shouldn't broadcast updates but directed updates to a specific neighbor.
When we use "neighbor x.x.x.x" command under router RIP process, it send unicast updates to the neighbor alongwith broadcast. To allow RIP to only send directed updates to a neighbor, use passive-interface command alongwith neighbor command.

- RIP updates shouldn't be received by interfaces participating in other routing protocols.
Though putting an interface in passive mode stops it from sending updates but doesnt stop it from recieving updates. So theres a chance that RIP broadcast may be received by the interfaces participating in other routing protocols. To avoid updates, either use the neighbor command under rip process to choose which neighbor should recieve updates. or use an acl that blocks rip communication.
access-list 100 deny udp any eq rip any eq rip
access-list 100 permit ip any any

EIGRP

Multicast updates on 224.0.0.10
Criteria for adjacency forming:
Same AS number
Source IP of Hello from same subnet as Primary IP add on interface on which Hello is recvd
K values must match
Authentication must pass

Hello & Dead Intervals need not match.

Updates:
Full updates when neighbor comes up for first time.
Full updates on neighbor recovery from failure
Partial updates when routes change
Update queries are multicast, waiting for ack. If no ack recvd within RTO then query is unicast to specific neighbor. Ack are unicast. Update & ack contain sequence No.

EIGRP Tables:
· Neighbor table-maintain adjacencies
· Topology table-contains entire topology to each network. Feasible successors are stored here.
· Routing table-best paths are chosen from topology table & populated here.

Composite Metrics:
Bandwidth, load, delay, reliability, MTU
K values can be changed with “metric weights tos k1 k2 k3 k4 k5”
BW = 10pwr7/kbps on interface
Delay = is in units of 10msec. delay of 1 = 10msec
Metric = 256 * BW + 256 * delay

If a route for a destination fails, then:
IF FS routes exist, then install lowest metric FS in to routing table.
If no FS exist, query neighbors for updates

Feasibility condition: to be a FS, reported distance of the route from a neighbor must be less than existing routers feasible distance.

SIA (stuck in active): if a router doesn’t recv a reply from a neighbor for a query within a specific time i.e. active timer, then router puts that route in to Active state.

Stub router: shouldn’t be a transit router. Stub rtr doesn’t recv query messages.

Variance- multiplier used for load-balancing across unequal cost paths.
Traffic-share balanced: more pkts sent to low metric routes.
Traffic-share min: sends traffic only on lowest metric route.
Traffic-share balanced across-interfaces: rtr choose routes with diff outgoing interfaces.

RIP

This is how a new RIP enabled router knows about routes from its connected routers. RIP operates on UDP 520. A new RIP enabled router broadcasts a Request message out of each RIP enabled interface. The neighbor respond to the Request mesage with updates in a Response message. The router then extracts the prefix & next-hop information to build a routing table. There after every 30 seconds the router updates its entire routing table to the neighbors in form of Response message.

RIPv1

• Classfull Routing,doesnt carry mask with updates
• Updates are Broadcast every 30 sec.
• No authentication of routes.

RIPv2

• Classless routing, carry mask with updates
• Authentication of routing updates
• Carries next-hop with each route entry
• External route-tags to identify redistributed routes
• Multicast routing updates on 224.0.0.9

Each RIP message can send updates for up to 25 routes.

RIP Update Timers

If a router doesnt hear update for a prefix in the 30 sec i.e. usual update time, it starts the invalid timer which lasts for upto 180 sec. At the end of this 180 sec, holdown timer starts till the timer for route reaches 240 sec. After 240 sec, the router flushes the rote from its routing table.

If during this period, an update is recieved from a router for the same route with a higher metric then the router waits for either the holdown timer to expire or flush timer whichever is earlist.

Any router interface can be configured to send & receive either v1 or v2 updates with following comands: "ip rip send version #", "ip rip recieve version #".

I'm yet to find out the significance of "next-hop" in the v2 updates. I thought next-hop should be there with every update. However, Jeff Doyle book mentioned it that way. I'll update this once I find answer to my query.

I got it from Wendell Odom & JDoyle books. Next-hop feature in v2 allow RIP to advertise a different next-hop router than the advertising router which may be a better option to reach destination than advertising router. If the field is set to 0.0.0.0 in the update, it means that the advertising router is the best router for destination.

Offset-lists

Help vary the metric of routes for prefixes being send out or recvd from neighbor. ACL is used to match the prefixes, then specific offset is added to the matches in acl & advertised based on the direction mentioned on interface "in / out". For routes not matching the acl, metric remains unchanged. "offset-list acl# in/out offset# interface#"