Splitting my traffic

[mmegale]

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.

[paolo bevilacqua]

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.

[mmegale]

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??

[paolo bevilacqua]

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.

[Joseph W. Doherty]

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.

[mmegale]

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.

[mmegale]

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?

[paolo bevilacqua]

No it is not, for the reasons mentioned above.

[Joseph W. Doherty]

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.

[mmegale]

              "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.

[Joseph W. Doherty]

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.