Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAHello everyone,I am building an enterprise network in Cisco Packet Tracer 8.2.2.0400 and I encountered a repeatable issue when enabling OSPF directly on GRE tunnel interfaces.The GRE tunnels are operational and their destination addresses are reachable through the ISP underlay. I also explicitly configured static routes to the GRE destination networks so that the forwarding path to each tunnel endpoint is deterministic and cannot accidentally resolve through the GRE overlay. However, as soon as OSPF is enabled on the GRE tunnel interfaces, the tunnels repeatedly enter a recursive-routing state and are temporarily disabled.Removing OSPF from the GRE tunnel interfaces immediately stops the behavior.I am trying to determine whether this is a Packet Tracer limitation/bug, an IOS behavior being simulated by Packet Tracer, or a configuration issue in the topology.1. Topology and addressing--------------------------The topology has two enterprise sites, each with two CE routers, connected through an ISP. There are two GRE tunnels providing an overlay between the sites:- CE1 <-> CE4: Tunnel0, 192.168.14.0/30- CE2 <-> CE3: Tunnel0, 192.168.23.0/30GRE endpoints:CE1:Tunnel0: 192.168.14.1/30Source: GigabitEthernet0/2 (11.0.1.1/30)Destination: 11.1.2.1 (CE4)CE4:Tunnel0: 192.168.14.2/30Source: GigabitEthernet0/2 (11.1.2.1/30)Destination: 11.0.1.1 (CE1)CE2:Tunnel0: 192.168.23.1/30Source: GigabitEthernet0/2 (11.0.2.1/30)Destination: 11.1.1.1 (CE3)CE3:Tunnel0: 192.168.23.2/30Source: GigabitEthernet0/2 (11.1.1.1/30)Destination: 11.0.2.1 (CE2)2. Underlay reachability and explicit static routes to GRE endpoints-------------------------------------------------------------------The CE routers have default routes toward their respective ISP next hops. The GRE tunnel destination addresses are therefore reachable through the ISP underlay.I initially noticed that Packet Tracer's `show ip route <destination>` can report `% Subnet not in table` for a tunnel endpoint even though the destination is reachable through the default route. Because recursive routing is a known cause of GRE tunnel instability, I wanted to eliminate any ambiguity around the forwarding path to the tunnel endpoints.For that reason, I configured explicit static routes to the remote GRE destination networks. I did this for two reasons:1. The exact path selected by the router to reach each GRE tunnel destination is known and can be verified from the routing table.2. The tunnel destination is explicitly forced through the ISP underlay, so it cannot be resolved through a GRE tunnel itself. This removes the usual recursive-routing cause in which the tunnel endpoint is reached via the tunnel that depends on that endpoint.The resulting routing entries are:CE1:CE1#show ip route 11.1.2.1Routing entry for 11.1.2.0/30Known via "static", distance 1, metric 0Routing Descriptor Blocks:* 11.0.1.2Route metric is 0, traffic share count is 1CE2:CE2#show ip route 11.1.1.1Routing entry for 11.1.1.0/30Known via "static", distance 1, metric 0Routing Descriptor Blocks:* 11.0.2.2Route metric is 0, traffic share count is 1CE3:CE3#show ip route 11.0.2.1Routing entry for 11.0.2.0/30Known via "static", distance 1, metric 0Routing Descriptor Blocks:* 11.1.1.2Route metric is 0, traffic share count is 1CE4:CE4#show ip route 11.0.1.1Routing entry for 11.0.1.0/30Known via "static", distance 1, metric 0Routing Descriptor Blocks:* 11.1.2.2Route metric is 0, traffic share count is 1These routes point only toward the ISP-facing next hop, not toward any GRE interface.For example, CE3 resolves the CE2 GRE endpoint as:11.0.2.1 -> 11.1.1.2 -> ISP underlayand CE4 resolves the CE1 GRE endpoint as:11.0.1.1 -> 11.1.2.2 -> ISP underlayThe GRE destination addresses are also successfully reachable with ping before OSPF is enabled on the tunnel interfaces.3. OSPF design--------------The OSPF design uses two areas:- Area 1: Site 1 (CE1/CE2)- Area 2: Site 2 (CE3/CE4)- GRE tunnels: intended to provide the inter-site OSPF adjacency and the Area 0 backbone connectivityThe relevant OSPF configuration before enabling OSPF on the GRE tunnels was:CE1:router ospf 1log-adjacency-changesauto-cost reference-bandwidth 10000network 10.0.0.0 0.0.3.255 area 1network 3.3.3.3 0.0.0.0 area 1default-information originateCE2:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.0.0.0 0.0.15.255 area 1network 4.4.4.4 0.0.0.0 area 1default-information originateCE3:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.1.1.0 0.0.0.3 area 2network 10.1.2.0 0.0.0.3 area 2network 7.7.7.7 0.0.0.0 area 2CE4:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.1.3.0 0.0.0.3 area 2network 8.8.8.8 0.0.0.0 area 2network 10.1.4.0 0.0.0.3 area 2The ISP-facing interfaces are passive in OSPF on CE2/CE3/CE4. Before the test, the GRE tunnel interfaces are not included in the OSPF network statements.4. Behavior before OSPF is enabled on GRE tunnels--------------------------------------------------With OSPF running only on the internal site networks, routing is stable. The GRE tunnels can reach their remote tunnel destination addresses through the ISP underlay.For example, CE3 has:C 11.1.1.0/30 is directly connected, GigabitEthernet0/2L 11.1.1.1/32 is directly connected, GigabitEthernet0/2S 11.0.2.0/30 [1/0] via 11.1.1.2S* 0.0.0.0/0 [1/0] via 11.1.1.2and CE3 can successfully ping the remote GRE endpoint 11.0.2.1.The same underlay reachability exists between CE1 and CE4.5. Problem when OSPF is enabled on the GRE tunnel interfaces--------------------------------------------------------------When I add the GRE tunnel network to OSPF Area 0, the tunnel initially forms an OSPF adjacency and reaches FULL. Immediately afterward, Packet Tracer reports recursive-routing messages and resets the tunnel.For example, on CE3, enabling OSPF on Tunnel0 with:router ospf 1network 192.168.23.0 0.0.0.3 area 0produces messages such as:%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Tunnel0 from LOADING to FULL, Loading Done%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of 0 65E900C0 - looped chain attempting to stack%TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of 0 65E900C0 - looped chain attempting to stack%TUN-5-RECURDOWN: 0 temporarily disabled due to recursive routing%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detachedThe same behavior is reproduced on the CE1/CE4 GRE tunnel.In some cases, the OSPF adjacency repeatedly transitions through LOADING/FULL and then drops when the recursive-routing condition occurs, resulting in repeated adjacency-change messages in the CLI.6. Reproducible isolation test------------------------------The most significant observation is that the recursive-routing messages stop as soon as OSPF is removed from the GRE tunnel interfaces.The behavior is therefore reproducible as follows:OSPF not enabled on GRE interfaces -> GRE tunnels remain stableOSPF enabled on GRE interfaces -> OSPF adjacency reaches FULL, then GRE reports recursive routing and is resetOSPF removed from GRE interfaces -> recursive-routing messages stopThis isolates the triggering change to the activation of OSPF on the GRE overlay interfaces.The attached screenshots document the topology, the routing state, and the CLI output immediately after OSPF is activated on the GRE tunnel interfaces.7. Current OSPF configuration after removing OSPF from GRE-----------------------------------------------------------CE1:router ospf 1log-adjacency-changesauto-cost reference-bandwidth 10000network 10.0.0.0 0.0.3.255 area 1network 3.3.3.3 0.0.0.0 area 1default-information originateCE2:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.0.0.0 0.0.15.255 area 1network 4.4.4.4 0.0.0.0 area 1default-information originateCE3:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.1.1.0 0.0.0.3 area 2network 10.1.2.0 0.0.0.3 area 2network 7.7.7.7 0.0.0.0 area 2CE4:router ospf 1log-adjacency-changespassive-interface GigabitEthernet0/2auto-cost reference-bandwidth 10000network 10.1.3.0 0.0.0.3 area 2network 8.8.8.8 0.0.0.0 area 2network 10.1.4.0 0.0.0.3 area 2With OSPF removed from the tunnel interfaces, the site-local OSPF routing remains stable and the GRE recursive-routing messages disappear. However, this also means the GRE tunnels are no longer being used as OSPF transit interfaces for the intended inter-site OSPF design.I am posting this with the complete topology, configurations, routing information, and CLI output so that the behavior can be evaluated independently. Any insight into the cause, expected behavior, or Packet Tracer limitations would be greatly appreciated.This topology is a simulated lab environment created in Cisco Packet Tracer for learning and testing purposes; it does not represent a real-world production network.Packet Tracer version: 8.2.2.0400
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | IOS firmware for Catalyst 2060c does not load entirely after upgrade | 0 | 6.96 | 06-10-2026 |
| 2 | CCNA Final Lab Challenge + Solution | 0 | 7.78 | 05-10-2026 |
| 3 | SSH Stale idle sessions | 0 | 10.29 | 05-10-2026 |
| 4 | IR1835 SDWAN Controller Mode | 0 | 8.33 | 06-10-2026 |
| 5 | Re: ISE 3.3 Patc 5- user cannot change password if expire | 0 | 22.24 | 05-10-2026 |
| 6 | Re: Can't move MR to Another Network | 0 | 4.52 | 05-10-2026 |
| 7 | Re: ISE 3.3 Patc 5- user cannot change password if expire | 0 | 5.96 | 05-10-2026 |
| 8 | The Compelling Need for AI-Ready ‘Smart Data’ | 0 | 12.56 | 11-08-2026 |
| 9 | How to segment a small office LAN with VLANs on a Catalyst 9300? | 0 | 7.84 | 05-10-2026 |
| 10 | [Updated] JUnit Output Requirements for Smarter Testing | 0 | 6.83 | 11-09-2026 |