Q in Q - customer ports as trunks?

[Luca]

Most of the documentation I have read about q in q says that access ports are considered to be part of the customer VLANS. I have a situation where I don't have any access ports, they are all trunks, but would like to use q in q since I will have overlapping VLAN ranges... So is it possible to have C-VLANS configured using trunks ports?

[wimclend]

if memory serves, with QinQ on the EX platform, you actually still configure the port as an Access port in the S-VLAN even though you will be receiving tagged frames.  I know that threw me off when I was trying to learn it and test it, but if you think about it it kind of makes sense, because in a QinQ environment the switch is just adding / removing the S-VLAN tag when traffic enters / exits the switch toward the customer, and doesn't care what the C-VLAN tag is

will

[Luca]

So just to confirm... is this the process?

start---Customer(VLAN500)-----C-VLAN(VLAN4001)----S-VLAN(4001)------SVLAN(4001)-----Customer(VLAN500)-----Finish

So I have a customer comming in using vlan 500, it hits the first q-in-q point where VLAN4001 is assigned.

VLAN4001 then traverses through a few service provider hops, all using VLAN4001, then goes out the last C-VLAN port where 4001 is removed and the original tag is used.

[wimclend]

I believe that should be the case, yes.

were you able to test this for your situation?  did this solve your problem?

will

[Luca]

Yes i was able to set this up successfully in a lab enviornment... it worked quite well actually

[wimclend]

one thing to caution you on -- make sure you raise the interface MTU of the QinQ 'core' interfaces to at least 1522 (though I would recommend higher just to be able to allow larger frames in the future).  I believe 1522 would be the minimum because Juniper's MTU calculation includes the L2 info (unlike Cisco I believe) -- 1500 byte payload + 14 byte MAC info + 4 byte C-VLAN Tag + 4 byte S-VLAN tag

if you do not, with simple tests like pings etc will flow fine, but 'normal' traffic that has higher frame sizes will not work properly

you can see this behavior by sending a larger ping with the DF bit set in your tests.  You want to make sure at a minimum a full-sized 1500 byte payload will go through.  at a minimum you would want to be able to send a ping with size 1472 with the DF bit set through the QinQ network from customer switch to customer switch (1472 + 8 byte ICMP header + 20 byte IP header = 1500 byte payload)

will

[Luca]

Can i configure a customer port (access port) to be a member of multiple QinQ VLANs?

I would like to be able to have some customer VLANs in one tag and others with anothe tag.  So somthing like this:

{master:0}[edit interfaces ge-0/0/26 unit 0 family ethernet-switching]
root# show
port-mode access;
vlan {
members [ s-vlan1 s-vlan2 ];
} 

root# run show configuration vlans
}
s-vlan1 {
vlan-id 4001;
dot1q-tunneling {
customer-vlans 500-600;
}
}
s-vlan2 {
vlan-id 4002;
dot1q-tunneling {
customer-vlans 10; 

[Michael Gonnason]

So you want to deliver two different circuits? Are they going to two different destinations?

[Luca]

They will be going to the same destination, but for other reaons I'd like to have them as seperate tags

[Michael Gonnason]

I have never tried it, but I guess it might work.

We typically use 1 port per circuit, and if a customer requests qinq we do the whole vlan range 1-4096 so that way they do not have to contact us to coordinate for new transit vlans.

Are you wanting to do different rate-limits or QoS classifications for each circuit?

In 10.3 documentation it states:

"An interface can be a member of multiple S-VLANs. You can map one C-VLAN to one S-VLAN (1:1) or multiple C-VLANs to one S-VLAN (N:1). Packets are double-tagged for an additional layer of segregating or bundling of C-VLANs. C-VLAN and S-VLAN tags are unique; so you can have both a C-VLAN 101 and an S-VLAN 101, for example."