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

[Adam Vitkovsky]

Hi Eric,

Thank you for bringing this "new" feature/EFP type to my attention,

Reading the doc this feature addresses a specific use case where the BD ID used to bundle two or more ports/EFPs together happens to match the VLAN ID on all these ports/EFPs.

So where we used to do:

interface gigabitethernet2/0/1
service instance 1 ethernet
encapsulation dot1q 1
bridge-domain 1
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3

we can now do:

interface gigabitethernet2/0/1
service instance trunk 123 ethernet
rewrite ingress tag pop 1 symmetric
encapsulation dot1q 1 - 3
bridge-domain from-encapsulation

-and frames with dot1q tag 1 would be inserted into BD1 automatically and so forth for VLAN tags 2 and 3.
-though one would lose the COS markings in this setup
-anyways this is a specific use case as most of the times VLANs do not match in two separate access domains.


  adam

>

        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Eric Van Tol
> Sent: 22 August 2015 13:50
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASR920 Service Instance - when to 'rewrite ingress'
>
> > > 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/