09.12.2012 Views

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

NOTE<br />

On switched E<strong>the</strong>rnet segments that are operating in full-duplex mode (a single<br />

end-station attached <strong>to</strong> switch port or an inter-switch link), <strong>the</strong>re should be no<br />

collisions. This is because full-duplex operation disables <strong>the</strong> collision detection<br />

aspect of CSMA/CD used by E<strong>the</strong>rnet in order for <strong>the</strong> end-station <strong>to</strong> send and<br />

receive data simultaneously. If you do see collisions on a link you believe is<br />

configured for full-duplex operation, chances are that, ei<strong>the</strong>r <strong>the</strong> end-station or <strong>the</strong><br />

switch port is misconfigured.<br />

As part of E<strong>the</strong>rnet's CSMA/CD implementation, E<strong>the</strong>rnet has defined minimum and<br />

maximum packet sizes. The minimum packet sizes are 72 bytes, 64-bytes data,<br />

including <strong>the</strong> frame header, <strong>the</strong> data PDU and <strong>the</strong> frames CRC, plus an 8-byte<br />

preamble. The maximum packet sizes are 1,526 bytes (802.3) or 1,530 bytes<br />

(802.3ac) (1,518-byte, including <strong>the</strong> CRC and header, plus an 8-byte preamble).<br />

E<strong>the</strong>rnet frames that are less than <strong>the</strong> minimum size are known as runts, and<br />

excessively long packets are known as jabs. Illegal packet sizes are caused by a bad<br />

NIC or corrupted NIC driver. Ano<strong>the</strong>r indication of a bad NIC is a condition called<br />

jabbering, which occurs when a NIC sends continuous stream bits that are longer<br />

than 1,526/1,530 bytes in length. Jabbering can bring <strong>the</strong> entire segment <strong>to</strong> halt<br />

because <strong>the</strong> jabbering station typically cannot hear collisions on <strong>the</strong> segment, and it<br />

just continues transmitting streams of random bits, consuming all <strong>the</strong> segment's<br />

available bandwidth.<br />

Token Ring Errors<br />

Token Ring has two types of error conditions: soft and hard. Soft errors are error<br />

conditions of an intermittent nature that only impact data transmission on a<br />

temporary basis. When a soft error is encountered on a Token Ring system, an error<br />

recovery process is initiated. This process begins with <strong>the</strong> detecting station<br />

collecting error type information and <strong>the</strong>n generating a report indicating <strong>the</strong> type of<br />

error (and <strong>the</strong> station at fault, if possible) and sends it <strong>to</strong> <strong>the</strong> Ring Error Moni<strong>to</strong>r<br />

(REM). REM is collects ring error information <strong>to</strong> troubleshoot error conditions on <strong>the</strong><br />

ring. Each station keeps track of <strong>the</strong> errors it detects on <strong>the</strong> ring and, when an error<br />

is detected, it increments it's internal soft error counter. The remainder of <strong>the</strong><br />

recovery process depends on <strong>the</strong> category and type of soft error that occurs.<br />

Token Ring soft errors are divided in<strong>to</strong> two categories: isolating and non-isolating.<br />

Isolating soft errors (ISEs) are soft errors that can be attributed <strong>to</strong> a specific Token<br />

Ring fault domain. A fault domain is a logical area of <strong>the</strong> ring that consists of <strong>the</strong><br />

station that has detected <strong>the</strong> error, it's nearest active upstream neighbor (NAUN),

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!