You probably have to be suspcicious of their authority on functionality
that cisco regards as legacy/and or provides almost as a courtesy, such as
RIP.
It's accorded 2nd citizen status within the confines of 1. cisco's
documentation 2. TAC/professional services' level of support provided for
complex RIP problems (most common response received in my admittedly
limited experience: "well, you wouldn't have this problem if you used EIGRP
or OSPF) 3. The RFC specifying requirements for IP routers authored
primarily by Fred Baker (1812).
In a perfect world, one might start with an RFC, but RFCs leave at least
some details to implementers charged with coding vendor-specific routing
protocols, even when those RFCs are followed to the letter, pointing to
potential differences in observed behavior. This could also be the case if
a drastic re-write of a routing protocol module occurs between IOS
releases.
(actual example: BayRS & IOS take different approaches to ensuring that the
metric associated with a RIP route increments as the update is propagated
from intermediate system to intermediate system , with material
consequences in a mixed-vendor environment).
For a technology such as HSRP or CDP, I'd probably wind up taking native
cisco materials as a starting point.
For OSI layers, I'm not sure what a good starting point is, and I assume
that there are profound difficulties in establishing compliance or lack
thereof.
In all cases however, the pivotal issue that addresses your point is,
What next?
In my case, supreme paranoia reigns & I wind up verifying most claims I
stumble across in my never-ending review of industry literature with an
attempt to emulate the functionality & a packet capturing program of some
kind. It becomes much more challenging/expensive when you are trying to
discern the effect a specific routing packet has within a given recipient
router as it is potentially processed by multiple modules.
Much harder to do this with theoretical touchstones such as the OSI stack.
I've had better success evaluating a given routing protocol
implementation's conformance with the notion of properly isolated
communication layers during troubleshooting exercises rather than testing
sessions.
I suspect the problem is deeper than we might perceive: the growth of the
data communications industry during the late 1990s led to an unprecendented
demand for supporting materials from the publishing industry, and it's not
clear that the pool of authors was able to commensurately scale to meet the
challenge, even though the output appeared to.
"Chuck Larrieu" @groupstudy.com on 12/10/2001 01:58:31
AM
Please respond to "Chuck Larrieu"
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Kevin Cullimore)
Subject: OT: who do you trust: WAS: RE: Does session layer protocol use
[7:28642]
This is probably as good a place as any to broach one of my pet peeves -
that being the reliability of the information one gets in ANY of the study
materials most of us use. We've had conversations here in the past about
some of the more bizarre proclamations one can find on CCO, for example. I
recall one I posted here a couple of times in the past, one which states
that the max diameter of an EIGRP network is 224 because of the TCP limit
on
how far packets can travel. ( No I can't locate the link now, and I have
better things to do than search for it again )
the point being that unless one is already expert in the material, how is
one to know whether or not a given statement can be accepted, or must be
questioned?
Let me give a good one I just read in "Large Scale IP Network Solutions", a
Cisco press book with the letters "CCIE" prominently displayed on the
binding, just below the words "Cisco Professional Development" In other
words, yet another of the Cisco Press books which purports to help one
along
the road to the CCIE.
Quote: "The only route RIP understands as the default route is 0.0.0.0. It
carries this route by default, which means you do not have to specify it.
For RIP to advertise a default route, it must find a route to the 0.0.0.0
network in its routing table."
OK. I understand what is being said. Now consider the following:
R8------------R7----------------R6---------------R5
10.1.1.0/24 192.168.1.16/28 192.168.2.48/28
relevant configuration for R7:
interface Serial1
ip address 10.1.1.7 255.255.255.0
clockrate 2000000
!
interface TokenRing0
ip address 192.168.1.17 255.255.255.240
ring-speed 4
!
router rip
network 10.0.0.0
network 192.168.1.0
!
ip classless
ip default-network 10.0.0.0
R7#
R7's routing table:
* 10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial1
192.168.1.0/28 is subnetted, 1 subnets
C 192.168.1.16 is directly connected, TokenRing0
R 192.168.2.0/24 [120/1] via 192.168.1.18, 00:00:03, TokenRing0
R7#
note that 10.0.0.0 is marked as the candidate default network, based on the
command ip default-network found in the configuration above
R6 routing table:
Gateway of last resort is 192.168.1.17 to network 0.0.0.0
R 10.0.0.0/8 [120/1] via 192.168.1.17, 00:00:15, TokenRing0
192.168.1.0/28 is subnetted, 1 subnets
C 192.168.1.16 is directly connected, TokenRing0
192.168.2.0/28 is subnetted, 1 subnets
C 192.168.2.48 is directly connected, Serial1
R* 0.0.0.0/0 [120/1] via 192.168.1.17, 00:00:15, TokenRing0
R6#
Huh??????? where did the quad zero come from? The only thing I have going
is
the default-network command on R7. No static to quad zero.
R5 routing table:
Gateway of last resort is 192.168.2.49 to network 0.0.0.0
172.29.0.0/24 is subnetted, 4 subnets
C 172.29.200.0 is directly connected, Loopback0
C 172.29.3.0 is directly connected, TokenRing0
C 172.29.2.0 is directly connected, TokenRing0
C 172.29.101.0 is directly connected, TokenRing0
R 10.0.0.0/8 [120/2] via 192.168.2.49, 00:00:08, Serial1
R 192.168.1.0/24 [120/1] via 192.168.2.49, 00:00:08, Serial1
192.168.2.0/28 is subnetted, 1 subnets
C 192.168.2.48 is directly connected, Serial1
R* 0.0.0.0/0 [120/2] via 192.168.2.49, 00:00:09, Serial1
R5#
Huh?????? Again, where exactly did this quad zero come from?
now if you follow the path of the 0.0.0.0 routes in the various routing
tables, you see that R5 shows 0.0.0.0 going to R6, and R6's 0.0.0.0 points
to the interface where lies R7.
But nowhere in this pod is there any reference to an ip route 0.0.0.0, nor
does the 0.0.0.0 route appear in R7's routing table, whence originates the
default route.
My read on this is that Cisco's implementation of RIP will indeed interpret
a default-network statement as an equivalent of the quad zero route and
therefore will perpetuate it.
But that's not what this "CCIE" level book says. In fact, it says something
which would lead one to conclude that RIP should not behave this way at
all.
I suppose I SHOULD grant the possibility that older IOS versions do behave
as the book describes. I'm using 12.1, and I do know that many things
changed in 12.1, including some things that many of us take for gospel
because we have proven them in earlier IOS versions.
So what's a body ( not to mention mind ) to do?
My point being that it is not easy for those of us who were not involved in
the working committees of the CCITT or the IETF to really know how to judge
the secondary sources we read. Cisco in particular, and especially in the
certification game, presents itself as the ultimate authority on a lot of
things. I daresay Cisco makes great effort to produce products and software
that is standards compliant. So why does stuff like this happen? Because
the
people who read the RFC's and write the books are not conversant with the
code designs and code operations that were written into the IOS? things
that
result in a behaviour which if interpreted as I have, seems to belie the
way
something is "supposed" to work?
I mean, I know a couple of places that propose to teach us about
access-lists, and if you do things exactly the way they are described in
the
text, routing breaks. This isn't just in Todd Lammle's books, BTW, but in
at
least one CCIE level treatise published by someplace that's trying to make
money selling CCIE prep materials.
If it's like this for standard stuff like RIP, what prayer is there for us
understanding nonintuitive, non standard and arbitrary mappings of DoD
based
protocols onto the OSI model? I've said it before - when I read some of the
RFC's I don't see people talking about layers or operation and
responsibility. I see people talking in terms of subroutines and process
modules. NFS and ARP and BGP do things because that is how they operate,
not
because of their place in the OSI model.
Go to bed, Chuck, you've had a long day and this is beyond any point of
redeeming study value.
Yes, Dear.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Priscilla Oppenheimer
Sent: Sunday, December 09, 2001 11:05 AM
To: [EMAIL PROTECTED]
Subject: RE: Does session layer protocol use IP address ? [7:28378]
At 06:18 PM 12/8/01, anil wrote:
>This is from Cisco Oct 2001 Packet..
>http://www.cisco.com/warp/public/784/packet/oct01/p76-training.html
>
>It must be out of date :-)
Not "out of date." Just wrong. You can keep coming up with wrong material.
What's your point?
Have you looked at NFS with a Sniffer? Have you read a Unix man page? Have
you checked some RFCs?
Have you considered what NFS does? What are its functions? What do its
messages look like? What protocols below it does it rely on? What problems
were its creators trying to solve?
Please stop sending messages about this topic (or any other topic) until
you have done some real research. In your last message you quoted page 9 of
a CCNA book. Sorry to burst your bubble, but nobody on this list could care
less what it says on page 9 of a CCNA book. This list is for people
studying for advanced Cisco certifications.
Priscilla
>-Anil
>------------------------
>
>5. Session Layer
>The session layer provides services in the application to manage
inter-host
>communication. Think of this function as the old-time telephone
switchboard
>operator: first, watching for a light on the switchboard indicating a
>connection was needed, next connecting and monitoring the call, and then
>finally disconnecting it by pulling the plug. For example, Network File
>System (NFS) is like an extended feature Telnet program for UNIX that
keeps
>a connection (session) alive and available until the terminate command is
>given. Other examples include Structured Query Language (SQL), Remote
>Procedure Call (RPC), and X-Windows.
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Priscilla Oppenheimer
>Sent: Saturday, December 08, 2001 3:13 AM
>To: [EMAIL PROTECTED]
>Subject: RE: Does session layer protocol use IP address ? [7:28378]
>
>
>That's 40% right.
>
>SQL, NFS, and XWindows are application-layer protocols.
>
>RPC and NetBIOS are session-layer protocols.
>
>We often have discussions about which books are best. Todd Lammle books
can
>teach you basic router configuration. They are often wrong where protocol
>behavior is concerned.
>
>A better reference for learning about OSI is the OSI paper by Howard
>Berkowitz at http://www.certificationzone.com.
>
>Priscilla
>
>At 11:32 PM 12/7/01, anil wrote:
> > >The session layer is an elusive beast that is not implemented much
> >Yes, I checked it out..
> >Session layer protocols include:
> >SQL, NFS, RPC, NetBios, Xwindows are examples of session layer
protocols.
> >Page 9 of CCNA 2nd Edition study guide Todd Lammle
> >
> >-Anil
> >
> >
> >
> >
> >-----Original Message-----
> >From: anil [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, December 07, 2001 11:17 PM
> >To: Priscilla Oppenheimer; [EMAIL PROTECTED]
> >Subject: RE: Does session layer protocol use IP address ? [7:28378]
> >
> >
> > >The session layer is an elusive beast that is not implemented much
> >Wait a sec, I thought SQL, NFS and netbios were session layer protocols?
> >Someone please correct me.
> >-Anil
> >
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> >Priscilla Oppenheimer
> >Sent: Friday, December 07, 2001 9:55 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Does session layer protocol use IP address ? [7:28378]
> >
> >
> >At 02:59 AM 12/7/01, mlh wrote:
> > >Hi, there,
> > >
> > >I read Todd Lammle's CCNA2.0 study guide and found this sentence:
>"Remember
> > >that none of the upper
> > >layers know anything about networking or network addresses." I am
>wondering
> > >if the session layer doesn't
> > >use network address, how can it establish a dialogue with other
session
> > >layer in other host?
> >
> >I would probably disagree with Todd's statement, although it's taken out
of
> >context and you haven't given us enough information to say that the
> >statement is definitely "wrong."
> >
> >However, try to picture the numerous OSI pictures you have seen. Most of
> >them show horizontal lines between a layer on one host talking to the
same
> >layer on another host. So the session layer talks to the session layer
on
> >the other host. That's probably what Todd was getting at.
> >
> >However, the pictures also show vertical lines. A layer calls on a layer
> >below to provide services. Each layer offers services to layers above
it.
> >
> >The session layer is an elusive beast that is not implemented much. But
one
> >example might help. NetBIOS is a session layer. On a Windows client,
when
> >you access a Server Message Block (SMB) server, NetBIOS has the job of
> >setting up a session with the server. Before it can do that, however, it
> >must find the address of the server. If it's a modern Windows network,
then
> >SMB and NetBIOS are probably running above TCP/IP and UDP/IP. So NetBIOS
> >sends a DNS or WINS query to find the IP address of the named server. It
> >then sets up a NetBIOS session with the server. Actually, first, the
client
> >sets up a TCP connection. TCP has port numbers. The client sends to the
> >well-known TCP port for NetBIOS session (139) and use an ephemeral port
on
> >its side. These port numbers could be considered "addresses" at the
> >transport layer.
> >
> >Anyway, back to the question. The statement is at best over-simplified.
I
> >recommend you get yourself a sniffer and watch what really happens
between
> >layers. (Ethereal is free by the way.)
> >
> >Priscilla
> >
> >
> >
> > >Thank you for your time.
> > >
> > >mlh
> >________________________
> >
> >Priscilla Oppenheimer
> >http://www.priscilla.com
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
________________________
Priscilla Oppenheimer
http://www.priscilla.com
================================================================
This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein. If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
================================================================
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=28652&t=28652
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
