Hi all, This may be interesting for everybody using MPLS-TE and Loadbalancing with ES+ LC.
We use Cisco 7600 with IOS 15.3.1-S2 and the following LCs: Module Part number Series CEF mode 1 RSP720-3C-10GE supervisor CEF 2 76-ES+T-4TG dCEF720 dCEF 3 76-ES+T-4TG dCEF720 dCEF 4 76-ES+T-40G dCEF720 dCEF We set up a MPLS core and because of multiple links between core routers, we have multiple MPLS-TE tunnels and load balancing between each two of them. E.g. Tunnel10301, Outgoing Label 39 and Tunnel10302, Outgoing Label 53 Some days ago I discovered that the imposed label stack on a VC does not show the truth as I compared "sh mpls l2transport vc 2105 detail" which said "Output interface: Tu10301, imposed label stack {39 0 18}" to my packet capture which showed label stack {53 0 18}. Thus the EoMPLS gets transferred on a not supposed tunnel which results in traffic on a different interface. I opened a TAC case and they raised a bug for this, CSCui14755. Now I got the following response: > Here is the situation. Whenever dual path exists to carry the EoMPLS VC, > when it is established, the software will take one of the CEF path to > build the label stack that is displayed under 'show mpls l2 vc ... > detail' but it is possible the hardware will forward the traffic on a > different path based on the load-balancing hashing algorithm. > The problem here is that there is no way with the current code and > hardware for the software to retrieve the hardware information which > could be used to forward the traffic. The developers looked to the code > architecture and it is not possible to modify it. > I even asked if this could be implemented as a new feature (then having > the whole code rewritten) but that still does not seem to be an option. First, I would like to warn everyone of you trusting the "imposed label stack" together with load balancing. Second, I would to know how many of you are affected by this bug which will not be fixed.. Holger _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/