RE: NBAR http matching

From: Antonio Soares (amsoares@netcabo.pt)
Date: Sat Jul 07 2007 - 15:16:52 ART


Hello group,

Still working on this topic. I developed a 3-level service policy and it
works perfectly !!! Even better than i would expect :)

+++++++++++++++++++++++++
Topology:

Web-client (SW1)===R6===Web-Server (SW2)
+++++++++++++++++++++++++
Objective:

- Limit replies from web server to 3Mbps
- Limit replies from specific URL to 2Mbps
- Limit transfer of image file to 1 Mbps
+++++++++++++++++++++++++
!
class-map match-all 1st-level
 match protocol http host "68.68.68.8"
!
class-map match-all 2nd-level
 match protocol http url "/univercd*"
!
class-map match-all 3rd-level
 match protocol http url "*.gif|*.jpg|*.jpeg"
!
!
policy-map 3rd-level
 class 3rd-level
   police 1000000
!
policy-map 2nd-level
 class 2nd-level
   police 2000000
  service-policy 3rd-level
!
policy-map 1st-level
 class 1st-level
   police 3000000
  service-policy 2nd-level
!
+++++++++++++++++++++++++
R6#sh runn int f0/1
Building configuration...

Current configuration : 127 bytes
!
interface FastEthernet0/1
 ip address 68.68.68.6 255.255.255.0
 duplex auto
 speed auto
 service-policy input 1st-level
end

R6#
+++++++++++++++++++++++++
SW1#copy http://68.68.68.8/univercd/config.gif null:
Loading http://68.68.68.8/univercd/config.gif !
2435 bytes copied in 0.025 secs (97400 bytes/sec)
SW1#
+++++++++++++++++++++++++
R6#sh policy-map interface
 FastEthernet0/1

  Service-policy input: 1st-level

    Class-map: 1st-level (match-all)
      8 packets, 3119 bytes <--------------------------- 8 packets matched
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http host "68.68.68.8"
      police:
          cir 3000000 bps, bc 93750 bytes
        conformed 8 packets, 3119 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

      Service-policy : 2nd-level

        Class-map: 2nd-level (match-all)
          8 packets, 3119 bytes <--------------------------- 8 packets
matched
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol http url "/univercd*"
          police:
              cir 2000000 bps, bc 62500 bytes
            conformed 8 packets, 3119 bytes; actions:
              transmit
            exceeded 0 packets, 0 bytes; actions:
              drop
            conformed 0 bps, exceed 0 bps

          Service-policy : 3rd-level

            Class-map: 3rd-level (match-all)
              8 packets, 3119 bytes <--------------------------- 8 packets
matched
              5 minute offered rate 0 bps, drop rate 0 bps
              Match: protocol http url "*.gif|*.jpg|*.jpeg"
              police:
                  cir 1000000 bps, bc 31250 bytes
                conformed 8 packets, 3119 bytes; actions:
                  transmit
                exceeded 0 packets, 0 bytes; actions:
                  drop
                conformed 0 bps, exceed 0 bps

            Class-map: class-default (match-any)
              0 packets, 0 bytes
              5 minute offered rate 0 bps, drop rate 0 bps
              Match: any

        Class-map: class-default (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any

    Class-map: class-default (match-any)
      2 packets, 120 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R6#
+++++++++++++++++++++++++

Thanks,
Antonio

-----Original Message-----
From: Sasa Milic [mailto:smilic2@pexim.co.yu]
Sent: sexta-feira, 6 de Julho de 2007 8:02
To: Antonio Soares; 'Bit Gossip'; 'WorkerBee'; ccielab@groupstudy.com
Cc: 'Cecil Wilson'; 'M S'; malcolm.salmons@gmail.com
Subject: Re: NBAR http matching

It will match server-to-client only if router can see client request and
then match host in server replies. Won't work with asymetric paths. Could be
trick in the lab, take care.

Regards,
  Sasa

----------------------------------
Sasa Milic, CCIE #8635 (R&S), CCSP

----- Original Message -----
From: "Antonio Soares" <amsoares@netcabo.pt>
To: "'Bit Gossip'" <bit.gossip@chello.nl>; "'WorkerBee'"
<ciscobee@gmail.com>; <ccielab@groupstudy.com>
Cc: "'Cecil Wilson'" <Cecil.Wilson@flextronics.com>; "'M S'"
<michaelgstout@hotmail.com>; <malcolm.salmons@gmail.com>
Sent: Thursday, July 05, 2007 10:53 PM
Subject: RE: NBAR http matching

> Yes, we have matches in both directions. I made the same test a few days
> ago
> and posted it in another discussion here at groupstudy. It's good to be
> sure
> about this. It means we can match not only the client queries but also the
> server replies.
>
> -----Original Message-----
> From: Bit Gossip [mailto:bit.gossip@chello.nl]
> Sent: quinta-feira, 5 de Julho de 2007 19:14
> To: WorkerBee; Antonio Soares; ccielab@groupstudy.com
> Cc: Cecil Wilson; M S; malcolm.salmons@gmail.com
> Subject: Re: NBAR http matching
>
> Group,
> I have done a very simple test that proves a behaviour different from what
> the link below describes, at least in the case of URL match:
> the very same service-policy matches client requests if it is configured
> in
> the direction from client -> server the very same service-policy matches
> server responses if it is configured in the direction from server ->
> client
> Please comment, Bit.
>
> SW1 (client 174.1.67.7) ---- R2 (NBAR) -----R3 (server 150.1.3.3)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ SW1
> Rack1SW1#copy http://150.1.3.3/index.html null:
> Loading http://150.1.3.3/index.html !
> 2696 bytes copied in 0.210 secs (12838 bytes/sec) Rack1SW1#
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ R2
>
> class-map match-all NBAR
> match protocol http host "150.1.3.3"
> match protocol http url "index.html"
> !
> policy-map NBAR1
> class NBAR
> !
> interface Multilink23
> service-policy input NBAR1
> service-policy output NBAR1
>
> Rack1R2#show policy-map int mu23
> Multilink23
>
> Service-policy input: NBAR1 <<<<<<<<<< server to client
>
> Class-map: NBAR (match-all)
> 8 packets, 3348 bytes
> 5 minute offered rate 0 bps
> Match: protocol http host "150.1.3.3"
> Match: protocol http url "index.html"
>
> Service-policy output: NBAR1 <<<<<<<<<< client to server
>
> Class-map: NBAR (match-all)
> 16 packets, 839 bytes
> 5 minute offered rate 0 bps
> Match: protocol http host "150.1.3.3"
> Match: protocol http url "index.html"
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ R3
>
> Rack1R3#show debugging
> Generic IP:
> IP packet debugging is on (detailed) for access list 180
>
> This is the capture split per direction: it is clear that the number of
> packets in each direction matches with the counters of the policy-map.
>
> CONCLUSION: the same policy-map matches the packet of a certain http
> session
> in the direction in which it is applied
>
> *Jul 5 19:44:01.977: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 44,
> rcvd 4
> *Jul 5 19:44:01.977: TCP src=11004, dst=80, seq=237677449, ack=0,
> win=4128 SYN
> *Jul 5 19:44:01.989: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:01.989: TCP src=11004, dst=80, seq=237677450,
> ack=508281107, win=4128 ACK
> *Jul 5 19:44:02.001: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len
> 207,
> rcvd 4
> *Jul 5 19:44:02.001: TCP src=11004, dst=80, seq=237677450,
> ack=508281107, win=4128 ACK
> *Jul 5 19:44:02.057: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.057: TCP src=11004, dst=80, seq=237677617,
> ack=508281363, win=3872 ACK
> *Jul 5 19:44:02.073: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.073: TCP src=11004, dst=80, seq=237677617,
> ack=508281407, win=3828 ACK
> *Jul 5 19:44:02.141: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.141: TCP src=11004, dst=80, seq=237677617,
> ack=508281663, win=3572 ACK
> *Jul 5 19:44:02.149: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.149: TCP src=11004, dst=80, seq=237677617,
> ack=508281663, win=4128 ACK
> *Jul 5 19:44:02.149: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.149: TCP src=11004, dst=80, seq=237677617,
> ack=508282199, win=3592 ACK
> *Jul 5 19:44:02.153: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.153: TCP src=11004, dst=80, seq=237677617,
> ack=508282199, win=4128 ACK
> *Jul 5 19:44:02.157: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.157: TCP src=11004, dst=80, seq=237677617,
> ack=508282735, win=3592 ACK
> *Jul 5 19:44:02.157: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.157: TCP src=11004, dst=80, seq=237677617,
> ack=508282735, win=4128 ACK
> *Jul 5 19:44:02.161: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.161: TCP src=11004, dst=80, seq=237677617,
> ack=508283271, win=3592 ACK
> *Jul 5 19:44:02.169: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.169: TCP src=11004, dst=80, seq=237677617,
> ack=508283271, win=4128 ACK
> *Jul 5 19:44:02.169: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.169: TCP src=11004, dst=80, seq=237677617,
> ack=508283807, win=3592 ACK
> *Jul 5 19:44:02.173: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.173: TCP src=11004, dst=80, seq=237677617,
> ack=508283807, win=4128 ACK
> *Jul 5 19:44:02.173: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.173: TCP src=11004, dst=80, seq=237677617,
> ack=508284104, win=4128 ACK
> *Jul 5 19:44:02.173: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.173: TCP src=11004, dst=80, seq=237677617,
> ack=508284104, win=3832 ACK
> *Jul 5 19:44:02.177: IP: s=174.1.67.7 (Multilink23), d=150.1.3.3, len 40,
> rcvd 4
> *Jul 5 19:44:02.177: TCP src=11004, dst=80, seq=237677617,
> ack=508284104, win=3832 ACK PSH FIN
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> *Jul 5 19:44:01.977: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 44, sending
> *Jul 5 19:44:01.977: TCP src=80, dst=11004, seq=508281106,
> ack=237677450, win=4128 ACK SYN
> *Jul 5 19:44:02.045: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 296, sending
> *Jul 5 19:44:02.045: TCP src=80, dst=11004, seq=508281107,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.061: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 84, sending
> *Jul 5 19:44:02.061: TCP src=80, dst=11004, seq=508281363,
> ack=237677617, win=3961 ACK PSH
> *Jul 5 19:44:02.137: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 296, sending
> *Jul 5 19:44:02.137: TCP src=80, dst=11004, seq=508281407,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.137: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 576, sending
> *Jul 5 19:44:02.137: TCP src=80, dst=11004, seq=508281663,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.141: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 576, sending
> *Jul 5 19:44:02.141: TCP src=80, dst=11004, seq=508282199,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.153: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 576, sending
> *Jul 5 19:44:02.153: TCP src=80, dst=11004, seq=508282735,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.153: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 576, sending
> *Jul 5 19:44:02.153: TCP src=80, dst=11004, seq=508283271,
> ack=237677617, win=3961 ACK
> *Jul 5 19:44:02.161: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 336, sending
> *Jul 5 19:44:02.161: TCP src=80, dst=11004, seq=508283807,
> ack=237677617, win=3961 ACK PSH FIN
> *Jul 5 19:44:02.177: IP: s=150.1.3.3 (local), d=174.1.67.7 (Multilink23),
> len 40, sending
> *Jul 5 19:44:02.177: TCP src=80, dst=11004, seq=508284104,
> ack=237677618, win=3961 ACK
>
>
>
> ----- Original Message -----
> From: "WorkerBee" <ciscobee@gmail.com>
> To: "Antonio Soares" <amsoares@netcabo.pt>
> Cc: "Cecil Wilson" <Cecil.Wilson@flextronics.com>; "M S"
> <michaelgstout@hotmail.com>; <malcolm.salmons@gmail.com>;
> <ccielab@groupstudy.com>
> Sent: Friday, June 29, 2007 2:18 AM
> Subject: Re: NBAR http matching
>
>
>> Read this link, it explicitly mentioned the direction flow of the
>> requestor and the position on the nbar router doing the protocol
>> inspection. It is the HTTP response that is being classified.
>>
>> Classification of HTTP Traffic by URL, Host, or MIME
>>
>> http://www.cisco.com/en/US/products/ps6441/products_configuration_guid
>> e_chapter09186a008064fb35.html#wp1055866
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART