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

Lukas Tribus luky-37 at hotmail.com
Sat Aug 22 07:11:06 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.



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

Exactly. Which is why with EVC you would pop the tag, instead of encapsulating
it as is in another bridge-domain/vlan.



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

The wire never see your S-Vlans. What you see on your tap is the
C-Vlan from the other side - because you never popped it.



> Adding the 'rewrite' command makes no difference to the traffic coming
> into or going out of the interfaces. Confirmed with inline tap.

Of course you don't see any difference, because both interfaces have
the exact same bidirectional encapsulation/decapsulation.

If you look at the 2 Catalyst configurations and connect a your tap
to one of the ports, you will also see the same behavior in tagged
Vlan 243 in both configurations, although the first one makes sense
(because its exactly what you need), while the second one is overly
complicated and unnecessary for your use case.



> It's now working just fine, it's just not yet in the optimal config.

If this would be a Catalyst, would you have used the dot1q-tunnel config?
If no, then this (pop 1 tag) is exactly the config you want.



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

Agreed.



Lukas

 		 	   		  


More information about the cisco-nsp mailing list