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 _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
