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
p.bevilacqua wrote:
JosephDoherty wrote:
Yes it does.
Very good and it would be great if you could add some details, for example how it deals with flows that quickly change their bandwitdh, how it prever out of order arrival when it moves flows from one link to another on changing conditions - assuming it does, and how it manages to balance traffic if it does not. Without using proven tecniques of chapping and reassembling ala ATM IMA or MLPPP.
Also which information you get in real time about flow, excellent would be some demonstrating "screenshot" taken from your real life experience of course.
Yes it would be great to provide all the details and real-life "screenshot"s, but such is akin to asking same about production experience using a dynamic routing protocol and providing "screenshots" of something like routing database.
However, I think I can manage to answer some of your explict questions.
how it deals with flows that quickly change their bandwitdh
It doesn't, nor do you really want it to.
how it prever out of order arrival when it moves flows from one link to another on changing conditions
It doesn't per-se, it changes a route or changes PBR and that change migrates the flow. (And yes, it does move flows.)
Also which information you get in real time about flow,
You don't get much real-time information about a flow, it does accumulate its own stats, which you can "show", and it also can optionally throw syslog messages about what it's doing. The PfR version can also throw stats to an external collector, somewhat akin to a Netflow stats collector, but at the time I was using OER/PfR, the collecter was 3rd party and didn't have it.
proven tecniques of chapping and reassembling ala ATM IMA or MLPPP.
Yes they are, but OER/PfR can do so much, much more. If fact, in the case where I used it, OER/PfR was often using ATM IMA or MLPPP links, which was great for increasing bandwidth across one logical WAN link, but doesn't balance across multiple routers (each with IMA or MLPPP). We already had pretty effective static load balancing across routers, whether via dynamic equal cost routing, GLBP, or even custom mHSRP, so much so OER/PfR was NOT implemented for link load balancing. Why it was implemented was to deal with WAN cloud egress congestion and/or WAN cloud brown outs or WAN cloud black holes. OER/PfR can do this because it monitor's flows using Netflow and optionally IP SLA (both activated depending on OER/PfR configuration).
In actual production usage, the biggest (initial) complainer was the engineer doing network performance monitoring, using explicit IP SLA,s because OER/PfR made most WAN network performance issues disappear.
PS:
I might add, don't recall I hit any major problems with the technology itself. The engineer doing network statistics collection did run into an issue because of OER/PfR running Netflow. Recall something about he was getting "doubled" stats. Also don't recall whether it was finally considered a bug in OER/PfR or the collector we were using.
Although the technology, for me, worked, doesn't mean we didn't have some issues dealing using this technology. These were the type of issues like where Cisco will note using an ACL will increase CPU load, but they don't document by how much. Likewise, depending on your platform and traffic going through the box, being too granular on some OER/PfR features will overtax the box.
