cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2792
Views
0
Helpful
11
Replies

ospf acl issue

francisco_1
Level 7
Level 7

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

11 Replies 11

danrya
Level 1
Level 1

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

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

i pasted the wrong output

will upload another one soon.

Francisco.

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

any thought?

Francisco.

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

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.

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

Not MTU issue. no restransmission happening!!

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

Francisco.

Try raising/lowering the MTU on both sides.

I had a similar issue because of MTU.

Hello Timor,

if the described ACL is applied inbound DBD packets can be denied if they have an unicast destination.

if it is applied oubound packets locally generated are not blocked by the ACL.

The question is that device behaviour has changed with an IOS upgrade causing a major issue to the network because the ACL had been tuned for the old behaviour.

It is good that cisco TAC has confirmed the change in 12.2(52) IOS.

Hope to help

Giuseppe

I have published a doc https://supportforums.cisco.com/docs/DOC-13359

Francisco.

Getting Started

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: