Changes between Version 3 and Version 4 of QinqResults
- Timestamp:
- 06/28/10 13:48:25 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
QinqResults
v3 v4 10 10 QinQ can be used to "tunnel" a particular VLAN of a "customer" network through a "service" network. This is a very important concept in GENI to allow multiple "customer" VLANS to be interconnected through the VLANS of regional service providers. 11 11 12 [[Image(source:/trunk/wikifiles QinqResults/QinQOverview.jpg)]]12 [[Image(source:/trunk/wikifiles/QinqResults/QinQOverview.jpg)]] 13 13 14 14 In the image above VLAN A and VLAN B are two VLANs that span between "Network 1" and "Network 2". These networks can be at two separate sites. VLANs A & B are tunneled through the "Intermediate network" using VLAN Q. This allows the customer network VLAN usage to be independent of the Intermediate Network while still allowing the customer VLAN traffic to transverse the intermediate network. The Intermediate Network has a "separate VLAN ID space" than the two other network sites. VLAN X could be the same VLAN ID as either VLAN A or VLAN B without any collision. … … 24 24 For 802.1q VLANs and 802.ad QinQ VLANs the !EtherType is actually a "Tag Protocol Identifier (TPID)" that, along with other tagging information, is inserted after the frame's source MAC address field. As this TPID is at the same byte offset as the original !EtherType field, it is common to refer to this field as the !EtherType field when discussing VLANs. The image below illustrates this distinction. Each tag adds 4 Bytes of data to the Ethernet frame. 25 25 26 [[Image( untaggedTaggedQinqTagged.jpg)]]26 [[Image(source:/trunk/wikifiles/QinqResults/untaggedTaggedQinqTagged.jpg)]] 27 27 28 28 * See http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_EtherType_field for more information on frame types. … … 43 43 A VLAN trunk between a DUT's customer and service VLANs looks like a "jumper" cable -- a customer VLAN trunk must be created out of a customer-level switch trunk port and conencted to a service-level switch's acess port. This is a consequence of simulating multiple virtual switches within a single physical switch This jumper is shown below in the Simulated Network Topology diagram. For complete end-to-end testing Two DUT's, each configured as shown, would be connected using the respective QinQ port. 44 44 45 [[Image( SimulatedTestTopology.jpg)]]45 [[Image(source:/trunk/wikifiles/QinqResults/SimulatedTestTopology.jpg)]] 46 46 47 47 == Device Summary == … … 61 61 This section outlines the configuration steps necessary to integrate the DUTs into the BBN internal network to allow for testing and configuration. 62 62 63 [[Image( TestTopology.jpg)]]63 [[Image(source:/trunk/wikifiles/QinqResults/TestTopology.jpg)]] 64 64 65 65 The above diagram represents all major "classes" of connections that are between between physical devices. these connections are implemented as required per test. … … 95 95 It is advantageous to use the same port assignments for each DUT to ensure consistency and prevent confusion. Each DUT will have the same port assignment as shown below. This configuration allows for a single configuration to accommodate all planned testing without reconfiguration between tests. 96 96 97 [[Image( PortstwoQinQtunnels.jpg)]]97 [[Image(source:/trunk/wikifiles/QinqResults/PortstwoQinQtunnels.jpg)]] 98 98 99 99 || '''Port''' || '''Note''' || … … 132 132 Verify that a given DUT's QinQ port sends double-tagged QinQ frames in the expected format. For switches to understand that the trunking mechanism is a QinQ VLAN trunk the Ethernet's Header must contain the appropriate QinQ header field type indication (0x8a88). 133 133 134 [[Image( QinQTaggingTestOverview.jpg)]]134 [[Image(source:/trunk/wikifiles/QinqResults/QinQTaggingTestOverview.jpg)]] 135 135 136 136 '''Method''' [[BR]] … … 152 152 This test insures that the customer VLAN ID and service VLAN ID ranges are mutually exclusive. 153 153 154 [[Image( QinQExclusitivityOverview.jpg)]]154 [[Image(source:/trunk/wikifiles/QinqResults/QinQExclusitivityOverview.jpg)]] 155 155 156 156 '''Method''' [[BR]] … … 161 161 This test explores the behavior of allowing a normal VLAN trunk and a service VLAN (QinQ) trunk to be allowed on the same port. 162 162 163 [[Image( CustomerAndServiceSamePort.jpg)]]163 [[Image(source:/trunk/wikifiles/QinqResults/CustomerAndServiceSamePort.jpg)]] 164 164 165 165 '''Method''' [[BR]] … … 174 174 Verify that hosts in the same VLAN on opposite sides of a QinQ tunnel can communicate. 175 175 176 [[Image( QinQBetweenDUTs.jpg)]]176 [[Image(source:/trunk/wikifiles/QinqResults/QinQBetweenDUTs.jpg)]] 177 177 178 178 '''Method''' [[BR]] … … 209 209 If this was feasible for two DUTs this test verifies that the hosts in this VLAN on separate DUTs can communicate. 210 210 211 [[Image( CustomerAndServiceSamePortQinQ.jpg)]]211 [[Image(source:/trunk/wikifiles/QinqResults/CustomerAndServiceSamePortQinQ.jpg)]] 212 212 213 213 '''Method'''[[BR]] … … 220 220 '''VLAN Latency'''[[BR]] 221 221 222 [[Image( LatencyVlan.jpg)]]222 [[Image(source:/trunk/wikifiles/QinqResults/LatencyVlan.jpg)]] 223 223 224 224 '''QINQ Latency'''[[BR]] 225 225 As this test relies on end-to-end host connectivity over a QinQ tunnel, the setup is the same as "the test QinQ between DUTs". This diagram is included again here for completeness. 226 [[Image( LatencyQinQ.jpg)]]226 [[Image(source:/trunk/wikifiles/QinqResults/LatencyQinQ.jpg)]] 227 227 228 228 '''Method'''[[BR]] … … 236 236 This test will involve inter-VLAN traffic tunneled across a QinQ Tunnel. 237 237 238 [[Image( TwoQinQTunnelsOneVlanPerTunnel.jpg)]]238 [[Image(source:/trunk/wikifiles/QinqResults/TwoQinQTunnelsOneVlanPerTunnel.jpg)]] 239 239 240 240 '''Method'''[[BR]] … … 361 361 }}} 362 362 363 [[Image( NEC_QinQ_inner_3702_outer_667.jpg)]]363 [[Image(source:/trunk/wikifiles/QinqResults/NEC_QinQ_inner_3702_outer_667.jpg)]] 364 364 365 365 === QinQ with OpenFlow === … … 386 386 }}} 387 387 388 [[Image( NEC_VLAN128NoQinQ.jpg)]]388 [[Image(source:/trunk/wikifiles/QinqResults/NEC_VLAN128NoQinQ.jpg)]] 389 389 390 390 VLAN 128 is capable of being sent out port 1, however it's tagged type is "0x8a88" (service VLAN), "not 0x8100" (customer VLAN). This implies that the Switch on the other side of the trunk must be a service VLAN; sending the VLAN as a "normal" VLAN isn't possible in this configuration. … … 403 403 }}} 404 404 405 [[Image( NEC_SameIds_broadcast_storm.jpg)]]405 [[Image(source:/trunk/wikifiles/QinqResults/NEC_SameIds_broadcast_storm.jpg)]] 406 406 A broadcast storm was induced from a single ping packet. The image also shows the continual nesting of VLAN headers as the frame continues to loop between access and trunk ports. From this it doesn't look possible to tunnel the same customer and service VLAN using one switch. This is an artifact caused by trying to emulate, on a single physical switch, service and customer VLANS of the with the same VLAN ID bridged with an Ethernet cable. 407 407 … … 511 511 }}} 512 512 513 [[Image( HP QinQ tags.jpg)]]513 [[Image(source:/trunk/wikifiles/QinqResults/HP QinQ tags.jpg)]] 514 514 515 515 === QinQ with OpenFlow ===