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

[Eric Van Tol]

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

> > I tested this in the lab and rewriting is unnecessary - I can pass traffic
> just fine.
> 
> 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.  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?  Maybe this is a portion I am missing, so I am happy to see how else it might be done.

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

> 
> > interface GigabitEthernet0/0/23
> > mtu 9216
> > no ip address
> > load-interval 30
> > negotiation auto
> > service instance trunk 1 ethernet
> > encapsulation dot1q 243,1958,1961,1969,1976,2305
> > bridge-domain from-encapsulation
> >
> > Then rewrite is required, for some reason
> 
> This could be either a bug or a unsupported configuration (whatever).
> However best
> practices would be to pop this tag, instead carrying it twice, which, as you
> confirmed
> does indeed work.

Docs don't say that the rewrite is explicitly required, but it doesn't say it's optional**.  Again, where are you getting that I am carrying this tag twice through my network?  The existence of the rewrite command appears to have no difference on the number of tags on frames between the core and downstream routers.

> > on both the 'local' interface (Gi0/0/6) and the core-facing interface
> (Gi0/0/23).
> 
> Obviously the configuration must match. You can't use 2 tags on one
> interface
> and one tag on the other interface and expect it to work.

Again, what is this second tag you keep mentioning?  The trunk EFP VLAN and the single instance EFP are configured the same way.  In the 'non-working' config, the configurations do match:

interface Gi0/0/6
 service instance 243 ethernet
  encapsulation dot1q 243
  bridge-domain 243
!
interface Gi0/0/23
 service instance trunk 1 ethernet
  encapsulation dot1q 243,1958,1961,1969,1976,2305
  bridge-domain from-encapsulation
!

Besides one being a trunk EFP, please point out the difference between the two configurations.  Where is the second tag here?  

> Let me recommend the following: configure a classic switchport trunk with
> those
> vlans, and connect it to a sniffer (that is able to see multiple dot1q
> tags). Check
> out what each configuration achieves. That should give you an aha effect
> about
> the PoP and not PoP configurations.

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.

> Really the "rewrite" command isn't neither complicate nor bad. 

I never said it was bad, nor did I say it was complicated.

> You are supposed to use "rewrite" more often than not in the EVC world.

And we do.  I understand what the rewrite command is for.  What I don't understand is why it's required on the trunk EFP to even see incoming frames**.  Again, the trunk EFP, unless there is something I am not getting, is essentially the same thing as configuring:

interface Gi0/0/23
 service instance 243 ethernet
  encapsulation dot1q 243
  bridge-domain 243
 !
 service instance 1958 ethernet
  encapsulation dot1q 1958
  bridge-domain 1958
 !
 service instance 1961 ethernet
  encapsulation dot1q 1961
  bridge-domain 1961
 !
!

My understanding is that it's a way to not only handle VLANs with similar attributes on an interface, but also to prevent having to write out 50 separate EFPs.

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

ASR920-1(config-if-srv)#no rew ing tag pop 1 sym
%Warning: Rewrite rule is required for traffic flow on this trunk service instance.

Maybe I missed it in the documentation, but it would be nice if someone can explain this requirement.

-evt