Hey Saku, happy new year! > From: Saku Ytti <s...@ytti.fi> > Sent: Tuesday, December 31, 2019 2:12 PM > > On Tue, 31 Dec 2019 at 15:59, <adamv0...@netconsultings.com> wrote: > > > I was going to object that this can't possibly be by design cause what if I > have 100 labels on the packet, then I realized that ASR1k's QFP gets the > whole packets not just the first N bytes, so I guess I can see the thought > process like "since we are getting the whole packet we might as well look > into IP header and balance based on what we'll find there". > > Based on context I believe 'this' here means ability to look past labels into > IP > headers. This is the norm, not exception. And it is typically followed by > restriction such as 'up tp 5 labels'. > I thought that what you wrote is obvious from the one liner comment quoted. Nevertheless yes correct that's what I meant, that on majority of the NPUs used in routers there are limits as to how many labels a platform can skip in order to inspect IP header contents and I was going to use this against ASR1k and the hard and fast rule to always look for IP header wondering how could this rule work if there's a limit of say 5 labels and my packet has more -what will the platform do then in terms of load-sharing if it can do such decision based solely on contents of the IP header but can't get those during parsing operation (due to up to 5 labels limit for instance) possibly leading to some kind of exception, however then I realized that QFP used in ASR9k is different in this regard and always has access to all the contents of a packet (very much like a FW NPUs for instance), therefore the "usual" router limits (e.g. lookup up to 5 labels deep) do not apply in case of asr1k so I was playing devil's advocate arguing how I could see ASR1k eng. Falling for this trap . So I guess this is the long version of my thought process summed in that one liner there.
> There is absolutely no way to know for sure what is carried by MPLS, Exactly > so fast > and simple rule of 4/6 is fine, Yes fine as to usually does the right thing, but completely oblivious to any guidance on load-sharing carried by the label stack > as it's the common case to follow MPLS label by > IP header, with implied promise that any other protocol you send does not > start with 4 or 6, i.e. code-word is non-optional if you plan to do any > transit > heuristics, no matter how smart the heuristics is, it is heuristics, not > guarantee. > Hence I'd always prefer transit nodes to use solely the MPLS stack for any clues on how to load-share. As the PE has much better chance of having an un-skewed view on what is or is not part of the same flow therefore my preference is for PEs to record the flow information in the flow stack and having P nodes blindly follow that (i.e. the use of entropy labels). For what it's worth nowadays it could be an application or a controller with true knowledge of what constitutes a flow programming the label stack a PE should impose on a set of packets. And it seems this ASR1k acting as MPLS transit node and using port-channel interfaces, will happily ignore any clues carried by the label stack. > I agree with Lukas that not including labels in balancing hash calculation is > broken behaviour. So do I. I'd have Cisco to update ASR1k documentation also on use of Entropy and Flow labels to put a note there that these features are not supported in combination with port-channels. adam _______________________________________________ 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/
