You're obviously a trainer! I am too.

The CRC is handled by the NIC, not the OS of the computer. Just a nit-picky 
thing. However, I also have to object to the main message that you are 
giving. I think it's very important to mention that it is rare that B1 (a 
bridge or router) would retransmit.

The "right answer" for certain tests is that the bridge or router won't 
retransmit, unless the question is asking about a particular protocol where 
this isn't the case. Retransmitting is usually the job of the end node. The 
end node doesn't hear its frame get acknowledged, so it retransmits. 
Retransmitting is the job of TCP or an upper-layer application. In the case 
of SNA or NetBEUI running above LLC2, it is the job of LLC2 at the end 
station (unless you use Local ACK). At some layer, for most applications, 
there is reliability. You mention UDP and say that there are no 
retransmissions. UDP doesn't handle retransmissions, but with most 
protocols that run above UDP, the host retransmits if there is no reply to 
its message.

Here's a list of cases where a router or bridge would retransmit instead of 
the end host.

BISYNC - YES
X.21 - YES
SDLC - YES
The various LAPs (LAPB, LAPF, etc.) - YES?
Cisco HDLC - NO!! (remember it's Cisco's own variety of HDLC)
PPP - NO
Frame Rely - NO
Ethernet - NO
Token Ring - NO
FDDI - NO
LLC1 - NO
LLC2 - NO, unless you're using DLSw or RSRB with Local ACK
LLC3 - who cares? ;-), but I think the answer is YES

Ethernet causes some confusion for people because a data-link-layer 
interface monitors for collisions while sending and retransmitting if one 
occurs. I don't think this fits into the same category as we're dealing 
with in this question, but the neophytes think it does, so it's worth 
addressing. I consider sending without collisions a basic part of Media 
Access Control, analogous to getting the token on Token Ring. It's not the 
same as monitoring for an ACK and retransmitting if you don't get one, 
which Ethernet NEVER does.

This is an extremely easy Networking 101 question where I come from. It's 
really frustrating that it results in so much confusion.

Priscilla



At 11:21 PM 11/12/01, Baety Wayne   A1C 18 CS/SCBX wrote:
>Line hits are caused by physical disturbances, electronic influences
>on the transmission medium.  The question draws attention to the serial
>connection between B1 and B2, and a possible difference between Ethernet
>connections.  Ethernet makes no provision for physical layer protocol
>retransmission in the face of erred communications.  An explanation follows.
>
>
>         There are different physical layer protocol entities for Ethernet,
>notably MLT-3 for fast Ethernet, Manchester for Ethernet, etc.  These are
>actual protocols for transferring bit streams over a common medium and only
>serve to perform line encoding.  When an error presents itself, most often
>these errors register as invalid code signals to the distant end, which
>somehow gets translated into a data signal, forcibly in the case of
>Ethernet.  After this process is complete the bit streams are compacted and
>provisioned into 8-bit boundaries and are passed up to the data link layer.
>At this point, the communication enters the prevue of a central processing
>unit. The OS controlling the CPU would naturally do a CRC function on the
>received data stream and extract the CRC that was computed by the sending
>node, and do a comparison of the two.  Actual implementations could vary.
>This in essence is an overview of Ethernet Technology.  The important thing
>to remember is that there is not a protocol function that occurs at the
>point the bit streams are sent from the hardware to the main CPU (channel
>access functions are handled in hardware on a NIC).  All communication is
>accepted carte blanche, and naturally so.  Ethernet is primarily a LAN
>technology were error prone communications (caused by EMI or other naturally
>occurring phenomenon) is tightly controlled and minimized. In serial
>communication technology there is such a protocol function because there is
>a higher chance of their being electromagnetic influences, propagation
>delay, etc.
>
>         In serial communications at the point that the bit streams are
>decoded into logical binary words (that 8 bit provisioning scheme
>aforementioned).  There is a protocol function implemented to control the
>actual reception and healthiness of the bit streams.  HDLC is the default
>protocol for Cisco Routers, but there are other notables.  Such as Bi-Sync,
>SDLC, LAPB, PPP, etc.  In some of these protocols there are provisions for
>the retransmission of frames when errors are detected, channel multiplexing,
>stream windowing as well as frame sequencing and acknowledgements.
>
>         Why this long answer?  Remember the question draws attention to the
>physical layer when 'line hits' are mentioned.  Further clues were given
>when the only difference mentioned was a change in physical composition.
>It's up to you to decide if the test maker in this instance is testing to
>see if you know all of this, judged by the overall difficulty of the exam.
>
>         To answer your question if there is a line hit between B1 and B2,
B1
>will always retransmit.  In most serial encapsulations method, the frame
>never clears the buffers on B1 until B2 acknowledges reception to B1.
>
>         There was an effort to add this amount of reliability to Ethernet
>and Token Ring environments, hence LLC which is a spin off of sorts of HDLC
>for serial communications.  With LLC there are actually 3 different modes of
>communication.  Type 1 is the normal mode that you would normally see in
>modern networking environments (Type 2 is more usual for Token Ring).  Type
>2 is modeled after communication qualities that serial communications need
>to overcome. Type 3 is not commonly used.  To be succinct, it is like
>slapping a serial protocol over Ethernet or Token Ring.  When Ethernet is
>behaving like a serial interface it will buffer, acknowledge and retransmit
>erred frames just like a serial interface (In that case, each intermediate
>device is responsible for retransmitting any frames with errors).  Like
>everything else in life, the true answer depends on what you are doing.
>
>To be safe, let me point out that all of this nonsense usually is spoken of
>in the books as residing at the Data Link layer.  I believe the test
>question may also be trying to confuse you with what are the
>responsibilities of the Transport layer (TCP to be exact).  But what if you
>aren't even using TCP, What if you are using UDP over IP over Ethernet?
>There is clearly no retransmission effort going on here.  All confusing
>isn't it?  Don't worry in time you'll sort it all out.
>
>Cheers and Good Luck,
>
>WAYNE BAETY, MCSE, A1C, USAF
>Network Systems Trainer
>
>
>-----Original Message-----
>From: Todd Carswell [mailto:[EMAIL PROTECTED]]
>Sent: Monday, November 12, 2001 11:09 PM
>To: [EMAIL PROTECTED]
>Subject: 2 "Line Hit" Scenarios... [7:25928]
>
>Here's the setup for my 2 questions...
>
>PCA-------B1-----------B2--------PCB
>
>Bridge 1 and Bridge 2 are running Transparent Bridging between them.
>
>Question 1:  There's a SERIAL connection between B1 and B2.  B1 and B2 are
>configured for transparent bridging.  If PCA sends a packet to PCB and the
>frame is errored somehow, who takes care of the retransmission?  I assume
>it's PCA because it's a serial connection.  Am I right?
>
>Question 2:  There's an ETHERNET connection between B1 and B2.  The bridges
>are still using Transparent Bridging and PCA sends a packet to PCB.  Again,
>the frame has an error.  Will B1 be the device to handle the retransmission?
>
>Thanks, guys!
>
>Todd
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=26130&t=25928
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to