Each I-component, however, serves only one S-cloud, meaning
one set of 4094 VLANs, each with a distinct VLAN ID. Since the I-component is, for
all practical purposes, itself a provider bridge??”even playing its part in the S-cloud??™s
Spanning Tree Protocols??”its redundant connections can even connect the two halves
of an S-cloud that is split, whether intentionally or by failure. This is the case for
S-cloud 1, which is split into 1A and 1B. Thus, in Figure 13.10, I-components A, B, and
E all serve (split) S-cloud 1.
Each I-component has its own individual MAC address and can recognize certain multicast
MAC addresses. These are the outer MAC addresses shown in Figure 13.9e and f.
Interconnecting I-Components The method used by the I-components to acquire each
others??™ MAC addresses, and to use them once acquired, can best be illustrated by following
a ???day in the life of a packet???:
1. A customer frame (Figure 13.9a) is transmitted by C-S to S-cloud 2 in Figure 13.10.
2. Without worrying about whether the S-cloud knows the destination MAC address
or not, the S-cloud delivers the frame, tagged with an S-tag identifying the customer??™s
particular EVC, to I-component C, part of PEB Q.
Pages:
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895