Aquileo | Hub & Switch



Just do it!  wrote in message
news:3gkAdc$Kn4@bbs.cynix.com.tw...
>  ޭzmYBO.bbs@bbs.yzu.edu.tw (WZ)nʨG
> >  ޭzmMjolnyr.bbs@BirdNest.infoX.Net (Francis Jan)nʨG
> > > J.
> > hubbhHsɤWWeOt
> > switch hubOݽ֦ݭn~LWe
> > ]NOhubܹOs覡ǻT
> > switch hubOǨQnxD
>
> @ HUB P Switch HUBAOsrAnM..
> ھFݱoADHCPpϥΩOH
>
> MAsupported VLAN ~ҥ~o..
>
> @ HUB P Switch HUB tOA@UAp~A
> ٱ氪HII.. :P
>
> Hub ݩ Layer 1 product.
> Switch Hub hݩ Layer 2 product.
>
> Switch Hub @ Hub h\A̤֥noaǲ
> C Port  Mac addressC
>
> ] Switch Hub port 1 Ǩ쪺 Mac address  00:10:B5:30:30:A9
> port 2 Ǩ쪺 Mac address  00:10:C1:D3:E2:A2
> port 3 Ǩ쪺 Mac address  00:10:B3:E3:A1:07
>
> Port 1 UO LinuxA
> Port 2 UO Win98A
> Port 3 UO RouterC
>
> ѡA]znq Linux zL Router sW InternetA򭺥eX
> ARP packages ݨ Router IP ҹ Mac addressAM Linux N
> s Router ҹ Mac address (00:10:B3:E3:A1:07) qC
>
> 䤤ASwitch HUB wgo Linux P Router  Mac addressA Linux
> P Router ƶǿɡAä|Nƥ port 2  win98Cpz
> Qnb Win98 W sniffer nťʥ]Azhť Linux
> P Router ǰeʥ]C
>
> oNO Switch HUB oaC
> OpGO HUBAL׬OoӽuqWơAC Port oC
>
> סASwitch HUBA HUB 󦳦wʡA֫ʥ]IAǿ󦳮ĲvC
>
> wja[СC
>


ڳwݨo˪סM]wMo˪BͰQסC

ڭ̳o̽ͨ쪺 switch ۫HO level 2 WaMڭ̭nD OSI level
2 layer WзǤ~nzѡC䤤 IEEE802.x Oγ̼sзǡMӧڭ̳
` ethernet hOϥ IEEE802.3 o MAC sublayer зǡMW DLC
sublayer 802.2 N浹g programing B@U aC

ڭ̳o̬ݬ IEEE802.3 OB@MSʦǡS

IEEE802.3 b ethernet WϥΪǿ޳NM̴MQĥΪO CSMA/CDMiH
}TӳӤFѡR

1) CS (Carrier Sense)

ǰe]ƭnNHeܶǿC餧eMnCO_wgsb carrierMpG
Mhܦ䥦]ƦbϥγoӴCi䥦ǰeCMhMǰe]ƴNVo
ӴCeXHMӥUS carrier ɭԤ~ǰeConz
ѡM]NOmĹMnbҰWoM֥|⻡֥MpGwgHb
FMNC

2) MA (Mutiple Access)
bP@ɶM\hӳ]ƨϥΦ@ɴC(M} CS M CD )Cb
CSMA/CD ޳NMoe]ƶQqL CS ˴VCeXHӨSo
Collision ܡMҦɵۦP@C骺]ơMবoӫHCC@ӳ]Ƴ
@Ӱߤ@}ѡMڭ̳q`٤ MAC }QӫHbǰeC餤hOH frame
ΦǰeMC frame @ source M@ destination }Cǰe]
N frame eܴCWMuQѬ destination ]ơM~|NH copy
UӡMAWh{e (decapsulate)MӨǳ]Ƶo{ destination Oۤv
ܡMNªBzo frame (Db promiscuous ҦU)C

PwM MA ϥΪPM]|vTĲvB@MҦpsʥ]MǥH
FF:FF:FF:FF:FF:FF  MAC }ʥ]Mswitch ٬O|eҦWM]
ϥγoӼs} frameMCӱ]Ƴ|N copy UӶi decapsulate B
zCҦp Microsoft Network waڡMϥμsʥ]vOD`MN
ϥ L2 switch o˪s]LCuQ subnet M router Χ
level  switch ~ġM]wʩMB~W[qM]OntM
ȴNWXثeQ׽dFC

3) CD (Collision Detection)
e CS L{MbzQpUMҦɵۦ@PC骺]ơMӦ|
oǰe|CuOMql]ƪB@tסMDڭ̤HүPMoǹB
@MC@i঳WUƦܦʸUhMҦp CAT 5 uMNBz
350Mhz Χ󰪪ǰeWvCpMӳ]ƭnboʸU@MPɰ
CS ʧ@MӤSPɱCWS carrierMoرΤUMoӳ]ƥi
|PɹoCǰeHMoNOڭ̱` Collision (I)FCpG@ӸI
oͤFMN|bCWfrequecy ripple {HC@Ӧbu]ư
ripple MN|oX@ӰWHhMҦ䥦HCyܻMoӫHPɧi
DҦ]ơMIwgo͡CoɭԡMC@ӳ]Ƴ|Hݤ@qɶAsi
 CSMpGs(D_)٬OJ collisionMN@wҩHݮ
ԡM`@iHi16դja~|̲שCҥHݥXMpGbP@
segment WMbu]ƶVhMo collision |]VjC

ƹWMF CSMA/CD ~M٦@ CSMA/CA (CA = Collision Avoidance) ޳N
ڭ̥iHϥΡRoeݥVݰeX RTS(Request To Send) ʥ]M CTS
(Clear To Send) ^M~VCeXHCAppleTalk wNOϥγoا޳NC
CA M CD OMiHιLWӤR CD ɭԡMnLNLMLFAӡQ
 CA ɭԡM|@ӤprMpGLqLFMMz~IMӹLC


nFMzF CSMA/CD oӨwMAӬݬ HUB M Switch OaR

HUB ªO@ repeaterMq@ port (M TCP w port @ˡMo
Ou)HiӤM|NoӫH쥻eҦ䥦
port WMޭ port O@xC

 switch OSۤv@ tableMOۭ port  MAC }]ƤWC
Hq@ port iӤM|ˬdo frame  destination O MACMM
 table o MAC  port MӶȱNHo port eM䥦 port
NeFC

o˦nBS

ݬ CS aM hub ɭԡMҦ port ҳs쪺]Ƴ carrierMM
NnQӥ switch OSǤO destination ]ơMèS
carrierM]NLݦAMiHVCeXHCHF switch 
ԡMswitch |Q cache oӫHMMi table MAV
destination eXCpG switch  cache VjMCPU BzOVjMĲv]V
MM]VQC

A CDM]jѳ]ưeXHM|Q switch cache _ӡMMAgL
table P_eXM collision |]j֡MѦM] CD Ӥ_ǰe
]Nj֡M۹諸MҦ]ƪϥήĲv]jC

ܩ MAM۫HΦhFaSϥ swtich ٦@ӦnBRwʡCp
Gڭ̥ hub ӳs]ơM] frame |FҦMpGYHb]ƤWˤW
@ӫʥ]nMPɱNd promiscuous mode }MNiHݨҦ
ʥ]FQpG switch OSuQeoxWʥ]M~QCq`b
wWMwʹįΫKQʬOϤ񪺡RnW[wʡMNn묹į
MKQʡQnW[įMKQʡMNn묹wʡC switchMGOߤ@}o
X]ƤFC

ק٬ݨ즳HN Bridge M Switch V@ͤFMڤDӤS bridge 
zѬO˪SbU{Mbridge \uӡRfiltering M forwardingQ
̬OھګȩP_~o͡C

ϥ bridge ɭԡM򥻤WNzsu segment (ΦhӡM bridge
ɭөw)MMMbridge ]|إ߰_ۤv tableMONP MAC 줣P
 segment hCM frame F bridge ɭԡMbridge |ˬd source M
destinationMpGo{o MAC bP@ segment WMNBzo
frame (o filter \)QpGo{ soure M destination bP@
segment WOMN_ forward \MN frame e destination  segment
WMάOªVҦD source segment(s) e( bridge O)C

oˬݨӡMbridge  CS M CD ]_ﵽ@ΡM frame BzMM
switch O@˪Rbridge H segment ̾ڡM switch hHӧO]ƬM
ҥHbĲvW٬OOCMMpGzNC@ port ҳs]Ƭݬ@
 segmentMMN switch ݬ learning bridgeMγ\iHN̬ݬ
ӳ]ƧaC

ܩ 10Base M 100Base ഫMuO switch @D`²檺\ӤwM
DO switch u[]C


HW¬ӤH{Mp~MЫMHK~[C

--


======= http://www.study-area.org =======
KMBeKk
wOHVʤVBMצKN
N]KMuKӳ
ݱos꺩ɡMLbOT
 
 
^Х 
 Re: аݦWeWD 
@: netman (---.seed.net.tw)
:   01/06/15 15:26


˭l_  wrote in message
news:3gkYKi$UHC@BirdNest.infoX.Net...

>
> o@qAiHIEEE 802.3حjamԭzAݤ@ݡAAkPڱp
> XJC

h´IT

ǲߪL{MuOӤobIikMQiXVMbeLCK~ɤj
aMNdߵGCpUR

4.1.2.2 Access interference and recovery
In half duplex mode,if multiple stations attempt to transmit at the same
time,it is possible for them to interfere with each other s
transmissions,in spite of their attempts to a oid this by deferring.When
transmissions
from two stations o erlap,the resulting contention is called a
collision.Collisions occur only in half duplex
mode,where a collision indicates that there is more than one station
attempting to use the shared physical
medium.In full duplex mode,two stations may transmit to each other
simultaneously without causing interference.The Physical Layer may generate
a collision indication,but this is ignored by the full duplex MAC.
A gi en station can experience a collision during the initial part of its
transmission (the collision window)
before its transmitted signal has had time to propagate to all stations on
the CSMA/CD medium.Once the
collision window has passed,a transmitting station is said to ha e acquired
the medium;subsequent collisions are a oided since all other (properly
functioning)stations can be assumed to ha e noticed the signal
and to be deferring to it.The time to acquire the medium is thus based on
the round-trip propagation time of
the Physical Layer whose elements include the PLS,PMA,and physical medium.
In the e ent of a collision,the transmitting station s Physical Layer
initially notices the interference on the
medium and then turns on the collision detect signal.In half duplex
mode,this is noticed in turn by the
Transmit Media Access Management component of the MAC sublayer,and
collision handling begins.First,
Transmit Media Access Management enforces the collision by transmitting a
bit sequence called jam.In 4.4,
implementations that use this enforcement procedure are provided.This
ensures that the duration of the collision is suf ?cient to be noticed by
the other transmitting station(s)in olved in the collision.After the jam is
sent,Transmit Media Access Management terminates the transmission and
schedules another transmission
attempt after a randomly selected time interval.Retransmission is attempted
again in the face of repeated
collisions.Since repeated collisions indicate a busy medium,howe
er,Transmit Media Access Management
attempts to adjust to the medium load by backing off (voluntarily delaying
its own retransmissions to reduce
its load on the medium).This is accomplished by expanding the interval from
which the random retransmission time is selected on each successi e
transmit attempt.Eventually,either the transmission succeeds,or the
attempt is abandoned on the assumption that the medium has failed or has
become o erloaded.
In full duplex mode,a station ignores any collision detect signal generated
by the Physical Layer.Transmit
Media Access Management in a full duplex station will always be able to
transmit its frames without contention,so there is ne er any need to jam or
reschedule transmissions.
At the receiving end,the bits resulting from a collision are recei ed and
decoded by the PLS just as are the
bits of a alid frame.Fragmentary frames recei ed during collisions are
distinguished from alid transmissions by the MAC sublayer s Recei e Media
Access Management component.


4.2.3.2.3 Collision handling (half duplex mode only)
Once a CSMA/CD sublayer has ?nished deferring and has started
transmission,it is still possible for it to
experience contention for the medium.Collisions can occur until acquisition
of the network has been accomplished through the deference of all other
stations  CSMA/CD sublayers.
The dynamics of collision handling are largely determined by a single
parameter called the slot time.This
single parameter describes three important aspects of collision handling:
a)It is an upper bound on the acquisition time of the medium.
b)It is an upper bound on the length of a frame fragment generated by a
collision.
c)It is the scheduling quantum for retransmission.
To ful ?ll all three functions,the slot time shall be larger than the sum
of the Physical Layer roundtrip propagation time and the Media Access Layer
maximum jam time.The slot time is determined by the parameters
of the implementation,see 4.4.

4.2.3.2.4 Collision detection and enforcement (half duplex mode only)
Collisions are detected by monitoring the collisionDetect signal provided
by the Physical Layer.When a collision is detected during a frame
transmission,the transmission is not terminated immediately.Instead,the
transmission continues until additional bits speci ?ed by jamSize ha e been
transmitted (counting from the
time collisionDetect went on).This collision enforcement or jam guarantees
that the duration of the collision
is suf ?cient to ensure its detection by all transmitting stations on the
network.The content of the jam is
unspeci ?ed;it may be any ?xed or ariable pattern con enient to the Media
Access implementation,however,the implementation shall not be intentionally
designed to be the 32-bit CRC alue corresponding to the
(partial)frame transmitted prior to the jam.
4.2.3.2.5 Collision backoff and retransmission (half duplex mode only)
When a transmission attempt has terminated due to a collision,it is retried
by the transmitting CSMA/CD
sublayer until either it is successful or a maximum number of attempts
(attemptLimit)ha e been made and
all ha e terminated due to collisions.Note that all attempts to transmit a
gi en frame are completed before
any subsequent outgoing frames are transmitted.The scheduling of the
retransmissions is determined by a
controlled randomization process called truncated binary exponential
backoff.At the end of enforcing a
collision (jamming),the CSMA/CD sublayer delays before attempting to
retransmit the frame.The delay is
an integer multiple of slotTime.The number of slot times to delay before
the nth retransmission attempt is
chosen as a uniformly distributed random integer r in the range:
0 r  ֻ?
> ЧIEEE 802.3зǤswitchMbridgewqӬݬݧaC
> t~AIEEE 802.1DDO MAC bridgeC
>


׬dF@U IEEE MTo{ḺN switch M bridge wqb@_FC
NǷbծɪOMөǦۤvSJӬݤo~~~

LMŪ IEEE  RFC MTOD`FMpGQqYݰ_MUO
ڡ_qUӪޤMƱ墨ǦݬݪBͦUaC



********************************************

IEEE Std 802.3, 2000 Edition
Part 3:Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications

1.4 Definitions
1.4.53 bridge:A layer 2 interconnection device that does not form part of a
CSMA/CD collision domain but
conforms to the ISO/IEC 15802-3:1998 [ANSI/IEEE 802.1D,1998
Edition ]International Standard.A
bridge does not form part of a CSMA/CD collision domain but,rather appears
as a Media Access Control
(MAC)to the collision domain.(See also IEEE Std 100-1996.)
1.4.264 switch:A layer 2 interconnection device that conforms to the
ISO/IEC 10038 [ANSI/IEEE 802.1D-
1990 ] International Standard..Syn:bridge.

4.1.1 Overview
The most common configuration envisioned for full duplex operation consists
of a central bridge (also
known as a switch)with a dedicated LAN connecting each bridge port to a
single device.


12.4.3.2.7 Collision presence startup
When a hub starts generating CP (as speci ?ed in 12.4.3.2.2 through
12.4.3.2.5)it shall synchronize the startup to a half or whole bit-cell
boundary of any immediately preceding signal.If it was sending IDL
immediately before the CP,no synchronization or preamble is required.
A hub may start transmission of CP at any point in the sequence that does
not result in periods of more than
one bit time without a transition during the switch from passing on data to
sending CP.Depending on the
preceding signal,it may start with L010H,010HL,10HL0,0HL01,or HL010.Because
startup may be synchronized to any half-bit-cell boundary,a hub may also
transmit the shifted ersion of CP starting with
1LH10,LH101,H101L,101LH,or 01LH1.



********************************************

ANSI/IEEE Std 802.1D, 1998 Edition
Part 3: Media Access Control (MAC) Bridges


6. Support of the MAC Service

MAC Bridges interconnect the separate IEEE 802 LANs that comprise a Bridged
LAN by relaying and filtering
frames between the separate MACs of the Bridged LAN.The position of the
bridging function within
the MAC Sublayer is shown in Figure 6-1.

Figure 6-1-Internal organization of the MAC Sublayer

This clause discusses the following aspects of service provision in Bridged
LANs:
a) Provision of the MAC Service to end stations;
b) Preservation of the MAC Service;
c) Maintenance of Quality of Service;
d) Provision of the internal sublayer service within the MAC Bridge;
e) Support of the Internal Sublayer Service by specific MAC procedures;
f) Filtering services.

6.5.1 Support by IEEE Std 802.3 (CSMA/CD)
The CSMA/CD access method is specified in IEEE Std 802.3. Clause 3 of that
standard specifies the MAC
frame structure, and Clause 4 specifies the MAC method.
On receipt of an M_UNITDATA.request primitive, the local MAC Entity
performs Transmit Data Encapsulation,
assembling a frame using the parameters supplied as specified below. It
prepends a preamble and a
Start Frame Delimiter before handing the frame to the Transmit Media Access
Management Component in
the MAC Sublayer for transmission (IEEE Std 802.3, 4.2.3).
On receipt of a MAC frame by Receive Media Access Management, the MAC frame
is passed to Receive
Data Decapsulation, which validates the FCS and disassembles the frame, as
specified below, into the
parameters that are supplied with an M_UNITDATA.indication primitive (IEEE
Std 802.3, 4.2.4).
The frame_type parameter takes only the value user_data_frame and is not
explicitly encoded in MAC
frames.
The mac_action parameter takes only the value request_with_no_response and
is not explicitly encoded in
MAC frames.
The destination_address parameter is encoded in the destination address
field of the MAC frame (IEEE Std
802.3, 3.2.3).
The source_address parameter is encoded in the source address field of the
MAC frame (IEEE Std
802.3, 3.2.3).
The number of octets in the mac_service_data_unit parameter is encoded in
the length field of the MAC
frame (IEEE Std 802.3, 3.2.6), and the octets of data are encoded in the
data field (IEEE Std 802.3, 3.2.7).

The user_priority parameter provided in a data request primitive is not
encoded in MAC frames. The
user_priority parameter provided in a data indication primitive takes the
value of the Default User Priority
parameter for the Port through which the MAC frame was received (see 6.4).
The frame_check_sequence parameter is encoded in the FCS field of the MAC
frame (IEEE Std 802.3,
3.2.8). The FCS is computed as a function of the destination address,
source address, length, data, and PAD
fields. If an M_UNITDATA.request primitive is not accompanied by this
parameter, it is calculated in accordance
with IEEE Std 802.3, 3.2.8.
NOTE 1-Since the PAD field, if present, contributes to the FCS, this
parameter needs to include at least the contribution
of the PAD field to the FCS in order for the original FCS to be preserved
(See Annex G).
No special action, above that specified for the support of use of the MAC
Service by LLC, is required for the
support of the MAC Internal Sublayer Service by the CSMA/CD access method.
NOTE 2-The support by IEEE Std 802.3 is described only in terms of the
operation of a Bridge when relaying frames
that result from the use of LLC services over an 802.3 MAC. ISO/IEC 11802-5
defines the recommended practice for
bridging Ethernet V2.0 frames.
NOTE 3-IEEE Std 802.3, 1998 Edition, describes the use of either a Length
or an Ethernet protocol type in its frame
format; however, the text of this subclause has yet to be revised to
describe the use of Ethernet protocol types.


6.6 Filtering services in Bridged LANs
MAC Bridges provide filtering services in Bridged LANs that support some
aspects of the maintenance of
Quality of Service; in particular, transit delay, priority, and throughput.
In addition, these services provide
for a degree of administrative control over the propagation of particular
MAC Addresses in the Bridged
LAN.
The services described are services in the most general sense; i.e., they
are descriptions of the functionality
that are made available to the MAC Service user or an administrator in
order to control and access filtering
capabilities in Bridged LANs. The description of each service makes no
assumptions in terms of how the
service might be realized. There are at least the following possibilities:
a) Use of existing protocols and mechanisms, defined in IEEE 802 standards
and elsewhere;
b) Use of management functionality, either locally defined or implemented
via remote management
protocols;
c) Other means, standardized or otherwise.
6.6.1 Purpose(s) of filtering service provision
Filtering services are provided in Bridged LANs for the purposes described
in the following subclauses.


6.6.7.1 Dynamic registration and de-registration services
These services allow MAC Service users dynamic control over the set of
destination Group MAC Addresses
that they will receive from the MAC Service provider, by
a) Registering/de-registering membership of specific Groups associated with
those addresses;
b) Registering/de-registering their service requirements with regard to the
overall forwarding/filtering
behavior for Groups.
Provision of these services is achieved by means of GMRP and its associated
procedures, as described in
Clause 10.
NOTE-The intent of these services is to provide the MAC Service user with
dynamic control over access to multicast
data streams, for example, multiple video channels made available by a
server using a different group MAC Address for
each channel. The ability to both register and de-register Group
membership, coupled with the filtering action associated
with the Group membership, limits the impact of such services on the
bandwidth available in the Bridged LAN. These
services can be used to control the reception of other categories of
multicast traffic, for similar reasons.

REGISTER_GROUP_MEMBER (MAC_ADDRESS)
Indicates to the MAC Service provider that the MAC Service user wishes to
receive frames containing the
group MAC Address indicated in the MAC_ADDRESS parameter as the destination
address. The MAC
Addresses that can be carried by this parameter do not include
a) Any individual address;
b) Any of the Reserved Addresses identified in Table 7-9;
c) Any of the GARP Application addresses, as defined in Table 12-1.
DEREGISTER_GROUP_MEMBER (MAC_ADDRESS)
Indicates to the MAC Service provider that the end station no longer wishes
to receive frames containing the
group MAC Address indicated in the MAC_ADDRESS parameter as the destination
address.
REGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)
Indicates to the MAC Service provider that the MAC Service user has a
requirement for any devices that
support Extended Filtering Services to forward frames in the direction of
the Mac Service User in accordance
with the definition of the service requirement defined by the
REQUIREMENT_SPECIFICATION
parameter. The values that can be carried by this parameter are
a) Forward All Groups;
b) Forward Unregistered Groups.
DEREGISTER_SERVICE_REQUIREMENT (REQUIREMENT_SPECIFICATION)
Indicates to the MAC Service provider that the MAC Service user no longer
has a requirement for any
devices that support Extended Filtering Services to forward frames in the
direction of the Mac Service User
in accordance with the definition of the service requirement defined by the
REQUIREMENT_SPECIFICATION parameter. The values that can be carried by this
parameter are
a) Forward All Groups;
b) Forward Unregistered Groups.
The use of these services can result in the propagation of group MAC
Address and service requirement
information across the Spanning Tree, affecting the contents of Group
Registration Entries (7.9.3) in Bridges
and end stations in the Bridged LAN, and thereby affecting the frame
forwarding behavior of the Bridges
and end stations with regard to multicast frames.


7.1 Bridge operation
The principal elements of Bridge operation are
a) Relay and filtering of frames.
b) Maintenance of the information required to make frame filtering and
relaying decisions.
c) Management of the above.
7.1.1 Relay
A MAC Bridge relays individual MAC user data frames between the separate
MACs of the Bridged LANs
connected to its Ports. The order of frames shall be preserved as defined
in 7.7.3.
The functions that support the relaying of frames and maintain the Quality
of Service supported by the
Bridge are
a) Frame reception.
b) Discard on received frame in error (6.3.2).
c) Frame discard if the frame_type is not user_data_frame, or if its
mac_action parameter is not
request_with_no_response (6.4).
d) Regeneration of user priority, if required (6.4).
e) Frame discard following the application of filtering information.
f) Frame discard on transmittable service data unit size exceeded (6.3.8).
g) Forwarding of received frames to other Bridge Ports.
h) Selection of traffic class, following the application of filtering
information.
i) Queuing of frames by traffic class.
j) Frame discard to ensure that a maximum bridge transit delay is not
exceeded (6.3.6).
k) Selection of queued frames for transmission.
l) Selection of outbound access priority (6.3.9).
m) Mapping of service data units and recalculation of Frame Check Sequence,
if required (6.3.7, 7.7.6).
n) Frame transmission.
7.1.2 Filtering and relaying information
A Bridge filters frames, i.e., does not relay frames received by a Bridge
Port to other Ports on that Bridge, in
order to prevent the duplication of frames (6.3.4). The function that
supports the use and maintenance of
information for this purpose is
a) Calculation and configuration of Bridged LAN topology.

A Bridge also filters frames in order to reduce traffic in parts of the
Bridged LAN that do not lie in the path
between the source and destination of that traffic. The functions that
support the use and maintenance of
information for this purpose are:
b) Permanent configuration of reserved addresses.
c) Explicit configuration of static filtering information.
d) Automatic learning of dynamic filtering information for unicast
destination addresses through observation
of source addresses of Bridged LAN traffic.
e) Ageing out of dynamic filtering information that has been learned.
f) Automatic addition and removal of dynamic filtering information as a
result of GMRP protocol
exchanges.
A Bridge classifies frames into traffic classes in order to expedite
transmission of frames generated by critical
or time-sensitive services. The function that supports the use and
maintenance of information for this
purpose is
g) Explicit configuration of traffic class information associated with the
Ports of the Bridge.
7.1.3 Bridge Management
The functions that support Bridge Management control and monitor the
provision of the above functions.
They are specified in Clause 14.

7.2 Bridge architecture
7.2.1 Architectural model of a Bridge
Figure 7-1 gives an example of the physical topology of a Bridged LAN. The
component LANs are interconnected
by means of MAC Bridges; each Port of a MAC Bridge connects to a single
LAN. Figure 7-2 illustrates
a Bridge with two Ports, and Figure 7-3 illustrates the architecture of
such a Bridge.
A Bridge is modeled as consisting of
a) A MAC Relay Entity that interconnects the Bridges Ports;
b) At least two Ports;
c) Higher layer entities, including at least a Bridge Protocol Entity.
7.2.2 MAC Relay Entity
The MAC Relay Entity handles the MAC method independent functions of
relaying frames between Bridge
Ports, filtering frames, and learning filtering information. It uses the
Internal Sublayer Service provided by
the separate MAC Entities for each Port. (The Internal Sublayer Service and
its support are described in 6.4
and 6.5.) Frames are relayed between Ports attached to different LANs.
7.2.3 Ports
Each Bridge Port transmits and receives frames to and from the LAN to which
it is attached. An individual
MAC Entity permanently associated with the Port provides the Internal
Sublayer Service used for frame
transmission and reception. The MAC Entity handles all the MAC method
dependent functions (MAC protocol
and procedures) as specified in the relevant standard for that IEEE 802 LAN
MAC technology.

7.5 Frame reception
The individual MAC Entity associated with each Bridge Port examines all
frames transmitted on the LAN to
which it is attached.
All error-free received frames give rise to M_UNITDATA indication
primitives, which shall be handled as
follows.
NOTE-A frame that is in error, as defined by the relevant MAC
specification, is discarded by the MAC Entity without
giving rise to any M_UNITDATA indication; see 6.4.
Frames with M_UNITDATA.indication primitive frame_type and mac_action
parameter values of
user_data_frame and request_with_no_response, respectively (6.4), shall be
submitted to the Learning and
Forwarding Processes.
Frames with other values of frame_type and mac_action parameters (e.g.,
request_with_response and response
frames), shall not be submitted to the Forwarding Process. They may be
submitted to the Learning Process.
Frames with a frame_type of user_data_frame and addressed to the Bridge
Port as an end station shall be
submitted to LLC. Such frames carry either the individual MAC Address of
the Port or a group address associated
with the Port (7.12) in the destination address field. Frames submitted to
LLC can also be submitted to
the Learning and Forwarding Processes, as specified above.
Frames addressed to a Bridge Port as an end station, and relayed to that
Bridge Port from other Bridge Ports
in the same Bridge by the Forwarding Process, shall also be submitted to
LLC.
No other frames shall be submitted to LLC.


7.6 Frame transmission
The individual MAC Entity associated with each Bridge Port transmits frames
submitted to it by the MAC
Relay Entity.
Relayed frames are submitted for transmission by the Forwarding Process.
The M_UNITDATA.request
primitive associated with such frames conveys the values of the source and
destination address fields
received in the corresponding M_UNITDATA.indication primitive.
LLC Protocol Data Units are submitted by LLC as a user of the MAC Service
provided by the Bridge Port.
Frames transmitted to convey such Protocol Data Units carry the individual
MAC Address of the Port in the
source address field.
Each frame is transmitted subject to the MAC procedures to be observed for
that specific IEEE 802 LAN
technology. The values of the frame_type and mac_action parameters of the
corresponding M_UNITDATA.
request primitive shall be user_data_frame and request_with_no_response,
respectively (6.5).
Frames transmitted following a request by the LLC user of the MAC Service
provided by the Bridge Port
shall also be submitted to the MAC Relay Entity.

7.7 The Forwarding Process
Frames submitted to the Forwarding Process after being received at any
given Bridge Port (7.5) shall be forwarded
through the other Bridge Ports subject to the constituent functions of the
Forwarding Process. These
functions enforce topology restrictions (7.7.1), use filtering database
information to filter frames (7.7.2),
queue frames (7.7.3), select queued frames for transmission (7.7.4), map
priorities (7.7.5), and recalculate
FCS if required (7.7.6).

The Forwarding Process functions are described in 7.7.1-7.7.6 in terms of
the action taken for a given frame
received on a given Port (termed the reception Port). The frame can be
forwarded for transmission on
some Ports (termed transmission Ports), and is discarded without being
transmitted at the other Ports.
NOTE-The model of operation of the Forwarding Process described in this
standard is limited to the operation of the
relay function of the MAC Bridge, and does not take into consideration what
may occur in real implementations once
frames are passed to the MAC for transmission. In some MAC implementations,
and under some traffic conditions, a
degree of indeterminacy may be introduced between the modeled description
of the process of passing selected frames to
the MAC for transmission and the actual sequence of frames as visible on
the LAN medium itself. Examples can be
found in the handling of access_priority in Token-Passing Bus MACs, or in
the effect of different values for Token Holding
Time in FDDI LANs. Such indeterminacy could result in apparent violation of
the queuing/de-queueing and prioritiation
rules described for the Forwarding Process, when observing traffic on the
medium. As a consequence, in some
implementations of this standard, it may prove to be impossible to test
conformance to the standard simply by relating
observed LAN traffic to the described model of the Forwarding Process;
conformance tests would have to allow for the
(permissible) behavior of the MAC implementations as well.
Figure 7-4 illustrates the operation of the Forwarding Process in a single
instance of frame relay between the
Ports of a Bridge with two Ports. Figure 7-8 illustrates the detailed
operation of the Forwarding Process.


7.8 The Learning Process
The Learning Process observes the source addresses of frames received on
each Port and updates the Filtering
Database conditionally on the state of the receiving Port.
Frames are submitted to the Learning Process by the individual MAC Entities
associated with each Bridge
Port as specified in 7.5.
The Learning Process may deduce the path through the Bridged LAN to
particular end stations by inspection
of the source address field of received frames. It shall create or update a
Dynamic Filtering Entry (7.9, 7.9.2)
in the Filtering Database, associating the Port on which the frame was
received with the MAC Address in the
source address field of the frame, if and only if
a) The Port on which the frame was received is in a state that allows
learning (8.4), and
b) The source address field of the frame denotes a specific end station,
i.e., is not a group address, and
c) No Static Filtering Entry (7.9, 7.9.1) for the associated MAC Address
exists in which the Port Map
specifies Forwarding or Filtering for that Port, and
d) The resulting number of entries would not exceed the capacity of the
Filtering Database.
If the Filtering Database is already filled up to its capacity, but a new
entry would otherwise be made, then an
existing entry may be removed to make room for the new entry.
Figure 7-5 illustrates the operation of the Learning Process in the
inclusion of station location information
carried by a single frame, received on one of the Ports of a Bridge, in the
Filtering Database.


7.9 The Filtering Database
The Filtering Database supports queries by the Forwarding Process as to
whether frames received by the
Forwarding Process from a given reception Port, and with given values of
destination MAC Address parameter,
are to be forwarded through a given potential transmission Port (7.7.1,
7.7.2). It contains filtering information
in the form of filtering entries that are either
a) Static, and explicitly configured by management action; or
b) Dynamic, and automatically entered into the Filtering Database by the
normal operation of the
bridge and the protocols it supports.
A single entry type, the Static Filtering Entry, represents all static
information in the Filtering Database, for
individual and for group MAC Addresses. It allows administrative control of

c) Forwarding of frames with particular destination addresses; and
d) The inclusion in the Filtering Database of dynamic filtering information
associated with Extended
Filtering Services, and use of this information.
The Filtering Database shall contain entries of the Static Filtering Entry
type.
Static filtering information is added to, modified, and removed from the
Filtering Database only under
explicit management control. It shall not be automatically removed by any
ageing mechanism. Management
of static filtering information may be carried out by use of the remote
management capability provided by
Bridge Management (7.11) using the operations specified in Clause 14.
Two entry types are used to represent dynamic filtering information.
Dynamic Filtering Entries are used to
specify the ports on which individual addresses have been learned. They are
created and updated by the
Learning Process (7.8), and are subject to ageing and removal by the
Filtering Database. Group Registration
Entries support the registration of group MAC Addresses. They are created,
updated, and removed by the
GMRP protocol in support of Extended Filtering Services (6.6.5, 7.9.3, and
Clause 10). Dynamic filtering
information may be read by use of the remote management capability provided
by Bridge Management
(7.11) using the operations specified in Clause 14.
Both static and dynamic entries comprise
e) A MAC Address specification;
f) A Port Map, with a control element for each outbound Port to specify
filtering for the MAC Address
specification.
The Filtering Services supported by a Bridge (Basic and Extended Filtering
Services) determine the default
behavior of the Bridge with respect to the forwarding of frames destined
for group MAC Addresses. In
Bridges that support Extended Filtering Services, the default forwarding
behavior of each Port for group
MAC Addresses can be configured both statically and dynamically by means of
Static Filtering Entries and/
or Group Registration Entries that can carry the following MAC Address
specifications:
g) All Group Addresses, for which no more specific Static Filtering Entry
exists;
h) All Unregistered Group Addresses (i.e., all group MAC Addresses for
which no Group Registration
Entry exists), for which no more specific Static Filtering Entry exists.
NOTE-The All Group Addresses specification (item g above), when used in a
Static Filtering Entry with an appropriate
control specification, provides the ability to configure a Bridge that
supports Extended Filtering Services to behave as a
Bridge that supports only Basic Filtering Services on some or all of its
Ports. This might be done for the following reasons:
- The Ports concerned serve legacy devices that wish to receive
multicast traffic, but are unable to register Group
membership;
- The Ports concerned serve devices that need to receive all multicast
traffic, such as routers or diagnostic devices.
The Filtering Database shall support the creation, updating, and removal of
Dynamic Filtering Entries by the
Learning Process (7.8). In Bridges that support Extended Filtering
Services, the Filtering Database shall
support the creation, updating, and removal of Group Registration Entries
by GMRP (Clause 10).
Figure 7-4 illustrates the use of the Filtering Database by the Forwarding
Process in a single instance of
frame relay between the Ports of a Bridge with two Ports.
Figure 7-5 illustrates the creation or update of a dynamic entry in the
Filtering Database by the Learning
Process.

Figure 7-6 illustrates the operation of the Bridge Protocol Entity (7.10),
which operates the Spanning Tree
Algorithm and Protocol, and its notification of the Filtering Database of
changes in active topology signaled
by that protocol.


7.12.1 End stations
Frames transmitted between end stations using the MAC Service provided by a
Bridged LAN carry the
MAC Address of the source and destination peer end stations in the source
and destination address fields of
the frames, respectively. The address, or other means of identification, of
a Bridge is not carried in frames
transmitted between peer users for the purpose of frame relay in the
Bridged LAN.
The broadcast address and other group MAC Addresses apply to the use of the
MAC Service provided by a
Bridged LAN as a whole. In the absence of explicit filters configured via
management as Static Filtering
Entries, or via GMRP as Group Registration Entries (Clause 14, Clause 10,
7.9), frames with such destination
addresses are relayed throughout the Bridged LAN.
7.12.2 Bridge Ports
The individual MAC Entity associated with each Bridge Port shall have a
separate individual MAC Address.
This address is used for any MAC procedures required by the particular MAC
method employed.
Frames that are received from the LAN to which a Port is attached and that
carry a MAC Address for the
Port in the destination address field are submitted to the MAC Service User
(LLC) exactly as for an end
station.


******************************************************


\hHMp̡MOܳwݤMNݱoMpzXӡMVja
աMݨӤ_ݤT



-----------


ӷ: x 
ɶ: 2001~ 616 P 082329 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network


==> b Toidi@cis_nctu (èp) 峹:
> ==> b siklo@cis_nctu (pͻH) 峹:
> > VLAN nqAO Layer 3  Switch, AΪPl Layer 2 Switch
> > W VLAN OiHq?
>         ҥH VLAN NOn VLAN }...
>         AqwqOiHM@I?
>         ڤWN@x VLAN `B@ switch hub
L3 Switch |Routing ModuleAqӴNO
zL L3 Swtich W Routing ModuleAӤݭnq
C VLan W@ Port uplink Wh Switch
άO Router WAHF VLan qaI


--------


ӷ: x 
ɶ: 2001~ 616 P 182415 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network

==> b siklo@cis_nctu (pͻH) 峹:
> ==> b Toidi@cis_nctu (èp) 峹:
> >         L{bO Layer 2  Switch
> >         |o Module
> >         ҥH VLAN ӴNबq...
> >         o]O VLAN ]pت
> p̤..??   VLAN  Layer 3 NiH route q
> p̦b@~qA쪺]O Layer 3 Switch
> U VLAN ϥ route 覡qC
    VLAN Ob L2 Switch WNFAL3 OӦ
@@ݭnӥB Router ӶQF]QQݨɭ
@@Cisco ѻhIqͥXӪND
@@oI^ӵoiXӪAҥH VLAN تNO
@@Y Ports L Ports MɭI
@@P collision domain rIOP
@@ VLAN uiHѦ۩ӡܡH
@@UIPqBǮաBKKKCIҥHn
@@qɭԡANb Layer 3 WI̡зǡ
@@kMOb Router WeAO]
@@$$ Pɧ޳NiBFAҥH Switch UӷUjA
@@NKoӤu@]ooNO
@@Layer 3 Switch FI

> >         L٬OiHC VLAN  uplink
>                         ^^^^^^^^^^^^^^^^^^^^
> o˪k..
@@YA Switch u Layer 2 ܡA uplink
    A VLAN nqH

> >         ]bP@ port NiHF..
> ݰ_ӧAܹO port trunking 覡
@@Trunking O TrunkingA VLAN SYI

~HDťAаoI



--------


ӷ: Ѻɤ֦~ 
ɶ: 2001~ 617 P 020550 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network

==> b hardstone@cis_nctu (x) 峹:
> ==> b siklo@cis_nctu (pͻH) 峹:
> >                         ^^^^^^^^^^^^^^^^^^^^
> > o˪k..
> @@YA Switch u Layer 2 ܡA uplink
>     A VLAN nqH
> > ݰ_ӧAܹO port trunking 覡
> @@Trunking O TrunkingA VLAN SYI
> ~HDťAаoI

      osikloS
      trunkingoӦrAAӦphwqH
      bCiscoo@̡ATrunkingNOvlan port trunking
      P@xswitchΤFƭVLANAӥu@s
      ܥt@x]ΤFƭ VLANswitchAoxswitch
      u@sAڭ̴NnboportW]wVLAN Trunk
      [W802.1q or ISL ʸˡA~oxvlan information
      iH۷qAPswitchP@VLAN~q
      pVLAN1@SW1  VLAN1@SW2, VLAN2@SW1  VLAN2@SW2
      HWOCisco"trunking"

      Ӥ@ڭtrunkingiOCiscoEtherChannel
      ]NOswitchƱqXWeΰredudant޳N
      WҭzO@˪FAMi|n


----------


ӷ: Ѧʩm 
ɶ: 2001~ 617 P 152022 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network


 ޭzmhardstone.bbs@bbs.cis.nctu.edu.tw (x)nʨG
: ФFI
: SIکҡ{ trunking OXWe@ءI
: Cisco  VLAN Trunking ]ťLALSݹLH
: bΡAҥHKKK
port trunk(EtherChannel) M VLAN trunk OXl

VLAN trunk b MAN WΪܦh, 쪺iHhdd䥦t(eg. Extreme)
 solution, Cisco b switch 譱äOSOj.

: ıoWӧhx Switch_ӡASp@x
:  Switch OܡH
򥻤Wn VLAN i@xHW], Nݭn VLAN trunk

٦@إiʴNOnh VLAN zL router q, ]iH VLAN trunk

: ڷQno򰵪]AӬO@x L3 Switch O
: backbone SwitchAUAƥx L2  SwitchAoˤl
: NqaIright?
{bͶլO L2/L3 Xb@xW, o˰ VLAN q|
~V, ӥBפ.



---------


ӷ: ϤjKPJO 
ɶ: 2001~ 618 P@ 002832 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network


==> wchuang.bbs@bbs.cis.nctu.edu.tw (Ѻɤ֦~) :
> ==> b hardstone@cis_nctu (x) 峹:
> > @@YA Switch u Layer 2 ܡA uplink
> >     A VLAN nqH
> > @@Trunking O TrunkingA VLAN SYI

TrunkingMVLANܤjY....
P]ƼtӹtrunkP

InteltrunkNƭportE@groupApGO4porttrunkA
xswitchWe400MB full-duplexAP˪޳NExtreme
٤link aggregationACisco٤Fast EtherChannelC

CiscotrunkO@linkWiHaƭVLANtrafficA]switch1
TVLANAswitch2]TVLANAvlan1@switch1QMvlan1@switch2qɡA
²檺kANOTsuOsxswitch۹TvlanAoؤ
k
ӮOportAѨMkNOxswitchU@port]wtrunk portAMs
_
Ao@trunk linkNiHaTvlantraffic(set trunk 1 on 1-3)A
WN
٤UportCoȤۦPvlanqCpGvlan1QMvlan2q
A
NnarouterΪ̬Omultilayer switchӶirouting\C
pGOExtreme switchܡA@Oip forwardingNdwApGOcisco switch
ܡAN[Rroute switching moduleC

MciscoswitchOnAOpGVDyݻܡAtrunkMvlan

KiYNiC
by the wayACCNPBCMSN@NҤF۷htrunk and vlan[C



--------


ӷ: ]Z 
ɶ: 2001~ 618 P@ 161918 CST
D: Re: ֯·Ф@UAswitch hubMhubtO...@@"
׾: tw.bbs.comp.network


m b shinlong. j@: n
: §AP~@@"...
: ڬdLWgS...>"e
d--->c
c--->a
c--->b

Ѧݨ, 䤤 c ̨w, c ƴNGӤHn.
bM e ̥i, wи̥iर򳣨S, ҥHSHnL.
d ̿W, SVL 4 xq, ٴѸƵ cq, ҥHdiO Server.
WeNܦ,
a=10/4=2.5Mbps
b=10/4=2.5Mbps
c=10/4=2.5Mbps
d=10/4=2.5Mpbs
e=10/4=2.5Mpbs

ҥHNO Switch Hub, Jo@諸ɭ, ]O򴶳q Hub@.
Cӳ@ˤF, Y dݰ_ӸOHo誺̤, NO] dc.
DNXb c, c o̦h, ɭP 5 xqWe@ˤF, n.

pGѨ䤤Gӳuۤ, NiHɦ 10Mbpst.
]NO۲`R, U۳SbOHo, o˴NiF Switch \.
o˳̦npNO  4 ports iHɨ UۿWߪ 10Mbps, 䤤@ port

ʧ@.
ӬOp, ܽЫ.
ҥHR Switch Hub ӶRƪ ports ƥ, 5, 7, 9 oǳnR.
R4, 6, 8, 16, ƪ Switch Hub.
 3Com M SMC Hub.



-------



ϤjKPJO  wrote in message news:3h2HkR$K5l@bbs.ntu.edu.tw...
> X@ӫĳA@ɦ䤧jAǤwAs벧w޳NA
> L_[cAjaboӰQװϩߪyAnHտؼJ˪y
> Ӧ^C
> ==> siklo.bbs@bbs.cis.nctu.edu.tw (pͻH) :
> > ==> b airborne.bbs@bbs.ntu.edu.tw (ϤjKPJO) 峹:
> > > 򥻤WӻAmeedsSèSC
> > > bQ׳oӰDɡAFEthernets覡~Aٻݪ`Nswitchw骺functionA
> > > switchABztrafficɰ򥻤WؼҦAstore-and-forwardMcut-throughA
> > S?  AAӺ] Switch @ڦ b,c,d,e Pɥhs a ?
> > > צؼҦAb,c,d,ePɦsaɡA@}lb,c,d,eiHRQ10mbpsWeA
> > oNOܤF, ֳDbAӺ̭ b,c,d,e OiPɦs a 
> > A~MٯRQ 10Mbps We   A Switch Wr  @_@
> iOڪFMAҿbcdePɦsaAObinitializingɭԡA
> bcdePɥtrafficaAtrafficMOswitchAAswitch forwardaA
> MswitchibcdepacketPɥᵹaA@wOpacket-by-packet
> (Hprocess-switchingǡAҼ{fast-switchingp)C
> > sUoq, ~MTX b,c,d,e @@F 40Mbps  a ~~
> Юe\ڻդ@IAҿbcdeF40mbpsaNOAbcde`@40mbps
> trafficiswitch backplane fabricAMport Abandwidthu10mbpsA
> MLkswitch backplane40mbps trafficAҥHѤUtrafficN
> sbport Aoutput queuḙAoutput queuebufferF(oversubscription)A
> packet}lQdropC
> > > b,c,d,e@@40mbpstrafficya portbufferBzAڤWa portWe
> > > ]u10mbpsAҥHa portbufferFAdata}lQdropAPɦ]a portloading
> > > WXtAswitch]|bb,c,d,e portoXnotificationAϱob,c,d,e|x
> > > wưeXtסA]b,c,d,ePɦsaɡANb,c,d,e@Pshare a10mbps
> > > HݨӡAb,c,d,eTuϥ2.5mbpsC
> > Wo@qOATa~~  hڤF..
> o@qHäYԡAbnpCڥiSTIII
> ҿתport B,C,D,E|oXnotificationAOIEEE 802.3Z flow control on
> gigabit ethernet portAcisco catalyst 6000 switch䴩A
> аѦҡG
> http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000
> /sw5_1/cnfigide/ether.htm#xtocid1934811
> N⤵ѧڭ̪switchSflow controlnFASYAڭ٦TCPA
> TCP`⦳error controlMflow controlFaAaNbpacketBzA
> ^b@ackAb~|~ǸƵaAq@ӷL[רӬݡAĤ@Bzb,
> ĤGBzcAĤTBzdAĥ|BzeAĤ~ABzbAqbרӬݡA
> |u@Ǹ(ab@ackAb~|~)A۹ӻAWeuΤF1/4C
> TCP/IPB@޿аѦҡG
> http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm#xtocid2236316
> 
> > > oäNѤU7.5mbpsյLGA7.5mbps٬OiHBΦb
> > > Ltraffic patternAĴpWinternetάOst~@fC
> > z @_@  r!  HWܤwgzF, ~M٥iHTXQ drop ٦L
> > BΫ~~
> > ӥb]ӳoTܪ?  jaݬݯNn    گhF..
> Юe\ڻդ@IA
> o̩һQdropƫObǵaơA
> port A output queue overflowQdropAB->Atraffic flow
> uΨ2.5mbpsutilizationAport Bbandwidth10mbpsAѩport A
> AϱoB->Au2.5mbpsAѤU7.5mbpsMiHΩL
> traffic patternAAԲӤ@IANO@ǸƵaATǸƨinternet
> (]SHLminternet)ApKiNport ButilizationF100%C
> ]AbDesign NetworkɡAq`|Ĩhierarchical designAaccess layer
> ĥ10100Adistribution layĥ1001000Ap@access layeryq
> EIdistribution layer঳ĲvBz|K׻EӪtrafficC
> 
> pGA٬O{PڪkAγ\AiHѦҰѦCiscoX
> CCNP/CCDP--Building Cisco Multilayer Switched Networks(P.56-59)
> nѧC

----------



 wrote in message news:3h2I7G$W1g@bbs.cis.nctu.edu.tw...
> ==> b siklo@cis_nctu (pͻH) 峹:
> > ==> b airborne.bbs@bbs.ntu.edu.tw (ϤjKPJO) 峹:
> > > 򥻤WӻAmeedsSèSC
> > > bQ׳oӰDɡAFEthernets覡~Aٻݪ`Nswitchw骺functionA
> > > switchABztrafficɰ򥻤WؼҦAstore-and-forwardMcut-throughA
> > S?  AAӺ] Switch @ڦ b,c,d,e Pɥhs a ?
> > > צؼҦAb,c,d,ePɦsaɡA@}lb,c,d,eiHRQ10mbpsWeA
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > oNOܤF, ֳDbAӺ̭ b,c,d,e OiPɦs a 
> > A~MٯRQ 10Mbps We   A Switch Wr  @_@
> > sUoq, ~MTX b,c,d,e @@F 40Mbps  a ~~
> 
> airboneSS
> AһAӺOe coaxial cable (10base2,10base5)
> shared LAN, ҥHDϥγ@channelhicommunication.
> ҥHbMAChOĨCSMA/CD覡.yܻ,Pɶu
> @Dϥκ._h|collision. iO ۱qFswitch  UTP ,@
> shared medium]Q,(ϥUTP|u,10baseTM100baseTXOϥΨ䤤
> TX/RX)]}lFuW
> full-duplex OTethernetS
> 1.carrier sense: full-duplex U,Dݭncarrier T
> 2.multiple access: ]HostswitchiHOTX/RX۶Ǹ
> 3.collision detection: PW,]OTX/RXǸƤ]NScollisionpo
> 
> y,bful-duplexU,wgSCSMA/CD
> ҥHb,c,d,epGnǸƵa ,zפWiHFt(ub}lLpɶI)
> ҥHdata bboutput queue(]Oϥstore-and-forward覡),switchF
> buffer overflow,iH}ldrop packets,pGb,c,d,eWhOϥTCPflow control
> protocol, Whprotocol|]packet lossӽվpacketedata linkt.
> Ϊswitch]iHeX PAUSE Frame(full-duplex,ݩMACh),sending hostCǰe
> t.
> 
> > > b,c,d,e@@40mbpstrafficya portbufferBzAڤWa portWe
> > > ]u10mbpsAҥHa portbufferFAdata}lQdropAPɦ]a portloading
> > > WXtAswitch]|bb,c,d,e portoXnotificationAϱob,c,d,e|x
> > > wưeXtסA]b,c,d,ePɦsaɡANb,c,d,e@Pshare a10mbps
> > > HݨӡAb,c,d,eTuϥ2.5mbpsC
> > Wo@qOATa~~  hڤF..
> > > oäNѤU7.5mbpsյLGA7.5mbps٬OiHBΦb
> > > Ltraffic patternAĴpWinternetάOst~@fC
> > z @_@  r!  HWܤwgzF, ~M٥iHTXQ drop ٦L
> > BΫ~~
> > -----------
> > ӥb]ӳoTܪ?  jaݬݯNn    گhF..
> airbone  SS
> pG a  b,b100base-TX, full-duplexU`WeiHF200Mbps.iOäO
> a --> b = 200Mbps  b --> a = 200Mbps  a -> b + b -> a = 200Mbps
> ӬO a->b ̦h 100Mbps, b->a ̦h 100Mbps, Pɶ`M 200Mbps
> 
> `Ө, bfull-duplexU,Any host  outgoing  incoming data OzZ
> ̥Dn]OĥCSMA/CDs覡. uswitchpowerful, incoming/outgoing
> iHbP@ɶF췥t,ӤXxDPɳsu
> 
> For more information, the following book is a great reference.
> The Switch Book: The Complete Guide to LAN Switching Technology
> by Rich Seifert
> John Wiley & Sons
> ISBN: 0471345865


----------



ϤjKPJO  wrote in message news:3h2k3F$NC1@bbs.ntu.edu.tw...
> ==> angus.bbs@bbs.svdcc.fju.edu.tw (êz) :
> > i b spen. j@: j
> > : 藍_ Ӫ бФ@U..
> > : u OO "PɶiHWUǤ@_ʧ@" ?
> > : A port ٬Oi " Pɱ "  B.C port e A port .
> > : (pG CSMA/CD )
> > : iHA@U  ϥ ful-duplexU,wgSCSMA/CD ?
> >  ٬Ocollision աAH Sniffer ۤwݬ
> >  ۦPq@s
> >  oˤNFܡH
> 
> full-duplexOΩend-to-endAYswitch-to-switch or switch-to-pcA
> ShubAWǩMUǨP諸uAiHPɶiA
> ѩOend-to-endAswitchportOdedicateclientAҥHclientbWUǮ
> ڥSHLmCYOhHsP@xserverAunserverMswitchOfull-deplex
> NO@uDAWǦWǪAUǦUǪC
> full-duplexWUǥiPɶiend-to-end(SLHbvmedia access)
> SʡAfull-duplex|collision]ݭnCSMA/CDC
> --


---------



˭l_  wrote in message news:3h33HN$TX6@BirdNest.infoX.Net...
>  ޭzmairborne.bbs@bbs.ntu.edu.tw (ϤjKPJO)nʨG
> : full-duplexOΩend-to-endAYswitch-to-switch or switch-to-pcA
> : ShubAWǩMUǨP諸uAiHPɶiA
> 
> WǩMUǨP諸uëDfull duplexnC
> 1000BASE-TWǩMUǦbfull duplexU٬OP@u(|uΨ)A
> MNNOHBzqӧoثHXӡC
> 
> : ѩOend-to-endAswitchportOdedicateclientAҥHclientbWUǮ
> : ڥSHLmCYOhHsP@xserverAunserverMswitchOfull-deplex
> : NO@uDAWǦWǪAUǦUǪC
> : full-duplexWUǥiPɶiend-to-end(SLHbvmedia access)
> : SʡAfull-duplex|collision]ݭnCSMA/CDC
> 
> bϥUTPΤUAtransmitterӨAcollisionNObǰeʥ]ɡA
> o{PɦOʥ]HiӡCoɭԥ|eXjamíswƤU@ǰeC
> bfull duplexUAMAC|z|physical layerqҲͪcollision detectA
> ]N|jamέsǰeCҥHYӻAӻMAC|collisionC
> 



-------




Oܪn ..  wrote in message news:3h3MQV$Kbx@bbs.yzu.edu.tw...
>  ޭzmsiklo.bbs@bbs.cis.nctu.edu.tw (pͻH)nʨG
> > ڤqNOiH route qAҥHp̻{ VLAN nqݭn
> > Layer 3 Switch.@U Virtual LAN iH Layer 3 Switch ӹF
> > q.
> > zΪ Layer 2 ӬO port trunking (Ҧp CISCO  InterLink)
> > o˧a?
> 
>   F...nFbѡASHDo~OT׶ܡHH
>   L2 Switch  VLAN O򥻪n\
>   C VLAN SzL Routing Module  Work |q~ ..
>   ҥHAo Siklo SO諸 ..
>   ƹWAH Cisco implementation ӨA1 26XXp Router
>   [WHK@ڤp Switch NiH InterVLAN Routing F ..
>   `AVLAN nqӴNnzL Layer 3 FunctionC
> 
>   ܩ󤰻O L3 Switch AA̯uιLܡHSιLNΧnF ...
>   ]ŪѤWFFOSΪ ...
>   nڻ L3 Switch iH] L2 Switching + L3 Routing ...
>   oOjS ......
>   HťL L3 Switching oFܡH L3 Switch NOΨӰo Function  ..
>   O L3 Switching OHuHardware-Base RoutingvO]
>   lFaIH Ciscoӻ]]ڥu Cisco :p^Aun䴩 MLSP 
>   SwitchAs L3 SwitchAYϨS RSMRSFCA٬O....
>   ФjaJӷQnAu[1;33mHardware-Base[m [1;37mRouting[mvwqnܡHH
>   AӰQפO L3 SwitchH
> 
>   ٦AzL ISL  Trunk äOP VLANs qAӬOuPv
>   Switch W֦uۦPvuVLAN IDv VLAN ۳qC
> 
> 


---------

Hub & switch bBzWet
@: iʷu (211.79.149.---)
:   01/07/26 14:31

HUBOҦPORT@Τ@WeASWITCHhUPORTWߤ@WeCpH100MbitsҡA
hHUB UPORTOpWeA]UPORTbϥΤAhUPORTɨhW
eAi_|һH
HWzҡAhSWITCHUPORTɨhWeH


^Х
 Re: Hub & switch bBzWet
@: netman (---.seed.net.tw)
:   01/07/26 15:57

MWjTC

HUB M SWITCH OMbWeΡMӦbWeϥήɾM䤤
jOORb HUB WMP@ɶMu঳@ port iǰeMӦb switch h
\Ҧ port PɶǰeC

pGѡMs 5 xb switch WMpG abcd PɦV e ǰeƾڡM
abcd eXƾڡM|Q queue _ӡMM switch |Φۤv CPU iBzM
N queue ƾڳBzQӴ hubMMa beܡMbcd nMpG b b
eܡMacd n....


 Re: Hub & switch bBzWet
@: spen (---.hinet-ip.hinet.net)
:   01/07/26 18:40

p̹oq ܷP

s 5 xb switch WMpG abcd PɦV e ǰeƾڡM abcd eX
ڡM|Q queue _ӡMM switch |Φۤv CPU iBzMN queue 
ƾڳBz.

бЪO.switch pBz.l׭neXƵ abcd.oɸhub ǰeO
?
switch eaP.b or c or d ٯPɶ e ʥ] ? pG.
HWҤl.p̬ݤX hub boqɶ.switch O.
Ы.


 Re: Hub & switch bBzWet
@: netman (---.seed.net.tw)
:   01/07/26 23:45

ڡMNOﵽF carry sensce ݰ(ЭsѦ CSMA/CD oӧ޳N)Mo˻
nFMpG abcd Pɵ e eƾڡMӥB a SPɦV b eM f M g ]զbe
ƾڡC

oɭԡMa unN e ƾک switch ᤧMNiH~V b U@ӤFM
P bcd ]iHV e eMH f ]iHV g ƾڡC

pG hub OM a V e eɭԡM b nMM c M dM a V b
eM]n d eMs f  g ]nNOFC

Dݨ쥦̪OܡSpHC 1 @ӹBgӬݡMڭ̥iHo{R

 switch (zQ)ΦpUR
Ĥ@Rabcd->e,f->g
ĤGRa->b ()

ӥ hub OR
Ĥ@Ra->e
ĤGRb->e
ĤTRc->e
ĥ|Rd->e
ĤRf->g
ĤRa->b ()

LMЯdNMHWO]zQAMӥB°w carry sensce (]NO node
 switch)Mܩ collision detectM٦ switch Bz queue Nƾ
e nodes |Ҽ{iӡC

ڤTwMڲq e ۤv٬O챵ǭMNpMH
switch port e nodes ɶM̪CuO switch  e ɶMӦb
eM䥦 queue wgMŤF(ڷQon switch BzOөwa)Q
hub ܡM䥦 queue NSPɳBziM]uO FIFO BzC

pUDMPɤS}F@suOMPDsuMNFMڥiH֩w@
IOMsuVhMswitch VoȡM hub huGC

pGz@wnjձq e eʥ]Xӵ abcd (ӤO abcd PɦV e e)MN CS
ӻMTSOMuo¬O local ݰeXʥ]ǭӤwMG
ӧW switch M hubC

٦MHWOb haff-duplex ΤUo͡MӦb full-duplex UhOo
˪MLMN hub FC


----------




"1sy줧fۤl"  gl news:3kf6eE$Vnq@bbs.ee.ntu.edu.tw...
>  ޭzmsiklo.bbs@bbs.cis.nctu.edu.tw (pͻH)nʨG
> : ==> b "Ѥ~"  峹:
> : > LFXƥueݭn, ӤOporte. o˴NiH
> : > ϧOhubMswitchF. ܩnlsε, AoرM~Hhť, u
> : > ໡ "t@I, tܦh". ڤ]SLS. uOLDnN䦳
> : > F.
> : ڦAj --> Switch |hפUʥ], ӬOھ MAC address  table
> : eتa,  table 䤣쥦~|. (ʥ])
> 
> MAC table 䤣 destination MAC address ܡA
> ӷ| forward L portsA]NO broadcast XhC


"^_^"  gl news:3kfObC$YDR@firebird.cs.ccu.edu.tw...
> i b stevel@bbs.ee.ntu.edu.tw (1sy줧fۤl) j@: j
> :  ޭzmsiklo.bbs@bbs.cis.nctu.edu.tw (pͻH)nʨG
> : MAC table 䤣 destination MAC address ܡA
> : ӷ| forward L portsA]NO broadcast XhC
> 
>     ya, switchOӳo˳]p
>     pG䤣tableNe, oswitchO}, ]@}ltableOŪ
>     OH]JLؤ{oNswitch, uOWΪ
> 


"sl..."  gl news:3l23i2$YLR@bbs.cis.nctu.edu.tw...
> ==> b siklo@cis_nctu (pͻH) 峹:
> > ==> b Merlin.bbs@firebird.cs.ccu.edu.tw (^_^) 峹:
> > >     ya, switchOӳo˳]p
> > >     pG䤣tableNe, oswitchO}, ]@}ltableOŪ
> > >     OH]JLؤ{oNswitch, uOWΪ
> > ]o table @}lOŪ, O@ʥ], |N source MAC
> > address T[JάOsۤv table.
> > Lp̩Ҫ, o table 䤣 MAC address , O|e
> > ӫʥ], oO_NOp̩Ҩ, ٬Ot@Bͩһܦs broadcast
> > Xh, p̱o~ƬŪ.
> KK...nܤ[Sݨsiklo{
> j~eNboݨA
> A٦bMISڡH
> oӰD...
> SwitchB@²
> eNpsikloһ
> SwitchOǲ48bit(6byte) source address
> O٥]tPortID
> DAoUΨӰnhx|
> oӼƦrOx]Oja@르config /all
> Physical address
> @Framex榡
> DA  SA  L/T   Payload      FCS
> 48b 48b 16b   368b~12000b  32b
> 
> ڴNΤ@ӨҤln{ABCDN|xq
> A(SA)=1 B(SA)=2  C(SA)=3  D(SA)=4
> ѥ|xqSwitch|ʧ@OH
> ӤSwitchnOC@xqxSAӥBnDC@x
> qb@Port(άODomainAPortU]i걵HUB^
> ڭ̤S]AP1,BP2,CP3,DP4
> AǲĤ@ƣxɭ
> SwitchSASOҥH|ObTable
>         DAϥ]SbOWDA
> BCDN|QBroadcast@ӦAxpacket
> TableN|OP1_from_SA=1
> HC@xqeXĤ@ƫ
> ҥHSwitch address Table|UCxF
> P1_from_SA=1
> P2_from_SA=2
> P3_from_SA=3
> P4_from_SA=4
> MwWoǼƦriHxsh,C@xSWW
> 1K 2K 4K 8K
> 
> CASE1:
> AnǪF赹B|򨫩OH
> A Packet SW Table
> o{sbP1_from_SA=1٬OUpdateuOSЦΤ@MAC address
> DA=2 hTableo{2bP2
> ]{bxSWOҿףxstore and forward
> NOW榡FCShBƦS~enhxaΪ̬OBroadcast
> He@إsCut throughݨDAbN|e
> na
> Ĥ@Latency|
> ĤGMĲvn
> LaPacket]|QeLPort
> ѥLXӨS
> OKo@ƴN|ܶQ"ueP2"
> ۹諸L]@˪ʧ@
> 
> CASE2:
> ѧAP2M᳣oXT|ƨƵoͩOH
> CnǪF赹A
> SAǲߩMWzʧ@@
> ObDA
> TableP1_from_SA=1
> AwgިP2
> OASSW
> SW|HA٦bP1
> ҥH|ܦ٬OǨP1OڥSH
> ҥHo]O󤣺ޥHeNovellΪ̲{bxMS or XX OS
> bw|oXBroadcast]OFbSW[cUnSW
> {bB٦MAC address୫ЩMoǳ
> ABrocastxɭ
> Table|OP2_from_SA=1
> P1_from_SA=1|QM
> ҥHo]OnOSA٭nOPortID
> 
> CASE3:
> APBbP2_DomainOAǪF赹B SW|ʧ@H
> Table|
> P2_from_SA=1
> P2_from_SA=2
> 
> AƤo{B]bP@Port_Domain
> ҥHOzLP2UDevice(HUB or SW)
> N|qFڥݭne
> ҥHAǵB|QDrop
> CASE3FSW]֦Filter\
> 
> WoǬOSWx[
> ۤveeϥiez
> SW٬O@ǰDsb
> pGWoAѤF
> UiHۤvQQ
> xSW걵
> A BUbxSWW
> Mմ
> pGOzפWNNhݪ
> |ưDsbH
> MnSW|@MmethodologyhѳoӰD
> LjaiHո
> 
> HWoǬ۫HOЬѨS
> ڥuOۤvgɵU
> p~Ϊ̰DwӰQ


---------------


"H"  gl news:...
>
> "~h"  gl
> news:3k3QMC$Jjh@bbs.ee.ntu.edu.tw...
> > nNAڹ Hub ѦIhFAGbбФja .... :-)
> >
> > @몺 Hub (H 4 ports ҡA10Bps  10/100Bps) F@몺
> > | port H~At~٦@Ӫ` Select Ĥ port, 
> > ťo port Pĥ| port PɱA@ӨӥΡA
> > @oHo "Select"  port 쩳O@ΩOH
>
> oDڦb network W^LhFMpUR
>  hub  uplink M䤤@ normal port ObP@ port WQӦǫhO
> }Wߪ@ uplinkC
>
> pGOP@ port WMӦ@Ӷ}Mzഫo port \CpGOW
> MЯdNOWO_e@ڽuMN uplink M䤤@ normal port sb@_
> FCpGOMo port ϥήɾORG@MPɨϥΡC
>
> L׬OرpMuplink q`OΨӱN hub s_Ӫ(ڬ۫HݨϥΪ̤U
> Ϩһ)R
>
> 1) pG hub S uplinkMNΤ@ cross over uN hub _ӡM
> 賣 normal port NiHFC
> 2) pG uplink ӱMNΤ@ straight through uMq䤤@ hub 
> uplink t@x normal port WC
>
> pz@@nt~| HUB ܡMq`|Ĩ걵覡M
> ]NO a->b->c->d->e MFbĲvWҼ{M]n`N 5-3-4 hC
>
> ڭ̳q`ĳĥΡ覡R
> a->b
> a->c
> a->d
> a->e
>
> oˡMC hub ̦hV@ hub NiHFFCoɭԡMa  uplink iH
> ΡMMN b,c,d,e  uplink δqu a q port NnC
>
> pGzuݭnuMNumYMɽu}VۤvMqWUơR
>
> N 1 M 3 M2 M 6 M(u@ӱYNn)
>
> uаѦҡR
> http://www.johnscloset.net/wiring/crossover.html
>
>
>
> >
> > t~@ӰDOѲĤ@J쪺AڱN Hub o˱
> >
> >                      +-----+
> >                      |     |
> >         World -------+ Hub +------------ Computer
> >                      |     |
> >                      +-----+
> >
> > Ӧbɥ~iӪuPquO 1 - 4  port 
> > AGo{ Hub WOS~ιqLӪʥ]A
> > GMqLksXhCpGڱN~uAιquAs
> > Select port ɡAh Select port WN|ʥ]OA
> > t@u¤@IASʥ]CyܻAF
> > Select port OH~ALSOC
> >
> > ڷQаݪOAo˪pON Hub aFܡH٬OL]H
> > (ڸդFx Hub Op)
> >
>
> pGդF hub oˡM@_a|~~
> γ\ˬd@UukaC
>
> t~M hub ɭԡMn`N 5-4-3 hM
> ݬݱz hub O_nWXFoӽdS
>
>
>
> --
>
> ======= http://www.study-area.org =======
> KMBeKk
> wOHVʤVBMצKN
> N]KMuKӳ
> ݱos꺩ɡMLbOT
>




"@_Ra^^"  gl news:40eVT4$FD5@bbs.ccns.ncku.edu.tw...
>  ޭzmwchuang.bbs@bbs.cis.nctu.edu.tw (Ѻɤ֦~)nʨG
> > ==> b "runnersam"  峹:
> > > what's the different between hub and switch?  thanks.
> >   hub -> layer 1
> >   switch -> layer 2
> hub OݩP@ collision (I) domain
> O CSMA/CD Ӱʥ]ǻ
> nǸƥXhɷ|hSL port bϥ
> ҥHC port PL port Pɨϥ
> ҥH hub WC port O shared total bandwidth 
> O switch hOW۪ collision domain
> C port HɳiHϥ   CSMA/CD   BOUUWWe
> WhӦW  p : switch P switching hub
> oOtO ]ڭ̳D switch (Layer 2) OݩP@ broadcast domain
> Dh vlan   ~XWߪ broadcast domain
> o switch SOQ   @nnXU
> BH{ ڨäݭn vlan ڥuƱ榳P collision domain Yi
> ҥH~| switching hub X{
> O@ӨS vlan \઺² switch  @unXd



"H"  gl news:ae2lv7$c7v$1@news.seed.net.tw...
> 
> 
> 
> "@_Ra^^"  gl
> news:40eVT4$FD5@bbs.ccns.ncku.edu.tw...
> >  ޭzmwchuang.bbs@bbs.cis.nctu.edu.tw (Ѻɤ֦~)nʨG
> > > ==> b "runnersam"  峹:
> > > > what's the different between hub and switch?  thanks.
> > >   hub -> layer 1
> > >   switch -> layer 2
> > hub OݩP@ collision (I) domain
> > O CSMA/CD Ӱʥ]ǻ
> > nǸƥXhɷ|hSL port bϥ
> > ҥHC port PL port Pɨϥ
> > ҥH hub WC port O shared total bandwidth 
> > O switch hOW۪ collision domain
> > C port HɳiHϥ   CSMA/CD   BOUUWWe
>                             ^^^^^^^^^^^^^^^^^^
> 
> ڤ{ switch MiHN CSMA/CD ߶}Mp physical O 802.3 W檺ܡC
> uOMswitch w CS M CD i榳ĪﵽMӴѾ MA OӤwC
> 
> eӦ\hQפ峹FMbU]F@ǡMѦҬݬݡR
> 
> http://www.study-area.org/tips/hub_switch.htm
> 


"@_Ra^^"  gl news:40f2XP$Fem@bbs.ccns.ncku.edu.tw...
>  ޭzmnetman@junk.com (H)nʨG
> > "@_Ra^^"  gl
> > news:40eVT4$FD5@bbs.ccns.ncku.edu.tw...
> > > hub OݩP@ collision (I) domain
> > > O CSMA/CD Ӱʥ]ǻ
> > > nǸƥXhɷ|hSL port bϥ
> > > ҥHC port PL port Pɨϥ
> > > ҥH hub WC port O shared total bandwidth 
> > > O switch hOW۪ collision domain
> > > C port HɳiHϥ   CSMA/CD   BOUUWWe
> >                             ^^^^^^^^^^^^^^^^^^
> > ڤ{ switch MiHN CSMA/CD ߶}Mp physical O 802.3 W檺ܡC
>                                                 ^^^^^^^^^^^^^^^^^^^^^^
> 802.3 O CSMA/CD a ??
> Ethernet P Ethernet_802.3 O@˪  OUOW
> Etherner OL1PL2h  Ethernet_802.3 OL2 Ubh Ethernet_802.2OWbh
> hub OL1~  ΪO CSMA/CD (Ethernet S)
>  switch ұĪ 802.3 h CS P CD udU MA
> 
> > uOMswitch w CS M CD i榳ĪﵽMӴѾ MA OӤwC
> > eӦ\hQפ峹FMbU]F@ǡMѦҬݬݡR
> > http://www.study-area.org/tips/hub_switch.htm
> 
> ڦiӬݧA峹
> Aݨ@qOog  ??
> A layer 2 interconnection device that does not form part of a
> CSMA/CD collision domain
> ڤSݨ@gڤ
> The CSMA/CD access method is specified in IEEE Std 802.3
> JM L2  CSMA/CD  L2  802.3 SO CSMA/CD
> SLiHӸѵ
> ڦb CISCO ICND ЧWݹL Switch ĥ CSMA/CD
> b RFC WSwqP CISCO WP
> 

"H"  gl news:ae3llg$pa$1@news.seed.net.tw...
> 
> "@_Ra^^"  gl
> news:40f2XP$Fem@bbs.ccns.ncku.edu.tw...
> 
> > > > C port HɳiHϥ   CSMA/CD   BOUUWWe
> > >                             ^^^^^^^^^^^^^^^^^^
> > > ڤ{ switch MiHN CSMA/CD ߶}Mp physical O 802.3 W檺ܡC
> >                                                 ^^^^^^^^^^^^^^^^^^^^^^
> > 802.3 O CSMA/CD a ??
> 
> pG CSMA/CDMΤS
> CSMA/CA ٬O token passing ٬O token bus ?
> 
> 
> > Ethernet P Ethernet_802.3 O@˪  OUOW
> > Etherner OL1PL2h  Ethernet_802.3 OL2 Ubh Ethernet_802.2OWbh
> 
> OSI O@ model MO@ӨwMбzndMoӷC
> bwзǤW@MiHѦ OSI ҫMwqMݬݦUӨwWdR
>     IEEE  IEEE зǡMIBM  IBM зǡMapple  apple з....
> 
> b IEEE 802.x aڤM802.2 U 3,4,5,6,12 oXӼзǡM
> }F LCC M MAC  sub layer MO 802.7M8M9M10M11 OwqF㪺 L2
> hšM
> Ӧb 802.3 зǤUMziHϥΪ physical W(`)oǡR
>     * 10Base2
>     * 10Base5
>     * 10/100BaseT(x)
> ziHκ٤ ethernet M̪ǿwoiHO CSMA/CD (ƪiH}ot~
> w)M
> ndVF physical M logical topology NOFC
> 
> 
> > hub OL1~  ΪO CSMA/CD (Ethernet S)
> >  switch ұĪ 802.3 h CS P CD udU MA
> 
> b node ݦӨM٬Oϥ CSMA/CDMuO switch }F CS M CD ӤwC
> ޱzp}M٬Oϥγo logical topology R
>  node bǰeɭԡMS sense  carrier MNiHN signle e media WQ
> unS collision  detect MN{ǰe\Q
> Ojab@ӧn mutiple access ҤFC
>  CS M CD ٬OsbMuO switch oקKӤwM
> ӤOMϥ switch NAĥ CSMA/CD աC
> 
> DzϤXӶܡS
> 
> >
> > > uOMswitch w CS M CD i榳ĪﵽMӴѾ MA OӤwC
> > > eӦ\hQפ峹FMbU]F@ǡMѦҬݬݡR
> > > http://www.study-area.org/tips/hub_switch.htm
> >
> > ڦiӬݧA峹
> > Aݨ@qOog  ??
> > A layer 2 interconnection device that does not form part of a
> > CSMA/CD collision domain
> 
> oyIORnot part of a XXXX collision domain M
> CSMA/CD uO@өwyMM collision @ˡMOΨөwq domain oӦWC
> 
> 
> > ڤSݨ@gڤ
> > The CSMA/CD access method is specified in IEEE Std 802.3
> 
> oy^²MҥHezѰ~~  ^_^
> 
> > JM L2  CSMA/CD  L2  802.3 SO CSMA/CD
> > SLiHӸѵ
> > ڦb CISCO ICND ЧWݹL Switch ĥ CSMA/CD
> > b RFC WSwqP CISCO WP
> 
> OROSI uO@ model MUawb@W٬OҥXJC
> pGzo{ cisco M RFC wqĬ𪺸ܡMR
>     * bzפWMХH RFC ǡQ
>     * b@WMХH cisco (u cisco ])
> 
> t~z@ӫĳROӰ۩WM]OFMNzd~O䪺C
> pGzwMۤv CSMA/CD _@ӦWrs ABC wMMN 802.3 ٬ XYZ зǡM
> 󤣥iS
> ̪zzNHKÿFMWMjabqW~|NFC
> 
> ɥRRӤHNM@ǡMȨѰѦҡC
> 



"LPZߥJ"  gl news:40fB2I$YDT@bbs.cis.nctu.edu.tw...
> ==> b "H"  峹:
> > b IEEE 802.x aڤM802.2 U 3,4,5,6,12 oXӼзǡM
> > }F LCC M MAC  sub layer MO 802.7M8M9M10M11 OwqF㪺 L2
> 
> ĳAAIEEE 802.1D5i[cϦAݤ@UC
> 
> > b node ݦӨM٬Oϥ CSMA/CDMuO switch }F CS M CD ӤwC
> > ޱzp}M٬Oϥγo logical topology R
> >  node bǰeɭԡMS sense  carrier MNiHN signle e media
>                                                            ^^^^^^
> ̦nsignalframeMA802.3ܦhphysical layerWbʥ]Ϋʥ]
> M|signalǰe(o٬idle signal)AӯunקKIOframeAOsignalC
> 
> > unS collision  detect MN{ǰe\Q
> > Ojab@ӧn mutiple access ҤFC
> >  CS M CD ٬OsbMuO switch oקKӤwM
> > ӤOMϥ switch NAĥ CSMA/CD աC
> 
> ĤĥCSMA/CDO_full duplexAuOswitchϥάOfull duplex
> nӤw(]Ҽ{xqǪ)CpGswitchCport
> O]full duplexANSCSMA/CDsbC
> 
> > > A layer 2 interconnection device that does not form part of a
> > > CSMA/CD collision domain
> > oyIORnot part of a XXXX collision domain M
> > CSMA/CD uO@өwyMM collision @ˡMOΨөwq domain oӦWC
> 
> oyNuObridgeiH*j*collision domainC
> 
> > > JM L2  CSMA/CD  L2  802.3 SO CSMA/CD
> > > SLiHӸѵ
> 
> *{b*Ethernet == IEEE 802.3AvGЦۦbWd\C
> --



"203.187.2.10"  gl news:40fB2i$YjL@bbs.cis.nctu.edu.tw...
> ==> b "H"  峹:
> > >                                                 ^^^^^^^^^^^^^^^^^^^^^^
> > > 802.3 O CSMA/CD a ??
> > pG CSMA/CDMΤS
> > CSMA/CA ٬O token passing ٬O token bus ?
> cut from 802.3 standard:
> 
> This standard provides for two distinct modes of operation: half duplex
> and full duplex. A given IEEE 802.3 instantiation operates in either half
> or full duplex mode at any one time. The term CSMA/CD MAC is used
> throughout this standard synonymously with 802.3 MAC, and may represent
> an instance of either a half duplex or full duplex mode data terminal
> equipment (DTE), even though full duplex mode DTEs do not implement the
> CSMA/CD algorithms traditionally used to arbitrate access to shared-media
> LANs.
> 
> ²檺, NNO"M CSMA/CD MAC oӺ٩I, OOκ٪
> 802.3 MAC, ަSΨ CSMA/CD"
> 
> > > hub OL1~  ΪO CSMA/CD (Ethernet S)
> > >  switch ұĪ 802.3 h CS P CD udU MA
> > b node ݦӨM٬Oϥ CSMA/CDMuO switch }F CS M CD ӤwC
> > ޱzp}M٬Oϥγo logical topology R
> >  node bǰeɭԡMS sense  carrier MNiHN signle e media WQ
> > unS collision  detect MN{ǰe\Q
> > Ojab@ӧn mutiple access ҤFC
> >  CS M CD ٬OsbMuO switch oקKӤwM
> > ӤOMϥ switch NAĥ CSMA/CD աC
> > DzϤXӶܡS
> 1.1.1.2 Full duplex operation
> Full duplex operation allows simultaneous communication between a pair
> of stations using point-to-point media (dedicated channel). Full duplex
> operation does not require that transmitters defer, nor do they monitor
> or react to receive activity, as there is no contention for a shared
> medium in this mode. Full duplex mode can only be used when all of the
> following are true:
> 
> a) The physical medium is capable of supporting simultaneous transmission
> and reception without interference.
> 
> b) There are exactly two stations connected with a full duplex
> point-to-point link. Since there is no contention for use of a shared
> medium, the multiple access (i.e., CSMA/CD) algorithms are unnecessary.
> 
> c) Both stations on the LAN are capable of, and have been configured to use,
> full duplex operation.
> 
> The most common configuration envisioned for full duplex operation
> consists of a central bridge (also known as a switch) with a dedicated
> LAN connecting each bridge port to a single device. Repeaters as defined
> in this standard are outside the scope of full duplex operation.
> 
> Full duplex operation constitutes a proper subset of the MAC functionality
> required for half duplex operation.
> 
> ҥH᭱ץiH٤F, ]uUڥ CSMA/CD, ]Sn.
> switch ]n host ]n, @˳O@ station, ̦OO?
> 
> > > ڦiӬݧA峹
> > > Aݨ@qOog  ??
> > > A layer 2 interconnection device that does not form part of a
> > > CSMA/CD collision domain
> > oyIORnot part of a XXXX collision domain M
> > CSMA/CD uO@өwyMM collision @ˡMOΨөwq domain oӦWC
> 1.4.82 collision domain: A single, half duplex mode CSMA/CD network.
> If two or more Media Access Control (MAC) sublayers are within the
> same collision domain and both transmit at the same time, a collision
> will occur. MAC sublayers separated by a repeater are in the same
> collision domain. MAC sublayers separated by a bridge are within
> different collision domains. (See IEEE 802.3.)
> 
> @, oǦWOTwq




"LPZߥJ"  gl news:40fB9b$Z1I@bbs.cis.nctu.edu.tw...
> ==> b fleece.bbs@bbs.csie.nctu.edu.tw (bŤb 峹:
> >  ޭzmlovekunfu.bbs@bbs.ccns.ncku.edu.tw (@_Ra^^)nʨG
> > ɫH pL
> > ݬOnQ HALF-DUPLEX  FULL-DUPLEX
> > Ϊ̬OQפP LAYER 洫ഫ
> > ]\NJIM|n «ĳ
> 
> hRich Seifert۪Gigabit EthernetThe Switch bookӬݡC
> @̬OFull duplexзǤpժDuݽsALgfull duplex[
> `|DaCpG^٤AiHcomp.dcom.lans.ethernet
> QװϪLHбСC



"H"  gl news:ae4890$gdf$1@news.seed.net.tw...
> "LPZߥJ"  gl
> news:40fB2I$YDT@bbs.cis.nctu.edu.tw...
> >
> > ĳAAIEEE 802.1D5i[cϦAݤ@UC
> 
> MФFTp̻²~~
> Ȯɤ]Sɶ½ѡMn IEEE 802.x 藍Τ@yܪM
> oOp̪LMƱSjayӦh~ɧaC
> 
> 
> > ̦nsignalframeMA802.3ܦhphysical layerWbʥ]Ϋʥ]
> > M|signalǰe(o٬idle signal)AӯunקKIOframeAOsignalC
> 
> LMD signal M frame pϤOS
> pbP@ɽuWM signal PɦbWǰeɭԡM
> DL`IpϤSڡMLNmáMuOuMܷQбЦӤwC
> 
> Np̭ӤH{(pM@Ǫ)Mҿת frame ]O signal caS
> }F signal Mp̹bQHX frame OFS
> ӦbUıoMLΤ signal ǰe޳NMkڵ٬O@ 0 M 1 ӤwM
> L׬O signal M٬O signal զ frame M
> o signal b@ɴCWǰeɭԡMNPɥX{C
> MiOp̹ signal M frame {٤FѧaMƱSxūФ@GC
> ¡T
> 
> 
> >
> > ĤĥCSMA/CDO_full duplexAuOswitchϥάOfull duplex
> > nӤw(]Ҽ{xqǪ)CpGswitchCport
> > O]full duplexANSCSMA/CDsbC
> 
> ڥuPN full duplex ݪkMPNN CSMA/CD kLΡC
> b FD pUM]SX{@ɴC骺pM
> ҥH@g]wMCS M CD iHٱM໡oӾsbC
> o]Op̤eV lovekunfu SXĳaC
> pG FD ҦsbOSDڭ̤S CSMA/CD _FܡS
> ڥu໡MCSMA/CD OsbMuOڭ̦b implement ɭԡM
> N CS M CD קKӤwC
> 
> pGp̨ӥӤ몺ܡMb FD pUM@}UӳOOM
> ڥLݭn٨NFتaM]b FD άOSIoͪC
> ڭ̤]ROM٨˸mOsbC
> 
> >
> > > > A layer 2 interconnection device that does not form part of a
> > > > CSMA/CD collision domain
> 
> > oyNuObridgeiH*j*collision domainC
> 
> Mo˸ehF~~
> 
> ٽ ilkitty SxhhСC¡T
> 




"203.187.2.10"  gl news:40fENF$YbT@bbs.cis.nctu.edu.tw...
> ==> b "H"  峹:
> > ڥuPN full duplex ݪkMPNN CSMA/CD kLΡC
> > b FD pUM]SX{@ɴC骺pM
> > ҥH@g]wMCS M CD iHٱM໡oӾsbC
> > o]Op̤eV lovekunfu SXĳaC
> > pG FD ҦsbOSDڭ̤S CSMA/CD _FܡS
> > ڥu໡MCSMA/CD OsbMuOڭ̦b implement ɭԡM
> > N CS M CD קKӤwC
> > pGp̨ӥӤ몺ܡMb FD pUM@}UӳOOM
> > ڥLݭn٨NFتaM]b FD άOSIoͪC
> > ڭ̤]ROM٨˸mOsbC
> tOb,  CSMA/CD ۷٬O@}b٨W, O FD 
> }Ob٨W, lW]o٨, OѤFP@ standard
> ]AΩ󧹥S half-duplex  Gigabit Ethernet.
> 




"H"  gl news:ae4c9n$jlk$1@news.seed.net.tw...
> 
> "203.187.2.10"  gl
> news:40fENF$YbT@bbs.cis.nctu.edu.tw...
> > tOb,  CSMA/CD ۷٬O@}b٨W, O FD 
> > }Ob٨W, lW]o٨, OѤFP@ standard
> > ]AΩ󧹥S half-duplex  Gigabit Ethernet.
> 
> F~~ ¡T
> 
> ڭ̦b hub M switch ɭԡMO_̦nNϤXӡR
> 
> 1) b half duplex pU
> 2) b full duplex pU
> 
> LMpGb FD UMڭ̮ڥz| hub FaS] no such thing!
> 
> ]oDدuC@ӬPNX{@MoڦAjaQפ]_ӦnFC
> uOMDh֤H|ݦӤw~~
> 



"LPZߥJ"  gl news:40fcO6$YnM@bbs.cis.nctu.edu.tw...
> ==> b "H"  峹:
> > > ̦nsignalframeMA802.3ܦhphysical layerWbʥ]Ϋʥ]
> > > M|signalǰe(o٬idle signal)AӯunקKIOframeAOsignalC
> > Np̭ӤH{(pM@Ǫ)Mҿת frame ]O signal caS
> > }F signal Mp̹bQHX frame OFS
> > ӦbUıoMLΤ signal ǰe޳NMkڵ٬O@ 0 M 1 ӤwM
> > L׬O signal M٬O signal զ frame M
> > o signal b@ɴCWǰeɭԡMNPɥX{C
> > MiOp̹ signal M frame {٤FѧaMƱSxūФ@GC
> 
> WAp100BASE-TXAbframeMframe]signalǰe(٬idle signal)A
> O11111Һc(scrambleMMLT-3sXe)Aӥ`frameƦb4B/5BsX
> ᤣiಣ11111o˪XAҥHݥiHϧOOframeάOidle signalC
> 100BASE-TXUcollision detectionP_̾ڬOˬdbǰeframePɡAO_
> Ӧۥt@ݪframeAӤONsignal(pidle signal)A]idle signal
> bframeMframeO@sbAPɥX{OframeC
> 
> ӹ10BASE2B10BASE5WӨAframeMframeSidle signalAcollision
> detectionOھڶǿuWHDC componentqO_WL{ɭȨӨMw(Ѧ
> 802.3зClause 8.3.1.4M8.3.1.5)C
> 
> > ڥuPN full duplex ݪkMPNN CSMA/CD kLΡC
> > b FD pUM]SX{@ɴC骺pM
> > ҥH@g]wMCS M CD iHٱM໡oӾsbC
> > o]Op̤eV lovekunfu SXĳaC
> > pG FD ҦsbOSDڭ̤S CSMA/CD _FܡS
> 
> implementөwA@10/100d|Pimplement half/full duplexA
> b]full duplexɷ|CSMCD\disableAѩustation
> i|@Τ@ӶǿCAҥHs"multiple" access]SFCOGigabit
> Ethernetަhalf duplexзǡAOSHhimplementA]NS
> disableDA]ڥsbCF10 Gigabit EthernetAshalf duplex
> зǤ]qFA󤣥λimplementFCަpA802.3зǪjD
> ٬OCSMA/CDAڷQuOFQפKC
> 
> full duplexзǪӸ`AiHhRich SeifertѡAoǪF
> OḼqXӪC



-----------


"ethan"  gl news:40fSI0$Vrt@bbs.im.tku.edu.tw...
> 1.unOEthernet NOcsma/cdשҤdeviceO
> 2.ܦhHswitchNScsma/cdSʳo˪kOǰD
> TӻӬOswitchcollision detection(CD),switchWڥIq
> ҥHbswitchSID,
> 3.]switchOlayer2deviceҥHiH䴩full-duplex.pGHLhubiH䴩
> full-duplex,NLYڤUh.layer2NNOCportOWߪcollision
> domain;p@portPportfull-duplex~i
> 



"huckly"  gl news:0AE6B04$0002G4R$1@bbs.openfind.com.tw...
>  ޭzmethanchn.bbs@bbs.im.tku.edu.tw (ethan)nʨG
> > 1.unOEthernet NOcsma/cdשҤdeviceO
> > 2.ܦhHswitchNScsma/cdSʳo˪kOǰD
> > TӻӬOswitchcollision detection(CD),switchWڥIq
> > ҥHbswitchSID,
> 
> pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
>  switch ӦpBz 
> 
> pGAJӬ UatP switch L̳䴩 802.3 
> b 802.3 |w Pp ӧ@ Bz 
> ҥH໡ switch  CSMA/CD 
> ӻ b full-duplex AU ä|  collision ҥH  CSMA/CD
> O pGO helf-duplex ٬O| CSMA/CD 
> 
> p[ Ы
> > 3.]switchOlayer2deviceҥHiH䴩full-duplex.pGHLhubiH䴩
> > full-duplex,NLYڤUh.layer2NNOCportOWߪcollision
> > domain;p@portPportfull-duplex~i
> 
> pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
>  switch ӦpBz 
> 




"LPZߥJ"  gl news:40g0bV$YHI@bbs.cis.nctu.edu.tw...
> ==> b "huckly"  峹:
> > pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
> >  switch ӦpBz
> 
> pGݳ䴩BQ]auto negotiationAoݦ۵M|hӥXӤ
> ӥfull duplexCpGΤʪ覡jh]wANpʪ]wGC
> ScollisionOѵoeݥh""APˬOPɦBeΡApGoe
> ]half duplexAN|collisionCpGoeݳ]full duplexAh
> |QcollisionC




"ethan"  gl news:40geEa$WDn@bbs.im.tku.edu.tw...
> i b huckly. j@: j
> :  ޭzmethanchn.bbs@bbs.im.tku.edu.tw (ethan)nʨG
> : > 1.unOEthernet NOcsma/cdשҤdeviceO
> : > 2.ܦhHswitchNScsma/cdSʳo˪kOǰD
> : > TӻӬOswitchcollision detection(CD),switchWڥIq
> : > ҥHbswitchSID,
> : pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
> :  switch ӦpBz 
> : pGAJӬ UatP switch L̳䴩 802.3 
> : b 802.3 |w Pp ӧ@ Bz 
> : ҥH໡ switch  CSMA/CD 
> : ӻ b full-duplex AU ä|  collision ҥH  CSMA/CD
> : O pGO helf-duplex ٬O| CSMA/CD 
> : p[ Ы
> : > 3.]switchOlayer2deviceҥHiH䴩full-duplex.pGHLhubiH䴩
> : > full-duplex,NLYڤUh.layer2NNOCportOWߪcollision
> : > domain;p@portPportfull-duplex~i
> : pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
> :  switch ӦpBz 
> 
> O_support full-duplexO]collision dection,switchYportwhalf-duplex
> ɭ;MI.
> hubOҥHవfull-duplex]hubȶȬOshare media,bhubҦport@ӳɶR
> ׬O_oportn򤣭npacket,󤣥νͤ@portnPɶePʧ@.
> unOethernetN@wcsma/cdS;switch]CportO@collision domainҥH
> ݦҼ{collisionD.switch]Yport]half-duplexܦnI.
> 
> ]\ziHѦҤ@UHUԭzӦCisco:http://www.cisco.com/warp/public/473/lan-switch-cisco.shtml
> Ъ`N峹ΨforgooӦr
> Fully switched networks employ either twisted pair or fiber optic cabling, 
> both of which use separate conductors for sending and receiving data. 
> In this type of environment, Ethernet nodes can forgo the collision detection 
> process and transmit at will ,since they are the only potential devices that 
> can access the medium.
> 
> ja@_sDiB 
> 



"ethan"  gl news:40gg3V$XD_@bbs.im.tku.edu.tw...
> i b ilkitty.bbs@bbs.cis.nctu.edu.tw (LPZߥJ) j@: j
> : ==> b "huckly"  峹:
> : > pGڪdS䴩 full-duplex ]NO boport ]| collision  ??
> : >  switch ӦpBz
> : pGݳ䴩BQ]auto negotiationAoݦ۵M|hӥXӤ
> : ӥfull duplexCpGΤʪ覡jh]wANpʪ]wGC
> : ScollisionOѱݥh""APˬOPɦBeΡApG
> : ]half duplexAN|collisionCpGݳ]full duplexAh
> : |QcollisionC
> 
> full-duplex|disable collision detectionS,but half-duplexUڪݪkO
> congestion control;ӤOcollision detection.
> ]switchCportbuffer|queuetrafficbuffer~oXcollision framen
> Dresend
> аѦҥHUԭzback-pressure from Cisco
> 
> Half Duplex with Back Pressure
> Half-duplex back pressure ensures retransmission of incoming packets if 
> a half-duplex switch port is unable to receive incoming packets. 
> When back pressure is enabled and no buffers are available to a port, 
> the switch sends collision frames across the affected port and causes the 
> transmitting station to resend the packets. 
> The switch can then use this retransmission time to clear its receive buffer 
> by sending packets already in the queue.
> 



"L"  gl news:40ggSX$Wzv@BirdNest.twbbs.org...
>  ޭzmethanchn.bbs@bbs.im.tku.edu.tw (ethan)nʨG
> : O_support full-duplexO]collision dection,switchYportwhalf-duplex
> : ɭ;MI.
> : hubOҥHవfull-duplex]hubȶȬOshare media,bhubҦport@ӳɶR
> : ׬O_oportn򤣭npacket,󤣥νͤ@portnPɶePʧ@.
> : unOethernetN@wcsma/cdS;switch]CportO@collision domainҥH
> : ݦҼ{collisionD.switch]Yport]half-duplexܦnI.
> HWkO~
> 
> : ]\ziHѦҤ@UHUԭzӦCisco:http://www.cisco.com/warp/public/473/lan-switch-cisco.shtml
> : Ъ`N峹ΨforgooӦr
> : Fully switched networks employ either twisted pair or fiber optic cabling,
> : both of which use separate conductors for sending and receiving data.
> : In this type of environment, Ethernet nodes can forgo the collision detection
> : process and transmit at will ,since they are the only potential devices that
> : can access the medium.
> : ja@_sDiB
> Ъ`NLO"fully switched networks", ̭wgtF"]Ƴqq
> O switch"oӷN. O switch c, M|H¨٦b
> ] half-duplex. ȱqo@IޥӨ"unO switch W port N
>  collision detection"oӵG.
> 


"L"  gl news:40ghNW$WXw@BirdNest.twbbs.org...
>  ޭzm"H" , ݪO: NetworknʨG
> : > Ъ`NLO"fully switched networks", ̭wgtF"]Ƴqq
> : > O switch"oӷN. O switch c, M|H¨٦b
> : > ] half-duplex. ȱqo@IޥӨ"unO switch W port N
> : >  collision detection"oӵG.
> : M](])Mu򡥲¡HF@ hub OS
> : GSpS
> ², F@ hub H, Ns"fully switched network"F, HW
> k]۵MAA.
> 


"L"  gl news:40ggdl$WXy@BirdNest.twbbs.org...
>  ޭzmethanchn.bbs@bbs.im.tku.edu.tw (ethan)nʨG
> : full-duplex|disable collision detectionS,but half-duplexUڪݪkO
> : congestion control;ӤOcollision detection.
> : ]switchCportbuffer|queuetrafficbuffer~oXcollision framen
> : Dresend
> : аѦҥHUԭzback-pressure from Cisco
> : Half Duplex with Back Pressure
> : Half-duplex back pressure ensures retransmission of incoming packets if
> : a half-duplex switch port is unable to receive incoming packets.
> : When back pressure is enabled and no buffers are available to a port,
> : the switch sends collision frames across the affected port and causes the
> : transmitting station to resend the packets.
> : The switch can then use this retransmission time to clear its receive buffer
> : by sending packets already in the queue.
> A flow control M collision ˲VF, oOP@.
> 
> flow control OΨӸѨM"switch "q, p 100Mbps
>  port Pɥtǰeƨt@ 100Mbps port, M|b switch ̭
> eLh, oɭ switch ӭnQkq sender ȽweX packet,.
> 
> full-duplex  port i઺kO 802.1x pause frame Ӱ flow control
> 
> half-duplex ܫ? ²檺覡NO switch  transmitter jam
> , ob switch ̭ buffer MXӥHe|, ҥHi|zZ
> segment W䥦`I. OѤF䥦˸m٬Ob CSMA/CD , u switch
> GNOäCKV.
> 


"H"  gl news:ae9p97$bp$1@news.seed.net.tw...
> 
> "L"  gl
> news:40ggdl$WXy@BirdNest.twbbs.org...
> >  ޭzmethanchn.bbs@bbs.im.tku.edu.tw (ethan)nʨG
> > : full-duplex|disable collision detectionS,but half-duplexUڪݪkO
> > : congestion control;ӤOcollision detection.
> > : ]switchCportbuffer|queuetrafficbuffer~oXcollision frame
> n
> > : Dresend
> > : аѦҥHUԭzback-pressure from Cisco
> > : Half Duplex with Back Pressure
> > : Half-duplex back pressure ensures retransmission of incoming packets if
> > : a half-duplex switch port is unable to receive incoming packets.
> > : When back pressure is enabled and no buffers are available to a port,
> > : the switch sends collision frames across the affected port and causes the
> > : transmitting station to resend the packets.
> > : The switch can then use this retransmission time to clear its receive buffer
> > : by sending packets already in the queue.
> > A flow control M collision ˲VF, oOP@.
> >
> > flow control OΨӸѨM"switch "q, p 100Mbps
> >  port Pɥtǰeƨt@ 100Mbps port, M|b switch ̭
> > eLh, oɭ switch ӭnQkq sender ȽweX packet,.
> 
> MդUǫSsΤkӡqsender @~
> WORthe switch sends collision frames across the affected port 
> D_бz@UOS
> 
> >
> > full-duplex  port i઺kO 802.1x pause frame Ӱ flow control
> >
> > half-duplex ܫ? ²檺覡NO switch  transmitter jam
> > , ob switch ̭ buffer MXӥHe|, ҥHi|zZ
> > segment W䥦`I. OѤF䥦˸m٬Ob CSMA/CD , u switch
> > GNOäCKV.
> 
> ~~ pMIáMp̹b򤣤WդUC
> eդUMS_w switch | CSMA/CD Mo̫o@ӡäCKVסM
> D_AԲӸѪR@UOS
> O~|Mp̤Ob challenge M ӬOuC
> Ʊe༷ŸѴbC¡T
> 




"˭l_"  gl news:40gj64$Wfu@BirdNest.twbbs.org...
>  ޭzm"H" , ݪO: NetworknʨG
> : > A flow control M collision ˲VF, oOP@.
> : > flow control OΨӸѨM"switch "q, p 100Mbps
> : >  port Pɥtǰeƨt@ 100Mbps port, M|b switch ̭
> : > eLh, oɭ switch ӭnQkq sender ȽweX packet,.
> : MդUǫSsΤkӡqsender @~
> 
> ݭnDsenderO֡Cbhalf duplexUAAiu׬Y@senderAn״N
> shared mediaتstation@סCΪkback pressureAjP
> kG
> (1) force collisionGݨ즳ʥ]eӤFANoӫʥ]GNcollisionCo
>     sendero{collisionN|wƭeA]queueQ뺡piHȮɵνwC
> (2) false carrierGSdeferralA軡AiHo@ꪺpreambleHA
>     sender@sensecarrierAosenderN|eʥ]XӤFC
> 
> Ofull duplexUA]SCSMA/CDAҥHWzkLġC]IEEE 802.3x
> (O802.1xAK@UstevenѤj~)b~bqfull duplexзǮɡAN
> KqFbfull duplexUflow controlkANOPAUSE frameC]full
> duplexUAs@portstation꦳@ӡAҥH@wOsenderA|O
> H(ƹWPAUSE framedestination addressO@multicast addressAN
> BzPAUSE framestationҺcgroupCsenderunimplementBzPAUSE
> frame\AN|o˪frame)C
> 
> : WORthe switch sends collision frames across the affected port 
> : D_бz@UOS
> 
> peҭzC
> 
> : ~~ pMIáMp̹b򤣤WդUC
> : eդUMS_w switch | CSMA/CD Mo̫o@ӡäCKVסM
> : D_AԲӸѪR@UOS
> : O~|Mp̤Ob challenge M ӬOuC
> : Ʊe༷ŸѴbC¡T
> 
> LEthernet flow controlϥ٬OhC~XoӾADnO
> Ҷqinput-queuedswitchCboutput-queuedswitchAYoutput queue
> ֺFA٬OSkflow controlC(Dt~hOCoutput queueW
> frameOqportiӪAAѨporthAoS·СA]P@
> output queueframeiӦۤPportAn?) oXѦbcomp.dcom.lans.
> ethernetnewsgroupnQPAUSE frameDAAiHhݬݡC
> 



"ethan"  gl news:40hUTg$W1y@bbs.im.tku.edu.tw...
> i b pachinko.bbs@BirdNest.twbbs.org (˭l_) j@: j
> :  ޭzm"H" , ݪO: NetworknʨG
> : : MդUǫSsΤkӡqsender @~
> : ݭnDsenderO֡Cbhalf duplexUAAiu׬Y@senderAn״N
> : shared mediaتstation@סCΪkback pressureAjP
> : kG
> : (1) force collisionGݨ즳ʥ]eӤFANoӫʥ]GNcollisionCo
> :     sendero{collisionN|wƭeA]queueQ뺡piHȮɵνwC
> : (2) false carrierGSdeferralA軡AiHo@ꪺpreambleHA
> :     sender@sensecarrierAosenderN|eʥ]XӤFC
> opachinkouOӱM~F;ڷQstevenPpachinko^ڪ[M,thanX
> iOھpachinkok[Wڤe`;O_NYhalf-duplexUswitch
> buffer̵M|queuetrafficbufferF~}lback pressure.ڬݰ_ӤOo˻
> ڪDcsma/cdPflow controlOƱ;Oڪ{Obfully switchU
> YϦhalf-duplexnode(ڵooܥ`;]ܦhȤ᩹d@wsupport full-duplex)
> switchݭncollisionѨM;iHpacket buffer_;Av@Xh;Ytraffic
> ӭbufferF;Nbhalf duplexback presure,bfull duplexpause frame



--