Monthly Archives: April 2013

3.5.a Describe packet types

i didn’t catch this on my last reading… note also that doyle sets hello/ack as distinct packet types whereas cisco pairs them as below…

from doyle:

Requests were a type of packet originally intended for use in route servers. This
application was never implemented, and request packets are noted here only because
they are mentioned in some older EIGRP documentation.

from cisco: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f07.shtml

Packet Formats

EIGRP uses five packet types:

  • Hello/Acks
  • Updates
  • Queries
  • Replies
  • Requests

Request packets are used to get specific information from one or more neighbors. Request packets are used in route server applications. They can be multicast or unicast. Requests are transmitted unreliably.

and wendell below from ccie r&s:

Hello Identifies neighbors, exchanges parameters, and is sent periodically as a
keepalive function
Update Informs neighbors about routing information
Ack Acknowledges Update, Query, and Response packets
Query Asks neighboring routers to verify their route to a particular subnet
Reply Sent by neighbors to reply to a Query
Goodbye Used by a router to notify its neighbors when the router is gracefully shutting down

note: wendell separates hello/ack, doesn’t mention request, sia-query, sia-reply and includes goodbye…

and wireshark chimes in:

eigrp_cap

theory, then lab, yes, no…

we know i am studying for the written because you can’t take the lab exam without first passing the written and that’s probably a good thing anyway… i have read about folks who prepare for the written by studying theory only… for me this is a patently bad idea… the fact is i don’t ever believe the shit will actually work until i’ve done it myself… if you are one of those people who subscribe to the theory only approach for the written, i don’t care…

i think there is no separation between the two… as peter otoole said in caligula, “one needs both”.

otoole

3.4 RIP [v2 and v6]

3.4.a Implement and troubleshoot RIPv2

we mostly ignore it, but i just read through doyle’s rip chapter (again) so i thought i might build it… can’t hurt…

doyle_rip_tcpip

the first task is to build it… note the little blue rip below… that is the gns3 config zipped as in the diagram with only ip addressing… go ahead and download it… tell me if it opens fine… you’ll find the router files, and .net… the image is for  7200’s… with this latest version of gns3, just extract the files and launch gns3… it should prompt you to point to an ios image that you have available… if not, just manually change the image file location in the .net file… i just tested it and it works… this is something i’ve been meaning to do for a while… then, because i know you have the same books as i do because we share the same kind of insanity, go to page 195 of doyle’s routing tcpip and do the exercises for rip…

download the topology here:

down arrow smaller

ripzip

feel free to tell me how awesome i am at any time…

note: the working directory is not included in the zip for obvious reasons…

3.3.c Compare routing protocol types

3.3.c [ii] Link state

Djikstra:

in his own words…

Construct [a] tree of minimum total length between the n nodes. (The tree is a graph with one and only one path between every two nodes.)
In the course of the construction that we present here, the branches are divided into three sets:
I. the branches definitely assigned to the tree under construction (they will be in a subtree);
II. the branches from which the next branch to be added to set I, will be selected;
III. the remaining branches (rejected or not considered).
The nodes are divided into two sets:
A. the nodes connected by the branches of set I,
B. the remaining nodes (one and only one branch of set II will lead to each of these nodes).

We start the construction by choosing an arbitrary node as the only member of set A, and by placing all branches that end in this node in set II. To start with, set I is empty. From then onwards we perform the following two steps repeatedly.
Step 1: The shortest branch of set II is removed from this set and added to set I. As a result, one node is transferred from set B to set A.
Step 2: Consider the branches leading from the node, which has just been transferred to set A, to the nodes that are still in set B. If the branch under construction is longer than the corresponding branch in set II, it is rejected; if it is shorter, it replaces the corresponding branch in set II, and the latter is rejected.
We then return to step 1 and repeat the process until sets II and B are empty. The branches in set I form the tree required.

doyle’s take on it:

1 A router initializes the Tree database by adding itself as the root. This entry shows the
router as its own neighbor, with a cost of 0.
2 All triples in the link state database describing links to the root router’s neighbors are
added to the Candidate database.
3 The cost from the root to each link in the Candidate database is calculated. The link
in the Candidate database with the lowest cost is moved to the Tree database. If two
or more links are an equally low cost from the root, choose one.
4 The Neighbor ID of the link just added to the Tree database is examined. With the
exception of any triple whose Neighbor ID is already in the Tree database, triples in the
link state database describing that router’s neighbors are added to the Candidate database.
5 If entries remain in the Candidate database, return to step 3. If the Candidate database is
empty, terminate the algorithm. At termination, a single Neighbor ID entry in the Tree
database should represent every router, and the shortest path tree is complete.