From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Sun Sep 19 2004 - 11:58:07 GMT-3
Just common sense says that the client has no way of knowing the type of
the content the server has... and my ethereal did confirm this. :-)
The client can specify type of content it is willing to accept from the
server though...
Scott Morris wrote:
> "both" is referring to the URL information as well as the MIME type.
>
> And previously, I would have agreed with you about the content-type header,
> however when I tested it with my trusty-rusty Ethereal packet capture, the
> only place I saw a reference to the content header stuff and MIME types was
> in the GET information from the client to the server.
>
> RFC 2045 which lays out the MIME stuff doesn't seem to indicate things one
> way or the other... At least not on a quick skimming...
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
> JNCIP, et al.
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> swm@emanon.com/smorris@ipexpert.net
> http://www.ipexpert.net
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Carlos G Mendioroz
> Sent: Sunday, September 19, 2004 10:06 AM
> To: Scott Morris
> Cc: 'Joe Rothstein'; ccielab@groupstudy.com
> Subject: Re: MQC to filter MIME-types
>
> Scott,
> what is "both" referring to in your statement ?
> URL goes from client to server (GET or POST request) But MIME type goes from
> server to client (HTTP Content-Type header)
>
> Problem in the exam is that there is no web server, and it might be the case
> that it is not clear where the server and the clients are regarding to the
> filtering you are asked to perform... good time to resort to your helpful
> proctor :-)
>
> Scott Morris wrote:
>
>
>>It depends on what way you are looking to filter the information....
>>Both of these are designed to be filters going TO the web servers (so,
>>in or out depends on whether you are the client or server system).
>>HTTP GET requests will contain both pieces of information. The
>>responses are simply labeled as "http data".
>>
>>This may have affected the functionality of your filtering!
>>
>>HTH,
>>
>>
>>Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
>>CISSP, JNCIP, et al.
>>IPExpert CCIE Program Manager
>>IPExpert Sr. Technical Instructor
>>swm@emanon.com/smorris@ipexpert.net
>>http://www.ipexpert.net
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>>Of Joe Rothstein
>>Sent: Sunday, September 19, 2004 5:08 AM
>>To: ccielab@groupstudy.com
>>Subject: Re: MQC to filter MIME-types
>>
>>I was just doing some testing with NBAR since I have been frustrated
>>with the documentation, etc., and needed to see for myself how this really
>
> works.
>
>>This config drops the .jpg and .gif files being sent by a web server:
>>
>>class-map match-any HTTP_IMAGES
>> match protocol http url "*.gif"
>> match protocol http url "*.jpg"
>>!
>>!
>> policy-map HTTP_DROP
>> class HTTP_IMAGES
>> drop
>>
>>
>>Applied to fa 0/1:
>>
>>interface FastEthernet0/1
>> ip address 10.60.60.1 255.255.255.248
>> service-policy output HTTP_DROP
>> speed 100
>> full-duplex
>>end
>>
>>
>>I also applied ip nbar protocol-disc on the opposite of the router
>>where traffic was flowing just to verify the flows. But as Marvin said
>>previously, this is NOT needed.
>>
>>I also got this variation to work with no problems:
>>
>> class-map match-any HTTP_IMAGES
>> match protocol http mime "*gif"
>> match protocol http mime "*jpg"
>>!
>>!
>> policy-map HTTP_DROP
>> class HTTP_IMAGES
>> drop
>>
>>
>>So it appears that both of these configurations work with no problems.
>>I wonder if one is preferred over the other.
>>
>>Any comments?
>>
>>Joe
>>
>>
>>
>>
>>On Sunday, Sep 19, 2004, at 02:57 Europe/Berlin, marvin greenlee wrote:
>>
>>
>>
>>>Example showing that matching traffic does NOT need protocol discovery
>>>turned on:
>>>
>>>***Sample policy map to drop telnet, applied inbound on an interface.
>>>
>>>r13(config)#ip cef
>>>r13(config)#class-map telnet
>>>r13(config-cmap)#match protocol telnet r13(config-cmap)#exit
>>>r13(config)#policy-map telnet r13(config-pmap)#class telnet
>>>r13(config-pmap-c)#drop r13(config-pmap-c)#exit r13(config-pmap)#exit
>>>r13(config)#int atm2/0 r13(config)#service-policy input telnet
>>>
>>>***Attempt telnet from another router. Telnet will be unsuccessful
>>>because traffic is being dropped.
>>>
>>>r14#telnet 172.16.2.2
>>>Trying 172.16.2.2 ...
>>>% Connection timed out; remote host not responding
>>>
>>>r14#
>>>
>>>***Remove the policy from the interface.
>>>
>>>r13(config)#int atm2/0
>>>r13(config-if)#no service-policy input telnet
>>>
>>>***Telnet is successful.
>>>
>>>r14#telnet 172.16.2.2
>>>Trying 172.16.2.2 ... Open
>>>
>>>User Access Verification
>>>
>>>Password:
>>>r13#
>>>
>>>
>>>- Marvin Greenlee, CCIE#12237
>>>Network Learning Inc
>>>marvin@ccbootcamp.com
>>>www.ccbootcamp.com (Cisco Training)
>>>
>>>
>>>-----Original Message-----
>>>From: Joe Rothstein [mailto:ziutek@mac.com]
>>>Sent: Saturday, September 18, 2004 11:08 AM
>>>To: ccielab@groupstudy.com
>>>Subject: Re: MQC to filter MIME-types [bcc][faked-from]
>>>Importance: Low
>>>
>>>Just a couple of things.
>>>
>>>It is pretty unclear as to whether the nbar protocol discovery command
>>>is actually needed. I do not think that it is needed. But since you
>>>have it configured, can you do a sh ip nbar discovery (or something
>>>like that, exact syntax escapes me), and see if it actually seeing any
>>>nbar traffic at all? If not, then there is nothing to match.:)
>>>
>>>
>>
>>--
>>There is more to life than increasing its speed. - Mahatma Ghandi
>>
>>
>>Joseph Rothstein
>>Ridlerstr. 32
>>80339 Munich
>>Germany
>>
>>ziutek@mac.com
>>http://www.geocities.com/jozek444
>>http://www.rothstein.no-ip.org/
>>http://waywardgenuses.blogspot.com/
>>http://ziutek.journalspace.com/
>>
>>______________________________________________________________________
>>_ Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>______________________________________________________________________
>>_ Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>
>
> --
> Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3