[c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

[Lukas Tribus]

Hi Eric,



>> Right, but the packet will be double-tagged, with both S-Vlan and C-Vlan tag
>> set
>> to 243. That's redundant (that bad kind of redundancy) and doesn't seem
>> right.
>
> Please explain how this is not "right" and how you would transport VLAN 243
> on one interface to VLAN 243 on the *trunk* EFP. Maybe I'm doing this wrong
> to begin with.

Suppose you need to transport the same tagged Vlan from on port to another
on a Catalyst switch. You would do:

int gi0/1
switchport mode trunk
switchport allowed vlan 243
int g0/2
switchport mode trunk
switchport allowed vlan 243


But you don't:
int g0/1
switchport mode dot1q-tunnel
switchport access vlan 243
int g0/2
switchport mode dot1q-tunnel
switchport access vlan 243

Even though the latter works, you do the former, because it achieves exactly
what you need already. Not need to encapsulate C-Vlans (one 243) in an S-Tag
(243) here.



>> I wouldn't call it unnecessary. What I would call unnecessary is carrying
>> the same
>> tag twice through your network.
>
> I'm not carrying two tags "through" my network. This is a locally switched VLAN,
> from one interface to another.

Thats besides the point. Call it the switch backplane then.



> Other than a local xcon, how else would I transport frames between two
> interfaces on the ASR, much less between two interfaces where one is
> configured as a trunk EFP?

I'm not saying you shouldn't use the bridge-domain. I'm saying you should
pop the C-Tag.



>> It works because the configuration is the same on each side, but it would
>> strongly
>> recommend to not use such a configuration.
>
> Don't see your point.

See the Catalyst example above. If you push a tag on the ingress port
and pop a tag on the egress interface, what you get is the same packet.



> The existence of the rewrite command appears to have no difference
> on the number of tags on frames between the core and downstream routers.

I find it very strange to use EVC for the core port (now I am beginning to
understand what you are trying to do). Depending of course on what you
are trying to achieve, but if you have lets say an adjacent ASR920 box and
you have core links between the 2, unless you run MPLS on that link you
would configure them as a classic dot1q tunk, but NOT as an EVC trunk.

Do not replace dot1q core trunks with EVC trunks. EVC is for edge ports
and EVC trunks do have some advantages for use cases like an NNI to
another carrier, but that still is an edge port.



> I understand tagging and double tagging. I also connected an inline tap
> between the downstream ASR and the upstream ASR - just a single VLAN being
> passed up my core interface, as it should be and as I expected. Still don't
> know why you keep bringing up a double tag.

An EVC trunk is not a core link. To see what I mean about double tagging,
configure:

int giga0/1
 descr core link (sniffer)
 switchport mode trunk
 switchport trunk allowed vlan 243
int g0/2
 descr edge port
 service instance 1 ethernet
 encapsulation dot1q 243
 bridge-domain 243

And check out the frame on the core link.



> ** During the course of writing this, I found that yes, the rewrite is actually required for the trunk EFP to work at all:

Correct, here's the documentation about it (which is what I guessed
in the other mail):
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-3s/ce-xe-3s-book/ce-trunk-efp.html#GUID-8A4D7103-7F30-46B3-8881-109C4DB7A161


You need to see what I mean about the double-tagging to understand
why an EVC trunk without rewrite doesn't make that much sense.



Regards,

Lukas