From: Donghai Zhang (zdh1207@gmail.com)
Date: Fri Aug 03 2007 - 01:43:09 ART
ACL seams not to apply to the router itself, you can help this suject by
doing this. For example, you forbid someone doing sth,but you don't forbid
yourself. So anything you do would not just try on yourself....
2007/8/3, Ben <bmunyao@gmail.com>:
>
> Thanks Antonio
>
> Today i managed to test the ip sla FR feature and it works perfectly. The
> IE
> CWB lab 9 task was broken though (the other end of the pvc was a backbone
> router) so i had to pick another pair of routers.
>
> Regards
> Ben
>
>
> On 8/2/07, Antonio Soares <amsoares@netcabo.pt> wrote:
> >
> > Hello Ben,
> >
> > Here it is:
> >
> > ===================
> > !
> > interface Loopback0
> > ip address 6.6.6.6 255.255.255.0
> > !
> > interface FastEthernet0/0
> > ip address 10.10.10.6 255.255.255.0
> > duplex auto
> > speed auto
> > !
> > router ospf 1
> > router-id 6.6.6.6
> > log-adjacency-changes
> > network 10.10.10.6 0.0.0.0 area 0
> > !
> > ip local policy route-map pbr
> > !
> > !
> > ip http server
> > no ip http secure-server
> > !
> > ip access-list extended ospf
> > permit ospf any any
> > !
> > !
> > route-map pbr permit 10
> > match ip address ospf
> > set interface Loopback0
> > !
> > ===================
> >
> > As Brian McGahan explained, the PBR will not work for Multicast Traffic
> > (i'm running 12.4.12):
> >
> > ===================
> > R6#deb ip policy
> > Policy routing debugging is on
> > R6#deb ip pa det
> > IP packet debugging is on (detailed)
> > R6#
> > *Jul 25 02:06:45.555: IP: s=10.10.10.6 (local), d=224.0.0.5(FastEthernet0/0),
> len 76, sending broad/multicast, proto=89
> > R6#
> > *Jul 25 02:06:55.555: IP: s=10.10.10.6 (local), d=224.0.0.5(FastEthernet0/0),
> len 76, sending broad/multicast, proto=89
> > R6#u all
> > All possible debugging has been turned off
> > R6#
> > ===================
> >
> > Then i changed the config in order to have Unicast Hellos:
> >
> > ===================
> > R6#conf t
> > Enter configuration commands, one per line. End with CNTL/Z.
> > R6(config)#int f0/0
> > R6(config-if)#ip ospf network non-broadcast
> > R6(config-if)#
> > R6(config-if)#
> > R6(config-if)#router ospf 1
> > R6(config-router)#neighbor 10.10.10.1
> > R6(config-router)#end
> > R6#
> >
> > ===================
> >
> > Now PBR is working. The set action here gives us an ICMP "Time to Live
> > exceeded in Transit" message.
> >
> > ===================
> > R6#deb ip pa de
> > IP packet debugging is on (detailed)
> > R6#
> > R6#deb ip policy
> > Policy routing debugging is on
> > R6#
> > *Jul 25 04:56:39.995: IP: s=10.10.10.6 (local), d=10.10.10.1, len 76,
> > policy match, proto=89
> > *Jul 25 04:56:39.995: IP: route map pbr, item 10, permit
> > *Jul 25 04:56:39.995: IP: s=10.10.10.6 (local), d=10.10.10.1(Loopback0),
> > len 76, policy routed, proto=89
> > *Jul 25 04:56:39.995: IP: local to Loopback0 10.10.10.1
> > *Jul 25 04:56:39.995: IP: tableid=0, s=6.6.6.6 (local), d=10.10.10.6(FastEthernet0/0),
> routed via RIB
> > *Jul 25 04:56:39.995: IP: s=6.6.6.6 (local), d=10.10.10.6(FastEthernet0/0),
> len 56, sending
> > *Jul 25 04:56:39.995: ICMP type=11, code=0
> > *Jul 25 04:56:39.995: IP: tableid=0, s=6.6.6.6 (FastEthernet0/0), d=
> > 10.10.10.6 (FastEthernet0/0), routed via RIB
> > R6#
> > *Jul 25 04:56:39.995: IP: s=6.6.6.6 (FastEthernet0/0), d=10.10.10.6(FastEthernet0/0),
> len 56, rcvd 3
> > *Jul 25 04:56:39.995: ICMP type=11, code=0
> > R6#
> > R6#u all
> > All possible debugging has been turned off
> > R6#
> > ===================
> >
> > The NAT option i mentioned before:
> >
> > ===================
> > R6#
> > R6#sh run int f0/0
> > Building configuration...
> >
> > Current configuration : 134 bytes
> > !
> > interface FastEthernet0/0
> > ip address 10.10.10.6 255.255.255.0
> > ip nat outside
> > ip virtual-reassembly
> > duplex auto
> > speed auto
> > end
> >
> > R6#
> > R6#
> > R6#sh runn | inc ip nat
> > ip nat outside
> > ip nat outside source static 99.99.99.99 224.0.0.5
> > R6#
> > ===================
> >
> > Debugs:
> >
> > ===================
> > R6#
> > *Jul 25 05:04:39.647: IP: s=10.10.10.6 (local), d=224.0.0.5(FastEthernet0/0),
> len 76, sending broad/multicast, proto=89
> > *Jul 25 05:04:39.647: NAT: i: ospf (10.10.10.6, 0) -> (224.0.0.5, 0)
> > [421]
> > *Jul 25 05:04:39.647: NAT: s=10.10.10.6, d=224.0.0.5->99.99.99.99 [421]
> > *Jul 25 05:04:39.647: IP: s=10.10.10.6 (local), d=99.99.99.99(FastEthernet0/0),
> len 76, encapsulation failed, proto=89
> > R6#
> > ===================
> >
> > Regards,
> >
> > Antonio Soares
> > CCIE #18473, CCNP, CCIP
> >
> >
> >
> > ------------------------------
> > *From:* Ben [mailto:bmunyao@gmail.com]
> > *Sent:* quinta-feira, 2 de Agosto de 2007 8:59
> > *To:* Antonio Soares
> > *Cc:* Scott Morris; Mohmmad, Imran; Djerk Geurts; ccielab@groupstudy.com
> > *Subject:* Re: OSPF ACL
> >
> > Hi Antonio,
> >
> > Would you kindly give me an example config of the local PBR you used.
> >
> > TIA
> > Ben
> >
> > On 8/2/07, Antonio Soares < amsoares@netcabo.pt> wrote:
> > >
> > > I was testing the "ip local policy" option and i found that it does
> not
> > > work
> > > with traffic sent to multicast addresses. I had to change OSPF network
> > > type
> > > in order to have unicast hellos and then it worked.
> > >
> > > Another option wuold be using NAT and force an "encapsulation failed"
> > > situation.
> > >
> > >
> > > Regards,
> > >
> > > Antonio Soares
> > > CCIE #18473, CCNP, CCIP
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf
> Of
> > > Scott Morris
> > > Sent: quinta-feira, 2 de Agosto de 2007 0:53
> > > To: 'Mohmmad, Imran'; 'Djerk Geurts'; ccielab@groupstudy.com
> > > Subject: RE: OSPF ACL
> > >
> > > Or "ip local policy" PBR.
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf
> Of
> > > Mohmmad, Imran
> > > Sent: Wednesday, August 01, 2007 7:24 PM
> > > To: Djerk Geurts; ccielab@groupstudy.com
> > > Subject: RE: OSPF ACL
> > >
> > > Hi Djerk,
> > >
> > > An outbound access-list does not affect locally generated traffic by
> the
> > > router. This means that traffic the router originates (routing
> protocol
> > > traffic, telnet, ping, etc) will not get evaluated.
> > >
> > > Sometime back I was going through some documentation and I have found
> > > the
> > > following way to block the traffic that is locally generated from the
> > > router
> > > using the service policy.
> > >
> > > R1-------R2
> > >
> > > R1#
> > > class-map match-all DENYOSPFHELLO
> > > match access-group 101
> > > !
> > > !
> > > policy-map DENY-OSPF
> > > class DENYOSPFHELLO
> > > drop
> > >
> > > interface Ethernet1/0
> > > ip address 192.168.1.1 255.255.255.252
> > > half-duplex
> > > service-policy output DENY-OSPF
> > >
> > > router ospf 100
> > > log-adjacency-changes
> > > network 10.10.10.10 0.0.0.0 area 0
> > > network 192.168.1.0 0.0.0.3 area 0
> > > !
> > > ip http server
> > > no ip http secure-server
> > > ip classless
> > > !
> > > !
> > > !
> > > access-list 101 permit ip host 192.168.1.1 host 224.0.0.5
> > >
> > > nash#sh policy-map int et1/0
> > > Ethernet1/0
> > >
> > > Service-policy output: DENY-OSPF
> > >
> > > Class-map: DENYOSPFHELLO (match-all)
> > > 78 packets, 7332 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: access-group 101
> > > drop
> > >
> > > Class-map: class-default (match-any)
> > > 92 packets, 9047 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > >
> > > R1# sh ip os nei
> > > Neighbor ID Pri State Dead Time Address
> > > Interface
> > > 192.168.1.2 1 INIT/DROTHER 00:00:39 192.168.1.2
> > > Ethernet1/0
> > >
> > > R2#
> > > interface Ethernet1/0
> > > ip address 192.168.1.2 255.255.255.252
> > > half-duplex
> > >
> > > R2# sh ip ospf neigh
> > >
> > > R2#debug ip ospf hello
> > > OSPF hello events debugging is on
> > > aus#
> > > *Mar 1 00:33:21.259: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:33: 31.263: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:33:41.267: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:33:51.271: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:34:01.275: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:34:11.279: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:34:21.283: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:34:31.287: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > > *Mar 1 00:34:41.291: OSPF: Send hello to 224.0.0.5 area 0 on
> > > Ethernet1/0
> > > from 1
> > > 92.168.1.2
> > >
> > > Regards,
> > > M mran
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > > Djerk Geurts
> > > Sent: Wednesday, August 01, 2007 3:31 PM
> > > To: ccielab@groupstudy.com
> > > Subject: FW: OSPF ACL
> > >
> > > > -----Original Message-----
> > > > From: Djerk Geurts
> > > >
> > > > No but a "deny ip any any" or "deny ospf any any" should match it
> > > > alright imho...
> > > >
> > > > It seems that ospf circumvents the acl entirely. Which should not be
> > > > surprising as this is known to be a problem in a few other cases as
> > > > well.
> > > >
> > > > I'm trying a service-policy now, but according to a firned of mine
> it
> > > > won't work either. So my only options left are to place and acl on
> the
> > > > switch or configure non-broadcast (which is half a solution as
> > > > mentioned before).
> > > >
> > > > The trouble is afaik an acl will be expected. How is one supposed to
> > > > configure the lab when there's a script which check the configs and
> I
> > > > know it won't read my comment in the interface description as to why
> > > > there's no acl there...
> > > >
> > > > Djerk
> > > >
> > > > > -----Original Message-----
> > > > > From: dayody@googlemail.com [mailto:dayody@googlemail.com] On
> Behalf
> > > > > Of dayo@ademuyiwa.com
> > > > > Sent: woensdag 1 augustus 2007 22:25
> > > > > To: Djerk Geurts
> > > > > Subject: Re: OSPF ACL
> > > > >
> > > > > have you tried it with IP ospf port number?
> > > > >
> > > > > On 8/1/07, Djerk Geurts <djerk.geurts@nl.easynet.net> wrote:
> > > > > > If I want to block hello's from being sent out an interface on
> the
> > >
> > > > > > router itself. Can I use an ACL? I've tried it and it
> > > > > doesn't work...
> > > > > >
> > > > > > IOS: 3640 /w 12.4(8c) or 12.4(7e) IP+
> > > > > >
> > > > > > interface FastEthernet0/0
> > > > > > description *** C3548 F0/3 - VL3 O#3 *** ip address 15.1.3.3
> > > > > > 255.255.255.0 ip access-group NACL-R3-F0/0-OUT out ip ospf 1
> > > > > > area 3
> > > > > >
> > > > > >
> > > > > > R3#sh access-list
> > > > > > Extended IP access list NACL-R3-F0/0-OUT
> > > > > > 10 deny ip any host 224.0.0.5
> > > > > > 20 deny ospf any host 224.0.0.5
> > > > > > 30 deny ospf any any
> > > > > > 40 permit ip any any
> > > > > >
> > > > > > R3#
> > > > > > *Mar 17 00:01:32.891: OSPF: Send hello to 224.0.0.5 area 3 on
> > > > > > FastEthernet0/0 from 152.1.3.3 *Mar 17 00:01:32.891: IP:
> > > > > > s=152.1.3.3 (local), d=224.0.0.5 (FastEthernet0/0), len 76,
> > > > > > sending broad/multicast
> > > > > >
> > > > > > The debug shows that the router generates and sends hellos, the
> > > > > > interface counters increate as do the counters on the
> > > > > attached switch.
> > > > > > So all in all either one can't filter this on the router
> > > > > itself and I
> > > > > > need to config it on the switch. Or, these IOSes are
> > > > broken. Or, I'm
> > > > > > doing something utterly wrong.
> > > > > >
> > > > > > I do have another solution that does work which is to set
> > > > > the network
> > > > > > type to non-broadcast which stops the router from sending
> > > > > hello's but if
> > > > > > another device were to initiate a neighborship the router
> > > > > would respond
> > > > > > resulting in hellos being sent.
> > > > > >
> > > > > > --
> > > > > > Djerk
> > > > > > www.djerk.nl
> > > > > >
> > > > > >
> > > > > ______________________________________________________________
> > > > > _________
> > > > > > 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
> > >
> > >
> _______________________________________________________________________
> > > 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
> > >
> > >
> _______________________________________________________________________
> > > 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
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART