[c-nsp] Matching all MPLS traffic for a class map

[Temkin, David]

For the tunnel, are you saying place it in there and then match on the
egress interface to set the exp bits?   

> -----Original Message-----
> From: Temkin, David 
> Sent: Tuesday, August 03, 2004 12:21 PM
> To: 'Oliver Boehmer (oboehmer)'; Rodney Dunn (rodunn)
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Matching all MPLS traffic for a class map
> 
> I'm trying this on a 7505/RSP4 and a 7204vxr/NPE-400, both 
> running 12.0.28S  - that might explain the differences in 
> what we're seeing...
> 
> I suppose stuffing it into the tunnel would work, though 
> that's adding extra complexity I was trying to avoid :-)
> 
> 
> 
> > -----Original Message-----
> > From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> > Sent: Tuesday, August 03, 2004 12:14 PM
> > To: Temkin, David; Rodney Dunn (rodunn)
> > Cc: cisco-nsp at puck.nether.net
> > Subject: RE: [c-nsp] Matching all MPLS traffic for a class map
> > 
> > Temkin, David <mailto:temkin at sig.com> wrote on Tuesday, August 03, 
> > 2004
> > 5:46 PM:
> > 
> > > Also, just tried setting it on the pvp... Because it's a
> > l2transport
> > > PVP, it doesn't allow it:
> > 
> > which IOS and platform are you using? I just tried on a GSR with
> > 4OC3X/ATM-IR-SC:
> > 
> > r(config-if)#int atm9/2
> > r(config-if)#no shut
> > r(config-if)#atm pvp 3 l2transport
> > r(cfg-if-atm-l2trans-pvp)#?
> > ATM L2transport VP configuration commands:
> >   cbr             Configure Constant Bit Rate (CBR) Service
> >   cell-packing    ATM Cell packing
> >   default         Set a command to its defaults
> >   exit            Exit from ATM L2transport VP Configuration Mode
> >   no              Negate a command or set its defaults
> >   service-policy  Attach a policy-map to a VP
> >   ubr             Configure Unspecified Bit Rate (UBR) Service
> >   vbr-nrt         Configure Variable Bit Rate Non-Realtime (VBR-NRT)
> > Service
> >   vbr-rt          Configure Variable Bit Rate Realtime 
> > (VBR-RT) Service
> >   xconnect        Xconnect commands
> > 
> > r(cfg-if-atm-l2trans-pvp)#       
> > 
> > 
> > as for your other question:
> > 
> > you can stuff the LSP into a TE tunnel using the pw-class config:
> > 
> > pseudowire-class my-pvp-class
> >  encapsulation mpls
> >  preferred-path interface Tunnel0 [disable-fallback]
> > 
> > 	oli
> > 
> > > 
> > >> -----Original Message-----
> > >> From: Temkin, David
> > >> Sent: Tuesday, August 03, 2004 11:41 AM
> > >> To: 'Oliver Boehmer (oboehmer)'; Rodney Dunn (rodunn)
> > >> Cc: cisco-nsp at puck.nether.net
> > >> Subject: RE: [c-nsp] Matching all MPLS traffic for a class map
> > >> 
> > >> Any suggestions on how to map something like that into a
> > tunnel?  I
> > >> can't think of how I'd do that for something locally 
> originated on 
> > >> the router...
> > >> 
> > >>> -----Original Message-----
> > >>> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> > >>> Sent: Tuesday, August 03, 2004 10:34 AM
> > >>> To: Temkin, David; Rodney Dunn (rodunn)
> > >>> Cc: cisco-nsp at puck.nether.net
> > >>> Subject: RE: [c-nsp] Matching all MPLS traffic for a class map
> > >>> 
> > >>> 
> > >>>> My issue is that the traffic that's going in there isn't
> > IP, it's
> > >>>> AToM (VP mode) and it's not in a tunnel so I can't set an 
> > >>>> experimental bit on it apparently...
> > >>> 
> > >>> just configure an MQC service-policy inbound within your
> > pvp and set
> > >>> exp-bits in your class-default, then match on these
> > exp-bits as PHB
> > >>> along the path. should work. or you stuff your PVP LSP into a 
> > >>> TE-tunnel and set the exp-bits there..
> > >>> 
> > >>> 	oli
> > >>> 
> > >>> 
> > > 
> > > IMPORTANT: The information contained in this email and/or its 
> > > attachments is confidential. If you are not the intended 
> recipient, 
> > > please notify the sender immediately by reply and
> > immediately delete
> > > this message and all its attachments.  Any review, use,
> > reproduction,
> > > disclosure or dissemination of this message or any 
> attachment by an 
> > > unintended recipient is strictly prohibited.  Neither this
> > message nor
> > > any attachment is intended as or should be construed as an offer, 
> > > solicitation or recommendation to buy or sell any 
> security or other 
> > > financial instrument.  Neither the sender, his or her
> > employer nor any
> > > of their respective affiliates makes any warranties as to the 
> > > completeness or accuracy of any of the information 
> contained herein 
> > > or that this message or any of its attachments is free of
> > viruses.   
> > 
> >