Why using CE-VLAN ID Preservation matters in Carrier Ethernet?

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.

11 thoughts on “Why using CE-VLAN ID Preservation matters in Carrier Ethernet?”

  1. 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.

  2. Pingback: Confluence: OneControl

  3. 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.

    1. 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.

  4. 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.

  5. 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?

  6. 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

    1. 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 !

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.