From: Sasa Milic (smilic2@pexim.co.yu)
Date: Fri Jul 06 2007 - 04:02:19 ART
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