OER/PfR Profile/Learn Phase

[alex_ciobanu]

Hello,

In the first phase of OER, the MC is learning  the traffic classes, and according to Cisco documentation, it can learn  them manually or automatically.

1. If automatic  learning is enabled by default, what would be the reason to define them  manually ? Maybe I am missing something, but once the traffic will  arrive to the defined interfaces, it will be learned anyway  automatically.

2. If we define for automatically learning of the traffic-classes  by protocols and port, all other protocols that were not defined within  the " protocol           {protocol-number | tcp | udp} [port port-number | gt port-number | lt port-number   range  lower-number upper-number][dst | src]" will be ignored ? If not, again, what is the use/purpose of this command ?

3.  If you create an access-list to to specify a filter for automatically  learned application traffic, all other traffic that is not matched by  this access-list will be ignored ?

4. When defining an  oer-map, is it mandatory to use the 'policy-rules' command in the oer  master configuration to 'call' the oer-map ?

Thanks in advance !

[smehrnia]

Hi Alex,

Automatic learning occures on the BR, happening on a interval and for a defined period of time, manual config is set on the Master Controller. auto learning process uses Netflow top talkers feature to define 100 top flows based on defined criterias (default: Throughput n Delay). so, despite this 100 limit in the MTC table, u may want to manully insert your desired prefix in OER process.

The Protocol command is used to tell the MC (master controller) to learn application traffic classes and aggregate them.

this will filter the prefix info based on the port # and only aggregate the flows matching our config.

yes, it is mandatory to use policy-rules command to actually call oer-map. it is like using route-maps.

plz Rate if it helped.

Soroush.

[olugbengaoyebande]

Alex,

1. Automatic Learning is not enable by default. To enable automatic learning you need to enable either traffic class parameter delay or throughput monitoring within the oer top talker top delay learning config mode. You could also enable learning for a configured traffic-class within an oer-map.

Reasons to define prefixes manually in addition to learned traffic include:

a. You may not have any live traffic to trigger learning of target prefix at setup time. So you configure the prefix manually.

b. You know the prefixes and application traffic you want oto optimize so you configure them manually. Why learn them?

c. When you want to override the default policy for specific application and/or prefix you can manually define prefix in oer-map and apply a customized policy to the prefix. Eg. you may want to assign an active jitter probe a forced target prefix to monitor your voice traffic only and optimize only voice traffic in fast-fail-over mode. You may also want to set a higher frequency for only voice probes. Though this can also be done by importing the required force-target into oer-map using learn-list. You will need to configure the traffic-class parameter that define your voice traffic-class as a subset of your traffic.

d. You may want to minimize your monitored traffic class list (MTC list) by manually configuring prefixes to be monitored. The larger the MTC, the more memory/CPU consumption of OER. That is why, when learning is enabled , prefixes learnt are aggregated to /24 by default. Aggregation is another way to minimize your MTC list in OER. It does this by 'sort of' summarizing the MTC prefixes. You can also specify number of prefixes you want to learn per cycle/total.

e. Learning can take time to verify/troubleshoot, because of the cycles.

Really you may not want to learn when your are under pressure unless you are explicitly told to do so.

2.Yes, you can use this command to exclude uninteresting traffic from your automatically generated MTC list. The difference btw the protocol command and the traffic-class filter command is that the later works with acess-lists and accepts prefixes within the access-list and also accepts DSCP specification.

USE/PURPOSE OF "PROTOCOL" COMMAND

Streamline your Optimized traffic to important/interesting traffic.

Save Router CPU resources by streamlining MTC list  and optimized traffic classes.

Save Router Memory resources by streamlining MTC list and optimized traffic classes.

Do all the above in a dynamic automated learning environment.

3. Yes, this is correct.

4.Correct, per say, though the term 'apply' is more appropriate than 'call'.

[alex_ciobanu]

Thanks Olugbenga, again