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) :
Pop operation
Push operation
Translate operation
Examples
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:
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
You cannot pop a range of vlans
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.
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
is equivalent to this
Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.
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! remove two tags 7600(config-if-srv)#rewrite ingress tag pop 2 ? symmetric Tag egress packets as specified in encapsulation
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! 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
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! 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 ! 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 ! 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
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 encapsulation7600(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.
No comments:
Post a Comment