Sure. See attached. It's from a bastardised lab and to be honest, I have
seen this in multiple scenarios on the same routers, in different labs,
so I am suspecting a bug of some kind.

All 3 routers are running 12.2(31)SB11 SP train. I haven't tried an
alternative IOS yet.


--Dan 

> -----Original Message-----
> From: Rick Mur [mailto:[email protected]]
> Sent: 10 November 2009 20:21
> To: Daniel Holme
> Cc: [email protected]
> Subject: Re: [OSL | CCIE_SP] Cell-mode ATM label stack
> 
> Would you share your configuration on the 2 routers? It may get easier
> to debug.
> All seems fine and labels/vc's are allocated. Have you tried reloading
> the routers?
> 
> 
> 
> --
> Regards,
> 
> Rick Mur
> CCIE2 #21946 (R&S / Service Provider)
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
> 
> On 10 nov 2009, at 18:57, Daniel Holme wrote:
> 
> > Hi
> >
> > R9 -- ATM1 -- R1
> > (both links are cell-mode MPLS)
> >
> > I've got a weird problem in the lab where I can see LSP created
> > across the ATM links and I can ping R1 loopback to R9 loopback no
> > problems, and beyond, all labelled through LDP/OSPF. I can see the
> > bindings are correct for this in ATM1 and the VCI/VPI looks okay
too:
> >
> > Rack1R9(config-vrf)#do sh mpls for  44.44.44.1
> > Local  Outgoing      Prefix            Bytes Label   Outgoing   Next
> > Hop
> > Label  Label or VC   or Tunnel Id      Switched      interface
> > 18     1/33          44.44.44.1/32     0             AT3/0.1
> > point2point
> >
> > CellModeATM#sh mpls atm-ldp binding 44.44.44.1 32
> > Destination: 44.44.44.1/32
> >    Headend Router ATM1/0.1 (1 hop) 1/33  Active, VCD=60
> >    Tailend Router ATM3/0.1 1/33 Active, VCD=102
> >
> > The problem is when I try to add a label to the stack. If I
> > provision a VPN in BGP and create loopbacks in this VPN on R1 and R9
> > and ping between them with no joy.
> >
> > When I come to debug I see weird label values in the FIB:
> >
> > Rack1R1#sh ip cef vrf VPN_A 10.44.9.9 det
> > 10.44.9.9/32, epoch 0
> >  recursive via 44.44.44.9 label 31
> >    nexthop 150.1.101.254 ATM3/0.1 label 65569
> >
> > Rack1R9#sh ip cef vrf VPN_A 100.100.100.1 det
> > 100.100.100.1/32, epoch 0
> >  recursive via 44.44.44.1 label 31
> >    nexthop 150.1.109.254 ATM3/0.1 label 65569
> >
> > Do they actually mean anything?
> >
> > Looking at the packets, you do not see the ATM VC in the label value
> > in the packet header (because there is no mechanism to put the
> > values in there), therefore you can not see if there is a problem
> > there:
> >
> > (ATM1)
> > 19:44:06: MPLS turbo: AT3/0.1: rx: Len 112 Stack {0 0 255} {31 0
> > 255} - ipv4 data
> > 19:44:06: MPLS turbo: AT1/0.1: tx: Len 112 Stack {0 0 254} {31 0
> > 255} - ipv4 data
> >
> > On the other end, I see the MPLS packet come in (again with a
> > zero'ed label) but then I do not see the IP packet materialise in a
> > 'debug ip packet'...
> >
> > (R1)
> > 19:45:39: MPLS turbo: AT3/0.1: rx: Len 112 Stack {0 0 254} {31 0
> > 255} - ipv4 data
> >
> > Normally in a frame-mode environment I would be able to trace the
> > label stacking and look at the stack change as the packets flow
> > through the network. I can't really do that here, other than see
> > that the VPN label does appear to remain. It looks like cell-mode
> > devices do not perform PHP?
> >
> > debug mpls atm-ldp X does not really produce anything helpful.
> >
> > It's almost like the routers are receiving the labelled packets (w/
> > stack) over the ATM interfaces and the not doing anything further
> > with them. However a single label on the packet is okay.
> >
> > Any suggestions on how to troubleshoot this further...
> >
> >
> > (Oh, and congrats Brian Bartik).
> >
> >
> > --
> > Dan Holme
> >
> >
> >
> >
> > This email has been scanned for all viruses.
> >
> > Please consider the environment before printing this email.
> >
> > The content of this email and any attachment is private and may be
> > privileged. If you are not the intended recipient, any use,
> > disclosure, copying or forwarding of this email and/or its
> > attachments is unauthorised. If you have received this email in
> > error please notify the sender by email and delete this message and
> > any attachments immediately. Nothing in this email shall bind the
> > Company or any of its subsidiaries or businesses in any contract or
> > obligation, unless we have specifically agreed to be bound.
> >
> > KCOM Group PLC is a public limited company incorporated in England
> > and Wales, company number 02150618 and whose registered office is at
> > 37 Carr Lane, Hull, HU1 3RE.
> >
> > 118288 - KCOM UK Directory Enquiries. Calls will cost no more than
> > 49p connection + 14p per minute including VAT from a KC or BT
> > landline. Call charges from mobiles and other networks may vary. If
> > you are calling from a mobile you will now receive your requested
> > number via text message. You will not be charged for the text
message.
> >
> > _______________________________________________
> > For more information regarding industry leading CCIE Lab training,
> > please visit www.ipexpert.com

This email has been scanned for all viruses.

Please consider the environment before printing this email.

The content of this email and any attachment is private and may be privileged. 
If you are not the intended recipient, any use, disclosure, copying or 
forwarding of this email and/or its attachments is unauthorised. If you have 
received this email in error please notify the sender by email and delete this 
message and any attachments immediately. Nothing in this email shall bind the 
Company or any of its subsidiaries or businesses in any contract or obligation, 
unless we have specifically agreed to be bound.

KCOM Group PLC is a public limited company incorporated in England and Wales, 
company number 02150618 and whose registered office is at 37 Carr Lane, Hull, 
HU1 3RE.

118288 - KCOM UK Directory Enquiries. Calls will cost no more than 49p 
connection + 14p per minute including VAT from a KC or BT landline. Call 
charges from mobiles and other networks may vary. If you are calling from a 
mobile you will now receive your requested number via text message. You will 
not be charged for the text message.

Attachment: cellmodeatm
Description: cellmodeatm

Attachment: r1
Description: r1

Attachment: r9
Description: r9

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to