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

Tue May 6 12:47:15 EDT 2008

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:paul at paulstewart.org]
> Sent: Tuesday, May 06, 2008 11:41 AM
> To: Fred Reimer; 'Phil Bedard'
> Cc: cisco-nsp at puck.nether.net
> 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:freimer at ctiusa.com]
> Sent: Tuesday, May 06, 2008 12:32 AM
> To: Paul Stewart; Phil Bedard
> Cc: cisco-nsp at puck.nether.net
> 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: 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/13320793/attachment.bin 