Ideally VLAN ID Preservation should be preserved ( CE-VLAN ID = Yes). After all, why it should matter, changing VLAN IDs. Having same VLANs IDs make it operationally efficient for both operator and customer. Operator can trace the circuit well, so can the end customer by just knowing the VLAN IDs. Not to forget that it would be easy to setup such an EVC since the VLAN ID to EVC map will be much simple in this case.
In this post I will explain that why it is needed to set VLAN Preservation ID = NO
Let’s see the example of setting VLAN Preservation ID = YES and its advantages. See the diagram 1 below, customer has two campuses with the same VLAN number 14. Obviously this situation demands that VLAN Preservation ID should be set to YES. Why asking the end customer to change VLAN IDs in the first place ?
Lets see a second scenario in which two campuses of the same customer are connected to each other but both have different VLANs. The obvious advantage here for using VLAN Preservation ID= No is to let the service provider do the switch and hence in that case the service provider will switch the VLAN ID from 15 to 14 before handing the traffic to B while the converse will be true when handing the traffic to A. This is shown in diagram 2 below.
Hello
Thank you for your post. In order to understand it better I have a questions in my mind. In the second scenario where the site A and site B are using different vlans why the service provider is required to do the switch. If the SP preserve the CE-VLAN IDs, communication between the two sites would still be possible as I believe the EVC would function like a layer 2 Trunk.
But yes if you set the bundling to Disabled or No and you want to realize the scenario B without asking the customer to renumber its VLANs, yes in that case the translation would be required but the question is why would you set the Bundling to No or Disabled when the requirements doesn’t demand so.
So I would really appreciate if someone can put a more realistic real network example that would demand a CE-VLAN ID preservation = No
in a layer 2 network, two domains can only talk to each other if they have the same vlan, if different then a router will be needed in between to do the switch. In the scenario 2 above there is no router so the only way the operator can stich the two different vlans is by doing the translation itself. In that case the vlan id preservation must be set to no. Otherwise the provider would not be able to translate the vlans between the two sites. Hope it helps !
Hello Faisal, thanks alot for your kind input. But in that case all the traffic from one vlan will be handed over to the other vlan which is a rare sight in data networks , as normally we would have occasional requirements for inter-vlan communication.
With the scenario presented above for CE-VLAN preservation= no , how would the inter and intra vlan communication occur between two vlans simultaneously?
Say for example on site A &B we have multiple vlans including 15 and 14. There is an instance where a user on site A on vlan 15 would like to communicate with someone in Vlan 14 on site B, while other users from the same vlan would like to carry on with intra vlan communication on vlan 15. With the translation on, how would this kind of communication be possible?
All the traffic will not be handed over to other vlan. The switch at Site A ( the one connected to service provider) will decide which traffic it will be pass on to the service provider and which one should stay within Site A. To the users in Site A all users in Site B will appear to on VLAN 15 and to the users in Site B all the users in Site A will appear to be on Site 14 ( because users do not know that the service provider is doing translation). Considering a user sends a traffic from Site A to a Site B and the switches have not yet built up the MAC table. That packet will be broadcasted across both VLANs ( thanks to translation by service provider). After the intended recipient from Site B responds , the switch at Site A will build up its MAC table and from then onwards it will be a unicast communication between the two. Now lets say that the destination is within domain A instead of domain B , the destination will respond and the switch now knows that it does not need to send the traffic across to service provider as this is pure intra vlan communication. So as you see both inter and intra vlan communication is possible with such setup based on simple rules of MAC learning.
Thank you Faisal. I really appreciate. It really helped.
in lieu of the discussion above it makes a perfect sense based on the simpl rules of address learning provided you have vlan 14 on one side and vlan 15 on other. But what if let’s say you have the both the vlans configured on both the switches i.e. vlans 14 and 15 on both switches at site A and site B. And lets say a user in vlan 14 on site A wants to communicate a user on vlan 14 on site B, in that case I guess it won’t work due to the translation as it would never be delivered to the correct vlan on site B.
Dear,
In such cases you don’t need any translation. as you have both vlans on either side. if user in SITE A wants to communicate with user in SITE B, probably you would set up on E-LAN kind of service between the two sites without TRANSLATION. This kind of service will make sure that any user in SITE A can talk to user in SITE A in the same VLAN or user in SITE B through E-LAN service.
Very good explaination.
First case is an applicable when more than ONE CE-VLAN IDs are mapped to an EVC (Either Bundling or All-to-One-Bundling =Yes). You must preserve it in that situation.
When exactly ONE CE-VLAN ID is mapped to an EVC (Bundling=No and All-to-One-Bundling =No) , you have choice either to preserve it or translate it.
Only ONE translation per EVC is allowed.
Thanks Azhar, I really appreciate for taking time to comment, I agree with your explanation
Thank you very much. so helpful.
I have a question about the 802.1ad standard.
I have seen 3 types of interfaces. provider-network, customer-network, and customer-edge ports.
My problem is with this customer edge port. should it be similar to the dot1q port on the customer side? for example a customer edge-hybrid port should act as a hybrid port on customer side?
Hi Mohsen, I am not sure if I understood your question properly. if you can clarify more
thanks,
Faisal
Hi Faisal,
I mean I’ve seen some kind of QinQ configuration which it’s literature isn’t dot1ad standard. for example, an interface could be configured as switchport [provider-network | customer-network | customer-edge (access | hybrid | trunk)] but I’m not sure about their functionalities especially customer edge ports. I think these types of ports are equivalent to nni and uni -c/s ports in dot1ad standard. now my question is about customer-edge ports on the customer side( I think they are similar to uni-c ports in dot1ad). Should they act as normal access, trunk, or hybrid ports there?
Thank’s for your help
Mohsen
Hi Mohsen, to my understanding they should be normal trunk ports on customer side. Sorry for very late reply
Hi Faisal,
I mean I’ve seen some kind of QinQ configuration which it’s literature isn’t dot1ad standard. for example, an interface could be configured as switchport [provider-network | customer-network | customer-edge (access | hybrid | trunk)] but I’m not sure about their functionalities especially customer edge ports. I think these types of ports are equivalent to nni and uni -c/s ports in dot1ad standard. now my question is about customer-edge ports on the customer side( I think they are similar to uni-c ports in dot1ad). Should they act as normal access, trunk, or hybrid ports there?
Thank’s for your help
Mohsen