08-31-2007 10:57 PM - edited 03-03-2019 06:33 PM
Hello, without an access list, OSPF works fine. I then tried the following
access-list 100 permit ospf 172.16.16.0 0.0.0.7 host 172.16.16.1
int e0
ip access-group 100 in
With the access list on the interface, OSPF does not work. With it off, OSPF works great.
Am I supposed to add additional rules to the acl? 224.0.0.5, 224.0.0.6 destination addresses coming in on the interface maybe?
08-31-2007 11:23 PM
Replying to my message is a bit silly, but as i look at my syslog (which is still not showing unicast), i see
DENY: 172.16.16.2 -> 224.0.0.5
Looks like i need an entry for "all ospf routers"
08-31-2007 11:39 PM
Hi,
what is the mission objective? You wish to deny OSPF neighbors to form adjacency or what? Please be more specific with your question.
09-01-2007 02:01 AM
Hi,
Yes you need to consider routing protocols in any inbound ACLs, but not with outbound ACLs as outbound ACLs don't affect locally generated traffic.
HTH,
Mohammed Mahmoud.
09-01-2007 05:02 AM
James,
Your access list would work if it was a unicast OSPF packet to host 172.16.16.1 but it's a multicast packet.
You don't even need to specify the source or destination in the access list as multicast packets have a TTL of 1 and thus only OSPF multicast packets local to the subnet will ever arrive in the router.
Reconfigure the access list as follows and try.
access-list 100 permit ospf any any
(or)
access-list 100 permit ospf 172.16.16.0 0.0.0.7 any
HTH
Sundar
09-01-2007 05:38 AM
Hi Sundar,
I totally agree with you about the TTL issue, but i guess that he might be in a situation that he needs to constrain even the local subnet routers that can have OSPF neighborship with the local router.
Rack1R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
155.1.146.4 1 FULL/DR 00:00:30 155.1.146.4 FastEthernet0/0
Rack1R1#sh access-lists 101
Extended IP access list 101
10 permit ospf host 155.1.146.4 host 224.0.0.6 log
20 permit ospf host 155.1.146.4 host 224.0.0.5 log (3 matches)
Rack1R1#
HTH,
Mohammed Mahmoud.
09-01-2007 07:21 AM
Mohammed,
In a broadcast multiaccess segment it can create problems if only select routers become OSPF neighbors. I don't have access to a lab at this time to test and post the results. You might want to try this is your lab and check the outcome.
HTH
Sundar
09-01-2007 02:13 PM
Hi Sundar,
I've tried it in the lab and it seemed fine, can you elaborate more on the problems that should arise, i am really interested.
BR,
Mohammed Mahmoud.
09-04-2007 04:46 PM
Mohammed,
Can you try the following example and check whether R3 puts the route (1.1.1.1/32) in it's routing table. I would expect it shouldn't because the LSA on R3 should show the next hop to get to 1.1.1.1/32 as 172.30.1.11 (R3) which R3 would consider as not reachable because of the ACL. That's a problem that can stem from selective filtering of OSPF neighbors in a multiaccess segment.
R1:
int lo0
ip add 1.1.1.1/32
int e0
ip add 172.30.1.11/24
router bgp 1
neig 172.30.1.12 remote-as 2
net 1.1.1.1 mask 255.255.255.255
R2:
int e0
ip add 172.30.1.12/24
router bgp 2
nei 172.30.1.11 remote-as 1
router ospf 1
net 172.30.1.12 0.0.0.0 area 0
redistribute bgp 2 subnets
R3:
int e0
ip add 172.30.1.13/24
ip access-group ospf in
router ospf 1
net 172.30.1.13 0.0.0.0 area 0
ip access-group ext OSPF in
deny ospf host 172.30.1.11 any
permit ip any any
Let me know what you find.
HTH
Sundar
05-01-2021 09:59 AM
BRAVO!!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: