Blah. I'm looking and looking and i could have sworn that i used to be able to control router traffic that way. The only way possible seems to be your way or through local policy routing if you fake it into thinking it comes from the loopback: http://routerric.blogspot.com/2008/10/acls-and-locally-generated-traffic.html
I read some comments which would back my statement up, apparently local control plane traffic is not subject to local policy routing anymore. http://www.2bccie.com/2011/07/04/acl-basics.html I tested this but i have to look into it some more. I don't think it will work (maybe because of the weird message i got : R4(config-route-map)#set in lo0 %Warning:Use P2P interface for routemap set interface clause Eh? Anyway i would have to somehow make R4 setup the OSPF connection first. Maybe i'll try and do that later. July 4, 2011 at 11:41 pm Locally generated packets are not subject to ACLs applied outbound on an interface. It has to do with the order of operations of the classifier on the interface. You’d see the same result if you said “deny ip any any” in your list. Local policy routing won’t work unless it’s a much older IOS version, as local control plane traffic is not subject to local policy routing anymore. The workaround is simply that you have to apply the ACL in on the other side. On Jul 13, 2011, at 8:14 AM, Di Bias, Steve wrote: > Well you're correct that "ip local policy" is used for router generated > traffic, but the command is really used for policy based routing and probably > won't work in this scenario. Think about it for a second, or better yet lab > it up, that's the only way to truly learn this stuff. Create an ACL, a > route-map, and an ip local policy blocking OSPF and see what happens. > > On the other hand, OSPF is considered control plane traffic, so output CoPP > works great. Let us know your results with ip local policy, I'm interested in > knowing if you can get that working > > //s > > > -----Original Message----- > From: Alef [mailto:[email protected]] > Sent: Tuesday, July 12, 2011 11:46 PM > To: Di Bias, Steve > Cc: marc abel; [email protected] IE > Subject: Re: [OSL | CCIE_RS] allowing ospf in acl > > Oh right. This is local traffic. I keep forgetting that. > > Thanks Marc/Steve. > > That's a cool way of blocking ospf Steve. Although what would happen if i > used ip local policy (can't remember the syntax now) with the acl, that would > work right ? > > On Jul 13, 2011, at 6:12 AM, Di Bias, Steve wrote: > >> Yup, Marc is spot on in that outbound ACL's don't affect router generated >> traffic, hence the reason it isn't being filtered. If you did want to filter >> the routers OSPF traffic (without using passive interface) you can do so by >> using a policy-map on the control plane like this: >> >> R1(config)#router ospf 1 >> R1(config-router)# log-adjacency-changes R1(config-router)# network >> 0.0.0.0 255.255.255.255 area 0 >> >> R2(config)#router ospf 2 >> R2(config-router)# log-adjacency-changes R2(config-router)# netw >> 0.0.0.0 0.0.0.0 area 0 >> >> >> *Jul 13 05:09:10.115: %OSPF-5-ADJCHG: Process 2, Nbr 150.10.1.1 on >> GigabitEthernet0/0 from LOADING to FULL, Loading Done >> >> >> R1(config)#ip access extend acl_no_ospf R1(config-ext-nacl)# permit >> ospf any any R1(config-ext-nacl)#! >> R1(config-ext-nacl)#class-map match-all CM_OSPF R1(config-cmap)# match >> access-group name acl_no_ospf R1(config-cmap)#! >> R1(config-cmap)#policy-map PM_DROP_OSPF R1(config-pmap)# class >> CM_OSPF >> R1(config-pmap-c)# drop >> R1(config-pmap-c)#! >> R1(config-pmap-c)#control-plane >> R1(config-cp)# service-policy output PM_DROP_OSPF >> >> >> R2(config-router)# >> *Jul 13 05:10:21.067: %OSPF-5-ADJCHG: Process 2, Nbr 150.10.1.1 on >> GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired >> >> Now from this point on R1 will show ip in INIT/DROTHER but the adjacency is >> pretty much dead >> >> R2#sh ip ospf neighbor gig0/0 >> <neighbor is gone> >> >> R1(config-cp)#do sh ip o ne fa0/1 >> >> Neighbor ID Pri State Dead Time Address Interface >> 150.246.0.2 1 INIT/DROTHER 00:00:31 150.21.21.2 >> FastEthernet0/1 >> >> >> -----Original Message----- >> From: marc abel [mailto:[email protected]] >> Sent: Tuesday, July 12, 2011 8:27 PM >> To: Alef >> Cc: Di Bias, Steve; [email protected] IE >> Subject: Re: [OSL | CCIE_RS] allowing ospf in acl >> >> The reason you don't have to allow OSPF out, is that you actually can't >> block it outbound with an ACL. Outbound acl's don't block packets generated >> by the router. >> >> Check this out. I have configured OSPF between R1 and R2 >> __________________________________ >> >> R2(config)# do show ip ospf nei >> >> Neighbor ID Pri State Dead Time Address Interface >> 1.1.1.1 1 FULL/DR 00:00:35 10.10.10.1 Ethernet0/0 >> R2(config)#do show run int e0/0 >> Building configuration... >> >> Current configuration : 91 bytes >> ! >> interface Ethernet0/0 >> ip address 10.10.10.2 255.255.255.0 >> ip access-group 101 out >> end >> >> R2(config)#do show access-list 101 >> Extended IP access list 101 >> 10 deny ospf any any >> >> >> The neighbor stays up. >> >> -Marc >> >> On Tue, Jul 12, 2011 at 5:49 PM, Alef <[email protected]> wrote: >>> Hey Steve, >>> Yes, only ospf. It's a lab from one of the Video on demands, i believe Day >>> security lab, can't remember what task. I don't have the sim running right >>> now but the outbound acl permits www, 443 and ssh i think. >>> >>> I just found it curious that you only need it one way. I guess once the tcp >>> session is setup all is exchanged forward within that one session from >>> there on. >>> >>> Alef >>> >>> On Jul 12, 2011, at 11:42 PM, Di Bias, Steve wrote: >>> >>>> That will work, but is OSPF they only thing you want to let in? What does >>>> the outbound ACL (102) look like? What lab are you working on? >>>> >>>> Thank you, >>>> >>>> Steve Di Bias >>>> Network Engineer - Information Systems Valley Health System - Las >>>> Vegas Office - 702- 369-7594 Cell - 702-241-1801 >>>> [email protected] >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[email protected]] On Behalf Of Alef >>>> Sent: Tuesday, July 12, 2011 2:59 PM >>>> To: [email protected] IE >>>> Subject: [OSL | CCIE_RS] allowing ospf in acl >>>> >>>> When you have say r1 and r2 >>>> and you want to only allow ospf in >>>> >>>> would applying this on R1 fa0/0 (assuming this is the connecting interface >>>> to R2) inbound be sufficient? >>>> Extended IP access list 101 >>>> 10 permit ospf any any (4826 matches) >>>> >>>> it seems it is. Do we not need to allow ospf going out as well? In my lab >>>> R1 has acl 102 outbound defined and there is nothing there about ospf. >>>> >>>> Regards, >>>> Alef >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>>> Are you a CCNP or CCIE and looking for a job? Check out >>>> www.PlatinumPlacement.com >>>> >>>> >>>> UHS Confidentiality Notice: This e-mail message, including any >>>> attachments, is for the sole use of the intended recipient (s) and may >>>> contain confidential and privileged information. Any unauthorized review, >>>> use, disclosure or distribution of this information is prohibited. If >>>> this was sent to you in error, please notify the sender by reply e-mail >>>> and destroy all copies of the original message. >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, >>> please visit www.ipexpert.com >>> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> www.PlatinumPlacement.com >>> >> >> >> UHS Confidentiality Notice: This e-mail message, including any attachments, >> is for the sole use of the intended recipient (s) and may contain >> confidential and privileged information. Any unauthorized review, use, >> disclosure or distribution of this information is prohibited. If this was >> sent to you in error, please notify the sender by reply e-mail and destroy >> all copies of the original message. > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient (s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited. If this was > sent to you in error, please notify the sender by reply e-mail and destroy > all copies of the original message. _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
