topic Re: Looking explanation on weird OSPF behavior in Routing

<?xml version="1.0" encoding="UTF-8"?> <rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0"> <channel> <title>topic Re: Looking explanation on weird OSPF behavior in Routing</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228598#M406106</link> <description>Since you describe connecting network was a /24, and&nbsp; OSPF routers were not in p2p mode, I'm wondering if the "different" behavior you describe, might also have something to do with which router was DR and which was BDR, which might have changed/swapped between the two instances.&nbsp; (What I'm thinking of, is possibly, BDR is "happy" hearing from a DR, but DR doesn't need to hear from a BDR.&nbsp; I.e. if ACL blocks replies from BDR to DR, all okay, but if BDR cannot hear from DR, it should become DR.) As far as routes disappearing, I agree with Paul that should be due to LS aging out (30 minutes?). In the big scheme of things, whatever the "odd" behavior was you observed, blocking some OSPF routing protocol traffic, between routers, is very likely to cause some issues, and you may have just stumbled across a case OSPF doesn't well handle (as, without a misconfigured ACL, this would be rather unusual to happen in a "normally" working network - unnormal being just some kinds of traffic being blocked in just one direction - sort of a selective bidirectional traffic issue). In other words, other than being curious, about why you had the different observed behaviors, you "know" you had a misapplied ACL, so identifying the specific "cause" of the observed behavior doesn't really help us much.&nbsp; I mean, how would you work around "fixing" or avoiding this problem beyond not misapplying an ACL? I'm guessing you're interesting in the "cause" lies much in "&nbsp;After 35hours, the neighboring was still UP but none of the OSPF routes were announced anymore (causing an incident)..", i.e. it took some time to identify this issue because OSPF neighbor still has adjacency, correct?</description> <pubDate>Mon, 25 Nov 2024 18:17:04 GMT</pubDate> <dc:creator>Joseph W. Doherty</dc:creator> <dc:date>2024-11-25T18:17:04Z</dc:date> <item> <title>Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228189#M406086</link> <description>Hi Everyone,A weird routing behavior happened between 2 routers and I'm looking now at some explanation to understand. We configured OSPF (broadcast) between 2 routers (R1 and R2) with a redistribution of a default route from BGP to OSPF on R1. R2 was advertising as well some routes.For a project, we applied an access-list on R1, on the interface facing R2. This ACL contained, by mistake, the interconnection IP subnet used between R1 and R2 meaning Unicast packets were dropped from R2 to R1. This interconnection subnet should have been excluded from the ACL but that was a mistake. The OSPF neighboring didn't went down because the HELLO packets were sent via Multicast to 224.0.0.5. After 35hours, the neighboring was still UP but none of the OSPF routes were announced anymore (causing an incident).. We performed a shut/no shut on one interface and the OSPF stayed DOWN (due to the ACL dropping the unicast packets). it went UP immediately after removing the ACL and the routes were exchanged.--&gt; We're now trying to understand why the OSPF routes disapeared from the routing table after this huge delay while the OSPF protocol was UP. When I reproduce it in GNS3, all HELLO packets as well as LS_update and LS_Acknowledge (when doing new advertisement) are in Multicast and not in Unicast..Thanks for your help.</description> <pubDate>Sun, 24 Nov 2024 17:15:33 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228189#M406086</guid> <dc:creator>thomas-ravail</dc:creator> <dc:date>2024-11-24T17:15:33Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228192#M406087</link> <description>it depend on your network type <img src="https://community.cisco.com/t5/image/serverpage/image-id/234443i280F2899630D1C74/image-size/large?v=v2&amp;px=999" role="button" title="ospf-network-types-k.jpg" alt="ospf-network-types-k.jpg" /></description> <pubDate>Sun, 24 Nov 2024 17:37:41 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228192#M406087</guid> <dc:creator>MHM Cisco World</dc:creator> <dc:date>2024-11-24T17:37:41Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228198#M406088</link> <description>Can we see the ACL applied? &nbsp;</description> <pubDate>Sun, 24 Nov 2024 18:37:38 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228198#M406088</guid> <dc:creator>balaji.bandi</dc:creator> <dc:date>2024-11-24T18:37:38Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228458#M406099</link> <description>Hi,We are in broadcast mode.</description> <pubDate>Mon, 25 Nov 2024 13:58:47 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228458#M406099</guid> <dc:creator>thomas-ravail</dc:creator> <dc:date>2024-11-25T13:58:47Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228462#M406100</link> <description>Hi,The ACL applied is as follow :deny ip any 192.168.0.0 0.0.255.255 permit ip any anyFor security reason, I changed the subnet IP but this is the same story. In this global /16 DENY, we have the interconnection subnet in /24, configured between both routers.</description> <pubDate>Mon, 25 Nov 2024 14:01:18 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228462#M406100</guid> <dc:creator>thomas-ravail</dc:creator> <dc:date>2024-11-25T14:01:18Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228469#M406101</link> <description>do you use neighbor command under ospf ? can you share&nbsp; show ip ospf inter brief &lt;&lt;- from real network MHM</description> <pubDate>Mon, 25 Nov 2024 14:15:31 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228469#M406101</guid> <dc:creator>MHM Cisco World</dc:creator> <dc:date>2024-11-25T14:15:31Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228575#M406105</link> <description>Hello I believe what you are seeing is correct, the ospf adjacency was formed before any acl was applied, so the initial ip unicast connectivity required for DR/BDR election and adjacency to form wasn't being negated , as/when you've applied the acl and depending how its was applied (egress/ingress or both) and to what side of the peering (DR/BDR)&nbsp; then the MC hellos kept the OSPF adjacency alive and I envisage the routes were eventually withdrawn upon the MAX age of the LSAs being reached due to the acl restriction As/When you've manually torn down the adjacency with the acl still applied then this is when the new adjacency should fail as the rtrs would not be able to complete the DR/BDR election and become stuck exchange/extstart state due the acl restriction of unicast</description> <pubDate>Mon, 25 Nov 2024 17:19:10 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228575#M406105</guid> <dc:creator>paul driver</dc:creator> <dc:date>2024-11-25T17:19:10Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228598#M406106</link> <description>Since you describe connecting network was a /24, and&nbsp; OSPF routers were not in p2p mode, I'm wondering if the "different" behavior you describe, might also have something to do with which router was DR and which was BDR, which might have changed/swapped between the two instances.&nbsp; (What I'm thinking of, is possibly, BDR is "happy" hearing from a DR, but DR doesn't need to hear from a BDR.&nbsp; I.e. if ACL blocks replies from BDR to DR, all okay, but if BDR cannot hear from DR, it should become DR.) As far as routes disappearing, I agree with Paul that should be due to LS aging out (30 minutes?). In the big scheme of things, whatever the "odd" behavior was you observed, blocking some OSPF routing protocol traffic, between routers, is very likely to cause some issues, and you may have just stumbled across a case OSPF doesn't well handle (as, without a misconfigured ACL, this would be rather unusual to happen in a "normally" working network - unnormal being just some kinds of traffic being blocked in just one direction - sort of a selective bidirectional traffic issue). In other words, other than being curious, about why you had the different observed behaviors, you "know" you had a misapplied ACL, so identifying the specific "cause" of the observed behavior doesn't really help us much.&nbsp; I mean, how would you work around "fixing" or avoiding this problem beyond not misapplying an ACL? I'm guessing you're interesting in the "cause" lies much in "&nbsp;After 35hours, the neighboring was still UP but none of the OSPF routes were announced anymore (causing an incident)..", i.e. it took some time to identify this issue because OSPF neighbor still has adjacency, correct?</description> <pubDate>Mon, 25 Nov 2024 18:17:04 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228598#M406106</guid> <dc:creator>Joseph W. Doherty</dc:creator> <dc:date>2024-11-25T18:17:04Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228716#M406108</link> <description>Hi Joseph,Thanks for your answer. You're right, we know how to fix this issue, just exclude the interconnection subnet in the ACL, but not be able to explain completely the incident is frustating..An important information received today : During the incident, on R1 and R2, the OSPF status was UP but R1 was showing these logs:Nov 21 06:14:04.115 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions Nov 21 06:15:04.115 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired Nov 21 06:17:16.242 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions Nov 21 06:18:16.243 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired Nov 21 06:20:22.467 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions Nov 21 06:21:22.467 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired Nov 21 06:23:35.654 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissionsBased on these log outputs, the OSPF neighboring was trying to establish the adjacency but on both side, OSPF status was UP (have been confirmed many times during the incident).&nbsp;</description> <pubDate>Mon, 25 Nov 2024 22:56:00 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228716#M406108</guid> <dc:creator>thomas-ravail</dc:creator> <dc:date>2024-11-25T22:56:00Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228717#M406109</link> <description>Hi Paul,Yes, couldn't agree more with your analysis, but the delay between the time we applied the ACL and the incident is huge (35 hours)..</description> <pubDate>Mon, 25 Nov 2024 22:57:45 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228717#M406109</guid> <dc:creator>thomas-ravail</dc:creator> <dc:date>2024-11-25T22:57:45Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228762#M406110</link> <description>As Paul also mentioned, he expected adjacency to get stuck in exchange/exstart, which appears to be confirmed by your posted log entries. What commands were you using that showed adjacency fully established while those log entries were generated? BTW, possibly the point I was trying to make in my prior reply was unclear.&nbsp; Let's assume your reported behavior is exactly as you describe, and you confirm the behavior was "incorrect", but as the triggering cause was also incorrect, what is the goal?&nbsp; Again, the issue was adjacency appeared to be fully established when it wasn't?&nbsp; If so, it sounds like a potential TAC bug case. You were unable to recreate issue in GNS?</description> <pubDate>Tue, 26 Nov 2024 02:37:37 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228762#M406110</guid> <dc:creator>Joseph W. Doherty</dc:creator> <dc:date>2024-11-26T02:37:37Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228860#M406114</link> <description>Hello <BLOCKQUOTE><HR /><a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1816218">@thomas-ravail</a>&nbsp;wrote: Yes, couldn't agree more with your analysis, but the delay between the time we applied the ACL and the incident is huge (35 hours) Nov 21 06:14:04.115 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions Nov 21 06:15:04.115 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from DOWN to DOWN, Based on these log outputs, the OSPF neighboring was trying to establish the adjacency but on both side, OSPF status was UP (have been confirmed many times during the incident).&nbsp;</BLOCKQUOTE> This suggest the OSPF adjacency had already been lost due to some event (ie: flapping interface etc. ) and its then at that point your routes were withdrawn&nbsp;which would also mean your applied acl wasn鈥檛 as restrictive that is still allowed the LSAs to be refreshed upto the time the ospf adjacency was torn down, At that point the&nbsp;ospf adjacency tried to restablish and got stuck in the exatart state due to unicast restriction of your applied interface acl&nbsp;</description> <pubDate>Tue, 26 Nov 2024 08:27:12 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228860#M406114</guid> <dc:creator>paul driver</dc:creator> <dc:date>2024-11-26T08:27:12Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228905#M406115</link> <description>this LAB all traffic is send as multicast as you also see in your lab&nbsp; and hence even with ACL OUTbound the OSPF is not down but in your real network Peers use unicast for ACK and this drop by ACL OUT&nbsp; this make OSPF retransmit the update it take 5 sec to retransmit and the retry numbers is 1-255&nbsp; after this retry the OSPF know that there is problem and down the OSPF to neighbor&nbsp; and it not 35 hr I think it 0.35 hr&nbsp; MHM <img src="https://community.cisco.com/t5/image/serverpage/image-id/234560i5F6BF539EA5C4437/image-size/large?v=v2&amp;px=999" role="button" title="Screenshot (888).png" alt="Screenshot (888).png" /></description> <pubDate>Tue, 26 Nov 2024 09:56:23 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228905#M406115</guid> <dc:creator>MHM Cisco World</dc:creator> <dc:date>2024-11-26T09:56:23Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228914#M406116</link> <description>Hello&nbsp;<a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1065752">@MHM Cisco World</a>&nbsp; this doesnt show the true issue of the OP. I dont have access to test myself however I envisage you need to: Allow the ospf adjacency to form as such the LSDB to be created and rib table populated with some routes At that point, check the LSDB (lsa age etc...) THEN apply the acl as per OP and check the&nbsp;LSDB again and ospf adjacency, at that point it should NOT fail or drop Lastly clear the ospf process or drop and interface, this should tear down the opsf process and as this point the ospf adjacency should then fail.</description> <pubDate>Tue, 26 Nov 2024 09:38:16 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228914#M406116</guid> <dc:creator>paul driver</dc:creator> <dc:date>2024-11-26T09:38:16Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228915#M406117</link> <description>Apologize&nbsp; your ack about the retransmit need to refresh&nbsp; it down the OSPF after specific retry&nbsp; <A href="https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/119433-technote-ospf-00.pdf" target="_blank">Troubleshoot the &amp;quot;OSPF Neighbor Down: Too Many retransmissions&amp;quot; Error Message</A> MHM</description> <pubDate>Tue, 26 Nov 2024 09:40:30 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228915#M406117</guid> <dc:creator>MHM Cisco World</dc:creator> <dc:date>2024-11-26T09:40:30Z</dc:date> </item> <item> <title>Re: Looking explanation on weird OSPF behavior</title> <link>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228925#M406118</link> <description>Hello <a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1065752">@MHM Cisco World</a>&nbsp; <BLOCKQUOTE><HR /><a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1065752">@MHM Cisco World</a>&nbsp;wrote: your ack about the retransmit need to refresh&nbsp; </BLOCKQUOTE> Not sure what you mean with the above comment I think you are on about the OP showing Nov 21 06:14:04.115 GMT: %OSPF-5-ADJCHG: Process 100, Nbr X.X.X.X on GigabitEthernet0/0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions And then my comment about the&nbsp;applied ACL not being as restrictive so still allowing the LSAs to be refreshed upto the point the ospf adjacency was torn down -&nbsp; If so then my statement is in reference to an already stable ospf adjacency and then having the acl applied thereafter but BEFORE any additional ospf process being cleared at that point I envisaged you would see the above error being logged. </description> <pubDate>Tue, 26 Nov 2024 09:54:38 GMT</pubDate> <guid>https://community.cisco.com/t5/routing/looking-explanation-on-weird-ospf-behavior/m-p/5228925#M406118</guid> <dc:creator>paul driver</dc:creator> <dc:date>2024-11-26T09:54:38Z</dc:date> </item> </channel> </rss>

CINXE.COM

topic Re: Looking explanation on weird OSPF behavior in Routing