Yes, no. Quality of Service Options on GRE Tunnel Interfaces:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080 17405e.shtml Quality of Service - qos pre-classify command: http://www.cisco.com/en/US/docs/routers/access/3200/software/configuration/g uide/M032qos.html#wp1077010 Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 > -----Original Message----- > From: Paul Stewart [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 06, 2008 11:41 AM > To: Fred Reimer; 'Phil Bedard' > Cc: [email protected] > Subject: RE: [c-nsp] VPN/QOS Questions Was MPLS - 6500's > > Thanks very much - I find this interesting for sure. > > There is already GRE/IPSec tunnels up between these locations - it's > the > added element of voice that has driven me in several different > directions ;) > > So if I read this correctly, it's possible to classify the voice > packets > inside of the existing VPN in place and maintain QOS so when it hits > congestion we can give voice a high precedence? Does it matter that > this is > currently GRE based? > > If this is correct, I just need to do some digging up on cisco.com > > Thanks, > > Paul > > > -----Original Message----- > From: Fred Reimer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 06, 2008 12:32 AM > To: Paul Stewart; Phil Bedard > Cc: [email protected] > Subject: RE: [c-nsp] VPN/QOS Questions Was MPLS - 6500's > > The VoIP packets should be marked normally at the ingress port to the > network. This is most likely the port on the switch that the phone is > plugged into, or on the switch the router is plugged into. You may > find it > difficult to classify and mark traffic on the (sub) interfaces on which > you > configure the xconnects for L2TPv3 because the router treats them as > layer-2 > interfaces (i.e., you can't assign an IP address to them, etc). With > the > VoIP properly marked before they get to the router, as they should be, > you > can use the tos reflect feature to copy the TOS bytes of the packets > coming > into the router (even though they are treated as "layer-2" packets) to > the > L2TPv3 header that is sent out the router. The resulting L2TPv3 > encapsulated traffic can be queued just like any other traffic. > > One note, you say you need to create VPN's. The P in VPN is Private; > L2TPv3 > provides no encryption of the packets. If you need a private network > you > should use IPsec. You can use qos preclassify in order to classify the > packets before they are encapsulated; providing a similar feature as > tos > reflect does with L2TPv3. > > It sounds to me like you just want to setup IPsec VPN's. You can put > the > voice and data into the same tunnel, and with qos preclassify have the > marking on the IPsec header reflect the QoS you want the packet treated > with. I don't see the need for MPLS here. At 5Mbps max rate there are > a > ton of options as far as what hardware to select. > > Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS > Senior Network Engineer > Coleman Technologies, Inc. > 954-298-1697 > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:cisco-nsp- > > [EMAIL PROTECTED] On Behalf Of Paul Stewart > > Sent: Monday, May 05, 2008 10:11 PM > > To: 'Phil Bedard' > > Cc: [email protected] > > Subject: [c-nsp] VPN/QOS Questions Was MPLS - 6500's > > > > 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
