I enjoyed Petr’s article regarding explicit next hop. It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.
Here is the topology for the scenario:
Here is the relevant (and working
) information for R1.
When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3
When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.
Can you solve this puzzle? Please post your ideas!
For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.
Here is the topology for the scenario:
Here is the relevant (and working
) information for R1.When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3
When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.
Can you solve this puzzle? Please post your ideas!
For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.
