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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
