On 13 January 2017 at 02:09, James Bensley <[email protected]> wrote:
>> The always correct behaviour is entropy or fat + control-word + no >> peek inside pseudowires and balance on labels. > > Hmm me too it seems, I was not suggesting that the control-word will > fix all your problems, as you said its a flawed approach from the > get-go. +1 for the above method instead. I mentioned it fixes reordering in Cisco EZchip but not on Juniper Trio (Because Trio peeks in pseudowire by default) and that in Trio is may be actively harmful, because it will open up rarer, harder to detect/troubleshoot reordering issues than simple ^4/^6 issue. Considering on the wire we cannot tell a) did I see control-word or XEROX DMAC => if we guess wrong we're subsequently peeking 32bits in wrong position inside the frame, if we happen to find valid IP keys due to bad/good luck, we have very hard to debug problems b) even if we always use control-word, so that operator config ensures platform always makes right guess (i.e. if it's not ^4 or ^6, it's control-word), and we start to peek at correct offset for ethernet, there is no guarantees pseudowire is carrying ethernetII, but due to bad/good luck might have bits in correct offsets which satisfies heurestics that it is indeed ethernetII carrying IP. bottom line is, MPLS does not know, by design, what it is carrying, and adding heuristics will just make problem occur less often, but when it does occur, it will be increasingly hard to troubleshoot. Would customer know to blame the operator, if the network over operator pseudowire works perfectly, then they also implement GRE tunneling (over the operator pseudowire) and after implementing GRE tunneling 1 host starts to experience bad TCP performance. If customer would know to blame the operator, could operator after such explanation believe customer, that it's problem in the network? After all customer admitted everything works just fine for all machines without GRE and even after GRE on all but one machine. If we'd believe it's our fault, would our vendor's TAC be able to help us? -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
