Yup, SLARP is pretty cool. It's one good reason to use HDLC. It makes
configuration so easy. Also, the students will love saying SLARP. I'm
helping out with the academy at our local high school, as I've mentioned
before. Those students will love saying SLARP, over and over and over again.
Lately, they have taken to giving me a hard time about "Sniffer." They
snicker every time I say it. It's kind of embarrassing, to be honest. I
want them to take it seriously. It's all boys, so I'm worried that Sniffer
means something dirty. Sigh.
I'm having a hard time, in general, teaching networking to kids who don't
really love it and don't have to know it for their jobs. I got spoiled,
teaching classes to people who had paid money to be there and needed the
info to survive on the job. I'm sure it's quite different at a community
college, but you probably get some young people too. Any advice?? Thanks!
Talk to you later!
Priscilla
At 06:38 PM 2/8/01, Tom Lisa wrote:
>WOW!! Great stuff, especially the SLARP info! I think I'll save this for
>when we
>start teaching CCNP level courses. It would frighten my CCNA students.
>
>BTW, for all Las Vegas area members, the Community College will be
>offering the
>BSCN course in the Fall Semester. It will be offered at both the Cheyenne and
>Henderson campuses. Email me directly if you would like more info.
>
>Tom Lisa, Instructor, CCNA, CCAI
>Community College of Southern Nevada
>Cisco Regional Networking Academy
>
>Priscilla Oppenheimer wrote:
>
> > At 03:09 PM 2/8/01, Tom Lisa wrote:
> > >Priscilla,
> > >
> > >In the Cisco Networking Academy (Sem4) curriculum, significantly more time
> > >is spent on
> > >PPP operation & configuration than Cisco's HDLC.
> >
> > That's just because you can say something useful about PPP. It's great for
> > instructors. They can show off how much they have learned about PAP and
> > CHAP. &;-)
> >
> > What can you say about Cisco HDLC? Not much, though here are some comments
> > on Cisco HDLC, since it is being talked about so much today:
> >
> > cisco's default encapsulation on synchronous serial lines uses HDLC
> framing,
> > with packet contents defined as follows:
> >
> > The first ("address") octet is set to 0x0F for unicast packets and 0x8F
> > for broadcast packets. Broadcast just means that the higher-level protocol
> > thought this was a broadcast packet; cisco doesn't support multidrop
> > HDLC at this time.
> >
> > The second ("control") octet is always 0.
> >
> > The next two octets are a 16-bit protocol code, sent
> most-significant-first.
> > These codes are usually Ethernet type codes. cisco has added some codes to
> > support packet types that don't appear on Ethernets. The current list
> of codes
> > is as follows:
> >
> > TYPE_PUP 0x0200 PUP
> > TYPE_XNS 0x0600 XNS
> > TYPE_IP10MB 0x0800 IP
> > TYPE_CHAOS 0x0804 Chaos
> > TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning
> > prot.
> > TYPE_DECNET 0x6003 DECnet phase IV
> > TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
> > TYPE_APOLLO 0x8019 Apollo domain
> > TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse
> ARP!)
> > TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol
> > TYPE_ETHERTALK 0x809b Apple EtherTalk
> > TYPE_AARP 0x80f3 Appletalk ARP
> > TYPE_NOVELL1 0x8137 Novell IPX
> > TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
> >
> > This list is shared between serial and Ethernet encapsulations. Not all
> > these codes will necessarily appear on serial lines. This list will
> probably
> > be extended as cisco adds support for more protocols.
> >
> > Bytes after this are higher-level protocol data. These normally look the
> > same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
> > MAC headers; no other packets do.
> >
> > Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
> > they would on an Ethernet. Instead, they carry a protocol cisco refers to
> > as SLARP. SLARP has two functions: dynamic IP address determination and
> > serial line keepalive.
> >
> > The serial line model supported by SLARP assumes that each serial line is
> > a separate IP subnet, and that one end of the line is host number 1, while
> > the other end is host number 2. The SLARP address resolution protocol
> allows
> > system A to request that system B tell system A system B's IP address,
> > along with the IP netmask to be used on the network. It does this by
> sending
> > a SLARP address resolution request packet, to which system B responds
> with a
> > SLARP address resolution reply packet. System A then attempts to
> determine its
> > own IP address based on the address of system B. If the host portion of
> system
> > B's address is 1, system A will use 2 for the host portion of its own IP
> > address. Conversely, if system B's IP host number is 2, system A will
> use IP
> > host number 1. If system B replies with any IP host number other than 1
> or 2,
> > system A assumes that system B is unable to provide it with an address via
> > SLARP.
> >
> > For the SLARP keepalive protocol, each system sends the other a keepalive
> > packet at a user-configurable interval. The default interval is 10 seconds.
> > Both systems must use the same interval to ensure reliable operation.
> > Each system assigns sequence numbers to the keepalive packets it sends,
> > starting with zero, independent of the other system. These sequence numbers
> > are included in the keepalive packets sent to the other system. Also
> included
> > in each keepalive packet is the sequence number of the last keepalive
> packet
> > _received_ from the other system, as assigned by the other system. This
> number
> > is called the returned sequence number. Each system keeps track of the last
> > returned sequence number it has received. Immediately before sending a
> > keepalive
> > packet, it compares the sequence number of the packet it is about to
> send with
> > the returned sequence number in the last keepalive packet it has received.
> > If the two differ by 3 or more, it considers the line to have failed, and
> > will route no further higher-level data across it until an acceptable
> keepalive
> > response is received.
> >
> > There is interaction between the SLARP address resolution protocol and the
> > SLARP keepalive protocol. When one end of a serial line receives a SLARP
> > address resolution request packet, it assumes that the other end has
> restarted
> > its serial interface and reset its keepalive sequence numbers. In addition
> > to responding to the address resolution request, it will act as if the
> > other end had sent it a keepalive packet with a sequence number of zero,
> > and a returned sequence number the same as the returned sequence number
> > of the last real keepalive packet it received from the other end.
> >
> > The following is a C definition for the SLARP packet. The "long" and
> "ulong"
> > types are 32-bit numbers, high octet sent first. The "ushort" type is a
> 16-bit
> > number, high octet sent first.
> >
> > struct slarp {
> > long code; /* SLARP packet type code */
> > union sl { /* followed by one of: */
> > struct { /* Address resolution functions */
> > ulong address; /* Address of system sending this
> > pkt */
> > ulong mask; /* IP subnet mask for this line */
> > ushort unused; /* Unused: contents undefined */
> > } add; /* -- or -- */
> > struct { /* Keepalive probing functions */
> > ulong mysequence; /* Outgoing sequence number */
> > ulong yoursequence; /* Returned sequence number */
> > ushort reliability; /* Reserved: set to FFFF */
> > } chk;
> > } t;
> > };
> >
> > Note that the data storage for t.add is overlayed on the data storage for
> > t.chk. The whole SLARP packet consists of a 32-bit type code, followed by
> > two 32-bit quantities and one 16-bit quantity. The overall length of the
> > SLARP packet is 14 octets. The "code" field is used to identify the
> packet's
> > SLARP type. Legal values for the "code" field are as follows:
> >
> > SLARP_REQUEST 0 Address resolution request
> > SLARP_REPLY 1 Address resolution reply
> > SLARP_LINECHECK 2 Line keepalive
> >
> > For address resolution request packets, the "address" and "mask" fields are
> > set to zero, and the contents of the "unused" field field are
> undefined. For
> > address resolution reply packets, the "address" field contains the IP
> address
> > of the _replying_ system, and the "mask" field contains the IP subnet mask
> > to be used. The contents of the "unused" field are undefined.
> >
> > For keepalive packets, the "mysequence" field contains the sequence number
> > of the packet and the "yoursequence" field contains the returned sequence
> > number, which is the sequence number of the last keepalive packet the
> sending
> > system has gotten from the receiving system. The "reliability" field is
> > reserved for future use, and _must_ be set to FFFF hexadecimal.
> >
> > Priscilla
> >
> > ________________________
> >
> > Priscilla Oppenheimer
> > http://www.priscilla.com
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
