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
access-list 100 permit ospf 172.16.16.0 0.0.0.7 any
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.
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.
Can you try the following example and check whether R3 puts the route (184.108.40.206/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 220.127.116.11/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.
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...