Note: The Clack implementations of RIP and OSPF intend to demonstrate the high-level concepts of distance-vector (RIP) and link-state (OSPF) protocols. As a result, they are greatly simplified from the real protocol specifications.

Clack is not required to answer all of the following questions, but trying out different scenarios will be helpful in confirming answers you are unsure of. The following two topology files will load networks that are running RIP or OSPF:

As described in student resources , these files are loaded using File->Open . To run two instances of Clack simultaneously, just open two browser windows to the Clack url.

1. This problem explores the update behavior of distance-vector and link-state protocols from the perspective of a single router R .

   For the following scenarios, consider whether R will "always", "never", or "sometimes" transmit routing data as a result of a certain event in the network (all events are described relative to R). Note that the "chain of events" leading to R sending an update may involve a sequence of actions by other routers. We are asking whether this stimulus will eventually result in an update from that would not have otherwise been sent by R had the stimulus not occurred. For each scenario, assume that all routers are advertising reachability to all locally connected subnets (including those between routers), that the network is not partitioned at any point, and that R has at least two neighbors.

   You can disable and enable links in Clack by double-clicking on them in the network view (disabled links turn red). The ifconfig command line program can also be used to bring links up or down, and change the link metric for local links. For RIP and OSPF, the routing table views in the network view shows additional routing specific information (e.g., the metric).

   Stimulus	RIP	OSPF
   One of R's local links goes down.	always never sometimes	always never sometimes
   One of R's local links changes its weight.	always never sometimes	always never sometimes
   A local routing table entry is removed, due to soft-state expiration or manual deletion	always never sometimes	always never sometimes
   A link not connected to R goes down.	always never sometimes	always never sometimes
   A link not connected to R changes its weight	always never sometimes	always never sometimes
   R receives a new routing update from a neighbor (ie: the routing update has a "fresh" ID for originating router)	always never sometimes	always never sometimes

2. You should already be familiar with the "counting to infinity problem" of distance-vector protocols like RIP. Given the Clack RIP topology, choose a set of one or more links that if disabled would to lead to the counting to infinity problem.

   router1-router2:
   router1-router3:
   router2-router3:
   router3-router4:
   router3-router5:
   router4-router5:
   

   With this outage, for what prefix did the cost "count to infinity?"

Username: