It's my understanding (which may be wrong entirely), that 802.1p is only set when 802.1q VLAN encapsulation is being used. In this setup, while there are two VLANs on the customer side, they are being terminated on the CPE and they connect to the L2VPN via a single VLAN, untagged to an Ethernet over Copper L2 CPE to the transport provider. Basically, all their traffic is sent to us over a single tagged VLAN.
From: Herro91 [mailto:herr...@gmail.com] Sent: Tuesday, October 26, 2010 10:30 AM To: Eric Van Tol Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] L2VPN CoS Hi, If memory serves on the ethernet side you would need something to classify on, 802.1p bits in vlan header. Is that not an option? On the TDM side, similarly you need something to classify on. If it was frame-relay encap you have some options - DLCI, etc On Tue, Oct 26, 2010 at 9:34 AM, Eric Van Tol <e...@atlantech.net<mailto:e...@atlantech.net>> wrote: Hi all, Probably a stupid question, but if I have an Ethernet-to-Ethernet or TDM-to-Ethernet P2P L2VPN, is there a way to classify the layer 3 traffic contained within it and schedule/queue based upon that traffic? For instance, customer is running some voice across their L2VPN and they want to give strict priority to that traffic - is that possible? I've been messing around some with the EXP rewrite rules and have yet to come up with a configuration that will rewrite the EXP bit using DSCP values. My feeling is that it isn't going to work, because it's L2, after all, and I will be stuck with 802.1p values to work with, which won't really work for me. Thanks, evt _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
