Ospf with access-list question

josunin75

Hello to you all Cisco gurus. ^^;;

I have question on debuging with unused access-list??

I was reading the "CCIE Troubleshooting IP routing Protocols" on OSPF
not forming neighboring relationship. and one of the possible reason is due to access-list.

There are two routers directly connected and has loopback 0 to simulate internal
attached network. And access-list to permit all tcp and udp traffice is implemented! The configuration of those two routers are as follows

R2
interface loopback 0
ip address 131.108.0.1 255.255.255.0
!
interface ethernet0
ip address 131.108.1.2 255.255.255.0
ip access-group 100 in
!
access-list 100 permit tcp any any
access-list 100 permit udp any any

access-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5

!
router ospf 1
network 131.108.0.0 0.0.255.255 area 0

and on R1
interface loopback 0
ip address 131.108.2.1 255.255.255.0
!
interface ethernet0
ip address 131.108.1.1 255.255.255.0
ip access-group 100 in
!
access-list 100 permit tcp any any
access-list 100 permit udp any any

access-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5

!
router ospf 1
network 131.108.0.0 0.0.255.255 area 0

I understand that in OSPF, the routers use ALLSPF multicast address of 224.0.0.5 to exchange hello, and since only tcp and udp are allow to come in through ethernet0, the neighborship is not formed.

however, the author uses the access-list 101 to troubleshoot

he does "debug ip packet 101 detail" to find out the problem.

My question here is how is that the author used the access-list 101 to debug?
I thought, if the access-list is not implemented as in "access-group" is not in effect.

Thank you in advance for your help!

jason_lunde

You use the access list to limit the scope of your debug. If you were to perform a regular debug ip packet the results would overwhelming, and would significantly raise the memory and processor utilization on the router or switch. Using the access list you are saying that you only want to debug packets from a source on the network 131.108.1.0/24 destined for a particular multicast address 224.0.0.5. IT is a really good troubleshooting tool. I have actually used varying forms of this debug in production to isolate problems.

josunin75

Cool! Thanks.