Cisco has some mechanisms for setting the DSCP on the L2TPv3 frames based on the incoming CoS bits. I'm not sure about widespread model support but I imagine it's supported on the VXR.
More info here: http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/tnl_mrkg_l2tpv3_tnls.html Phil On May 5, 2008, at 10:11 PM, Paul Stewart wrote: > Oops.. overlooked it in the software advisor. According to Cisco.com > l2tpv3 > is supported even in the 1811's... > > So, what QOS levels can I invoke with l2tpv3 if the packets are > tunneled? > In other words, is there a way to mark voice packets inside of l2tpv3 > tunnels across a core network to another location? > > Here's a scenario on where the MPLS thoughts came from: > > Location A - Cisco 1811, two subnets inbound to the router > internally - one > voice and one data. > > Location B - Cisco 1811, two subnets inbound to the router > internally - one > voice and one data. > > The data portions need to be joined via VPN (currently using GRE/ > IpSec). > Each site has public Internet access via NAT. The voice portions > need to be > joined on a VPN basis also. I want the voice portions to have dscp > bits set > (could mark via NBAR?) so that on the transport side we can > prioritize. > Each site has 5 Mb/s of layer3 connectivity so congestion will > definitely > occur at times. > > In between each site is some 6500's (hence my questions on MPLS with > 6500's) > running Sup2/MSFC2 functioning as distribution routers. To do this > properly > I keep coming back to an MPLS solution that we don't have today... > our > other option is to convert a bunch of gear and make each site a > trunked > layer2 connection but rather avoid that if possible... > > Open to ideas... thanks folks.. > > Paul > > > -----Original Message----- > From: Phil Bedard [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 7:16 PM > To: Paul Stewart > Cc: 'Justin M. Streiner'; [email protected] > Subject: Re: [c-nsp] MPLS - 6500's > > You may want to look at L2TPv3 unless you really need TE features. > It's supported on more platforms and supported in non 'T' train > releases. > > Phil > > > On May 5, 2008, at 4:52 PM, Paul Stewart wrote: > >> Thanks... >> >> So if someone wanted to build a low traffic volume, "bare bones" MPLS >> network could they not use: >> >> Cisco 7206VXR-NPE-G1 for P router >> Cisco 3825 or 2821 for PE router >> >> This would give you every MPLS feature but VPLS specifically or am I >> way >> off? Why I bring this up is that in this particular case there is >> still the >> Sup2/MSFC2 6500's in the middle but they could remain in the middle >> just as >> layer2 devices connecting the above devices together at layer3 as >> MPLS >> devices right? >> >> This particular project *could* use some of the TE and QOS features >> in MPLS >> but total traffic might be 10Mb/s on a peak hence why upgrading the >> 6500's >> would not make sense but adding some gear "around" them might work >> just >> fine...?? >> >> Thanks, >> >> Paul >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Justin M. >> Streiner >> Sent: Monday, May 05, 2008 4:40 PM >> To: [email protected] >> Subject: Re: [c-nsp] MPLS - 6500's >> >> On Mon, 5 May 2008, Paul Stewart wrote: >> >>> With a 6500 Catalyst, regular line cards, and Sup720-3BXL - what >>> can you >> NOT >>> do with MPLS on these chassis? Is it "just" VPLS that requires an >>> OSM >> card >>> or a FlexWAN card for example? >>> >>> We are working on a project where MPLS may come into play .. VPLS >>> would be >> a >>> nice option to throw in but not 100% necessary. Today, these are >>> 6500's >>> with Sup2/MSFC2 which I'm told are pretty much useless for anything >>> MPLS >>> oriented.... >> >> I'm not sure about MPLS limitations in the Sup2/MSFC2, but it >> wouldn't >> surprise me if they're pretty major since those engines are much more >> software driven and have substantially lower forwarding capabilities >> than >> the Sup720/3BXL. The 3BXL does MPLS just fine, but I'm not running >> it in >> a 'true' service provider environment. We run MPLS using LDP to >> distribute labels to some non-Cisco gear and terminate Martini >> tunnels and >> that seems to work pretty cleanly, although the hair-pinning needed >> to >> land a Martini tunnel is somewhat strange... >> >> jms >> _______________________________________________ >> 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/ > > > > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.8/1415 - Release Date: > 5/5/2008 > 6:01 AM > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
