Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

ospf acl issue

The following ACL is applied inbound on a router interface, ospf is point-to-point and logs below but ospf state stuck EXSTART through the Database descriptor process (i see DBD and we are not SLAVE).!! This is not MTU issue.

access-list 101 permit ospf any host 224.0.0.5 log
access-list 101 permit ospf any host 224.0.0.6 log
access-list 101 deny   ip any any

Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: OSPF: Send DBD to 150.1.1.1 on FastEthernet0/13 seq 0x20F1 opt 0x52 flag 0x7 len 32
*Mar  1 00:33:43.751: OSPF: Retransmitting DBD to 150.1.1.1 on FastEthernet0/13 [3]
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, sending, proto=89
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, output feature, proto=89, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, sending full packet, proto=89
*Mar  1 00:33:43.751: IP: s=192.168.1.1 (FastEthernet0/13), d=192.168.1.2, len 84, access denied, proto=89
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1, len 56, local feature
*Mar  1 00:33:43.751:     ICMP type=3, code=13, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1, len 56, local feature
*Mar  1 00:33:43.751:     ICMP type=3, code=13, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: FIBipv4-packet-proc: route packet from (local) src 192.168.1.2 dst 192.168.1.1
*Mar  1 00:33:43.751: FIBipv4-packet-proc: packet routing succeeded
*Mar  1 00:33:43.751: IP: tableid=0, s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), routed via FIB
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, sending
*Mar  1 00:33:43.751:     ICMP type=3, code=13
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, output feature
*Mar  1 00:33:43.751:     ICMP type=3, code=13, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:43.751: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, sending full packet
*Mar  1 00:33:43.751:     ICMP type=3, code=13pak 4009D6C consumed in input feature , packet consumed, Access List(26), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: OSPF: Send DBD to 150.1.1.1 on FastEthernet0/13 seq 0x20F1 opt 0x52 flag 0x7 len 32
*Mar  1 00:33:48.642: OSPF: Retransmitting DBD to 150.1.1.1 on FastEthernet0/13 [4]
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, sending, proto=89
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, output feature, proto=89, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, sending full packet, proto=89
*Mar  1 00:33:48.642: IP: s=192.168.1.1 (FastEthernet0/13), d=192.168.1.2, len 84, access denied, proto=89
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1, len 56, local feature
*Mar  1 00:33:48.642:     ICMP type=3, code=13, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1, len 56, local feature
*Mar  1 00:33:48.642:     ICMP type=3, code=13, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.642: FIBipv4-packet-proc: route packet from (local) src 192.168.1.2 dst 192.168.1.1
*Mar  1 00:33:48.642: FIBipv4-packet-proc: packet routing succeeded
*Mar  1 00:33:48.642: IP: tableid=0, s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), routed via FIB
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, sending
*Mar  1 00:33:48.642:     ICMP type=3, code=13
*Mar  1 00:33:48.650: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, output feature
*Mar  1 00:33:48.650:     ICMP type=3, code=13, Check hwidb(72), rtype 1, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.650: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 56, sending full packet
*Mar  1 00:33:48.650:     ICMP type=3, code=13pak 4E36040 consumed in input feature , packet consumed, Access List(26), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.986: IP: s=192.168.1.2 (local), d=224.0.0.5 (FastEthernet0/13), len 80, local feature, proto=89, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.994: IP: s=192.168.1.2 (local), d=224.0.0.5 (FastEthernet0/13), len 80, local feature, proto=89, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:48.994: IP: s=192.168.1.2 (local), d=224.0.0.5 (FastEthernet0/13), len 80, sending broad/multicast, proto=89
*Mar  1 00:33:48.994: IP: s=192.168.1.2 (local), d=224.0.0.5 (FastEthernet0/13), len 80, sending full packet, proto=89
*Mar  1 00:33:49.153: IP: s=192.168.1.1 (FastEthernet0/13), d=224.0.0.5, len 80, input feature, proto=89, Access List(26), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:49.153: IP: s=192.168.1.1 (FastEthernet0/13), d=224.0.0.5, len 80, rcvd 0, proto=89pak 4004924 consumed in input feature , packet consumed, MCI Check(63), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:53.163: OSPF: Send DBD to 150.1.1.1 on FastEthernet0/13 seq 0x20F1 opt 0x52 flag 0x7 len 32
*Mar  1 00:33:53.163: OSPF: Retransmitting DBD to 150.1.1.1 on FastEthernet0/13 [5]
*Mar  1 00:33:53.163: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:53.163: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, Local Clustering(8), rtype 0, forus FALSE, sendself FALSE, mtu 0
*Mar  1 00:33:53.163: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, sending, proto=89

  • LAN Switching and Routing
11 REPLIES
Bronze

Re: ospf acl issue

Your debug shows that OSPF is using unicast and not multicast.  So the ACL is blocking the packet:

s=192.168.1.2 (local), d=192.168.1.1

The destination is not multicast, so allowing 224. will not work.

Dan

Hall of Fame Super Silver

Re: ospf acl issue

Hello Francisco,

as noted by other colleague Dan, database packets are exchanged using unicast destination

*Mar  1 00:33:48.642: OSPF: Retransmitting DBD to 150.1.1.1 on FastEthernet0/13 [4]
*Mar  1 00:33:48.642: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/13), len 64, local feature, proto=89, RCLI(7), rtype 0, forus FALSE, sendself FALSE, mtu 0

so the ACL allows hello packets but then may block the DBD packets

Hope to help

Giuseppe

Re: ospf acl issue

i pasted the wrong output

will upload another one soon.

Francisco.

Re: ospf acl issue

This question is related to another one i posted https://supportforums.cisco.com/message/3194029#3194029

any thought?

Francisco.

Hall of Fame Super Silver

Re: ospf acl issue

Hello Francisco,

one of the two behaviours is wrong and only RFC 2328 can say what is correct, if this aspect is clearly specified.on it.

As I guess this can have had a big impact in your network, it would be wise to open a Cisco TAC service request

Hope to help

Giuseppe

Re: ospf acl issue

yes we have had some downtime due to this issue.

Cisco TAC has confirmed the behavior on the code 12.2(52)SE using unicast.

We noticed the issue we upgraded from 12.2(25)SEE to 12.2(52)SE and ospf stuck in "exstart state" and notied ospf packet being blocked by extended ACL. We had this ACL before the upgrade "permit ospf any host 224.0.0.5" applied on the interface used for adjacency. we had to modify the ACL and allowed unicast traffic through before OSPF adjacency worked.

Francsco.

New Member

Re: ospf acl issue

Hi,

I don't think that its an ACL issue but rather a MTU issue.

What is the MTU on both ends?

Do you have any switches in the middle?

Do you have "ip ospf mtu ignore" configured on the intefaces?

BR,

Timor Sherf

Re: ospf acl issue

Not MTU issue. no restransmission happening!!

Also tested by having "ip ospf mtu ignore" in the interface and it does nothing. 

Francisco.

New Member

Re: ospf acl issue

Try raising/lowering the MTU on both sides.

I had a similar issue because of MTU.

1934
Views
0
Helpful
11
Replies
This widget could not be displayed.