Go CCIE Go!! - A Cisco Certified Internetwork Expert

Yes, i confirm that behavior. I still don’t know why this is happening. It’s not the Bug i mentioned, must be something else. Basically we can say that “match mpls experimental topmost” does not work when “debug mpls packets” is enabled. This on a 3725 running 12.4M (i tried 12.4.23 and the problem is the same).
Regards,
Antonio Soares, CCIE #18473 (R&S) amsoares@netcabo.pt
—–Original Message—– From: Rich Collins [mailto:nilsi2002@gmail.com] Sent: quinta-feira, 20 de Novembro de 2008 22:49 To: Antonio Soares Cc: Pavel Bykov; Con Spathas; ccielab@groupstudy.com Subject: Re: MPLS EXP remarking
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 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 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 > > > >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