From: john matijevic (matijevi@bellsouth.net)
Date: Sat Sep 18 2004 - 21:43:38 GMT-3
Hello Richard,
First of all I haven't repro the issue yet. But from reading the
question the first part of the question is when R6 address(10.60.60.1)
connects to a virtual IP address 10.80.80.12, again this address does
not exist, that the traffic is sent to R2 (10.90.90.1) Then the next
part of the question R1 is to receive traffic from R6 it should see the
source address of 10.8.8.2, so it is the return traffic from R6 not R2.
if you don't have the nat configured the ip address would be 10.60.60.1,
since the question is stating that is the source. Also make sure Richard
that you lab this out and look at the debug on R8, the book also has
this debug listed, I think it may make more sense to you in the lab
debrief.
Sincerely,
John Matijevic, CCIE #13254, MCSE, CNE, CCEA
CEO
IgorTek Inc.
151 Crandon Blvd. #402
Key Biscayne, FL 33149
Hablo Espanol
305-321-6232
http://home.bellsouth.net/p/PWP-CCIE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Richard Dumoulin
Sent: Saturday, September 18, 2004 4:18 PM
To: Richard Dumoulin; Joe Rothstein; ccielab@groupstudy.com
Subject: RE : NAT
For anyone having done the NAT section of lab 3. I think there is an
overconfiguration and the line "ip nat inside source static 10.60.60.1
10.80.80.2" is not needed. This is because when R2 answers, the source
is
10.90.90.1 and the destination 10.80.80.2. So the return traffic goes
directly from R1 to R6 without passing through R8 !!
Anyone confirm ?
John Matijevic, do you agree ?
Thanks
--Richard
-----Message d'origine-----
De : Richard Dumoulin
Envoyi : Saturday, September 18, 2004 9:29 PM
@ : Joe Rothstein; ccielab@groupstudy.com
Objet : NAT
Hi Joe, have you done the NAT section ??
I am still trying to understand how the hell this does work. My problem
is I
always thought we needed an inside and an outside for NAT to work :(
--Richard
-----Message d'origine-----
De : Joe Rothstein [mailto:ziutek@mac.com]
Envoyi : Saturday, September 18, 2004 8:08 PM
@ : ccielab@groupstudy.com
Objet : Re: MQC to filter MIME-types
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.:)
Seems to me that either the mime type or the url will work. But then
again, this is not clear in the documentation.
I also have my doubts about nbar on a subinterface. Any chance of
reconfiguring and trying the config on the physical one?
the more I delve into NBAR, the more questions I have unfortunately.
Joe
On Saturday, Sep 18, 2004, at 19:13 Europe/Berlin, Joseph D. Phillips
wrote:
> If you were asked that on the exam, the config would suffice. I think
> that's what they look for.
>
> Why it wouldn't work is anybody's guess.
>
>
> ----- Original Message ----- From: "Julian Skelley"
> <julian.skelley@itex.je>
> To: "Joseph D. Phillips" <josephdphillips@fastmail.us>
> Cc: "group study" <ccielab@groupstudy.com>
> Sent: Saturday, September 18, 2004 10:09 AM
> Subject: RE: MQC to filter MIME-types
>
>
> Hi Joseph
>
> I tried that as well but it did not seem to work.
>
> Has anyone else see this config in operation?
>
> Thanks
>
> J
>
> This was the actual full interface config:
>
> r6#sh run int f0/0.26
> Building configuration...
>
> Current configuration : 272 bytes
> !
> interface FastEthernet0/0.26
> encapsulation dot1Q 26
> ip address 174.1.26.6 255.255.255.0
> ip accounting precedence input
> ip nbar protocol-discovery
> ip pim sparse-dense-mode
> service-policy input HTTP_OUT
> ip ospf authentication
> ip ospf authentication-key CISCO
> end
>
> -----Original Message-----
> From: Joseph D. Phillips [mailto:josephdphillips@fastmail.us]
> Sent: 18 September 2004 14:44
> To: Julian Skelley
> Cc: group study
> Subject: Re: MQC to filter MIME-types
>
> I didn't see a reference to nbar in your configs.
>
> I think you have to enable nbar protocol discovery under your
> interface(s).
>
> Julian Skelley wrote:
>
>> Hi Joseph
>>
>> I tried this last night with no success, I have set it up as the doc
> suggest but can not seem to "catch" anything with the map.
>>
>> I must have missed something but I am not sure what?!
>>
>> Can anyone help?
>>
>> Thanks
>> J
>>
>> The set up was:
>>
>> WWW_SERVER---174.1.167.x---[r6]---174.1.26.x---BROWSER
>>
>> r6
>> ip cef
>> !
>> class-map match-any PICS
>> match protocol http mime "*jpg"
>> match protocol http mime "*gif"
>> match protocol http mime "*jpeg"
>> !
>> policy-map HTTP_OUT
>> class PICS
>> drop
>> !
>> interface FastEthernet0/0.26
>> encapsulation dot1Q 26
>> ip address 174.1.26.6 255.255.255.0
>> service-policy output HTTP_OUT
>>
>> r6#sh policy-map int f0/0.26
>> FastEthernet0/0.26
>>
>> Service-policy input: HTTP_OUT
>>
>> Class-map: PICS (match-any)
>> 0 packets, 0 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: protocol http mime "*jpg"
>> 0 packets, 0 bytes
>> 5 minute rate 0 bps
>> Match: protocol http mime "*gif"
>> 0 packets, 0 bytes
>> 5 minute rate 0 bps
>> Match: protocol http mime "*jpeg"
>> 0 packets, 0 bytes
>> 5 minute rate 0 bps
>> drop
>>
>> Class-map: class-default (match-any)
>> 5972 packets, 434656 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: any
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
Of
>> Joseph D. Phillips
>> Sent: 17 September 2004 17:52
>> To: group study
>> Subject: MQC to filter MIME-types
>>
>>
>> If you wanted to filter out all picture files from entering an
>> interface, would you have to specify every extension, using MQC? Or
is
>> there a way to filter them all at once?
>>
>> E.g. match protocol http mime "*jpeg"
>> E.g. match protocol http mime "*tiff"
>> E.g. match protocol http mime "*jpg"
>> E.g. match protocol http mime "*gif"
>> E.g. match protocol http mime "*bmp"
>>
>>
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3