Similarly, customer
cloud 2 decides that the odd-numbered VLANs will pass through F-H and the even
VLANs will use E-G. Both customer clouds inform the provider??™s C-components of this
decision via MVRP. Each of the C-components, which learn only the odd-numbered
VLANs are needed (bridges C and F in Figure 13.13), knows from this that S-VLAN
20 is not needed by that S-component, since none of its constituent VLANs are being
delivered through that C-component. The C-component can signal through the provider
cloud using the provider??™s MVRP. Bridges C and F are pruned from the tree for S-VLAN
20, and bridges D and G are pruned from the tree for S-VLAN 21. Thus, these two
S-VLANs, 20 and 21, each become point-to-point, instead of four-point, VLANs.
Among the results of using bridge gateways are
?– None of the provider bridges in this example need to learn any of the customer??™s
MAC addresses. (Of course, if there were three client clouds sharing a 3-UNI EVC,
learning in the provider network would be needed.)
?– A failure or restoration in the interior of the server (provider) cloud does not cause
any activity in either of the client (customer) clouds??™ spanning trees.
Pages:
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916