[c-nsp] VPN/QOS Questions Was MPLS - 6500's

Tue May 6 00:32:18 EDT 2008

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: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Paul Stewart
> Sent: Monday, May 05, 2008 10:11 PM
> To: 'Phil Bedard'
> Cc: cisco-nsp at puck.nether.net
> 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:philxor at gmail.com]
> Sent: Monday, May 05, 2008 7:16 PM
> To: Paul Stewart
> Cc: 'Justin M. Streiner'; cisco-nsp at puck.nether.net
> 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: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin M.
> > Streiner
> > Sent: Monday, May 05, 2008 4:40 PM
> > To: cisco-nsp at puck.nether.net
> > 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  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > 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/
> 
> 
> 
> --
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3080 bytes
Desc: not available
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20080506/e3b2fa26/attachment.bin 