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

[Eric Van Tol]

> 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

Of course, but that's a Catalyst switch, not an ASR, which does not accept switchport configuration:

ASR-1(config)#int gi0/0/15
ASR-1(config-if)#swi?
% Unrecognized command
ASR-1(config-if)#swi?
% Unrecognized command

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

This isn't the intent of the configuration.  The intent of the configuration is to transmit frames on VLAN243 on one interface to VLAN243 on another interface.  What other options are there for moving frames between interfaces on the ASR?  

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

No, that's exactly the point.  You tell me "transporting two tags through your network" and that's how it's interpreted.  It's also not what I am doing and that distinction is important.

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

Yes, if I was working on an ME3600.  I'm not on an ME3600.  Let me put it another way.  This config works fine:

int gi0/0/6
 service instance 243 eth
 encapsulation dot1q 243
 bridge-domain 243
!
int gi0/0/23
 service instance 243 eth
 encapsulation dot1q 243
 bridge-domain 243

I don't need to pop any tags with this to get traffic to flow between two interfaces on my ASR - I'm still transporting one S-VLAN out each of the interfaces, not a double-tagged S-243 C-243.  Adding the 'rewrite' command makes no difference to the traffic coming into or going out of the interfaces.  Confirmed with inline tap.

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

Again, you can't just do this on an ASR920, as far as I know.  Someone please correct me if I am wrong, but the only way to handle VLANs is by using EFPs.  It's at this point that I should mention that this configuration was meant to act as a transition config, as we were not yet ready to just dump the customer-facing EFP into an MPLS xcon on this router.  As such, the VLAN is supposed to be transported to the existing MPLS router that is upstream from the ASR920.  Regardless of that fact, I am not aware of anything "wrong" with this config, as it's the only way to get a VLAN from one interface to another (except for local xcon, which we can't do on the EFP trunk instance).  It's now working just fine, it's just not yet in the optimal config.

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

Then, again, please explain how *you* would transport VLAN 243 on one interface to VLAN 243 on another interface that is in an EFP bundle on an ASR920, not a Catalyst switch.  I'm all ears and willing to admit that I'm not an expert and there might be a different way to do this.

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

*sigh*  I don't have any experience with any other ASR model, but the 920 does not have classic 'switchport' configurations, unless it's done some other way of which I am not aware.  I am not saying you are wrong if your exact config is being put into an ME switch, just that this config is impossible on an ASR.  You can only do EFP-style configs for VLAN trunks.

> > ** 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

My brain obviously skipped over the second sentence in that link when I originally read it.  Thanks for pointing that out.

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

That's all fine and good, but given that the 'rewrite' is absolutely necessary in an EFP trunk to even get it to pass traffic, it's a moot point.

-evt