Changes between Version 3 and Version 4 of QinqResults


Ignore:
Timestamp:
06/28/10 13:48:25 (14 years ago)
Author:
jwilliams@bbn.com
Comment:

Updated Image macros to use files stored in svn

Legend:

Unmodified
Added
Removed
Modified
  • QinqResults

    v3 v4  
    1010QinQ 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.
    1111
    12 [[Image(source:/trunk/wikifilesQinqResults/QinQOverview.jpg)]]
     12[[Image(source:/trunk/wikifiles/QinqResults/QinQOverview.jpg)]]
    1313
    1414In 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.
     
    2424For 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.
    2525
    26 [[Image(untaggedTaggedQinqTagged.jpg)]]
     26[[Image(source:/trunk/wikifiles/QinqResults/untaggedTaggedQinqTagged.jpg)]]
    2727
    2828 * See http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_EtherType_field for more information on frame types.
     
    4343A 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.
    4444
    45 [[Image(SimulatedTestTopology.jpg)]]
     45[[Image(source:/trunk/wikifiles/QinqResults/SimulatedTestTopology.jpg)]]
    4646
    4747== Device Summary ==
     
    6161This section outlines the configuration steps necessary to integrate the DUTs into the BBN internal network to allow for testing and configuration.
    6262
    63 [[Image(TestTopology.jpg)]]
     63[[Image(source:/trunk/wikifiles/QinqResults/TestTopology.jpg)]]
    6464
    6565The above diagram represents all major "classes" of connections that are between between physical devices.  these connections are implemented as required per test.
     
    9595It 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.
    9696
    97 [[Image(PortstwoQinQtunnels.jpg)]]
     97[[Image(source:/trunk/wikifiles/QinqResults/PortstwoQinQtunnels.jpg)]]
    9898
    9999|| '''Port''' || '''Note''' ||
     
    132132Verify 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).
    133133
    134 [[Image(QinQTaggingTestOverview.jpg)]]
     134[[Image(source:/trunk/wikifiles/QinqResults/QinQTaggingTestOverview.jpg)]]
    135135
    136136'''Method''' [[BR]]
     
    152152This test insures that the customer VLAN ID and service VLAN ID ranges are mutually exclusive.
    153153
    154 [[Image(QinQExclusitivityOverview.jpg)]]
     154[[Image(source:/trunk/wikifiles/QinqResults/QinQExclusitivityOverview.jpg)]]
    155155
    156156'''Method''' [[BR]]
     
    161161This test explores the behavior of allowing a normal VLAN  trunk and a service VLAN (QinQ) trunk to be allowed on the same port.
    162162
    163 [[Image(CustomerAndServiceSamePort.jpg)]]
     163[[Image(source:/trunk/wikifiles/QinqResults/CustomerAndServiceSamePort.jpg)]]
    164164
    165165'''Method''' [[BR]]
     
    174174Verify that hosts in the same VLAN on opposite sides of a QinQ tunnel can communicate.
    175175
    176 [[Image(QinQBetweenDUTs.jpg)]]
     176[[Image(source:/trunk/wikifiles/QinqResults/QinQBetweenDUTs.jpg)]]
    177177
    178178'''Method''' [[BR]]
     
    209209If this was feasible for two DUTs this test verifies that the hosts in this VLAN on separate DUTs can communicate.
    210210
    211 [[Image(CustomerAndServiceSamePortQinQ.jpg)]]
     211[[Image(source:/trunk/wikifiles/QinqResults/CustomerAndServiceSamePortQinQ.jpg)]]
    212212
    213213'''Method'''[[BR]]
     
    220220'''VLAN Latency'''[[BR]]
    221221
    222 [[Image(LatencyVlan.jpg)]]
     222[[Image(source:/trunk/wikifiles/QinqResults/LatencyVlan.jpg)]]
    223223
    224224'''QINQ Latency'''[[BR]]
    225225As 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)]]
    227227
    228228'''Method'''[[BR]]
     
    236236This test will involve inter-VLAN traffic tunneled across a QinQ Tunnel.
    237237
    238 [[Image(TwoQinQTunnelsOneVlanPerTunnel.jpg)]]
     238[[Image(source:/trunk/wikifiles/QinqResults/TwoQinQTunnelsOneVlanPerTunnel.jpg)]]
    239239
    240240'''Method'''[[BR]]
     
    361361}}}
    362362
    363 [[Image(NEC_QinQ_inner_3702_outer_667.jpg)]]
     363[[Image(source:/trunk/wikifiles/QinqResults/NEC_QinQ_inner_3702_outer_667.jpg)]]
    364364
    365365=== QinQ with OpenFlow ===
     
    386386}}}
    387387
    388 [[Image(NEC_VLAN128NoQinQ.jpg)]]
     388[[Image(source:/trunk/wikifiles/QinqResults/NEC_VLAN128NoQinQ.jpg)]]
    389389
    390390VLAN 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.
     
    403403}}}
    404404
    405 [[Image(NEC_SameIds_broadcast_storm.jpg)]]
     405[[Image(source:/trunk/wikifiles/QinqResults/NEC_SameIds_broadcast_storm.jpg)]]
    406406A 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.
    407407
     
    511511}}}
    512512
    513 [[Image(HP QinQ tags.jpg)]]
     513[[Image(source:/trunk/wikifiles/QinqResults/HP QinQ tags.jpg)]]
    514514
    515515=== QinQ with OpenFlow ===