Sunday, June 28, 2009

EVC : Flexible VLAN Tag Rewrite

Following the previous post about Flexible Frame Matching, this new post describes the second major step in configuring service instances using the EVC framework : Flexible VLAN Tag Rewrite.

Each service instance can change the existing VLAN tag to be a new VLAN tag by adding, removing, or translating one or two VLAN tags. Flexible VLAN tag rewrite includes 3 main operations :

1) pop (remove an existing tag)
2) push (add a new tag)
3) translate (change one or two tags to another one or two tags) - this can be seen as a combination of pop and push operations

Theoretically, any existing combination of one or two VLAN tags can be changed to any new combination of one or two VLAN tags by just using a simple (as soon as you get the idea) line of configuration. Practically, there are some limitations what you'll see below.

These are the relevant CLI options under the service instance (you need first to have configured flexible frame matching for these to appear) :

7600(config-if-srv)#rewrite ingress tag ?
pop        Pop the tag
push       Rewrite Operation of push
translate  Translate Tag


Pop operation
7600(config-if-srv)#rewrite ingress tag pop ?
1  Pop the outermost tag
2  Pop two outermost tags

! remove one tag
7600(config-if-srv)#rewrite ingress tag pop 1 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>

! remove two tags
7600(config-if-srv)#rewrite ingress tag pop 2 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>


Push operation
7600(config-if-srv)#rewrite ingress tag push ?
dot1q  Push dot1q tag

! add one tag
7600(config-if-srv)#rewrite ingress tag push dot1q ?
<1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 ?
second-dot1q  Push second dot1q tag
symmetric     Tag egress packets as specified in encapsulation
<cr>

! add two tags
7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q ?
<1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q 30 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>


Translate operation
7600(config-if-srv)#rewrite ingress tag translate ?
1-to-1  Translate 1-to-1
1-to-2  Translate 1-to-2
2-to-1  Translate 2-to-1
2-to-2  Translate 2-to-2

! remove one tag and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 20 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>

! remove one tag and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 1-to-2 dot1q 20 second-dot1q 30 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>

! remove two tags and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 2-to-1 dot1q 20 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>

! remove two tags and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 2-to-2 dot1q 20 second-dot1q 30 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>


Examples
interface GigabitEthernet1/2
!
service instance 10 ethernet
encapsulation dot1q 10
! remove one tag (10) on ingress
! add one tag (10) on egress
rewrite ingress tag pop 1 symmetric
!
service instance 20 ethernet
encapsulation dot1q 10 second-dot1q 20
! remove two tags (10/20) on ingress
! add two tags (10/20) on egress
rewrite ingress tag pop 2 symmetric
!
service instance 30 ethernet
encapsulation dot1q 30
! add one tag (300) on ingress
! remove one tag (300) on egress (if the resulting frame doesn't match tag 30, it's dropped)
rewrite ingress tag push dot1q 300 symmetric
!
service instance 40 ethernet
encapsulation dot1q 40
! add two tags (400/410) on ingress
! remove two tags (400/410) on egress (if the resulting frame doesn't match tag 40, it's dropped)
rewrite ingress tag push dot1q 400 second-dot1q 410 symmetric
!
service instance 50 ethernet
encapsulation dot1q 50 second-dot1q 1-4094
! remove one tag (50) and add one new tag (500) on ingress
! remove one tag (500) and add one new tag (50) on egress
! the inner tags (1-4094) remain unchanged
rewrite ingress tag translate 1-to-1 dot1q 500 symmetric
!
service instance 60 ethernet
encapsulation dot1q 60
! remove one tag (60) and add two new tags (600/610) on ingress
! remove two tags (600/610) and add one new tag (60) on egress
rewrite ingress tag translate 1-to-2 dot1q 600 second-dot1q 610 symmetric
!
service instance 70 ethernet
encapsulation dot1q 70 second-dot1q 100
! remove two tags (70/100) and add one new tag (700) on ingress
! remove one tag (700) and add two new tags (70/100) on egress
rewrite ingress tag translate 2-to-1 dot1q 700 symmetric
!
service instance 80 ethernet
encapsulation dot1q 80 second-dot1q 200
! remove two tags (80/200) and add two new tags (800/810) on ingress
! remove two tags (800/810) and add two new tags (80/200) on egress
rewrite ingress tag translate 2-to-2 dot1q 800 second-dot1q 810 symmetric


There are some important things to keep in mind when configuring Flexible VLAN Tag Rewrite.

1) You have to use the "symmetric" keyword, although the CLI might not give you this impression:

7600(config-if-srv)#rewrite ingress tag pop 1 ?
symmetric  Tag egress packets as specified in encapsulation
<cr>

7600(config-if-srv)#rewrite ingress tag pop 1
Configuration not accepted by the platform
7600(config-if-srv)#rewrite ingress tag pop 1 symmetric
7600(config-if-srv)#


Generally rewrite configurations should always be symmetric. Whatever rewrites are on the ingress direction, you should have the reverse rewrites on the egress direction for the same service instance configuration. So, if you pop the outer VLAN tag on ingress direction, then you need to push the original outer VLAN tag back on the egress direction for that same service instance. All this is done automatically by the system when using the "symmetric" keyword. Have a look at the examples included above and check the comments to see what operations are happening on ingress and egress.

2) Due to the mandatory symmetry, some operations can only be applied to a unique tag matching service instance (so they are not supported for VLAN range configurations) or cannot be applied at all.

i.e.
You cannot translate a range of vlans
7600(config-if-srv)#encapsulation dot1q 10 - 20
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 30 symmetric
Encapsulation change is not logically valid.


You cannot pop a range of vlans
7600(config-if-srv)#encapsulation dot1q 10 second-dot1q 20,30
7600(config-if-srv)#rewrite ingress tag pop 2 symmetric
Encapsulation change is not logically valid.


If supposedly you could do the above, how could the opposite be done? i.e. if the system removed the tags from frames matching inner vlans 20,30 on the ingress, how would the system know on which frames to add 20 and on which to add 30 on the egress?

Of course you can push a new vlan over a range of vlans.
7600(config-if-srv)#encapsulation dot1q 10-20
7600(config-if-srv)#rewrite ingress tag push dot1q 30 symmetric


You can only push one or two tags for "encapsulation untagged" and "encapsulation default". No pop or translate operations are supported.

As a rule you can think of "you cannot pop or translate something that is not specifically defined as a single unit". Just imagine what would happen in the opposite direction and everything should become clear.

Keep in mind that some configurations might be accepted, but they won't work.

3) You cannot have more than one VLAN tag rewrite configuration under a single service instance. That means you can have either none or one. If there is no VLAN tag rewrite configuration, the existing VLAN tag(s) will be kept unchanged. If you need more than one, you might want to try to create more service instances using more specific frame matching criteria on each one. The translate operation might also seem useful in such conditions.

4) You need to be extra careful when using Flexible VLAN Tag Rewrite and Bridge Domains. Flooded (broadcast/multicast/unknown unicast) packets will get dropped by the service instances that do not agree on the egress tag. Although all service instances under a common bridge domain will get the flooded frame, there is an internal validation mechanism that checks whether the result of egress rewrite (based on the opposite of ingress rewrite) will allow the flooded frame to pass. The push operations under the examples show this behavior.

5) To have an EVC based port act like a L2 802.1q trunk port, you need to remove the outer tag manually and then put it under a bridge domain. On normal L2 switchports this is done automatically by the system.

So this
interface Gi1/1
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10

is equivalent to this
interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10

Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.

13 comments:

  1. Very interesting articel. Was looking for this since the Cisco doumentation that I have found isn't the most describing.

    Was on my way requesting a little information about this when I was reading the first EVC post.

    In the EVC post about frame matching it's a exampel when you "connect" (with xconnect) a service instance to MPLS.
    Is that required or can a service instance work in just a flat layer 2 network ?

    Is it possible to have a switch doing dot1q-tunneling and sending double-tagged frames to a 6500/7600 with ES20 and then doing the vlan translation with that switch/router ?

    ReplyDelete
  2. The post is really awesome. But could you tell me how it would be help in live network or its deployment scenario.

    ReplyDelete
  3. @zlobb,
    You can use the service instance to make a point-to-point L2 connection between 2 ports on the same box, or put it under a bridge domain for the usual native L2 bridging between multiple ports. The most interesting part is that you can aggregate multiple services into the same transport vc. Btw, my next post will be about the available service mappings.

    Regarding your last question, on the ES/ES+ cards (supported only on 7600; btw, ASR9000 has cards with similar features) you can do almost everything with vlan tags, so, unless you fall into one of the limitations referenced on my post, you'll be able to do vlan translation without any problem.


    @shivlu jain,
    You can use the EVC framework on many different scenarios, but it's becoming like a de facto on Cisco's proposed IP NGN Carrier Ethernet design solution. If you search CCO for Carrier Ethernet you'll find a lot of references.

    ReplyDelete
  4. hello... hapi blogging... have a nice day! just visiting here....

    ReplyDelete
  5. I am assuming ES20/40 cards only, not SIP cards ??

    ReplyDelete
  6. Although i'm not 100% sure, i believe the EVC infrastructure applies to some SIP cards too, i.e. SIP-400 and V2 SPAs.

    http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/configuration/7600series/76cfgeth.html#wp1212735

    ReplyDelete
  7. sure is, V2 SPA restriction but it is supported !!

    Thanks mate, owe you a beer - great write up !!

    (our lab had a V1 SPA, hence the disappointment)

    ReplyDelete
  8. Hello, wonderful post. so just wanted to confirm that these 2 service instances below cannot send frames to each other, due to mismatch tags on ingress and egress direction. So, a frame coming in on SI 1 with dot1q 20, becomes 10,20 but will not be able to be flooded out service instance 2 because the tag confiured there is dot1q 30. Is that correct?
    Any idea, why they don't allow different ingress and egress tags?

    service instance 1
    encap dot1q 20
    rewrite ingress push 10
    bridge-domain 10

    service instance 2
    encap dot1q 30
    bridge-domain 10

    ReplyDelete
  9. Petr, frames under a common bridge-domain will be flooded to all services instances belonging to this bridge domain, but eventually they will be dropped by the internal validation. So, indeed frames from SI 1 cannot pass to SI 2.
    You can possibly use the translate operation in order to achieve what you're looking for, as long as you keep an eye on some L2 protocols that carry tag information too (i.e. PVST+).

    ReplyDelete
  10. Hi Tassos,

    Below config doesn't work in my MPLS PE which is done in a SPA-2X1GE-V2 on 7600-SIP-400 (IOS - 12.2(33) SRD)

    service instance 155 ethernet
    encapsulation dot1q 155
    rewrite ingress tag translate 1-to-1 dot1q 156 symmetric
    bridge-domain 10

    !

    service instance 156 ethernet
    encapsulation dot1q 156
    bridge-domain 10
    !
    End
    !
    bridge-domain 10
    !
    bridge irb


    Hope you could help me out..

    Chaminda

    ReplyDelete
  11. Hello everybody, hope everything is fine. Great post Tassos, but i have got some issues trying to configure hair pinning using one physical interface and different service instances under it.
    Here is the scenario...
    Two nodes are connected to a Catalyst 3750 ME switch on two physical interfaces with different vlans(60,80 respectively) and GigabitEthernet port on the switch configured as trunk connected to 7604, but local connect does not work between instances.
    Here is the configuration of 7603



    interface GigabitEthernet4/0/0
    service instance 1 ethernet
    encapsulation dot1q 60
    rewrite ingress tag pop 1 symmetric

    service instance 2 ethernet
    encapsulation dot1q 80
    rewrite ingress tag pop 1 symmetric



    connect eline-3 GigabitEthernet4/0/0 1 GigabitEthernet4/0/0 2


    I just want to get some clarification about the above described issue, any help would be appreciated.
    Thanks in advance.

    ReplyDelete
  12. i have a Question, can we have two different interfaces on two routers but one port is single vlan tag and second is in qinq. in this case how will be the configuration, ofcourse here im talking about l2VPN ( EOMPLS) circuit

    ReplyDelete

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.