Q-in-Q in EX switch

I have prepared a small setup to test Q-in-Q or formally known as IEEE 802.1ad. There are several names given to this technique but the ones I prefer most are Provider Bridging or Stacked VLANs but I think most common name is QinQ. Anyway, I have set up the following lab.

This is the physical setup:) but below is the topology I have set up by using these devices. I wish to add one more EX2200 to make the setup more realistic but I have spent too much for these boxes so far for my lab purposes. No new purchases in the near future:) Let’s see the topology and explain what it really does;

What do we want to achieve here? Just assume that these two switches are actually two provider edge switches in a provider network. Normally in my setup they are directly connected. Any packet we send from either side of this cloud will be tagged by the Provider TAG 1000 which literally means we will tunnel our traffic in another tagged frame. Let’s see the config from EX2200-1 side

{master:0}[edit]
root@ex2200-1# show vlans                                                   
S-VLAN1000 {
    vlan-id 1000;
    interface {
        ge-0/0/0.0;
        ge-0/0/1.0;
    }
    dot1q-tunneling {
        customer-vlans 500;  <<<<----This is actually optional. 
    }
}

root@ex2200-1# show ethernet-switching-options dot1q-tunneling 
ether-type 0x88a8;


{master:0}
root@ex2200-1# show interfaces 
ge-0/0/0 {                        <<<<<--Yes it is true that this isn't a tagged interface
    unit 0 {
        family ethernet-switching;
    }
}
ge-0/0/1 {
    unit 0 {
        family ethernet-switching {
            port-mode trunk;
        }
    }
}

SRX side doesn't have any special config. You can just configure tagged interface with the IP address given on the topology. Now we will initiate ping from SRX210 192.168.1.2 towards 192.168.1.1 and see what happens on the command line and wire.

root@srx210> ping 192.168.1.1 count 5 rapid 
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.821/2.153/3.011/0.434 ms

root@srx210> show arp no-resolve 
MAC Address       Address         Interface     Flags
88:e0:f3:0b:7c:00 192.168.1.1     ge-0/0/0.0           none   <<<----remote SRX100 MAC

Yes we can learn MAC and ping other side of the cloud. Let's see on EX2200-1 how we learned the MAC.

root@ex2200-1> show ethernet-switching table vlan 1000 
Ethernet-switching table: 2 unicast entries
  VLAN              MAC address       Type         Age Interfaces
  S-VLAN1000        *                 Flood          - All-members
  S-VLAN1000        78:19:f7:a9:97:40 Learn         45 ge-0/0/0.0
  S-VLAN1000        88:e0:f3:0b:7c:00 Learn         55 ge-0/0/1.0  <<<<---- 

{master:0}
root@ex2200-1> show ethernet-switching interfaces ge-0/0/0 detail 
Interface: ge-0/0/0.0, Index: 70, State: up, Port mode: Access
Ether type for the interface: 0x8100
VLAN membership:
    S-VLAN1000, 802.1Q Tag: 1000, dot1q-tunneled, untagged, msti-id: 0, unblocked
Number of MACs learned on IFL: 1

{master:0}
root@ex2200-1> show ethernet-switching interfaces ge-0/0/1 detail    
Interface: ge-0/0/1.0, Index: 76, State: up, Port mode: Trunk
Ether type for the interface: 0x88a8
VLAN membership:
    S-VLAN1000, 802.1Q Tag: 1000, dot1q-tunneled, tagged, msti-id: 0, unblocked
Number of MACs learned on IFL: 1

Yes, through our cloud facing interface we have learned the MAC of SRX100 device. The best part is the packet capture I took.

As you can see in the packet capture, client frame which has Vlan 500 tag is encapsulated in another frame which has provider tag 1000.

On this setup, I am not tunneling Layer 2 protocols e.g LLDP,RSTP etc but it can also be done. I am just practicing here some switching stuff not really complete post but I hope this gives some idea.