From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Aug 02 2007 - 01:34:40 ART
In 12.2 mainline and before you were able to policy route
locally generated routing protocol traffic, but they changed the
behavior probably due to TAC cases. It was an interesting situation
because you'd see the routing process say that it was sending traffic to
the interface but then the policy would intercept it and it would
actually be sent out a different interface or dropped altogether. They
probably thought "why would you ever want to policy route your local
routing protocol traffic other than ridiculous CCIE questions?" ;)
Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Antonio Soares
Sent: Wednesday, August 01, 2007 7:44 PM
To: 'Scott Morris'; 'Mohmmad, Imran'; 'Djerk Geurts';
ccielab@groupstudy.com
Subject: RE: OSPF ACL
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
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART