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

Eric Van Tol eric at atlantech.net
Sat Aug 22 08:50:24 EDT 2015


> > 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
> 
> 
> Ok, I didn't know about that. So my particular example with the sniffer
> on the core link "switchport" doesn't apply to the ASR920, but that
> doesn't change anything about the EVC behavior and the point I'm trying
> to make.

It does, given the example you provided *and* the behavior you wanted me to observe (because it doesn't produce that behavior), but it doesn't matter because this whole discussion is pointless now.  My understanding of when to use rewrite was actually correct, yours is correct, and my entire issue stemmed from a missed line in the config docs that explicitly states rewrite is required on EFP trunks.  This was literally in the first bulltetpoint of the listed 'Restrictions'.

I also think that another misunderstanding from your end is that I am trying to use core ports to transport C-Vlans (in the literal sense) when in reality, this is an S-Vlan.  The ASR was acting as a "distribution" layer router, in between non-MPLS capable edge switches and MPLS-capable hardware upstream.  It's all moot now, since we were able to migrate these edge-facing EFPs to MPLS xcons directly off the ASRs last night and the EFP trunks are now gone.

Finally, I still argue that your point about not using EVC on core-facing links is incorrect *on the ASR*, because that's the only way to transport VLANs, as far as I know.  There is no other option but to use EFPs for core-facing links (no classic switchport config).  Again, if you or anyone else can provide alternative configs, I'm happy and appreciative to learn about it.

Thanks for taking the time to help educate.

-evt


More information about the cisco-nsp mailing list