From: Rich Collins (nilsi2002@gmail.com)
Date: Thu Nov 20 2008 - 20:49:21 ARST
Hi Antonio,
Actually I was using your mini-scenario MPLS VPN QoS (Uniform Mode)
and rewriting the precedence to EXP. The debug mpls packet will
display it as CoS
CE1 - PE1 - P1 - P2 - P3- PE2- CE2
ping from CE1 (precedence set to 5), P1 marks it down to 3
In my output below you will see some return traffic mixed in.
Here when I DO NOT activate "debug mpls packet" on P1. - It works all
as expected.
debug mpls packet on P2
*Mar 1 00:12:53.039: MPLS: Se1/0: recvd: CoS=3, TTL=253, Label(s)=18/24
*Mar 1 00:12:53.039: MPLS: Se1/1: xmit: CoS=3, TTL=252, Label(s)=18/24
*Mar 1 00:12:53.343: MPLS: Se1/1: recvd: CoS=3, TTL=253, Label(s)=19/23
*Mar 1 00:12:53.343: MPLS: Se1/0: xmit: CoS=3, TTL=252, Label(s)=19/23
*Mar 1 00:12:53.947: MPLS: Se1/0: recvd: CoS=3, TTL=253, Label(s)=18/24
*Mar 1 00:12:53.947: MPLS: Se1/1: xmit: CoS=3, TTL=252, Label(s)=18/24
I also do a tcpdump on the P1 to P2 interface.
17:38:36.729265 MPLS (label 18, exp 3, ttl 253) (label 24, exp 5, [S],
ttl 254), IP, length: 111
17:38:37.634277 MPLS (label 18, exp 3, ttl 253) (label 24, exp 5, [S],
ttl 254), IP, length: 111
NOW
Here when I activate "debug mpls packet" on P1.
debug mpls packet on P2
*Mar 1 00:18:26.699: MPLS: Se1/0: recvd: CoS=5, TTL=253, Label(s)=18/24
*Mar 1 00:18:26.699: MPLS: Se1/1: xmit: CoS=5, TTL=252, Label(s)=18/24
*Mar 1 00:18:27.003: MPLS: Se1/1: recvd: CoS=5, TTL=253, Label(s)=19/23
*Mar 1 00:18:27.003: MPLS: Se1/0: xmit: CoS=5, TTL=252, Label(s)=19/23
*Mar 1 00:18:27.303: MPLS: Se1/0: recvd: CoS=5, TTL=253, Label(s)=18/24
*Mar 1 00:18:27.303: MPLS: Se1/1: xmit: CoS=5, TTL=252, Label(s)=18/24
I also do a tcpdump on the P1 to P2 interface. (No marking down was done)
17:44:10.395041 MPLS (label 18, exp 5, ttl 253) (label 24, exp 5, [S],
ttl 254), IP, length: 111
17:44:12.204094 MPLS (label 18, exp 5, ttl 253) (label 24, exp 5, [S],
ttl 254), IP, length: 111
Rgds,
Rich
On Thu, Nov 20, 2008 at 3:54 PM, Antonio Soares <amsoares@netcabo.pt> wrote:
>
> Well, i've seen this problem before. I made a little search with Bug Tookit and found this:
>
> ++++++++++++++++++++++++++++++++++
> CSCse78533 Bug Details
>
> Debug mpls packet shows incorrect label stack
>
> Symptom:
> Debug mpls packets shows bogus label stack.
>
> Conditions:
> When debug mpls packets is turned on.
>
> Workaround:
> Do not run debug mpls packets.
>
> Related Bug Information
>
> Printing incorrect label information in mpls debug
>
> Symptom: When MPLS Traffic is sent over a TE Tunnel, the debug output produced using the command debug mpls packet produces
> incorrect information about the label stack.
>
> Workaround: There is no workaround.
>
> ++++++++++++++++++++++++++++++++++
>
> I saw this problem in scenarios without MPLS TE.
>
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S)
> amsoares@netcabo.pt
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Pavel Bykov
> Sent: quinta-feira, 20 de Novembro de 2008 20:04
> To: Rich Collins
> Cc: Con Spathas; ccielab@groupstudy.com
> Subject: Re: MPLS EXP remarking
>
> Since CEF is the mechanism that is working with tags, I expect FIB/LFIB to do the tag bidding.
> When you debug, then it has to be process switched, so that might be responsible.
>
> What I was thinking of though, is the exact output of debug command. Is it really EXP or CoS? Because since you are using VLANs, it
> could just refer to cos markings.
> Are you setting CoS as well? Can you try setting CoS?
>
> On Thu, Nov 20, 2008 at 5:20 PM, Rich Collins <nilsi2002@gmail.com> wrote:
>
> > Hello,
> >
> > I just tried a very similar scenario to yours (Uniform mode) with dynamips.
> >
> > If I turned on "debug mpls packet"on P1 (where the match and rewrite
> > of the EXP occurs) then the policy maps/service policies wouldn't
> > work. It confused me because I had seen some increment in the
> > counters but that was from the time before I had activated the debug.
> > So it worked properly after turning off this debug and observing
> > further along in the P core such as on your R4 (enabling debug mpls
> > packet here).
> >
> > Is there some caveat when using "debug mpls packet"?
> >
> > -Rich
> >
> >
> >
> > On Mon, Nov 17, 2008 at 11:40 AM, Con Spathas
> > <ccie19226@googlemail.com
> > >wrote:
> >
> > > Gday,
> > >
> > > I think I'm missing something quite fundamental here but I can't
> > > seem to find the reason why...
> > >
> > > I have the following setup:
> > >
> > > R1 (CE) - R2 (PE) - R3 (P) - R4 (P) - R5 (PE) - R6 (CE)
> > >
> > > R2 is matching ICMP inbound from R1 and marking it MPLS EXP 4
> > > R3 is matching MPLS EXP 4 from R2 and remarking it to MPLS EXP1
> > >
> > > I see that is happening when I debug on R4 (the COS=4 on the XMIT is
> > > the VPN
> > > label) which is what I expect as R5 is currently sending implicit
> > > null to R4.
> > > If I configure R5 to advertise explicit null in LDP, the debug
> > > output changes correctly and the xmit CoS = 1. Anyhow that's not my
> > > issue - just background info.
> > >
> > > R4
> > > *Mar 1 02:40:51.859: MPLS: Et0/0.34: recvd: CoS=1, TTL=253,
> > Label(s)=19/21
> > > *Mar 1 02:40:51.863: MPLS: Et0/0.45: xmit: CoS=4, TTL=252,
> > > Label(s)=21
> > >
> > > The bit that is eluding my understanding is the output on R3.
> > >
> > > R3
> > > *Mar 1 00:10:59.075: MPLS: Et0/0.23: recvd: CoS=4, TTL=254,
> > Label(s)=17/21
> > > *Mar 1 00:10:59.079: MPLS: Et0/0.34: xmit: CoS=4, TTL=253,
> > Label(s)=19/21
> > >
> > > I can't work out why the xmit is showing the CoS=4 - even though R4
> > > does receive it as CoS=1 ? I expected on R3 to see CoS=1 on the XMIT.
> > >
> > > This is the policy map in have inbound on R3's connection to R2.
> > >
> > > class-map match-all EXP4
> > > match mpls experimental topmost 4
> > > !
> > > policy-map IN
> > > class EXP4
> > > set mpls experimental topmost 1
> > >
> > > The policy-map output is incrementing counters correctly. So whilst
> > > the re-marking is working - I don't quite understand why the debug
> > > on R3
> > isn't
> > > consistent with what I subsequently see on R4.
> > >
> > > Any insight would be great. Thanks.
> > >
> > > Con.
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > ____________________________________________________________________
> > > ___ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > ______________________________________________________________________
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Pavel Bykov
> -------------------------------------------------
> Stop the braindumps!
> http://www.stopbraindumps.com/
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:31 ARST