Re: OER Automatic Learning vs Manual Selection (Application

From: Tom Kacprzynski <tom.kac_at_gmail.com>
Date: Sun, 25 Mar 2012 17:24:37 -0500

Brian, thank you for responding to my email. Here is my base config from
the master, please see the rest for what I tried in the lab:

r3#sh run | s oer
oer master
 logging
 !
 border 10.1.123.1 key-chain OER
  interface Serial0/0/0 external
  interface GigabitEthernet0/0 internal
 !
 border 10.1.123.2 key-chain OER
  interface GigabitEthernet0/0 external
  interface GigabitEthernet0/1 internal
 !
 learn
  delay
  periodic-interval 1
  monitor-period 1
  aggregation-type bgp
 delay threshold 20
 mode route control
 !

I tried these four configs in the lab:
1. I used the "protocol tcp port 80" command to learn traffic-class for
http traffic.
2. I tried using an ACL "permit tcp any any eq www" in an oer-map and
applied it with the policy-rules.
3. I tried using an ACL with an IP address "permit tcp any 10.1.80.0
0.0.0.255 eq 80" in an oer-map and applied it with the policy-rules command.
4. I tried using learn lists with the acl "permit tcp any 10.1.80.0
0.0.0.255 eq 80".

1. When I tried using the protocol command with port 80, everything worked
well. OER moved traffic to the correct path with lower than 20ms latancy
(in my case it's the next-hop of 10.1.123.2). Since this command can only
aggregate and send the relevant prefixes only (no protocol, port, dscp
info), I can see that the protocol controlling it is BGP without any
specific port numbers.

<CONFIG>
learn
   protocol tcp port 80

<CONFIG>

r3#sh oer mas traffic-class
<...>

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
           Flags State Time CurrBR CurrI/F
Protocol
         PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw
IBw
         ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos
ActLLos
--------------------------------------------------------------------------------
10.1.80.0/24 N defa N N N N
                          *INPOLICY *0 10.1.123.2
Gi0/0 *BGP*
              14 14 0 0 0 0
1 1
               U U 0 0 N N
N N

2. When I tried with the ACL "permit tcp any any eq www" nothing really
worked. Traffic-class was in Default state, meaning OER is not controlling
it. What I did see is a new entry in the output of "show oer master
traffic-class" that was the prefix 0.0.0.0. I'm not sure what that was but
it was setup to match protocol tcp with destination port 80. After further
research I found out in a nicely hidden PfR FAQ
(http://docwiki.cisco.com/wiki/Performance_Routing_FAQs#Q._If_a_traffic_class_is_configured_using_an_ACL_with_.22any_any.22_instead_of_specifying_a_destination_subnet.2C_is_it_supported.3F_For_example.2C_.22access-list_101_permit_tcp_any_any_eq_telnet..22)
which said that "permit tcp any any eq x" can't be use in traffic-class for
automatic learning, since OER won't be able to learn about the default
prefix (0.0.0.0) and won't be able to collect any statistics on it. This
was my answer to the original question. When would you use traffic-class
ACL over the protocol command? You would use traffic-class with an ACL when
you know of a more specific network to match the application, if you don't
just use the protocol command.

<CONFIG>

ip access-list extended HTTP-ACL
 permit tcp any any eq www

oer-map HTTP-MAP 10
 match traffic-class access-list HTTP-ACL

oer master
 policy-rules HTTP-MAP

<CONFIG>

r3#SH OER MAS TRAFfic-class
<..>

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
           Flags State Time CurrBR CurrI/F
Protocol
         PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw
IBw
         ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos
ActLLos
--------------------------------------------------------------------------------
0.0.0.0/0 N defa tcp *1-65535 80-80* 0.0.0.0/0
                          *DEFAULT** 136 10.1.123.2
Gi0/0 U

10.1.80.0/24 N defa N N N N
                          *DEFAULT** @8 10.1.123.1
Se0/0/0 U
               U U 0 0 0 0
1 1
               U U 0 0 N N
N N

3. Next, I tried adding an IP address to the ACL. Which seems to have
worked, traffic class was INPOLICY, controlled by OER setting the next hop
to 10.1.123.2. This time there was no 0.0.0.0 prefix in the output of "show
oer master traffic-class" but rather the actual prefix list of the
destination. I notices that the prefix by itself was also controlled by OER
and the HTTP application by PBR.

<CONFIG>
ip access-list extended HTTP-ACL
 permit tcp any *10.1.80.0 0.0.0.255* eq 80
oer-map HTTP-MAP 10
 match traffic-class access-list HTTP-ACL

oer master
 policy-rules HTTP-MAP

<CONFIG>

r3#sh oer master traffic-class
<..>

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
           Flags State Time CurrBR CurrI/F
Protocol
         PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw
IBw
         ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos
ActLLos
--------------------------------------------------------------------------------
10.1.80.0/24 N defa N N N N
                          *INPOLICY *0 10.1.123.2
Gi0/0 *BGP*
               U U 0 0 0 0
1 1
               U U 0 0 N N
N N

10.1.80.0/24 N defa tcp *1-65535 80-80* 0.0.0.0/0
                          *INPOLICY *0 10.1.123.2
Gi0/0 *PBR*
              15 15 0 0 0 0
1 1
               U U 0 0 N N
N N

4. The last thing I tried, per you recommendation, was to use learn lists.
I'm not sure if I configured it correctly, but I don't think I got that
working with the ACL. Output of show oer master traffic-class showed me
that prefix 10.1.80.0 was INPOLICY but it was the whole prefix and not the
application tcp 80.

<CONFIG>
 learn
  delay
  periodic-interval 1
  monitor-period 1
  aggregation-type bgp
  *list seq 10 refname HTTP-LST**
   traffic-class access-list HTTP-ACL
   aggregation-type bgp
   delay*
 mode route control

ip access-list extended HTTP-ACL
 permit tcp any 10.1.80.0 0.0.0.255 eq www

<CONFIG>

r3#SH OER MASter TRAFfic-class
<..>

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
           Flags State Time CurrBR CurrI/F
Protocol
         PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw
IBw
         ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos
ActLLos
--------------------------------------------------------------------------------
10.1.80.0/24 N defa N N N N
                          *INPOLICY *0 10.1.123.2
Gi0/0 *BGP*
              15 14 0 0 0 0
1 1
               U U 0 0 N N
N N

Apologies for the long response, I wanted to make sure nothing is missing.
OER/PfR is a very in depth topic. I'm very surprised Cisco on the blue
print says you have to know this topic without any specifics. The problem
is that it's a technology that still being developed and new features added
with different IOS version. For example, learn lists, were only added in
12.4(15)T, it's not covered very well in the 12.4 T OER Configuration
Guide, just mentioned, and are we suppose to know it for the CCIE lab? I
agree with you that this is a very interesting technology and useful
technology, but in my opinion it lacks implementations in enterprise
networks cause of the initial complexity used to set it up.

Thanks again for your help.

Tom

On Sat, Mar 24, 2012 at 3:01 AM, Brian Dennis <bdennis_at_ine.com> wrote:

> Have you tried to lab this up and look at the difference with what traffic
> classes are learned by the MC (show oer master traffic-class)? Without
> seeing the rest of your configuration it's hard to know what will or won't
> happen. Post the full configuration if you have one as commands like route
> control being left to observe under "oer master" but control under the
> "oer-map" makes a difference in what happens.
>
> Personally I would match a learn list over matching an access-list under
> the oer-map. Test out your two options and then switch it to a learn list
> and you'll see why a learn list is better for optimizing traffic based upon
> a port. The output of the show oer master traffic-class command will be
> totally different with the three options and depending on your learn
> configuration, your oer-map option will not have any effect on the HTTP
> traffic at all. If you lab it up and still have questions I can post where
> you would use the two options you listed below along with why a learn list
> is a better option in most situations.
>
> OER/PfR can be really complicated to say the very least and it's hard to
> make general assumptions without knowing your full configuration.
>
> As a side the documentation for OER/PfR is 30% larger than OSPF and will
> only get bigger when QOS and PfR domains are added in sometime in IOS 15.
> PfR might also undergo a name change again soon (OER->PfR->???).
> Personally I love that Cisco is covering OER in the lab as it's a very
> useful feature but I think it's kicking candidate's butts since it's such a
> new feature ;-)
>
> --
> Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/**Voice)
> bdennis_at_ine.com
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
>
> On 03/23/2012 10:20 PM, Tom Kacprzynski wrote:
>
>> My question is what is the biggest advantage of configuring manual
>> selection of application classes vs automatic learning where you specify
>> protocol and port numbers? Are you doing pretty much the same thing?
>> For example:
>>
>> oer master
>> learn
>> delay
>> protocol tcp port 80
>>
>> vs
>>
>> ip access-list extended HTTP
>> permit tcp any any 80
>>
>> oer-map POLICY
>> match ip address access-list HTTP
>>
>> oer master
>> policy-rules POLICY
>>
>> In that example why would you pick one method over the other? Isn't it
>> doing the same thing?
>>
>> Thank for any input.
>>
>>
>> Tom
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> ______________________________**______________________________**
>> ___________
>> Subscription information may be found at:
>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________**______________________________**
> ___________
> Subscription information may be found at: http://www.groupstudy.com/**
> list/CCIELab.html <http://www.groupstudy.com/list/CCIELab.html>

Blogs and organic groups at http://www.ccie.net
Received on Sun Mar 25 2012 - 17:24:37 ART

This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART