Hi all,

Thanks for the interesting discussion.

I found that for IGP it is best practice to "PASS" IGP in the direction of
the self zone, say, self-Outside
or vice-versa. No point to "INSPECT" - that doesn't do anything useful.

If you do not have the other direction (no Outside-self) configured, the
incoming IGP packets are
not blocked.  However 12.4(15)T14, which you may encounter in the actual
lab,
ignores IGP packets, and you do not need a PASS action (weird, inconsistent
behaviour of IOS).

What confused me was difference between 12.4(15)T14 and 12.4(24)T3; one
passes multicast IGP
and routing protocols work, the other needs explicit PASS actions. So
confusing.

Case 1: One direction self zone

policy type inspect self-Outside-pmap
  class XXXXX
   inspect
!--- all TCP/UDP/ICMP inspections
!---
  class IGP
   pass
!--- needed for 12.4(24)T3
!--- not needed for 12.4(15)T14
 class class-default
  drop

!---- no Outside-self zone configured
!---  multicast IGP incoming packets are not blocked
!---------------End of Case 1

Case 2: Outside-self zone configured as well

policy-map type inspect Outside-self-pmap
  class YYYYYY
   inspect
!--- all TCP/UDP/ICMP inspections
 class IGP
   pass
!--- MUST for 12.4(24)T3
!--- not needed for 12.4(15)T14
 class class-default
  drop
!---


On Wed, Mar 2, 2011 at 3:30 AM, Bruno <[email protected]> wrote:

> Correct Tyson. That confirms our thoughts
>
> FYI
>
> ---------- Forwarded message ----------
> From: Bruno <[email protected]>
> Date: Tue, Mar 1, 2011 at 12:56 PM
> Subject: Re: [OSL | CCIE_Security] ZBF with self-zones configured: IGPs -
> PASS or INSPECT?
> To: Kingsley Charles <[email protected]>
>
>
> No
> Rack1R3#sh access-l 102
> Extended IP access list 102
>     10 permit ospf any any
>
> After 1h and 10min having a route installed
> O       2.2.2.2 [110/2] via 136.1.23.2, 01:10:11, FastEthernet0/1
>
> I still ain't getting any hits at all
>
> Rack1R3#sh policy-map type inspect zone outside-self
>  Zone-pair: outside-self
>
>   Service-policy inspect : outside-self
>
>     Class-map: outside-self (match-any)
>       Match: protocol tcp
>         0 packets, 0 bytes
>         30 second rate 0 bps
>       Match: protocol udp
>         0 packets, 0 bytes
>         30 second rate 0 bps
>       Match: protocol icmp
>         5 packets, 400 bytes
>         30 second rate 0 bps
>       Inspect
>         Packet inspection statistics [process switch:fast switch]
>         icmp packets: [5:0]
>
>
>         Session creations since subsystem startup or last reset 5
>         Current session counts (estab/half-open/terminating) [0:0:0]
>          Maxever session counts (estab/half-open/terminating) [0:1:0]
>         Last session created 00:57:51
>
>         Last statistic reset never
>         Last session creation rate 0
>         Maxever session creation rate 5
>         Last half-open session total 0
>
>     *Class-map: ospf (match-all)
>       Match: access-group 102
>       Pass
>         0 packets, 0 bytes*
>
>     Class-map: class-default (match-any)
>       Match: any
>       Drop
>         15 packets, 1200 bytes
>
> I think the answers for that would be that either CBAC or ZBF are there for
> TCP/UDP/ICMP only and as soon as they have no capabilities on OSPF and such,
> they do not inspect that in any ways. I am believing in this to answer such
> output
>
>
> On Tue, Mar 1, 2011 at 12:40 PM, Kingsley Charles <
> [email protected]> wrote:
>
>> Is the hit counter for the ospf acl incrementing?
>>
>>
>> With regards
>> Kings
>>
>>
>> On Tue, Mar 1, 2011 at 8:23 PM, Bruno <[email protected]> wrote:
>>
>>> Well, not sure what it means but I lab here and no OSPF packets got
>>> dropped so far
>>>
>>> policy-map type inspect outside-self
>>>  class type inspect outside-self
>>>   inspect
>>>  class type inspect ospf
>>>   pass
>>>
>>> class-map type inspect match-all ospf
>>>  match access-group 102
>>> class-map type inspect match-all outside-self
>>>  match protocol tcp
>>>  match protocol udp
>>>  match protocol icmp
>>>
>>> access-l 102 permit ospf any any
>>>
>>> Neither any packets hit the ACLs
>>>
>>> Rack1R3(config)#do sh policy-map ty ins zone outside-self
>>>  Zone-pair: outside-self
>>>
>>>   Service-policy inspect : outside-self
>>>
>>>     Class-map: outside-self (match-all)
>>>       Match: protocol tcp
>>>       Match: protocol udp
>>>       Match: protocol icmp
>>>       Inspect
>>>         Session creations since subsystem startup or last reset 0
>>>         Current session counts (estab/half-open/terminating) [0:0:0]
>>>         Maxever session counts (estab/half-open/terminating) [0:0:0]
>>>         Last session created never
>>>         Last statistic reset never
>>>         Last session creation rate 0
>>>         Maxever session creation rate 0
>>>         Last half-open session total 0
>>>
>>>     *Class-map: ospf (match-all)
>>>       Match: access-group 102
>>>       Pass
>>>         0 packets, 0 bytes*
>>>
>>>     Class-map: class-default (match-any)
>>>       Match: any
>>>       Drop (default action)
>>>         5 packets, 400 bytes
>>>
>>> Any idea why it did not hit on ACLs. That wou
>>>
>>>
>>> On Tue, Mar 1, 2011 at 11:26 AM, Bruno <[email protected]> wrote:
>>>
>>>> More info about this
>>>> Tried to create a PAM and that`s the message I get
>>>> %Unable to add port-map entry.
>>>>  TCP or UDP protocol must be specified for user-defined applications
>>>>
>>>>
>>>> On Tue, Mar 1, 2011 at 11:24 AM, Bruno <[email protected]> wrote:
>>>>
>>>>> I don't think your suggestion would work King.
>>>>> I think when you go under policy-map to attach a class-map you must
>>>>> have configured at least 1 INSPECT. A class-map with no inspect statement,
>>>>> when attached under policy-map generates this:
>>>>> %No specific protocol configured in class test for inspection. All
>>>>> protocols will be inspected
>>>>>
>>>>> I don't know the answer for the question but would shoot that is not
>>>>> possible as King said
>>>>>
>>>>>
>>>>> On Tue, Mar 1, 2011 at 9:43 AM, Kingsley Charles <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> BGP and RIP which uses TCP and UDP can be inspected. But not sure, if
>>>>>> OSPF and EIGRP which are directly encapsulated in IP can be inspected 
>>>>>> using
>>>>>> their protocol numbers.
>>>>>>
>>>>>> You can configure access-list for ospf/eigrp and associate to the
>>>>>> class map for testing it.
>>>>>>
>>>>>> With regards
>>>>>> Kings
>>>>>>
>>>>>> On Tue, Mar 1, 2011 at 10:42 AM, Richard Chan <[email protected]
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> What is the best practice for allowing IGP traffic
>>>>>>>  when self zones are configured in both directions?
>>>>>>>
>>>>>>> 1. Say you have self-Outside zone and Outside-self zone configured.
>>>>>>>
>>>>>>> 2. For IGPs like OSPF/RIP/EIGRP would you add a PASS action class
>>>>>>> to both zone-pairs? Or do you "inspect" one of them. I don't think of
>>>>>>> IGP peerings as "sessions" in the UDP/TCP sense.
>>>>>>>
>>>>>>>
>>>>>>> !---
>>>>>>> policy-map type inspect XXX-out-self
>>>>>>>  class IGP
>>>>>>>   pass
>>>>>>> !--- apply to Outside-self zone-pair
>>>>>>> !---
>>>>>>> policy-map type inspect XXX-self-out
>>>>>>>  class IGP
>>>>>>>   pass
>>>>>>> !--- apply to self-Outside zone-pair
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> For more information regarding industry leading CCIE Lab training,
>>>>>>> please visit www.ipexpert.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> For more information regarding industry leading CCIE Lab training,
>>>>>> please visit www.ipexpert.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bruno Fagioli (by Jaunty Jackalope)
>>>>> Cisco Security Professional
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bruno Fagioli (by Jaunty Jackalope)
>>>> Cisco Security Professional
>>>>
>>>
>>>
>>>
>>> --
>>> Bruno Fagioli (by Jaunty Jackalope)
>>> Cisco Security Professional
>>>
>>
>>
>
>
> --
> Bruno Fagioli (by Jaunty Jackalope)
> Cisco Security Professional
>
>
>
> --
> Bruno Fagioli (by Jaunty Jackalope)
> Cisco Security Professional
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to