I did verfy form a couple of lookup websites and the trace goes through the same path
but cant verify from the remote end have raised a issue with the remote end operation waiting for them to get back to me Nareshchandra Paturi On , naresh reddy <[email protected]> wrote: Hi we don't manage remote end so cant verify the return path this router dosen't hold full bgp table total routes in this box is ~500 prefixes the route being used for this destination is default route form isp M(134368 ): E | 1 FFF 0 0 0 0 0.0.0.0 V(134368 ): 8 | 1 0 0 0 0 0 0.0.0.0 (A:16402 ,P:0,D:0,m:0 ,B:0 ) sh mls cef adjacency entry 16402 detail Index: 16402 smac: 0015.c7a0.8c00, dmac: e8b7.4829.eac0 mtu: 1518, vlan: 1022, dindex: 0x0, l3rw_vld: 1 format: MAC_TCP, flags: 0x2000008408 delta_seq: 0, delta_ack: 0 packets: 174350, bytes: 33339216 Nareshchandra Paturi On Wednesday, February 26, 2014 2:44 PM, Saku Ytti <[email protected]> wrote: On (2014-02-26 06:30 -0800), naresh reddy wrote: > svis are on the 6500 destination is 11 hops away and route is learned from > BGP table Lot of domain to cover here, 11 hops :) Can you verify return path for working and non-working? Are they using same path or different path? Can you verify which direction packet loss is (if you have PC in both directions, it's easy with iperf or so) If you manage the path end-to-end, and if it is 7600/6500 you can try to check path in HW via: sh mls cef lookup DST detail sh mls cef adjacency entry XYZ detail (XYZ from above output A:12345) If you have DFC (in device you showed you don't have), you need to check for ingress card DFC by prepending command with 'module X' -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
