05-22-2012 09:48 AM - edited 03-04-2019 04:26 PM
I'm looking for a way to force my traffic between source A and destination B, which is taking a path thru a mesh of routers, to split up (does not have to be evenly) here at my local router and then take multiple paths to destnation B. In this scenario, I want the same session, or the same netflow, to split up and take multiple paths to destination B, where it will be re-ordered and re-assembled. It is similar to the concept of fragmentation/reassembly in the TCP world, but the fragments are sent in different directions and finally all landing at destination B from different directions.
I understand there is a Cisco Per-Packet Load Balancing concept that allows traffic to be load balanced across different paths on a per-packet basis vice a per-destination basis. So I'm pretty sure using Per-Packet Load Balancing is part of the solution, is it not?
How do I do this? And is there a way, either thru policy based routing or EEM scripting or another method, where I can exert some control over how and when and how much I can split this traffic?
Thank you in advance.
05-22-2012 10:05 AM
You may be surprised but that doesn't work so easily.
Short answer: you need to have path of equal speed, and load balancing will happen automatically without any additional configuration. Morever, per-packet load balacing will not help but will just make things worst as it cause out of order packet arrival. Also please note, router do not reassemble and do not re-orderg packets.
If you don't believe my answer (as it is your right), you can go ahead, search and try and experiment, fight the fact and form your informed opinion, please when you're done the full circle come back with your findings.
05-22-2012 10:12 AM
Isn't that the point of TCP, that the final destination (not a router) can re-order the arriving packets based on their sequence numbers, etc. and reassemble it so that it is readable??
05-22-2012 11:14 AM
Yes, but when dealing with out of order packets, performances go to the trashbin.
Again, recommend you do some research on the subject, that is very often raised, before making any assumption on how things could work.
05-22-2012 04:56 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
MATTHEW JOSEPH wrote:
Isn't that the point of TCP, that the final destination (not a router) can re-order the arriving packets based on their sequence numbers, etc. and reassemble it so that it is readable??
Yes it is, but start researching what most TCP "flavors" do/assume when they start to receive duplicate ACKs for out-of-order packets they've sent; especially when the get 3 or more.
05-22-2012 06:44 PM
Wow, I didn't know that. Can you point me to an article, or an example of what you are talking about? Are you hinting that excess re-transmissions might occur, or something like that?
If that is the case, it sort of flies in the face of using per-packet load balancing doesn't it? Even if evenly distributed across equal cost links because unequal hops further down the path can still cause packets to arrive out of sequence.
05-22-2012 07:37 PM
Yep, I do see it now. The client tries to trigger a fast retransmit, and ultimately can result in immediate retransmissions.
But I think my point mentioned in my last update, about per-packet load balancing, is valid, is it not?
05-22-2012 09:57 PM
No it is not, for the reasons mentioned above.
05-23-2012 03:12 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
But I think my point mentioned in my last update, about per-packet load balancing, is valid, is it not?
No, as equal cost links, by default, don't split an individual flow.
BTW, per-packet load balancing, if multiple paths will deliver packets in the same time (e.g. same distance/bandwidth links between network device pair), should only reorder packets if the packets are different sizes. As TCP (ignoring possible fragmentation) would normally size all packets of a flow the same, except the last packet (which should, ideally, only cause one dup ACK), per-packet load balancing might be used. But although IP doesn't guarantee packet sequence, many other non-TCP protocols have come to rely upon packets within a flow not being resequenced, so it's often best to avoid using this feature.
05-23-2012 05:22 AM
"No, as equal cost links, by default, don't split an individual flow."
Just to clarify, even if equal cost links are configured for per-packet load balancing?
"so it's often best to avoid using this feature"
Even thoough it would open up a whole other issue and would not make sense for my application, would it still cause the problem if the IP traffic was all UDP? Just curious from a technical point of view.
You've been a lot of help, thank you. I'm just curious about these last two questions.
05-23-2012 04:43 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
"No, as equal cost links, by default, don't split an individual flow."Just to clarify, even if equal cost links are configured for per-packet load balancing?
Per-packet is not the default, i.e. it would split packets within the same flow.
"so it's often best to avoid using this feature"Even thoough it would open up a whole other issue and would not make sense for my application, would it still cause the problem if the IP traffic was all UDP? Just curious from a technical point of view.
Depends on the non-TCP app. Many assume packet sequence will be, more or less, in sequence.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide