[c-nsp] Port-based EoMPLS treatment of l2protocol packets

[Jason Lixfeld]

End-to-end port-based eompls shouldn't care about tunneled PDUs coming in on a customer facing port, should it?

Or are you referring to a non-eompls environment on at least one of the customer-facing ends? (ie: dot1q-tunnel + forwarding | tunneling of whatever L2 BPDUs might be supported by that port)

Sent from my iPhone

> On Feb 5, 2014, at 5:17 PM, Saku Ytti <saku at ytti.fi> wrote:
> 
>> On (2014-02-05 16:09 -0500), Jason Lixfeld wrote:
>> 
>> Would it be fair to say that the way a port-based EoMPLS port treats l2protocol packets is essentially the same as if someone were to configure l2protocol forward?  That is, the packets are just forwarded along the PW unprocessed.  Whereas l2protocol tunnel (like on an ME3400) will rewrite the destination MAC making it incompatible with a 'forward'ed l2protocol packet?
> 
> Correct.
> 
> MAC rewrite is only needed if between end points there would be L2 switches,
> which, without mac rewrite would terminate the BPDU.
> With end-to-end MPLS, there is no reason to use it.
> 
> There is reason not to use it though, it is not fully transparent, as if you
> receive 'tunneled' frame from client side, you'll go to 'errdisable' mode. So
> your product towards customers should specify that this and that MAC address
> are not allowed or supported by your product.
> 
> 
> -- 
>  ++ytti
> _______________________________________________
> 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/